CVE-2024-26951

What it actually does

Use-after-free in WireGuard netlink peer iteration during concurrent wg_peer_remove_all() and resumed device dump, allowing access to freed peer objects protected only by is_dead flag.

Why it matters to the business

Local users on WireGuard-enabled Linux systems can trigger kernel crashes or potential arbitrary code execution, leading to denial of service or full host compromise; high urgency for any server or endpoint using WireGuard tunnels despite low exploitation probability.

How an attack unfolds

An attacker with local access creates a WireGuard interface, loads a large peer configuration, then repeatedly runs wg showconf in one process while removing or replacing peers in another; a resumed netlink dump follows a dangling peer pointer into freed memory, causing KASAN-detected slab-use-after-free during lock acquisition.

How to fix it

Upgrade the Linux kernel to a version containing commit f52be46e3e6ecefc2539119784324f0cbc09620a or apply the equivalent stable backport; for packaged distributions apply the corresponding fixed phpsysinfo packages where applicable and reboot affected systems.

How to confirm the fix worked

Confirm kernel version contains the is_dead check in wg_get_device_dump and get_peer; reproduce the provided reproducer script and verify absence of KASAN slab-use-after-free reports; run automated kernel regression tests exercising WireGuard netlink dump under peer churn.

Typical attack path

1. Obtain local shell or script execution on target Linux host
2. Create WireGuard interface and apply large peer configuration via wg setconf
3. Launch concurrent loop executing wg showconf while issuing peer removal or replacement commands
4. Trigger netlink dump resumption against a peer removed via wg_peer_remove_all()
5. Access freed peer structure leading to use-after-free during lock_acquire

How to detect it

Review kernel logs for KASAN reports citing __lock_acquire, get_peer, or wg_get_device_dump with slab-use-after-free; search audit logs for sequences of wg setconf followed immediately by wg showconf under high peer churn; inspect crash dumps for dangling peer pointers originating from wg_peer_remove_all stacks.

What your security team should do

• Prioritize kernel updates on all systems exposing WireGuard interfaces within 30 days
• Restrict unprivileged local access to wg configuration commands until patched
• Monitor for kernel oops or KASAN reports mentioning wg_get_device_dump or get_peer
• Test WireGuard configurations in staging before deploying the fix broadly