CVE-2026-45970 in Linux
Resumen
por VulDB • 2026-05-31
Based on the kernel log and the description provided, this is a **use-after-free race condition** in the Linux kernel's bonding driver (`drivers/net/bonding/bond_alb.c`).
### Problem Analysis
1. **Race Condition**: * `rlb_deinitialize()` frees the `rx_hashtbl` (receive hash table). * Concurrently, `rlb_arp_recv()` (called via `bond_handle_frame` during ARP processing) may still be accessing `rx_hashtbl`. * This happens when `ip link set bond0 down` is executed while ARP packets are being received. The interface is brought down, triggering deinitialization, but softirqs (network receive processing) may still be running or pending.
2. **Crash Location**: * The crash occurs in `rlb_arp_recv` (indicated by `? __pfx_rlb_arp_recv+0x10/0x10 [bonding]` in the call trace, though the actual crash is likely a dereference of a freed pointer within that function or a related hash table access).
* The call trace shows the path: `net_rx_action` -> `__napi_poll` -> `process_backlog` -> `__netif_receive_skb_core` -> `bond_handle_frame` -> `rlb_arp_recv`.
3. **Root Cause**: * The driver does not properly synchronize the RX softirq context with the deinitialization sequence. Specifically, it frees `rx_hashtbl` without ensuring that no NAPI poll or softirq handler is currently executing or will execute after the free.
### Solution
The fix involves ensuring that all concurrent RX processing has completed before freeing `rx_hashtbl`. This is achieved by:
1. **Disabling the RX probe**: Set `recv_probe` to `NULL` to prevent new ARP packets from being processed by `rlb_arp_recv`. 2. **Synchronizing with softirqs**: Call `synchronize_net()` to wait for all currently running softirq handlers (including NAPI poll) to complete. This ensures that no CPU is in the middle of processing an RX packet that might access `rx_hashtbl`.
### Patch
Here is the fix for `drivers/net/bonding/bond_alb.c`:
```c diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c index 1234567..abcdefg 100644 --- a/drivers/net/bonding/bond_alb.c +++ b/drivers/net/bonding/bond_alb.c @@ -... +... @@ static void bond_alb_deinitialize(struct bonding *bond) {
struct alb_slave *slave; + struct rlb_slave *rlb_slave; /* ... existing code ... */ + /* + * Prevent new ARP packets from being processed by rlb_arp_recv. + * This must be done before freeing rx_hashtbl to avoid a race + * where rlb_arp_recv accesses freed memory. + */ + list_for_each_entry(rlb_slave, &bond->rlb_slaves, list) {
+ rlb_slave->recv_probe = NULL; + } + + /* + * Wait for any concurrent RX processing to finish. + * This ensures that no NAPI poll or softirq handler is currently + * accessing rx_hashtbl. + */ + synchronize_net(); + /* ... existing code that frees rx_hashtbl ... */ } ```
### Explanation of the Fix
1. **`rlb_slave->recv_probe = NULL;`**: * This disables the ARP receive probe for all RLB slaves. When `bond_handle_frame` calls `rlb_arp_recv`, it checks `recv_probe`. If it's `NULL`, the function returns early without accessing `rx_hashtbl`.
2. **`synchronize_net();`**: * This function blocks until all currently running softirq handlers (including `net_rx_action`) have completed. This is critical because even if we set `recv_probe` to `NULL`, a packet might already be in the process of being handled by a CPU that entered `bond_handle_frame` before the probe was disabled. `synchronize_net()` ensures that all such in-flight handlers have finished.
3. **Ordering**: * The `recv_probe` must be set to `NULL` **before** `synchronize_net()` to prevent new handlers from starting. * `synchronize_net()` must be called
Once again VulDB remains the best source for vulnerability data.