Publiée par NVD le 15 octobre 2026 et analysée depuis, CVE-2026-101307 touche le stack TCP RACK de FreeBSD 15.1. Un pair distant qui a établi une connexion TCP peut, en envoyant suffisamment d'ACK, déclencher une écriture hors limites d'environ 512 Ko dans le tas du noyau.
Pas d'authentification, pas d'interaction : une connexion TCP établie suffit. C'est ce qui rend la faille intéressante pour quiconque expose un service sur un FreeBSD qui utilise RACK.
La vulnérabilité
| Champ | Valeur |
|---|---|
| CVE | CVE-2026-101307 |
| CVSS 3.1 (NVD) | 9.1 (CRITICAL) — AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H |
| CVSS 4.0 (FreeBSD, CNA) | 8.2 (HIGH) — AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H |
| Type | Débordement de tas, écriture hors limites (CWE-122, CWE-787) |
| Composant | stack TCP RACK du noyau |
| Versions (CPE NVD) | FreeBSD 15.1, 15.1-p1 à 15.1-p4 |
| Advisory | FreeBSD-SA-26:70.tcp |
| Publication NVD | 2026-10-15 |
| Statut NVD | Analyzed |
La CVE n'est pas au CISA KEV à la date de rédaction.
Le mécanisme
Le stack RACK conserve un tableau d'échantillons PCM. Quand ce tableau doit grandir, le code double un compteur d'allocation stocké sur 16 bits.
Doubler une valeur 16 bits ne peut se faire qu'un nombre limité de fois : à force de doublements, le compteur revient à zéro. Le noyau alloue alors un tampon de taille quasi nulle, puis y copie les échantillons existants. D'où l'écriture hors limites, d'environ 512 Ko d'après la description.
Et c'est le pair distant qui pilote la croissance du tableau : il lui suffit d'envoyer assez d'ACK sur une connexion établie.
C'est une classe de bug très classique — un dépassement d'entier qui devient un débordement de tampon — mais dans le chemin le plus exposé qui soit : le traitement des segments TCP entrants.
Deux scores, deux lectures
- NVD note la faille 9.1 avec un impact intégrité élevé (
I:H) en plus de la disponibilité : une écriture de 512 Ko dans le tas noyau corrompt des données arbitraires. - FreeBSD, en tant que CNA, ne retient en CVSS 4.0 que la disponibilité (
VA:H, 8.2) et ajouteAT:P(une condition préalable : le stack RACK doit être utilisé).
La description dit « possibly resulting in a kernel panic ». L'issue documentée est donc le plantage de la machine. Une exécution de code n'est pas décrite ; elle ne peut pas être exclue avec une écriture de cette taille, mais rien dans les données publiées ne l'établit.
Qui est concerné
Deux conditions :
- FreeBSD 15.1, jusqu'au niveau de correctif p4 inclus (configurations CPE de NVD) ;
- le stack TCP RACK est utilisé pour les connexions concernées.
FreeBSD permet plusieurs stacks TCP chargeables, et le choix se fait par configuration. Vérifie lequel est actif :
sysctl net.inet.tcp.functions_available
sysctl net.inet.tcp.functions_default
kldstat | grep tcp_rack
Si rack n'apparaît ni comme stack par défaut ni comme stack sélectionné par une application, la machine n'emprunte pas le chemin vulnérable. Les dérivés de FreeBSD (appliances, pare-feu, stockage) qui activent RACK sont à vérifier auprès de leur éditeur.
Correctif
NVD liste les versions 15.1 à 15.1-p4 comme vulnérables, sans indiquer explicitement la version corrigée. Le niveau de correctif à installer et les patchs sources sont dans l'advisory FreeBSD-SA-26:70.tcp.
Sur un système installé en binaire :
freebsd-update fetch
freebsd-update install
shutdown -r now
Le correctif porte sur le noyau : un redémarrage est indispensable.
Détection et mesures en attendant
- Paniques noyau inexpliquées sur des serveurs exposés : consulter
/var/crashet les journaux système. - Connexions avec un volume anormal d'ACK : un pic de trafic ACK sur une seule connexion, sans données correspondantes, est le signal à chercher dans les captures.
- Mesure de contournement possible : revenir au stack TCP par défaut de FreeBSD au lieu de RACK, en modifiant
net.inet.tcp.functions_default, puis redémarrer les services pour que les nouvelles connexions l'utilisent. C'est une déduction à valider avec l'advisory, qui fait foi sur les contournements. - Filtrage : restreindre l'accès aux services qui n'ont pas besoin d'être publics réduit le nombre de pairs capables d'établir une connexion.
Pourquoi surveiller en continu vos systèmes FreeBSD
Une faille du stack TCP ne concerne pas un logiciel installé à côté : elle touche le noyau de chaque serveur, et dépend d'un réglage qu'on oublie vite. Savoir quelles machines tournent en 15.1, et à quel niveau de correctif, est ce qui permet de réagir le jour de l'advisory.
Avec cveo.tech, inventorie tes systèmes FreeBSD avec leur version et reçois une alerte dès qu'une CVE critique les touche.