---

Executive Summary

A critical deadlock (CVE-2022-49305) was identified and patched in the Linux kernel’s Realtek rtl8192u wireless driver. This bug could hang the kernel, leading to system freezes when handling wireless beacons. Let’s break down exactly what went wrong, how to spot the issue, read the code, and understand the fix.

The Vulnerability Explained

The bug exists in the “staging” Realtek 8192u driver. The problem is a classic deadlock scenario involving the function ieee80211_beacons_stop() and the Linux timer subsystem — specifically, the use of spin_lock_irqsave() and del_timer_sync().

Simple Deadlock Timeline

| Thread 1 (ieee80211_beacons_stop) | Thread 2 (Timer Handler) |
|-------------------------------------------------------|-----------------------------------|
| spin_lock_irqsave() (acquire beacon_lock) | |
| ... | ieee80211_send_beacon() |
| del_timer_sync() (wait for timer to finish) | mod_timer() (schedules timer) |
| (timer handler wants beacon_lock, but it's taken) | ieee80211_send_beacon_cb() |
| Deadlock! | spin_lock_irqsave() (wants lock) |

Result: System deadlock, requiring a hard reboot or a kernel panic.

Here’s a simplified version of the vulnerable code in the driver

void ieee80211_beacons_stop(struct ieee80211_device *ieee)
{
    unsigned long flags;
    spin_lock_irqsave(&ieee->beacon_lock, flags);
    del_timer_sync(&ieee->beacon_timer); // Deadlocks here if timer running
    spin_unlock_irqrestore(&ieee->beacon_lock, flags);
}

And in the timer callback

void ieee80211_send_beacon_cb(unsigned long data)
{
    struct ieee80211_device *ieee = (struct ieee80211_device *)data;
    unsigned long flags;
    spin_lock_irqsave(&ieee->beacon_lock, flags);
    // ... work ...
    spin_unlock_irqrestore(&ieee->beacon_lock, flags);
}

Both use spin_lock_irqsave() on beacon_lock.

- If del_timer_sync() waits for a timer callback that’s also waiting for the same lock, they block each other.

The Fix

The fix is to only hold the lock while necessary. Specifically, release the lock before calling del_timer_sync(), so the timer handler can run and finish.

Corrected code

void ieee80211_beacons_stop(struct ieee80211_device *ieee)
{
    unsigned long flags;

    spin_lock_irqsave(&ieee->beacon_lock, flags);
    // pre-timer work; no del_timer_sync yet
    spin_unlock_irqrestore(&ieee->beacon_lock, flags);

    del_timer_sync(&ieee->beacon_timer); // Now it's safe
}

Why is this safe?

References

- Original CVE-2022-49305 entry
- Patch commit in kernel source
- Linux Kernel Staging rtl8192u driver

How could attackers abuse it?

- Denial of Service: A malicious process or a bug in wireless management tools could trigger ieee80211_beacons_stop() while beacons are active, freezing the whole system.
- Privileged Context: Exploitation requires ability to affect the wireless layer — usually only root or driver access.
- Affected Systems: Linux boxes using the Realtek rtl8192u "staging" driver (usually older USB wifi adapters).

Proof of Concept

While a direct proof-of-concept is just racing these two code paths (kernel module actions + timer callback), you could simulate via:

# This is not an actual exploit but shows the issue
# Unload driver while it's busy sending beacons
modprobe rtl8192u
# Start or connect to a wireless network
# Then immediately remove the module
rmmod rtl8192u
# If unlucky kernel will freeze due to deadlock

Summary

- CVE-2022-49305 was a classic slumber-party deadlock: two pieces of code waiting on each other, neither budging.
- Only the Linux "staging" driver for rtl8192u is affected, but the lesson applies to all lock + timer code.
- The fix is simple: never block on del_timer_sync() while holding a spinlock needed by the timer callback.

Want to Learn More?

- Linux Device Drivers, Third Edition (Chapter 5: Concurrency and Race Conditions)
- Kernel Locking Primer

Stay secure! If you have this hardware, patch your kernel or swap the driver ASAP.

Timeline

Published on: 02/26/2025 07:01:07 UTC
Last modified on: 04/14/2025 20:06:16 UTC