[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"repo-stars":3,"vuln-DEBIAN-CVE-2026-45970":6},{"stargazers_count":4,"fetched_at":5},8,"2026-09-19T04:32:17.889Z",{"id":7,"descriptions":8,"cisa":9,"weaknesses":10,"exploits":11,"aliases":12,"duplicate_of":9,"upstream":13,"downstream":16,"duplicates":17,"related":18,"reserved_at":9,"published_at":19,"modified_at":20,"state":9,"summary":21,"references_raw":23,"kevs":30,"epss":9,"epss_history":31,"metrics":32,"affected":39},"DEBIAN-CVE-2026-45970","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 \u003C0f> 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]  \u003CIRQ> [  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]  \u003C/IRQ>  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().",null,[],[],[],[14],{"_key":15},"CVE-2026-45970",[],[],[],"2026-05-27T14:17:13.920Z","2026-06-15T19:06:29.170983813Z",{"cisa_kev":22,"cisa_ransomware":22,"cisa_vendor":9,"epss_severity":9,"epss_score":9,"severity":9,"severity_score":9,"severity_version":9,"severity_source":9,"severity_vector":9,"severity_status":9},false,[24],{"url":25,"sources":26,"tags":28},"https://security-tracker.debian.org/tracker/CVE-2026-45970",[27],"osv_debian",[29],"Advisory",[],[],[33],{"source":27,"cvss_v2_0":9,"cvss_v3_0":9,"cvss_v3_1":34,"cvss_v4_0":9},{"baseScore":35,"baseSeverity":9,"vectorString":36,"impactScore":37,"exploitabilityScore":38},7.8,"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",9.8,4.6,[40],{"ecosystem":41,"name":42,"vendor":43,"product":42,"cpe_part":9,"purl_type":44,"purl_namespace":43,"purl_name":42,"source":9,"versions":45},"Debian","linux","debian","deb",[46,50,54,57,60],{"version":47,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":9,"version_end_type":9,"fixed_in":9},"all",true,"ecosystem",{"version":51,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":52,"version_end_type":53,"fixed_in":9},"lt5_10_257_1","5.10.257-1","excluding",{"version":55,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":56,"version_end_type":53,"fixed_in":9},"lt6_1_170_1","6.1.170-1",{"version":58,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":59,"version_end_type":53,"fixed_in":9},"lt6_12_85_1","6.12.85-1",{"version":61,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":62,"version_end_type":53,"fixed_in":9},"lt6_18_14_1","6.18.14-1"]