WireGuard, the modern VPN protocol integrated into the Linux kernel, recently faced a major bug that could lead to use-after-free issues and memory corruption. This flaw, tracked as CVE-2024-26951, highlights the importance of careful resource management in kernel-level networking code. Let's break down what happened, how it can be exploited, and what the fix looks like, all in plain terms.

TL;DR

CVE-2024-26951 lets an attacker trigger a dangerous use-after-free error by racing WireGuard peer removal and configuration queries, leading to possible memory corruption or even kernel crashes. The issue is fixed in Linux kernel versions after 6.8.-rc2.

The Problem

WireGuard keeps a list of all "peers" (other VPN endpoints) in its kernel module. When removing all peers quickly with wg_peer_remove_all(), the old code did not set the peer list to empty. Instead, it shuffled peers into a temporary list. If an admin or script ran a query (like wg showconf wg) just as this happened, the kernel could try to read info for a peer that no longer exists in memory.

This is called a use-after-free bug: the kernel tries to use memory that's already been freed. Attackers often exploit these to crash the system, leak data, or even run malicious code as root.

This is simplified pseudocode for what happened

void wg_peer_remove_all(struct wg_device *wg_dev) {
    struct list_head temp_list;
    INIT_LIST_HEAD(&temp_list);

    // Move all peers to temp_list instead of marking as dead
    list_splice_init(&wg_dev->peer_list, &temp_list);

    // ...free memory for each peer in temp_list...
    // But queries might still see these since peer_list isn't empty!
}

When a user runs

ip link add dev wg type wireguard
wg setconf wg /big-config
(
    while true; do
        wg showconf wg > /dev/null
    done
) &
sleep 4
wg setconf wg <(printf "[Peer]\nPublicKey=$(wg genkey)\n")

The tool rapidly reads and removes WireGuard peers, causing a race. The kernel tries to dump the peer list for netlink communication, but hits freed memory.

If you trigger this bug, you might see kernel messages like

BUG: KASAN: slab-use-after-free in __lock_acquire+x182a/x1b20
Read of size 8 at addr ffff88811956ec70 by task wg/59
CPU: 2 PID: 59 Comm: wg Not tainted 6.8.-rc2-debug+ #5
Call Trace:
 <TASK>
 dump_stack_lvl+x47/x70
 ...
 wg_get_device_dump+x471/x113

KASAN (Kernel Address Sanitizer) detects the invalid access.

The Fix

Instead of just checking if the peer is still in the list, the code must also check if the peer is "dead".

The member peer->is_dead is a flag used to show if a peer object has been unlinked and is waiting to be fully deleted.

Fixed pseudocode

// When iterating peers for queries:
if (peer->is_dead) {
    // Skip this peer, it has been marked for removal
    continue;
}

In summary:

Hold the right locks when accessing peer data.

Full patch is here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5fff2ba6a2e

Exploit Details

You do not need privileged access to trigger this bug—just the ability to configure the WireGuard interface as root (like for managing VPNs, which is common).

Flood WireGuard with large peer configurations.

2. Rapidly query/show the configuration in a tight userland loop.

This makes the kernel reference a peer object that has just been deleted.

Result:

Possible memory corruption.

_Note: There is no known remote code execution, but such races can become dangerous with other kernel flaws!_

Upstream Linux Patch:

b5fff2ba6a2e: wireguard: netlink: check for dangling peer via is_dead instead of empty list

WireGuard mailing list discussion:

https://lore.kernel.org/wireguard/20240202225219.45969-1-Jason@zx2c4.com/

CVE page:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26951

Recommendations

- Patch your kernel: Make sure you're running at least Linux kernel 6.8. (or the latest update from your distribution with the backported patch).
- Minimize root-level VPN scripting: Until patched, avoid rapidly running config and show commands in parallel.

Conclusion

This bug was a classic case of subtle race conditions in the Linux kernel's networking codebase. The WireGuard team responded quickly, building on defensive coding best-practices. Keeping systems updated and understanding how such bugs can bite is crucial for sysadmins and users alike.

Read more

- WireGuard kernel module
- Netlink & Linux kernel internals


*Want more technical deep dives? Follow and bookmark our blog!*

Timeline

Published on: 05/01/2024 06:15:11 UTC
Last modified on: 05/04/2025 09:00:32 UTC