CVE-2024-27021

What it actually does

Causes an RTNL-related deadlock on r8169 module removal because devm_led_classdev_register binds LED handling to the netdev, preventing clean teardown.

Why it matters to the business

Driver unload operations can hang the system, interrupting network availability and requiring manual intervention or reboot to recover.

How an attack unfolds

An attacker with local privileges triggers module removal on a system using the r8169 driver, causing the deadlock during LED class device cleanup.

How to fix it

Apply the upstream fix that replaces device-managed LED registration with explicit led_classdev_register/unregister calls; rebuild and deploy the corrected kernel module.

How to confirm the fix worked

Confirm the patch is present by inspecting the r8169 source for direct led_classdev_unregister calls and test module load/unload cycles for absence of deadlock.

Typical attack path

1. Gain local user access on an affected Linux system
2. Unload or trigger removal of the r8169 kernel module
3. Exploit the missing non-device-managed LED registration to induce RTNL deadlock

How to detect it

Review kernel logs for hung task warnings or RTNL lock contention involving r8169 and LED classdev operations during module unload events.

What your security team should do

• Prioritize kernel updates containing the r8169 LED fix on all affected systems
• Test module removal in staging environments before production rollout
• Monitor kernel changelogs for related networking driver stability updates