CVE-2024-44967

What it actually does

The vulnerability is a use-after-free caused by releasing the I2C adapter via devm-managed cleanup when the Linux device disappears while a stale pointer remains in struct drm_connector.ddc for the mgag200 DRM driver.

Why it matters to the business

Systems using affected Linux kernels with mgag200 graphics hardware face elevated risk of kernel instability or crashes; the low EPSS and absence from KEV indicate limited real-world exploitation but still require prompt patching to avoid local impact on graphics subsystems.

How an attack unfolds

An attacker with local access triggers device removal or driver unload timing that frees the I2C adapter before the connector is cleaned up, dereferencing the dangling pointer in drm_connector.ddc to achieve use-after-free; listed threat actor campaigns targeting Linux kernel issues provide context for potential local privilege escalation attempts.

How to fix it

Update the Linux kernel to a version containing commit 55a6916db77102765b22855d3a0add4751988b7c or later stable releases that bind I2C adapter lifetime to the DRM connector using DRM managed release instead of devm.

How to confirm the fix worked

Verify the running kernel contains the fix commit 55a6916db77102765b22855d3a0add4751988b7c, confirm no stale ddc pointer warnings appear during device removal, and test connector cleanup ordering on mgag200 hardware.

Typical attack path

1. Obtain local user access on a system with the mgag200 DRM driver loaded
2. Trigger or wait for Linux device removal that activates devm cleanup of the I2C adapter
3. Force access to the stale ddc pointer in the still-active drm_connector
4. Exploit the resulting use-after-free for memory corruption or denial of service

How to detect it

Review kernel logs for use-after-free warnings or oops involving drm_connector and i2c during device teardown; examine dmesg and audit logs around graphics driver load/unload events for patterns matching the mgag200 I2C release sequence.

What your security team should do

• Prioritize kernel upgrades on all systems exposing the mgag200 driver within the next patching cycle given the 7.8 CVSS
• Monitor upstream stable kernel releases for backports of the lifetime binding change
• Audit graphics driver usage in production workloads and restrict local access where feasible until patched