CVE-2026-74726 in Linux
Riassunto
di VulDB • 22/08/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
bonding: alb: verificare nuovamente primary_is_promisc sotto RTNL in bond_alb_monitor
bond_alb_monitor() legge primary_is_promisc sotto RCU, quindi rilascia RCU e acquisisce RTNL tramite rtnl_trylock() prima di revocare il promiscuo impostato sullo slave attivo. In questa finestra temporale lo slave attivo può cambiare sotto RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), che già revoca il promiscuo e azzera primary_is_promisc. Il monitor agisce ancora sulla decisione obsoleta: se lo slave è stato rimosso senza failover, curr_active_slave è ora NULL e si verifica un fault per dereferenziazione; in caso di failover, la chiamata stale dev_set_promiscuity(-1) causa un underflow del contatore promiscuo del nuovo slave, bloccandolo in IFF_PROMISC.
Oops: general protection fault, probabilmente per indirizzo non canonico ... KASAN: null-ptr-deref nell'intervallo [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
Verificare nuovamente primary_is_promisc (e curr_active_slave) dopo aver acquisito RTNL, in modo che il monitor revochi solo un incremento di cui possiede ancora la proprietà. Gli altri monitor del bonding già rileggono lo stato sotto RTNL nella fase di commit (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() era l'unico ad agire sulla decisione pre-trylock.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.