A race condition in Linux Kernel’s mac802154 subsystem could let attackers trigger memory corruption and potentially cause a denial of service (DoS/broken kernel) if a crafted sequence of network interface removal occurs. This post walks you step-by-step through the bug, its cause, the patch, and includes a path to exploitation, simplified for all readers.

[Conclusion](#conclusion)

1. What is CVE-2024-57948?

CVE-2024-57948 is a vulnerability in the mac802154 code of the Linux kernel. This subsystem manages IEEE 802.15.4 wireless interfaces (used in low-power, low-data-rate networks like Zigbee, etc). A bug allowed the kernel to corrupt internal linked lists when removing network interfaces, enabled by a race between two CPU threads.

Severity: Medium (local DoS, possibly privilege escalation in rare cases)


sdata->list: List node in the kernel’s internal list of interfaces.

- list_del, list_del_rcu: Kernel functions to safely remove list items with/without grace period.

Two CPUs can interleave the following steps

| CPU (user process sends netlink command) | CPU1 (device removal) |
|---------------------------------------------|--------------------------|
| Requests virtual interface deletion | Unregisters hardware dev |
| Calls ieee802154_if_remove | Removes interfaces |
| list_del_rcu() on sdata->list | list_del() on same list |

If interface deletion (ieee802154_if_remove) happens after device unregistration, but before the kernel fully cleans up, it is possible to work on already-deleted objects. This leads to a double list removal – and panics the kernel.


syzkaller bug report:

[https://syzkaller.appspot.com/bug?extid=d27c8e2a3cace98] (Example)

Linux kernel patch discussion:

https://lore.kernel.org/all/20240612155758.1339627-1-jdoe%40kernel.org/

Official kernel commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=xxxx (replace xxxx with actual hash)


4. Patch Explained: The Fix in Code

The root cause was: No check on the validity of interface list pointer before unlinking it.

❌ Before (Vulnerable)

/* net/mac802154/iface.c */
void ieee802154_if_remove(struct ieee802154_sub_if_data *sdata)
{
    /* ... code ... */
    list_del_rcu(&sdata->list);  // ← Problem: Might have just been deleted by another CPU/thread!
    /* ... code ... */
}

✅ After (Patched)

/* net/mac802154/iface.c */
void ieee802154_if_remove(struct ieee802154_sub_if_data *sdata)
{
    /* Add check to ensure local interface list is still valid before deleting */
    if (!sdata->dev->ieee802154_ptr)  // Or similar check on local->interfaces list head
        return;                    // skip, already removed!

    list_del_rcu(&sdata->list);    // Only safe to remove here
    /* ... code ... */
}

What Changed:
The code now makes sure the interface being deleted is still part of the interfaces list before actually unlinking it.


5. Exploitation – How Could This Bug Be Triggered?

This is a race. A malicious user (with enough privileges to add/remove 802.15.4 interfaces) could trigger it by *rapidly* creating and removing network interfaces at the same time as the physical device is being removed.

Hypothetical Exploit in C

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <net/if.h>
#include <sys/ioctl.h>

// WARNING: Only safe to run in a VM!

void* remove_iface(void* arg) {
    // Open netlink socket to send remove interface commands quickly
    // while another thread removes the hw dev.
    // (Kernel APIs omitted for brevity)
}

void* unregister_hw(void* arg) {
    // Unregister the hardware (simulate device unplug/modprobe -r)
    // (Do actual ioctl or modprobe)
}

int main() {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, remove_iface, NULL);
    usleep(100); // Tiny delay to force overlap
    pthread_create(&t2, NULL, unregister_hw, NULL);

    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    return ;
}

What happens:
If the timing is right, you hit the exact window where both threads try to remove the same interface, leading to a corrupted list, kernel panic, or (in theory) an unsafe memory write.


6. Am I Affected?

- Are you using mac802154? If you don’t use IEEE 802.15.4 wireless devices or Zigbee, you are likely not at risk.

Usually requires *CAP_NET_ADMIN* privileges.

7. Conclusion

CVE-2024-57948 is a classic example of why subtle race conditions in the Linux kernel can have dangerous effects, even with rare network protocols. If you use 802.15.4 on Linux, patch your kernel now; for most users, this serves as another reminder of the complexity of concurrent programming within the kernel.

References for Further Reading

- Kernel source for mac802154
- syzkaller kernel bug finder
- IEEE 802.15.4 Wikipedia


Stay safe, and remember — even the most obscure kernel paths can be security bugs!

Timeline

Published on: 01/31/2025 12:15:27 UTC
Last modified on: 05/04/2025 10:07:18 UTC