UBUNTU-CVE-2026-98302: Medium severity ubuntu/linux vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1119.126~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1125.134~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1124.133~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1120.130~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-202.212~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-197.207~20.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1070.72~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1116.122~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-202.212 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1115.121 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1102.110 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1113.117 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.116 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-197.207 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1114.115 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 5.15.0-1070.72 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-igxto a version that resolves this vulnerability.Fixed in 5.15.0-1059.59 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1116.122 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1103.105 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1118.127 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-202.212+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130+fips1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Guard the adapter reset with netif_running() and skip ResetAdapter() when the interface is down; leave dev_addr_set() unconditional.
Linux kernel net/fddi/skfp ResetAdapter invocation in skfp_ctl_set_mac_address() = only invoke when netif_running() is true
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel SKFP FDDI network driver are exposed when an FDDI interface exists and has never been brought up. The affected Ubuntu kernel package families listed are linux, linux-fips, linux-aws, linux-azure, linux-aws-fips, linux-azure-fips, linux-gcp, and linux-gcp-fips.
What action triggers the failure?
An attacker or local user needs the ability to change the MAC address of an SKFP FDDI interface while it is down and has never been brought up. The described trigger is setting an address with ip link set dev fddi0 address 02:00:00:00:00:01, which can cause a kernel NULL-pointer dereference and oops.
Are interfaces that have previously been brought up affected in the same way?
The described NULL dereference depends on the transmit queue pointers still being NULL, which occurs before the interface is first opened. Bringing the interface up reaches initialization that populates those queues.
What can be done before a fixed kernel is installed?
Avoid changing the MAC address of a down SKFP FDDI interface before it has been brought up. Restrict untrusted users' ability to administer network interfaces, since exploitation requires changing the interface MAC address.