Nouvelles vulnérabilités FreeBSD

2

Le 30 juin 2026, des notifications ont été publiées concernant la correction de 13 nouvelles vulnérabilités dans le système d'exploitation FreeBSD.

• CVE-2026-49418. Un utilisateur ayant accès à un dispositif avec une interface memory-mapped peut provoquer un double libération / utilisation après libération dans le noyau. Cela pourrait potentiellement entraîner une élévation de privilèges.
• CVE-2026-49419. (uniquement FreeBSD 15+) Double réduction du refcount de la jail actuelle lors du traitement d'une erreur d'accès à une autre jail via des descripteurs de jail (introduit dans FreeBSD 15), entraînant finalement la libération imprévue de la structure de contrôle de la jail et des utilisations après libération partout où elle est utilisée. Théoriquement, cela peut conduire à une élévation de privilèges.
• CVE-2026-49415. Lors de l'exécution d'un programme setuid, les droits d'accès à sa mémoire sont établis légèrement plus tard que l'initialisation de cette mémoire, ce qui permet, pendant une courte période, d'y accéder et de la modifier sans avoir les privilèges nécessaires via procfs ou linprocfs. Dans la plupart des systèmes, procfs, et encore plus libprocfs, ne sont pas montés, donc le problème concerne probablement peu de gens.
• CVE-2026-49429, CVE-2026-49430, CVE-2026-49431. (uniquement pour les systèmes avec ZFS) Les deux premières erreurs sont liées à l'allocation de mémoire de taille incorrecte : un tampon de taille transmise sous la forme d'un nombre 32 bits est alloué et des données de la véritable taille sont ensuite écrites dedans, entraînant un débordement si la taille réelle du tampon était supérieure à 4 Go. Les deux peuvent être provoquées uniquement par root ou par un utilisateur ayant des privilèges explicitement accordés pour effectuer les opérations vulnérables. La troisième erreur est exploitée par n'importe qui, permettant à quiconque d'ajouter le drapeau "$hasrecvd" à un dataset à l'aide de ZFS_IOC_SET_PROP (sans que l'on puisse comprendre à quel point cela est dangereux à partir de l'annonce).
• CVE-2026-49420. L'absence de validation adéquate de la taille du paquet avant son écriture dans un tampon de taille fixe sur la pile dans le module libalias de support RTSP permet la possibilité d'un débordement de la pile ou du noyau (pour ipfw nat) ou du processus natd (qui est généralement exécuté par root) à distance et sans autorisation. Cela peut potentiellement conduire à une exécution de code à distance. La vulnérabilité peut être exploitée par un hôte malveillant à l'intérieur d'un réseau local derrière un NAT, implémenté via libalias, transmettant des paquets RTSP malveillants. Par conséquent, la vulnérabilité n'affecte pas les hôtes sur lesquels le NAT n'est pas exécuté d'une manière ou d'une autre. De plus, natd ne sera plus vulnérable si on supprime la ligne libalias_smedia.so de /etc/libalias.conf et redémarre natd, et ipfw nat ne sera pas vulnérable sans le chargement du module alias_smedia.ko (il n'est pas spécifié s'il peut le charger automatiquement). De plus, le gestionnaire vulnérable ne traite que les paquets TCP/UDP sortants, dont l'un des ports est 554 ou 7070 — si l'on bloque de tels paquets avant qu'ils n'atteignent le NAT, la vulnérabilité disparaît également.
• CVE-2026-49421. unlinkat() et funlinkat() ne prenaient pas en compte le drapeau AT_RESOLVE_BENEATH, qui devait empêcher de sortir du répertoire spécifié par l'argument dirfd lors du passage de ce chemin. Ainsi, cela permettait de supprimer des fichiers en dehors de ce répertoire alors que l'appelant souhaitait imposer cette restriction.
• CVE-2026-49422. Une condition de course dans le module tcp_rack.ko (qui n'est pas chargé par défaut). Chaque socket TCP peut choisir individuellement la pile TCP à travers laquelle il fonctionnera, y compris les basculer à la volée. Si l'on procède ainsi : 1) sur le socket avec tcp_rack, on appelle setsockopt() spécifique au rack, 2) dans un autre thread, on réussit à rapidement basculer la pile TCP de rack à une autre, puis encore une fois vers rack au moment voulu, alors le gestionnaire rack de setsockopt() fonctionnera avec l'ancienne adresse (avant le basculement) de la structure d'état du socket, ce qui entraîne une corruption de mémoire et un possible gain de privilèges. Cela ne concerne que les systèmes où tcp_rack.ko est explicitement chargé, ce qui n'est pas par défaut.
• CVE-2026-49427, CVE-2026-49428. Les grandes pages POSIX (shm_create_largepage) n'étaient pas suffisamment marquées comme utilisées lors de l'allocation, ce qui pouvait conduire à leur libération incorrecte dans diverses circonstances (des appels mentionnés incluent sendfile avec le drapeau SF_NOCACHE, open avec le drapeau O_TRUNC et fspacectl) et ensuite à une utilisation après libération avec des conséquences habituelles.
• CVE-2026-49426. Des journaux audit(4) incorrects concernant des syscalls distants via ptrace(PT_SC_REMOTE). Cela peut embrouiller les systèmes d'analyse des situations suspectes, s'ils sont utilisés.
• CVE-2026-49423. Un possible kernel-panic lors de la réception de données via kTLS impliquant des enregistrements TLS 1.2 CBC. Pour éviter le problème, il est possible de définir kern.ipc.tls.enable=0 ou kern.ipc.tls.cbc_enable=0.
• CVE-2026-49424. Fuite de données (104 octets) du stack du noyau lors de l'appel de linux-compat waitid(), qui oublie de réinitialiser la partie inutilisée de la structure linux siginfo_t lors du transfert de données depuis FreeBSD. Dans les noyaux GENERIC par défaut, l'émulateur linux est désactivé et ne s'active que par le chargement manuel du module.
• CVE-2026-49425. De manière similaire à la précédente, kevent 32 bits oublie de réinitialiser la structure 32 bits avant le transfert des données depuis la structure native 64 bits, ce qui entraîne une fuite de données du stack. Par défaut, la compatibilité 32 bits dans le noyau est activée (pas par module).
• CVE-2026-58081, CVE-2026-58082. Vulnérabilités dans iconv. Première : de nombreux modules ne vérifient pas la taille du buffer de sortie fourni par l'appelant avant d'écrire le résultat (mentionnés HZ, UTF-7, VIQR, ZW). Deuxième : le module ISO-2022 utilise un buffer de 6 octets sur la stack pour des opérations internes, mais jusqu'à 10 octets peuvent y être écrits, corrompant la stack. En fin de compte, l'exécution d'iconv pour la conversion vers ou depuis l'un des encodages mentionnés avec des entrées non vérifiées peut être sujette à des débordements de buffer.

Source : linux.org.ru