Linux Kernel bis 7.3-rc3 skfp skfp_ctl_set_mac_address Denial of Service

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

Zusammenfassunginfo

Es wurde eine als problematisch klassifizierte Schwachstelle in Linux Kernel bis 7.3-rc3 entdeckt. Davon betroffen ist die Funktion skfp_ctl_set_mac_address der Komponente skfp. Durch das Beeinflussen mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Schwachstelle trägt die Bezeichnung CVE-2026-98302. Umgesetzt werden muss der Angriff lokal. Es gibt keinen verfügbaren Exploit. Die Aktualisierung der betroffenen Komponente wird empfohlen.

Detailsinfo

In Linux Kernel bis 7.3-rc3 wurde eine problematische Schwachstelle gefunden. Dabei geht es um die Funktion skfp_ctl_set_mac_address der Komponente skfp. Durch das Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-476. Dies wirkt sich aus auf die Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: net: fddi: skfp: fix NULL deref when setting the MAC address while down skfp_ctl_set_mac_address() calls ResetAdapter() unconditionally, without checking netif_running(). ResetAdapter() first calls card_stop(), which sets smc->hw.hw_state to STOPPED, and then mac_drv_clear_tx_queue(), which walks the two transmit queues: for (i = QUEUE_S; i <= QUEUE_A0; i++) { queue = smc->hw.fp.tx[i] ; ... t = queue->tx_curr_get ; smc->hw.fp.tx[] is only populated by init_tx(), which is reached from skfp_open() through init_smt() -> init_fddi_driver() -> init_fplus() -> init_mac() -> init_tx(). The private area is allocated and zeroed by alloc_fddidev(), so on an interface that has never been brought up both queue pointers are still NULL. The hw_state test at the top of mac_drv_clear_tx_queue() does not catch this, because card_stop() has just set STOPPED; the function proceeds into the loop and dereferences NULL. ResetAdapter() does call init_smt() itself, but only after the queues have been cleared. Setting the MAC address on a down interface therefore oopses: ip link set dev fddi0 address 02:00:00:00:00:01 BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp] Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: <TASK> mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] netif_set_mac_address+0x1e4/0x2c0 do_setlink+0x684/0x2680 </TASK> Address 0x10 is the offset of tx_curr_get, the third pointer in struct s_smt_tx_queue, on 64-bit. mac_drv_clear_rx_queue(), which ResetAdapter() calls immediately afterwards, dereferences smc->hw.fp.rx[QUEUE_R1] in the same way behind the same ineffective hw_state test; the transmit queue merely crashes first. Both are covered by the guard below. Skip the adapter reset when the interface is down. dev_addr_set() is left unconditional, so the new address is still recorded in dev->dev_addr. Nothing is lost by not resetting the adapter here: skfp_open() deliberately re-reads the factory address on every open, read_address(smc, NULL); eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a); and the comment above it states this is done to discard exactly such an address override across a close/open cycle. An address set while the interface is down could not have survived the following open even before this change, so the guard removes no working behaviour. Guarding the hardware side of ndo_set_mac_address() with netif_running() is established practice; skge_set_mac_address() has done so since commit 2eb3e621c4e0 ("skge: set mac address bonding fix"). Guarding the reset as a whole, rather than NULL-checking the queues, is also what the rest of the driver expects. After a previous open/close the queue pointers are stale but non-NULL, so there is no crash, yet ResetAdapter() goes on to call smt_online() and STI_FBI() ("Enable Board Interrupts") while skfp_close() has already called free_irq() - the adapter would be brought back online with no handler installed. The only other ResetAdapter() caller is skfp_interrupt(), which by construction runs only while the device is open. Found by automated driver testing against an emulated SysKonnect FDDI adapter under a KASAN-enabled 7.0.0 kernel. Triggering it requires CAP_NET_ADMIN.

Auf git.kernel.org kann das Advisory eingesehen werden. Eine eindeutige Identifikation der Schwachstelle wird seit dem 25.09.2026 mit CVE-2026-98302 vorgenommen. Sie gilt als leicht ausnutzbar. Die Umsetzung des Angriffs hat dabei lokal zu erfolgen. Das Angehen einer erweiterte Authentisierung ist erforderlich, um eine Ausnutzung anzugehen. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht.

Ein Upgrade auf die Version 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54, 7.2.8 oder 7.3-rc4 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 835903bea770ad96ab4322e18d98e00f8e0b39c3/5fd0f401b3eee95c93daa35ef99cb03d676031f0/731db6110b3148331ed8d5d11a564bfd520721d9/822903ed991971780db1db1be31a4f00e2b13e30/616ba18b2cfb72b7bea214bdd72df2485b2e37dc/d6f63fdb298d546a47790cb373db65462c264d04/438131e7ae847e907d345bf504d7e25585561b5c/7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1 beheben. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

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.4
VulDB Meta Temp Score: 4.2

VulDB Base Score: 4.4
VulDB Temp Score: 4.2
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

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-476 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Nein

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

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

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 5.10.271/5.15.222/6.1.189/6.6.158/6.12.112/6.18.54/7.2.8/7.3-rc4
Patch: 835903bea770ad96ab4322e18d98e00f8e0b39c3/5fd0f401b3eee95c93daa35ef99cb03d676031f0/731db6110b3148331ed8d5d11a564bfd520721d9/822903ed991971780db1db1be31a4f00e2b13e30/616ba18b2cfb72b7bea214bdd72df2485b2e37dc/d6f63fdb298d546a47790cb373db65462c264d04/438131e7ae847e907d345bf504d7e25585561b5c/7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1

Timelineinfo

25.09.2026 CVE zugewiesen
06.10.2026 +11 Tage Advisory veröffentlicht
06.10.2026 +0 Tage VulDB Eintrag erstellt
06.10.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-98302 (🔒)
GCVE (CVE): GCVE-0-2026-98302
GCVE (VulDB): GCVE-100-414058

Eintraginfo

Erstellt: 06.10.2026 12:25
Anpassungen: 06.10.2026 12:25 (59)
Komplett: 🔍
Cache ID: 216::103

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

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

Want to know what is going to be exploited?

We predict KEV entries!