Linux Kernel bis 6.1.119/6.6.63/6.11.10/6.12.1 rtlwifi uevent_show Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
4.0$0-$5k0.00

Zusammenfassunginfo

Eine Schwachstelle, die als problematisch eingestuft wurde, wurde in Linux Kernel bis 6.1.119/6.6.63/6.11.10/6.12.1 gefunden. Hiervon betroffen ist die Funktion uevent_show der Komponente rtlwifi. Mittels Manipulieren mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Verwundbarkeit ist als CVE-2024-53190 gelistet. Es existiert kein Exploit. Ein Upgrade der betroffenen Komponente wird empfohlen.

Detailsinfo

Eine problematische Schwachstelle wurde in Linux Kernel bis 6.1.119/6.6.63/6.11.10/6.12.1 gefunden. Dies betrifft die Funktion uevent_show der Komponente rtlwifi. Mittels Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-834. Die Auswirkungen sind bekannt für die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.

Das Advisory findet sich auf git.kernel.org. Die Verwundbarkeit wird seit dem 19.11.2024 mit der eindeutigen Identifikation CVE-2024-53190 gehandelt. Die Ausnutzbarkeit gilt als schwierig. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht.

Für den Vulnerability Scanner Nessus wurde ein Plugin mit der ID 216493 (Ubuntu 24.10 : Linux kernel vulnerabilities (USN-7276-1)) herausgegeben, womit die Existenz der Schwachstelle geprüft werden kann.

Ein Aktualisieren auf die Version 6.1.120, 6.6.64, 6.11.11 oder 6.12.2 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches c386fb76f01794f1023d01a6ec5f5c93d00acd3b/8f3551f67991652c83469c7dd51d7b9b187b265f/eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c/ac064c656f105b9122bc43991a170f95f72b7a43/5c1b544563005a00591a3aa86ecff62ed4d11be3 lösen. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von Tenable (216493) dokumentiert. Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 4.0
VulDB Meta Temp Score: 4.0

VulDB Base Score: 2.6
VulDB Temp Score: 2.5
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

NVD Base Score: 5.5
NVD Vector: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

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

Exploitinginfo

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

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

Verfügbarkeit: 🔍
Status: Nicht definiert

EPSS Score: 🔍
EPSS Percentile: 🔍

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Nessus ID: 216493
Nessus Name: Ubuntu 24.10 : Linux kernel vulnerabilities (USN-7276-1)

Threat Intelligenceinfo

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

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔍

Upgrade: Kernel 6.1.120/6.6.64/6.11.11/6.12.2
Patch: c386fb76f01794f1023d01a6ec5f5c93d00acd3b/8f3551f67991652c83469c7dd51d7b9b187b265f/eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c/ac064c656f105b9122bc43991a170f95f72b7a43/5c1b544563005a00591a3aa86ecff62ed4d11be3

Timelineinfo

19.11.2024 🔍
27.12.2024 +38 Tage 🔍
27.12.2024 +0 Tage 🔍
01.10.2025 +278 Tage 🔍

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2024-53190 (🔍)
GCVE (CVE): GCVE-0-2024-53190
GCVE (VulDB): GCVE-100-289427

Eintraginfo

Erstellt: 27.12.2024 15:13
Aktualisierung: 01.10.2025 23:16
Anpassungen: 27.12.2024 15:13 (59), 20.02.2025 14:04 (2), 01.10.2025 23:16 (12)
Komplett: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!