A critical security flaw, CVE-2024-26875, was recently discovered and patched in the Linux kernel’s pvrusb2 media driver. This vulnerability allowed a use-after-free (UAF) condition that could let attackers escalate privileges or execute arbitrary code by exploiting kernel memory corruption. The bug was found and reported with detailed stack traces by Syzbot, a powerful Linux kernel fuzzing tool.

1. What is CVE-2024-26875?

CVE-2024-26875 is a Use-After-Free vulnerability in the pvrusb2_context_set_notify function within the Linux kernel’s pvrusb2 driver. User-attached hardware (like TV tuner USB sticks) can trigger this flaw in some situations, leading to kernel memory corruption.

The bug boils down to the fact that a notifiable context (pointer) can get freed by one thread while another is still trying to access it.

Where is the bug?

The problem lies in the pvr2_context_disconnect() and pvr2_context_set_notify() functions in this file (link to the source).

Let’s summarize what the trace says

BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+x2c4/x310
Read of size 4 at addr ffff888113aebd8 by task kworker/1:1/26
...
kfree+x105/x340 mm/slub.c:4409
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
pvr2_context_thread_func+x69d/x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158

If two tasks (“Task A” and “Task B”) are both operating on the same context, setting a disconnect_flag at the wrong time might let Task B prematurely free the memory. Meanwhile, Task A continues to use this now-invalid memory—BAM! use-after-free.

Simplified Pseudo-code

// This is a simplified flow.
struct pvr2_context {
    int disconnect_flag;
    // ...
};

void pvr2_context_disconnect(struct pvr2_context *mp) {
    // Old (vulnerable) way:
    mp->disconnect_flag = 1; // Task A does this immediately!
    // ... other code that might do kfree(mp) in another thread (Task B)
}

int pvr2_context_set_notify(struct pvr2_context *mp, <...>) {
    // Here, mp could already be freed, leading to UAF!
    if (mp->disconnect_flag)
        // unsafe access!
}

3. Exploiting the Vulnerability

Who can trigger this?
Malicious local users or exploit primitives in untrusted code running on the system which can trigger hotplug events or interact with USB media devices.

How does the exploit work?

1. A specially crafted operation or a series of device events manipulates the USB device and triggers a disconnect at a precise time.
2. This causes one kernel thread to set disconnect_flag, and subsequent kernel logic to free the memory.
3. Meanwhile, another thread (woken up by USB event) still has a pointer to that context and calls pvr2_context_set_notify(), using freed memory.
4. The attacker can leverage this UAF to read or write kernel memory, potentially escalating their privileges or escaping containers.

Example Exploit Snippet

Here’s a notional kernel exploit example. WARNING: This code is for security research and should not be used on production systems.

// Pseudocode only - not a full working exploit
void race_pvr2_disconnect() {
    while (1) {
        // Trigger rapid connect/disconnect
        attach_pvrusb2_device();
        usleep(random_short_delay());
        detach_pvrusb2_device();
    }
}

// In parallel, register for notifications
void spam_set_notify() {
    while (1) {
        pvr2_context_set_notify(context, ...);
    }
}

This brute-force approach races the set_notify against disconnect to increase the chance of exploiting the UAF.

4. The Fix

The solution is straightforward:
Move the setting of disconnect_flag to a later point — after all business with the memory context is done. This prevents other threads from seeing the flag set while the context might be released underneath them.

Patch Example (diff)

-   mp->disconnect_flag = 1;
-   // dangerous: might trigger kfree(mp) right away in another thread!

    // <all other cleanup code>

+   mp->disconnect_flag = 1;
+   // now memory won't be touched after this point

- See the official kernel patch.

If you distribute embedded media hardware using pvrusb2, notify your users!

- Consider using kernel hardening features (KASAN, lockdown, LSMs) to mitigate class-wide vulnerabilities.

6. References and Further Reading

- Kernel commit fixing CVE-2024-26875
- Syzbot report _(actual extid in original report)_
- Linux vulnerability tracker - NVD CVE-2024-26875
- Linux source file: drivers/media/usb/pvrusb2/pvrusb2-context.c

7. Conclusion

CVE-2024-26875 is a great example of how concurrency and race conditions in kernel code can lead to severe vulnerabilities. Developers should always be mindful of pointer lifetimes, especially in code where threads and hardware events can free memory at unpredictable times. If you're maintaining or using Linux-based devices with pvrusb2 media hardware, make sure your kernels are up to date!

Stay informed, and patch fast!

*Exclusive writeup by AI for educational purposes. If you share, please link back!*

Timeline

Published on: 04/17/2024 11:15:09 UTC
Last modified on: 08/08/2024 19:35:13 UTC