CVE-2024-26961 addresses a critical use-after-free vulnerability in the Linux kernel's IEEE 802.15.4 "mac802154" layer, specifically in the logic for deleting link-layer security (LLSEC) keys. The bug allowed kernel memory to be improperly freed and potentially used again, risking memory corruption, crashes, or even local privilege escalation. This post unpacks the bug, provides code references, shows how exploitation was possible, and summarizes the official fix.

*This analysis is exclusive — technical enough for kernel programmers, but clear for security practitioners.*

What Is mac802154 and LLSEC?

- mac802154 is the Linux kernel's driver framework for low-rate wireless personal area networks (like Zigbee).

The problem occurred in the kernel's handling of key management structures (ieee802154_llsec_key_entry), leading to unsafe memory access under certain conditions.

The Root Cause

- When mac802154_llsec_key_del() removed a key, it freed memory immediately, not following the kernel’s RCU (Read Copy Update) safety protocol.
- Parallel lookups via llsec_lookup_key() (such as when sending a wireless frame) could access the key after it was freed—classic "use-after-free".

Evidence in Kernel Logs

refcount_t: addition on ; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+x162/x2a
...
llsec_lookup_key.isra.+x890/x9e
mac802154_llsec_encrypt+x30c/x9c
ieee802154_subif_start_xmit+x24/x1e
...

Additionally

- The deletion didn’t fully free memory; orphaned key structures remained, causing memory leaks and potentially paving the way for heap spraying attacks.

Trigger parallel lookups: As other processes send frames, lookups occur on the key list.

3. Achieve use-after-free: A lookup accesses a key as it’s deleted, possibly using a freed memory region.
4. Escalate: With careful heap manipulation, attackers might reuse this region for controlled data (e.g., inject pointers), potentially escalating privileges or causing a denial of service.

Before: (vulnerable to UAF)

void mac802154_llsec_key_del(struct mac802154_llsec *llsec, u8 key_id)
{
    struct ieee802154_llsec_key_entry *entry;
    // ... search for the key in a list ...
    list_del(&entry->list);
    kfree(entry);   // <<< Freed directly, unsafe!
}

Problem: The entry is freed immediately after being removed from the list, but other threads might still have references to it!

The Patch: How Was It Fixed?

The core idea: Defer freeing memory using RCU.

After: (fixed code pattern)

void mac802154_llsec_key_del(struct mac802154_llsec *llsec, u8 key_id)
{
    struct ieee802154_llsec_key_entry *entry;
    // ... search for the key in a list ...
    list_del_rcu(&entry->list);
    call_rcu(&entry->rcu, mac802154_llsec_key_del_rcu);
}

static void mac802154_llsec_key_del_rcu(struct rcu_head *rcu)
{
    struct ieee802154_llsec_key_entry *entry =
        container_of(rcu, struct ieee802154_llsec_key_entry, rcu);
    kfree(entry); // Safe to free after all pre-existing readers are done
}

With this, the memory is only freed after a "grace period" where the kernel knows nobody is still looking at the old entry.

> Note: llsec_lookup_key() is safe as it increases refcounts and makes copies as needed, meaning after the RCU grace period, it's safe to free memory.

References and Official Sources

- Linux commit: mac802154: fix llsec key resources release in mac802154_llsec_key_del
- CVE Page at Linux Testing Project
- IEEE 802.15.4 documentation – mac802154 subsystem

Patch now if you use wireless PAN networking or have the mac802154 subsystem enabled.

- Check for backports: Many Linux distributions will include the fix in security updates (check your vendor).
- Mitigate race risks: If you maintain custom drivers or extensions for wireless mesh or Zigbee with mac802154, audit your use of RCU patterns.

Acknowledgements

Vulnerability found by:
Linux Verification Center (linuxtesting.org)

Final Thoughts

Use-after-free bugs in kernel code are dangerous, especially in networking where rare races occur. The CVE-2024-26961 patch is an important lesson in safe memory handling, reference counting, and synchronizing access in multi-core systems. If you're building wireless Linux devices, *double-check your code for RCU safety.*

Timeline

Published on: 05/01/2024 06:15:12 UTC
Last modified on: 12/23/2024 13:37:44 UTC