UBUNTU-CVE-2026-74726: High severity ubuntu/linux vulnerability
In the Linux kernel, the following vulnerability has been resolved: bonding: alb: re-check primaryispromisc under RTNL in bondalbmonitor bondalbmonitor() reads primaryispromisc under RCU, then drops RCU and takes RTNL via rtnltrylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTMDELLINK -> bondreleaseone() -> bondalbhandleactivechange()), which already drops the promiscuity and clears primaryispromisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curractiveslave is now NULL and the deref faults; if it failed over, the stale devsetpromiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFFPROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bondalbmonitor RIP: 0010:bondalbmonitor (drivers/net/bonding/bondalb.c:1600) processonework (kernel/workqueue.c:3322) workerthread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) Kernel panic - not syncing: Fatal exception Re-check primaryispromisc (and curractiveslave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bondmiimoncommit/bondabarpcommit); bondalbmonitor() was the only one acting on the pre-trylock decision.
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-1117.124~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1123.132~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1122.131~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1118.128~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-198.208~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1112.118~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-195.205~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-198.208 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1122.131 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1113.119 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1100.108 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1112.118 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1109.114 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-195.205 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1112.113 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-xilinx-zynqmpto a version that resolves this vulnerability.Fixed in 5.15.0-1080.84 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1101.103 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1109.111 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1116.125 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-198.208+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128+fips1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1036.39
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux bonding driver with adaptive load balancing (ALB) are exposed when an active bonded slave can be removed or changed while the ALB monitor runs. 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 does an attacker or local user need to trigger the vulnerability?
The issue is locally exploitable and requires low privileges. Triggering it depends on racing the ALB monitor with an active-slave change or removal through the networking configuration path.
What is the impact if the race succeeds?
Removing the active slave without failover can cause a null-pointer dereference and kernel fault or panic. During failover, the new active slave's promiscuity counter can underflow, leaving that interface stuck in promiscuous mode.
How can I determine whether a system is affected?
Check whether the host uses a bonded network interface configured for ALB and whether its running Ubuntu kernel belongs to one of the listed package families. Relevant symptoms include a bond_alb_monitor null-pointer/KASAN report, a general protection fault, or an interface unexpectedly remaining in IFF_PROMISC after bond failover.