CVE-2024-39465

What it actually does

Calling debugfs_remove_recursive() on a parent directory followed by the same call on a child directory triggers a kernel panic due to invalid state in the debugfs hierarchy.

Why it matters to the business

Systems using the mgb4 media driver may experience unexpected kernel crashes, leading to downtime and potential loss of media capture functionality until the kernel is updated.

How an attack unfolds

An attacker with local access triggers the mgb4 driver initialization or teardown paths that invoke the double debugfs removal; no remote or unauthenticated exploitation path is known and no named threat actors have been observed using it.

How to fix it

Update the Linux kernel to a version containing commit 252204b634efffd8b167d77413c93d0192aaf5f6 or later; for Debian-based distributions apply the 6.5+dfsg1-1 package or newer equivalent.

How to confirm the fix worked

Verify the running kernel contains the fix commit or package version, then load the mgb4 driver and confirm no panic occurs during module insertion and removal while debugfs entries are present.

Typical attack path

1. Obtain local access to a system running an affected kernel with the mgb4 driver loaded
2. Trigger driver probe or removal operations that register and then recursively remove debugfs entries
3. Cause the kernel to panic when the child removal follows the parent removal

How to detect it

Review kernel logs for panic messages mentioning debugfs_remove_recursive and mgb4; inspect module load/unload events around the time of any crash.

What your security team should do

• Prioritize kernel updates on any system exposing the mgb4 driver
• Monitor for kernel oops or panic logs related to debugfs_remove_recursive
• Apply the fix in all stable kernel trees before the next scheduled maintenance window