CVE-2026-98302

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: 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

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.