CVE-2026-74726

CVE CVE-2026-74726EUVD EUVD-2026-64413Published 2026-08-22T15:33:17.000ZLast changed 2026-08-25T05:42:07.000ZCVSS 7.3

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 7.1.9; patch: 6.12.104; patch: 6.6.152; d0e81b7e2246a41d068ecaf15aac9de570816d63 <257c4a3a34d8f51efb00f35375a0c6ce3c8f6ce2; d0e81b7e2246a41d068ecaf15aac9de570816d63 <2faf75a8a06504071b4c0aea7e45a9cc49a4e187; patch: 6.18.45; patch: 5.10.265; d0e81b7e2246a41d068ecaf15aac9de570816d63 <dccec0227ed8d9e36936d66e256b957dc2858468; patch: 5.15.216; d0e81b7e2246a41d068ecaf15aac9de570816d63 <b82f51681a7a88c7d3c865e817a3340d42b5fa2a; d0e81b7e2246a41d068ecaf15aac9de570816d63 <09add8d5cfa9c46828f51eaad162c36e86366b71; d0e81b7e2246a41d068ecaf15aac9de570816d63 <dd148539fb4741d01c06b7d2c8bd84b01920756c; patch: 6.1.183; 2.6.24; patch: 0; d0e81b7e2246a41d068ecaf15aac9de570816d63 <683c6ba6e58e6ed1037831ea97dd58d9c0e76b8d; d0e81b7e2246a41d068ecaf15aac9de570816d63 <f7668762bf5fd6db9397de5c0514407489d9d815; patch: 7.2

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.