CVE-2026-74726

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor<br /> <br /> bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and<br /> takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the<br /> active slave. In that window the active slave can change under RTNL<br /> (RTM_DELLINK -&gt; __bond_release_one() -&gt; bond_alb_handle_active_change()),<br /> which already drops the promiscuity and clears primary_is_promisc. The<br /> monitor still acts on the stale decision: if the slave was removed with no<br /> failover, curr_active_slave is now NULL and the deref faults; if it failed<br /> over, the stale dev_set_promiscuity(-1) underflows the new slave&amp;#39;s<br /> promiscuity counter and pins it in IFF_PROMISC.<br /> <br /> Oops: general protection fault, probably for non-canonical address ...<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> Workqueue: b42 bond_alb_monitor<br /> RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600)<br /> process_one_work (kernel/workqueue.c:3322)<br /> worker_thread (kernel/workqueue.c:3486)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so<br /> the monitor only undoes an increment it still owns. The other bonding<br /> monitors already re-read state under RTNL in their commit phase<br /> (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only<br /> one acting on the pre-trylock decision.