Linux Linux Kernel Vulnerability Permits Kernel Panic

Status: UPDATED  |  Advisory ID: CVE-2026-74726

Key Details

Affected Products, Subsystems & Sectors

What to Know

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

bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor

bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and

takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the

active slave. In that window the active slave can change under RTNL

(RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()),

which already drops the promiscuity and clears primary_is_promisc. The

monitor still acts on the stale decision: if the slave was removed with no

failover, curr_active_slave is now NULL and the deref faults; if it failed

over, the stale dev_set_promiscuity(-1) underflows the new slave's

promiscuity counter and pins it in IFF_PROMISC.

Oops: general protection fault, probably for non-canonical address ...

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]

Workqueue: b42 bond_alb_monitor

RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600)

process_one_work (kernel/workqueue.c:3322)

worker_thread (kernel/workqueue.c:3486)

kthread (kernel/kthread.c:436)

ret_from_fork (arch/x86/kernel/process.c:158)

Kernel panic - not syncing: Fatal exception

Re-check primary_is_promisc (and curr_active_slave) 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

(bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only

one acting on the pre-trylock decision. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References