CVE-2024-44937 - Linux Kernel `intel-vbtn` ACPI Notify Handler Race Condition Exploit and Patch Analysis

CVE-2024-44937 is a recently patched race condition in the Linux kernel, specifically in the platform/x86 driver for Intel Virtual Button (VBTN) devices (intel-vbtn). This issue could allow for kernel crashes (NULL pointer dereference) or file system errors when ACPI notify handlers run concurrently on multiple CPU cores—a situation that was made possible after an upstream kernel change.

In this post, we'll walk you through what caused the bug, how it could be exploited (with sample code snippets), and how the mainline Linux kernel fixed it. If you're running Linux on Intel-based laptops or tablets (notably some Dell Venue devices), this information is especially relevant.

Technical Background

intel-vbtn is a Linux kernel driver that exposes ACPI Virtual Button events to user space—these are the signals from the hardware for things like tablet mode switches, lid closures, etc.

ACPI Notify Handler: Handles events from the ACPI firmware.

- Race Condition: Since kernel v6.5 (commit e2ffcda16290), notify handlers can be triggered on multiple CPUs *at the same time*.
- The Vulnerability: Without extra protection in intel-vbtn, two notify handlers could try to register the same input device simultaneously.

This double-registration attempt eventually leads to kernel warnings (about duplicate devices) and a fatal kernel crash (NULL pointer dereference).

Suppose two CPUs trigger the event at the same time (for example, undocking a Dell Venue tablet)

[ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event
[ 83.861858] input: Intel Virtual Switches as /devices/pci000:00/000:00:1f./PNPC09:00/INT33D6:00/input/input17
[ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event

But only one registration should succeed! Instead, the kernel tries to create two devices with the same name:

[ 83.861872] sysfs: cannot create duplicate filename '/devices/pci000:00/000:00:1f./PNPC09:00/INT33D6:00/input/input17'
[ 83.861967] kobject: kobject_add_internal failed for input17 with -EEXIST, don't try to register things with the same name in the same directory.
[ 83.877338] BUG: kernel NULL pointer dereference, address: 0000000000000018

The crash follows from trying to clean up a device that was only half-initialized.

Exploit Scenario (POC & Impact)

While the flaw is not a direct privilege escalation, it's a denial of service with possible data loss or system instability. An attacker with physical access could potentially cause the race on purpose (by rapidly undocking and docking the keyboard or sending crafted ACPI events) to crash the system.

Proof-of-concept (as root or via physical access)

# Simulate rapid undocking (on a vulnerable device)
for i in {1..10}; do
    echo "event" > /sys/devices/pci000:00/000:00:1f./PNPC09:00/INT33D6:00/notify
    sleep .01
done

Or trigger two ACPI switch events in close succession from different users or scripts.

Effect: You may see kernel logs about duplicate devices and, ultimately, the system may freeze or auto-reboot from the NULL pointer dereference.

The old code simply registered the device without any lock

static void notify_handler(...)
{
    /* ... */
    if (!priv->switches_dev) {
        /* Register new input device */
        priv->switches_dev = input_allocate_device();
        /* ... */
        input_register_device(priv->switches_dev); // <--- Potential for race/double-registration
    }
}

Race Condition: Two notify_handler calls could both see !priv->switches_dev and both try to register the device simultaneously.

Fixed Code (After Patch)

Reference: Upstream Patch Link

The handler now uses a mutex to ensure only one registration at a time

static void notify_handler(...)
{
    mutex_lock(&priv->event_lock);

    if (!priv->switches_dev) {
        /* Register new input device */
        priv->switches_dev = input_allocate_device();
        /* ... */
        input_register_device(priv->switches_dev);
    }

    mutex_unlock(&priv->event_lock);
}

This ensures that only one handler at a time can check and (if necessary) register the input device, protecting against races.

How To Protect Your Systems

- Update your Kernel: Apply the latest stable kernel update (at least kernel version containing the fix).
- Check for Vendor Patches: If you use an LTS or vendor-specific kernel, verify when/if the fix lands. Search for "CVE-2024-44937" in your distribution's advisories:
- Debian Security Tracker
- Red Hat Bugzilla
- Mitigation: If you can't update, avoid rapidly cycling ACPI events (undock/dock) on affected devices until patched.

Conclusion

CVE-2024-44937 shows that even simple hardware drivers can become security issues, especially as core kernel behavior changes. If you use hybrid laptops or tablets running recent Linux kernels, update now to avoid race conditions that could crash your device. The fix is simple—a mutex—but without it, a fundamental kernel component could be taken down by something as basic as undocking your keyboard.

Stay patched, and check your dmesg logs for any "duplicate device" warnings, especially on Dell Venue tablets or similar Intel-based systems.

*This post is exclusive content, written to clearly explain the bug, risk, and fix in plain language. Contributions and corrections welcome!*

Timeline

Published on: 08/26/2024 11:15:05 UTC
Last modified on: 08/27/2024 16:10:11 UTC