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

In the Linux kernel, the following vulnerability has been resolved:

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

skfpctlsetmacaddress() calls ResetAdapter() unconditionally, without checking netifrunning(). ResetAdapter() first calls cardstop(), which sets smc->hw.hwstate to STOPPED, and then macdrvcleartxqueue(), which walks the two transmit queues:

for (i = QUEUES; i <= QUEUEA0; i++) { queue = smc->hw.fp.tx[i] ; ... t = queue->txcurrget ;

smc->hw.fp.tx[] is only populated by inittx(), which is reached from skfpopen() through initsmt() -> initfddidriver() -> initfplus() -> initmac() -> inittx(). The private area is allocated and zeroed by allocfddidev(), so on an interface that has never been brought up both queue pointers are still NULL. The hwstate test at the top of macdrvcleartxqueue() does not catch this, because cardstop() has just set STOPPED; the function proceeds into the loop and dereferences NULL. ResetAdapter() does call initsmt() 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 macdrvcleartxqueue+0x68/0x2c0 [skfp] Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: <TASK> macdrvcleartxqueue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] skfpctlsetmacaddress+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] netifsetmacaddress+0x1e4/0x2c0 dosetlink+0x684/0x2680 </TASK>

Address 0x10 is the offset of txcurrget, the third pointer in struct ssmttxqueue, on 64-bit. macdrvclearrxqueue(), which ResetAdapter() calls immediately afterwards, dereferences smc->hw.fp.rx[QUEUER1] in the same way behind the same ineffective hwstate test; the transmit queue merely crashes first. Both are covered by the guard below.

Skip the adapter reset when the interface is down. devaddrset() is left unconditional, so the new address is still recorded in dev->devaddr. Nothing is lost by not resetting the adapter here: skfpopen() deliberately re-reads the factory address on every open,

readaddress(smc, NULL); ethhwaddrset(dev, smc->hw.fddicanonaddr.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 ndosetmacaddress() with netifrunning() is established practice; skgesetmacaddress() 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 smtonline() and STIFBI() ("Enable Board Interrupts") while skfpclose() has already called freeirq() - the adapter would be brought back online with no handler installed. The only other ResetAdapter() caller is skfpinterrupt(), 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 CAPNETADMIN.