CVE-2026-45970: bonding: alb: fix UAF in rlb_arp_recv during bond up/down
In the Linux kernel, the following vulnerability has been resolved:
bonding: alb: fix UAF in rlbarprecv during bond up/down
The ALB RX path may access rxhashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlbdeinitialize() frees rxhashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN.
However, the root cause is that rlbarprecv() can still be accessed after setting recvprobe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag.
[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlbarprecv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? pfxrlbarprecv+0x10/0x10 [bonding] [ 214.320975] bondhandleframe+0x166/0xb60 [bonding] [ 214.326537] ? pfxbondhandleframe+0x10/0x10 [bonding] [ 214.332680] netifreceiveskbcore.constprop.0+0x576/0x2710 [ 214.339199] ? pfxarpprocess+0x10/0x10 [ 214.343775] ? schedbalancefindsrcgroup+0x98/0x630 [ 214.349513] ? pfxnetifreceiveskbcore.constprop.0+0x10/0x10 [ 214.356513] ? arprcv+0x307/0x690 [ 214.360311] ? pfxarprcv+0x10/0x10 [ 214.364499] ? lockacquire+0x58c/0xbd0 [ 214.368975] netifreceiveskbonecore+0xae/0x1b0 [ 214.374518] ? pfxnetifreceiveskbonecore+0x10/0x10 [ 214.380743] ? lockacquire+0x10b/0x140 [ 214.385026] processbacklog+0x3f1/0x13a0 [ 214.389502] ? processbacklog+0x3aa/0x13a0 [ 214.394174] napipoll.constprop.0+0x9f/0x370 [ 214.399233] netrxaction+0x8c1/0xe60 [ 214.403423] ? pfxnetrxaction+0x10/0x10 [ 214.408193] ? lockacquire.part.0+0xbd/0x260 [ 214.413058] ? schedclockcpu+0x6c/0x540 [ 214.417540] ? markheldlocks+0x40/0x70 [ 214.421920] handlesoftirqs+0x1fd/0x860 [ 214.426302] ? pfxhandlesoftirqs+0x10/0x10 [ 214.431264] ? neigheventsend+0x2d6/0xf50 [ 214.436131] dosoftirq+0xb1/0xf0 [ 214.439830] </IRQ>
The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlbarprecv() can race with rlbdeinitialize() and dereference a freed rxhashtbl entry.
Fix this by setting recvprobe to NULL and then calling synchronizenet() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rxhashtbl after it is freed in bondalbdeinitialize().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in 6.19.0-rc8+ - Configuration
In rlb_deinitialize()/bonding ALB teardown, set recv_probe to NULL before deinitializing to prevent further use-after-free (UAF) involving rlb_arp_recv() during bond up/down.
Linux kernel bonding (ALB) recv_probe = NULL - Compensating control
Ensure rlb_deinitialize/bond_alb_deinitialize waits for concurrent RX processing to finish by calling synchronize_net() (so rlb_arp_recv() cannot run after rx_hashtbl is freed).