CVE-2024-43867

What it actually does

Refcount underflow in nouveau_bo when nouveau_bo_ref() is called on an uninitialized object during drm_gem_object_init() unwind, allowing use-after-free in the TTM backing buffer.

Why it matters to the business

Kernel instability or potential privilege escalation on Linux systems using the Nouveau GPU driver; high ecosystem prevalence increases exposure across servers, desktops, and Android devices with affected SoCs.

How an attack unfolds

An attacker with local access crafts a sequence of DRM/GEM operations that forces the error path in prime handling, triggering the uninitialized refcount decrement and subsequent use-after-free for memory corruption or code execution. Mentioned threat actors have targeted similar Linux kernel uninitialized resource issues in espionage and financially motivated campaigns.

How to fix it

Upgrade the Linux kernel to a version containing commit 3bcb8bba72ce89667fa863054956267c450c47ef or later; for Android devices apply the SoC vendor fix dated 2020-12-05 or newer kernel with the backport.

How to confirm the fix worked

Verify kernel source contains the referenced commit or check dmesg/modinfo for driver version post-update; confirm nouveau module no longer exhibits the underflow path via code review or targeted fuzzing.

Typical attack path

1. Obtain local unprivileged access on a system with Nouveau driver loaded
2. Trigger DRM prime import/export or GEM object creation that enters drm_gem_object_init() error unwind
3. Cause nouveau_bo_ref() on uninitialized nouveau_bo
4. Induce refcount underflow leading to premature object release
5. Reuse freed memory for privilege escalation or denial of service

How to detect it

Review kernel logs for nouveau or ttm refcount warnings, audit process activity involving /dev/dri or GEM handles around crash times, and correlate with any zero-day exploitation patterns reported by the listed threat actors.

What your security team should do

• Prioritize kernel updates on all systems using the Nouveau driver due to 782 days of public exposure
• Restrict unprivileged access to DRM/GEM interfaces via LSM or container policies until patched
• Monitor EPSS trend stability and re-evaluate if exploit maturity increases