Am 30. Juni 2026 wurden Mitteilungen über die Behebung von 13 neuen Schwachstellen im Betriebssystem FreeBSD veröffentlicht.
- CVE-2026-49418. Ein Benutzer mit Zugriff auf ein Gerät mit einem speicherabgebildeten Interface kann einen Double-Free/Use-After-Free im Kernel auslösen. Dies kann möglicherweise zu einer Erhöhung der Berechtigungen führen.
- CVE-2026-49419. (nur FreeBSD 15+) Doppelte Reduzierung des Referenzzählers des aktuellen Jails bei der Fehlerbehandlung eines Zugriffs auf ein anderes Jail über den Jail-Descriptor (eingeführt in FreeBSD 15), was letztendlich zu einer unvorhergesehenen Freigabe der Steuerstruktur des Jails und folgenden Use-After-Free führt, wo auch immer sie verwendet wird. Theoretisch kann dies zu einer Erhöhung der Berechtigungen führen.
- CVE-2026-49415. Bei der Ausführung eines Setuid-Programms werden die Zugriffsrechte auf dessen Speicher etwas später gesetzt als dieser Speicher initialisiert wird, was einen kurzen Zeitraum ermöglicht, in dem man auf ihn zugreifen und ihn bearbeiten kann, ohne die benötigten Berechtigungen über procfs oder linprocfs zu haben. In den meisten Systemen werden procfs und insbesondere libprocfs nicht gemountet, sodass das Problem wahrscheinlich nur wenige betrifft.
- CVE-2026-49429, CVE-2026-49430, CVE-2026-49431. (nur für Systeme mit ZFS) Die ersten beiden Fehler hängen mit der Zuweisung von nicht korrekter Speichergröße zusammen: Es wird ein Puffer in der Größe eines 32-Bit-Wertes zugewiesen, in den dann Daten in der tatsächlichen Größe geschrieben werden, was zu einem Überlauf führt, wenn die tatsächliche Puffergröße größer als 4 GB war. Beide können nur von root oder einem Benutzer mit expliziten Privilegien für verwundbare Operationen ausgelöst werden. Der dritte Fehler kann von allen ausgenutzt werden; er ermöglicht es jedem, das Flag „$hasrecvd“ auf einem Datensatz mit ZFS_IOC_SET_PROP zu setzen (wie gefährlich das ist, lässt sich aus der Ankündigung nicht erkennen).
- CVE-2026-49420. Das Fehlen einer angemessenen Überprüfung der Paketgröße, bevor es in einen Puffer fester Größe im Stack im libalias-Modul zur Unterstützung von RTSP geschrieben wird, führt zu der Möglichkeit, den Stack oder den Kernel (für ipfw nat) oder den Prozess natd (normalerweise unter root ausgeführt) aus der Ferne und ohne Autorisierung zu überfluten. Dies kann potenziell zu RCE führen. Eine böswillige Quelle innerhalb des lokalen Netzwerks hinter NAT, das über libalias implementiert wurde und schadhafte RTSP-Pakete weiterleitet, kann die Schwachstelle auslösen. Daher betrifft die Schwachstelle keine Hosts, auf denen NAT in irgendeiner Form nicht ausgeführt wird. Außerdem wird natd nicht mehr anfällig sein, wenn die Zeile libalias_smedia.so aus /etc/libalias.conf entfernt wird und natd neu gestartet wird. Das ipfw nat wird ohne das Laden des Moduls alias_smedia.ko nicht anfällig sein (es wird nicht erwähnt, ob es automatisch geladen werden kann). Zudem betrachtet der anfällige Handler nur TCP/UDP-Pakete, die nach außen geschickt werden und bei denen einer der Ports 554 oder 7070 ist – wenn solche Pakete vor ihrem Erreichen des NAT gefiltert werden, verschwindet die Schwachstelle ebenfalls.
- CVE-2026-49421. unlinkat() und funlinkat() berücksichtigten das Flag AT_RESOLVE_BENEATH nicht, das verhindern sollte, dass beim Durchlaufen des Pfades der Bereich des angegebenen Verzeichnisses (dirfd) überschritten wird. Dadurch war es möglich, Dateien außerhalb des Verzeichnisses zu löschen, wenn der aufrufende Code dieses Einschränkung einführen wollte.
- CVE-2026-49422. Rennen im Modul tcp_rack.ko (standardmäßig nicht geladen). Jeder TCP-Socket kann individuell den TCP-Stack auswählen, über den er arbeiten wird, einschließlich der Möglichkeit, sie zur Laufzeit umzuschalten. Wenn man Folgendes tut: 1) Auf dem Socket mit tcp_rack wird ein rack-spezifisches setsockopt() aufgerufen, 2) in einem anderen Thread schnell den TCP-Stack von rack auf einen anderen wechselt und dann zum richtigen Zeitpunkt wieder auf rack wechselt, dann arbeitet der rack-Handler von setsockopt() mit der alten (vor dem Wechsel) Adresse der Socket-Zustandsstruktur, was zu Speicherbeschädigung und möglichem Aufstieg von Rechten führt. Betroffen sind nur Systeme, auf denen tcp_rack.ko ausdrücklich geladen ist; dies ist nicht die Standardkonfiguration.
- CVE-2026-49427, CVE-2026-49428. POSIX Largepages (shm_create_largepage) wurden bei der Zuweisung unzureichend als verwendet markiert, was zu einer fehlerhaften Freigabe unter verschiedenen Umständen führen konnte (namentlich Aufrufe von sendfile mit dem Flag SF_NOCACHE, open mit dem Flag O_TRUNC und fspacectl), und zu einem Use-After-Free mit den üblichen Konsequenzen.
- CVE-2026-49426. Unzureichende Auditprotokolle (audit(4)) über entfernte Syscalls via ptrace(PT_SC_REMOTE). Diese können Systeme zur Analyse verdächtiger Situationen verwirren, falls solche verwendet werden.
- CVE-2026-49423. Ein möglicher Kernel-Panic beim Empfang von Daten über kTLS, der TLS 1.2 CBC-Aufzeichnungen betrifft. Um das Problem zu vermeiden, können Sie kern.ipc.tls.enable=0 oder kern.ipc.tls.cbc_enable=0 setzen.
- CVE-2026-49424. Datenleck (104 Bytes) aus dem Kernel-Stack beim Aufruf von linux-compat waitid(), der vergisst, den ungenutzten Teil der linux-Struktur siginfo_t beim Transfer von Daten aus der FreeBSD-Struktur zu nullen. In normalen GENERIC-Kernen ist der Linux-Emulator standardmäßig deaktiviert und wird nur durch manuelles Laden des Moduls aktiviert.
- CVE-2026-49425. Ähnlich wie zuvor vergisst die 32-Bit-Kevent, die 32-Bit-Struktur vor dem Übertragen von Daten aus der nativen 64-Bit-Struktur zu initialisieren, was zu einem Datenleck vom Stack führt. Standardmäßig ist die 32-Bit-Kompatibilität im Kernel aktiviert (nicht über ein Modul).
- CVE-2026-58081, CVE-2026-58082. Schwachstellen in iconv. Erstens: Viele seiner Module überprüfen nicht die Größe des von dem aufrufenden Code bereitgestellten Ausgabebuffers, bevor sie Ergebnisse darin schreiben (zitiert werden HZ, UTF-7, VIQR, ZW). Zweitens: Das ISO-2022-Modul verwendet einen 6-Byte-Buffer im Stack für interne Operationen, aber darin können bis zu 10 Byte geschrieben werden, was den Stack beschädigt. Folglich kann die Ausführung von iconv zur Konvertierung in oder aus einem der angegebenen Encodings mit unvalidierten Eingabewerten anfällig für Pufferüberläufe sein.
Quelle: linux.org.ru
