PT-2026-43837 · Linux · Linux
Published
2026-05-27
·
Updated
2026-05-27
·
CVE-2026-45970
CVSS v3.1
7.8
High
| Vector | AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
In the Linux kernel, the following vulnerability has been resolved:
bonding: alb: fix UAF in rlb arp recv during bond up/down
The ALB RX path may access rx hashtbl concurrently with bond
teardown. During rapid bond up/down cycles, rlb deinitialize()
frees rx hashtbl while RX handlers are still running, leading
to a null pointer dereference detected by KASAN.
However, the root cause is that rlb arp recv() can still be accessed
after setting recv probe 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:rlb arp recv+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]
[ 214.315318] ? pfx rlb arp recv+0x10/0x10 [bonding]
[ 214.320975] bond handle frame+0x166/0xb60 [bonding]
[ 214.326537] ? pfx bond handle frame+0x10/0x10 [bonding]
[ 214.332680] netif receive skb core.constprop.0+0x576/0x2710
[ 214.339199] ? pfx arp process+0x10/0x10
[ 214.343775] ? sched balance find src group+0x98/0x630
[ 214.349513] ? pfx netif receive skb core.constprop.0+0x10/0x10
[ 214.356513] ? arp rcv+0x307/0x690
[ 214.360311] ? pfx arp rcv+0x10/0x10
[ 214.364499] ? lock acquire+0x58c/0xbd0
[ 214.368975] netif receive skb one core+0xae/0x1b0
[ 214.374518] ? pfx netif receive skb one core+0x10/0x10
[ 214.380743] ? lock acquire+0x10b/0x140
[ 214.385026] process backlog+0x3f1/0x13a0
[ 214.389502] ? process backlog+0x3aa/0x13a0
[ 214.394174] napi poll.constprop.0+0x9f/0x370
[ 214.399233] net rx action+0x8c1/0xe60
[ 214.403423] ? pfx net rx action+0x10/0x10
[ 214.408193] ? lock acquire.part.0+0xbd/0x260
[ 214.413058] ? sched clock cpu+0x6c/0x540
[ 214.417540] ? mark held locks+0x40/0x70
[ 214.421920] handle softirqs+0x1fd/0x860
[ 214.426302] ? pfx handle softirqs+0x10/0x10
[ 214.431264] ? neigh event send+0x2d6/0xf50
[ 214.436131] do softirq+0xb1/0xf0
[ 214.439830]
The issue is reproducible by repeatedly running
ip link set bond0 up/down while receiving ARP messages, where
rlb arp recv() can race with rlb deinitialize() and dereference
a freed rx hashtbl entry.
Fix this by setting recv probe to NULL and then calling
synchronize net() to wait for any concurrent RX processing to finish.
This ensures that no RX handler can access rx hashtbl after it is freed
in bond alb deinitialize().
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux