CVE-2026-98302 - Vulnerability Details

- net: fddi: skfp: fix NULL deref when setting the MAC address while down

Description

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.

Published: 2026-10-06

Score: 5.5 Medium

EPSS: < 1% Very Low

KEV: No

Impact:

Action:

Analysis

Impact

The Linux kernel driver skfp contains a bug that causes a NULL pointer dereference when an administrator attempts to set a MAC address on an interface that is administratively down. The bug triggers the kernel to call ResetAdapter unconditionally, which walks internal transmit and receive queues that are still uninitialized, resulting in a kernel oops and a system crash. This represents a denial‑of‑service condition, as the crash forces a reboot or otherwise renders the affected system unusable until restarted.

Affected Systems

All Linux kernel releases that include the skfp FDDI driver module and have not yet applied the upstream patch that guards ResetAdapter when the interface is down are vulnerable. The vulnerability affects every build containing the problematic code path; there is no specific version string in the advisory, so any kernel that includes the unpatched driver should be considered impacted.

Risk and Exploitability

The flaw requires local execution with CAP_NET_ADMIN privileges, typically held by root or other privileged users. An attacker can trigger the crash by executing a command such as "ip link set dev fddi0 address 02:00:00:00:00:01" while the interface is down. There is no publicly known remote exploitation pathway, and the EPSS score is less than 1%. The CVSS score is 5.5, indicating moderate severity. The CISA KEV catalog does not list it, so it is not classified as a known exploited vulnerability. Nonetheless, because it causes an uncontainable kernel fault, the risk to systems where privileged jump‑start or mis‑configured hardware exists is moderate to high.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< 835903bea770ad96ab4322e18d98e00f8e0b39c3
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< 5fd0f401b3eee95c93daa35ef99cb03d676031f0
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< 731db6110b3148331ed8d5d11a564bfd520721d9
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< 822903ed991971780db1db1be31a4f00e2b13e30
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< 616ba18b2cfb72b7bea214bdd72df2485b2e37dc
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< d6f63fdb298d546a47790cb373db65462c264d04
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< 438131e7ae847e907d345bf504d7e25585561b5c
`1da177e4c3f41524e886b7f1b8a0c1fc7321cac2`	affected	< 7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1

Linux

affected

Version	Status	Constraints
`2.6.12`	affected	—
`0`	unaffected	< 2.6.12
`5.10.271`	unaffected	≤ 5.10.*
`5.15.222`	unaffected	≤ 5.15.*
`6.1.189`	unaffected	≤ 6.1.*
`6.6.158`	unaffected	≤ 6.6.*
`6.12.112`	unaffected	≤ 6.12.*
`6.18.54`	unaffected	≤ 6.18.*
`7.2.8`	unaffected	≤ 7.2.*
`7.3`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,835903bea770ad96ab4322e18d98e00f8e0b39c3)`	affected	code_commit	—
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,5fd0f401b3eee95c93daa35ef99cb03d676031f0)`	affected	code_commit	—
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,731db6110b3148331ed8d5d11a564bfd520721d9)`	affected	code_commit	—
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,822903ed991971780db1db1be31a4f00e2b13e30)`	affected	code_commit	—
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,616ba18b2cfb72b7bea214bdd72df2485b2e37dc)`	affected	code_commit	—
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,d6f63fdb298d546a47790cb373db65462c264d04)`	affected	code_commit	—
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,438131e7ae847e907d345bf504d7e25585561b5c)`	affected	code_commit	—
`[1da177e4c3f41524e886b7f1b8a0c1fc7321cac2,7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1)`	affected	code_commit	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`2.6.12`	affected	semver	—
`[0,2.6.12)`	unaffected	semver	—
`[5.10.271,5.10.*]`	unaffected	generic	—
`[5.15.222,5.15.*]`	unaffected	generic	—
`[6.1.189,6.1.*]`	unaffected	generic	—
`[6.6.158,6.6.*]`	unaffected	generic	—
`[6.12.112,6.12.*]`	unaffected	generic	—
`[6.18.54,6.18.*]`	unaffected	generic	—
`[7.2.8,7.2.*]`	unaffected	generic	—
`[7.3-rc4,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

Apply an updated kernel that contains the commit which guards ResetAdapter when the interface is down
Restart the system after applying the kernel update to ensure the new module is loaded
If an immediate kernel upgrade is not possible, avoid setting the MAC address on an interface that is administratively down; bring the interface up before changing its address

Generated by OpenCVE AI on October 11, 2026 at 16:10 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source	ID	Title
Debian DLA	DLA-4841-1	linux security update
Debian DLA	DLA-4850-1	linux-6.12 security update
Debian DSA	DSA-6568-1	linux security update
Ubuntu USN	USN-8961-1	Linux kernel vulnerabilities

No CVSS v4.0

Attack Vector Local

Attack Complexity Low

Privileges Required Low

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

The EPSS score is 0.00177.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98302.mbox
https://git.kernel.org/stable/c/438131e7ae847e907d345bf504d7e25585561b5c
https://git.kernel.org/stable/c/5fd0f401b3eee95c93daa35ef99cb03d676031f0
https://git.kernel.org/stable/c/616ba18b2cfb72b7bea214bdd72df2485b2e37dc
https://git.kernel.org/stable/c/731db6110b3148331ed8d5d11a564bfd520721d9
https://git.kernel.org/stable/c/7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1
https://git.kernel.org/stable/c/822903ed991971780db1db1be31a4f00e2b13e30
https://git.kernel.org/stable/c/835903bea770ad96ab4322e18d98e00f8e0b39c3
https://git.kernel.org/stable/c/d6f63fdb298d546a47790cb373db65462c264d04
https://nvd.nist.gov/vuln/detail/CVE-2026-98302
https://www.cve.org/CVERecord?id=CVE-2026-98302

History

Sun, 11 Oct 2026 12:15:00 +0000

Type	Values Removed	Values Added
References		https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98302.mbox https://nvd.nist.gov/vuln/detail/CVE-2026-98302 https://www.cve.org/CVERecord?id=CVE-2026-98302
Metrics	threat_severity `None`	cvssV3_1 `{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}` threat_severity `Moderate`

Wed, 07 Oct 2026 03:45:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-476

Tue, 06 Oct 2026 18:00:00 +0000

Type	Values Removed	Values Added
Weaknesses	CWE-690

Tue, 06 Oct 2026 14:15:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-690

Tue, 06 Oct 2026 09:00:00 +0000

Type	Values Removed	Values Added
Description		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.
Title		net: fddi: skfp: fix NULL deref when setting the MAC address while down
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/438131e7ae847e907d345bf504d7e25585561b5c https://git.kernel.org/stable/c/5fd0f401b3eee95c93daa35ef99cb03d676031f0 https://git.kernel.org/stable/c/616ba18b2cfb72b7bea214bdd72df2485b2e37dc https://git.kernel.org/stable/c/731db6110b3148331ed8d5d11a564bfd520721d9 https://git.kernel.org/stable/c/7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1 https://git.kernel.org/stable/c/822903ed991971780db1db1be31a4f00e2b13e30 https://git.kernel.org/stable/c/835903bea770ad96ab4322e18d98e00f8e0b39c3 https://git.kernel.org/stable/c/d6f63fdb298d546a47790cb373db65462c264d04

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-10-06T08:45:59.718Z

Updated: 2026-10-19T09:17:13.166Z

Reserved: 2026-09-25T10:25:14.337Z

Link: CVE-2026-98302

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-10-06T09:18:21.183

Modified: 2026-10-19T10:18:32.150

Link: CVE-2026-98302

Redhat

Severity : Moderate

Publid Date: 2026-10-06T00:00:00Z

Links: CVE-2026-98302 - Bugzilla

OpenCVE Enrichment

Updated: 2026-10-11T16:15:17Z

Weaknesses

CWE-476
NULL Pointer Dereference

Impact

Affected Systems

Risk and Exploitability

Tracking

Attack Vector Local

Attack Complexity Low

Privileges Required Low

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object