Linux Kernel bis 5.15.155/6.1.86/6.6.27/6.8.6 af_unix Denial of Service

CVSS Meta Temp Score	Aktueller Exploitpreis (≈)	CTI Interest Score
5.8	$0-$5k	0.00

Zusammenfassunginfo

Eine Schwachstelle wurde in Linux Kernel bis 5.15.155/6.1.86/6.6.27/6.8.6 ausgemacht. Sie wurde als problematisch eingestuft. Das betrifft eine unbekannte Funktionalität der Komponente af_unix. Mittels dem Manipulieren mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Schwachstelle trägt die Bezeichnung CVE-2024-35970. Es gibt keinen verfügbaren Exploit. Die Aktualisierung der betroffenen Komponente wird empfohlen.

Detailsinfo

Es wurde eine problematische Schwachstelle in Linux Kernel bis 5.15.155/6.1.86/6.6.27/6.8.6 entdeckt. Dabei betrifft es ein unbekannter Prozess der Komponente af_unix. Mittels dem Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-769 vorgenommen. Das hat Auswirkungen auf die Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.

Das Advisory kann von git.kernel.org heruntergeladen werden. Die Verwundbarkeit wird seit dem 17.05.2024 unter CVE-2024-35970 geführt. Es sind weder technische Details noch ein Exploit zur Schwachstelle bekannt.

Ein Upgrade auf die Version 5.15.156, 6.1.87, 6.6.28 oder 6.8.7 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches b4bc99d04c68/84a352b7eba1/601a89ea24d0/698a95ade1a0/b46f4eaa4f0e beheben. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von CERT Bund (WID-SEC-2025-2711) dokumentiert. VulDB is the best source for vulnerability data and more expert information about this specific topic.

Betroffen

• Lenovo BIOS
• Lenovo Computer
• Google Android

Produktinfo

Typ

• Operating System

Hersteller

• Linux

Name

• Kernel

Version

• 5.15.155
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.1.22
• 6.1.23
• 6.1.24
• 6.1.25
• 6.1.26
• 6.1.27
• 6.1.28
• 6.1.29
• 6.1.30
• 6.1.31
• 6.1.32
• 6.1.33
• 6.1.34
• 6.1.35
• 6.1.36
• 6.1.37
• 6.1.38
• 6.1.39
• 6.1.40
• 6.1.41
• 6.1.42
• 6.1.43
• 6.1.44
• 6.1.45
• 6.1.46
• 6.1.47
• 6.1.48
• 6.1.49
• 6.1.50
• 6.1.51
• 6.1.52
• 6.1.53
• 6.1.54
• 6.1.55
• 6.1.56
• 6.1.57
• 6.1.58
• 6.1.59
• 6.1.60
• 6.1.61
• 6.1.62
• 6.1.63
• 6.1.64
• 6.1.65
• 6.1.66
• 6.1.67
• 6.1.68
• 6.1.69
• 6.1.70
• 6.1.71
• 6.1.72
• 6.1.73
• 6.1.74
• 6.1.75
• 6.1.76
• 6.1.77
• 6.1.78
• 6.1.79
• 6.1.80
• 6.1.81
• 6.1.82
• 6.1.83
• 6.1.84
• 6.1.85
• 6.1.86
• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.6.21
• 6.6.22
• 6.6.23
• 6.6.24
• 6.6.25
• 6.6.26
• 6.6.27
• 6.8.0
• 6.8.1
• 6.8.2
• 6.8.3
• 6.8.4
• 6.8.5
• 6.8.6

Lizenz

• Open-Source

Webseite

• Hersteller: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 5.9
VulDB Meta Temp Score: 5.8

VulDB Base Score: 5.5
VulDB Temp Score: 5.3
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CNA Base Score: 6.3
CNA Vector: 🔍

CVSSv2info

AV	AC	Au	C	I	A
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳

Vektor	Komplexität	Authentisierung	Vertraulichkeit	Integrität	Verfügbarkeit
freischalten	freischalten	freischalten	freischalten	freischalten	freischalten
freischalten	freischalten	freischalten	freischalten	freischalten	freischalten
freischalten	freischalten	freischalten	freischalten	freischalten	freischalten

VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-769 / CWE-400 / CWE-404
CAPEC: 🔍
ATT&CK: 🔍

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔍
Status: Nicht definiert

EPSS Score: 🔍
EPSS Percentile: 🔍

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍

0-Day	freischalten	freischalten	freischalten	freischalten
Heute	freischalten	freischalten	freischalten	freischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔍

Upgrade: Kernel 5.15.156/6.1.87/6.6.28/6.8.7
Patch: b4bc99d04c68/84a352b7eba1/601a89ea24d0/698a95ade1a0/b46f4eaa4f0e

Timelineinfo

17.05.2024 🔍
20.05.2024 +3 Tage 🔍
20.05.2024 +0 Tage 🔍
11.12.2025 +570 Tage 🔍

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2024-35970 (🔍)
GCVE (CVE): GCVE-0-2024-35970
GCVE (VulDB): GCVE-100-265248
CERT Bund: WID-SEC-2025-2711 - Android Patchday Dezember 2025: Mehrere Schwachstellen

Eintraginfo

Erstellt: 20.05.2024 12:35
Aktualisierung: 11.12.2025 05:57
Anpassungen: 20.05.2024 12:35 (56), 02.11.2024 05:45 (13), 11.12.2025 05:57 (7)
Komplett: 🔍
Cache ID: 216::103

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Diskussion

Do you know our Splunk app?

Download it now for free!