CVE-2024-27021 in Linuxinfo

Summary

by MITRE • 05/01/2024

In the Linux kernel, the following vulnerability has been resolved:

r8169: fix LED-related deadlock on module removal

Binding devm_led_classdev_register() to the netdev is problematic because on module removal we get a RTNL-related deadlock. Fix this by avoiding the device-managed LED functions.

Note: We can safely call led_classdev_unregister() for a LED even if registering it failed, because led_classdev_unregister() detects this and is a no-op in this case.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 02/07/2026

The vulnerability identified as CVE-2024-27021 resides within the Linux kernel's r8169 network driver implementation, specifically addressing a critical deadlock condition that occurs during module removal operations. This issue affects the Realtek r8169 ethernet driver which is commonly used in various network interface cards across different hardware platforms. The problem manifests when the driver attempts to manage LED indicators through device-managed LED functions during the cleanup phase of module unloading, creating a problematic interaction with the kernel's RTNL (Routing Netlink) subsystem.

The technical flaw stems from the improper use of devm_led_classdev_register() function within the driver's module removal path. This device-managed LED registration approach creates a circular dependency situation where the LED cleanup process attempts to acquire RTNL locks that are already held by the module removal mechanism. The RTNL subsystem is responsible for network configuration operations and maintains strict locking mechanisms to ensure consistency during network state changes. When the device-managed LED cleanup routine executes during module removal, it encounters a deadlock condition because it cannot acquire the necessary RTNL locks while they are already occupied by the removal process itself.

This vulnerability represents a classic case of improper resource management within kernel space code, specifically violating the principles outlined in CWE-362 which addresses concurrent execution using locks and similar synchronization mechanisms. The deadlock condition prevents the proper cleanup of network driver resources and can lead to system instability or complete system hangs during driver unloading operations. The issue is particularly concerning because it affects the fundamental module management capabilities of the Linux kernel, potentially preventing administrators from safely updating or removing network drivers from active systems.

The operational impact of this vulnerability extends beyond simple system performance degradation to potential system crashes and service interruptions in production environments where network drivers are frequently updated or reloaded. Network administrators may encounter situations where they cannot safely remove the r8169 module from memory, leading to resource leaks and potential conflicts with newer driver versions. This vulnerability affects systems running Linux kernel versions that include the problematic r8169 driver implementation and poses a risk to server environments, desktop systems, and embedded devices that rely on Realtek network hardware.

The mitigation strategy for CVE-2024-27021 involves modifying the driver code to avoid using device-managed LED functions during the module removal process. The fix implements a direct approach to LED cleanup by calling led_classdev_unregister() without relying on device management frameworks that can cause RTNL deadlocks. This solution aligns with ATT&CK technique T1547.001 which involves establishing persistence through kernel modules, as proper module cleanup is essential for maintaining system stability. The fix leverages the inherent safety of led_classdev_unregister() which handles cases where LED registration failed gracefully, making it safe to call even when the registration process encountered issues. This approach resolves the deadlock condition while maintaining the expected LED functionality for network interface cards that support LED indicators. The solution demonstrates proper kernel module lifecycle management and follows established best practices for resource cleanup in kernel space code, ensuring that driver removal operations complete successfully without leaving the system in an inconsistent state.

Reservation

02/19/2024

Disclosure

05/01/2024

Moderation

accepted

CPE

ready

EPSS

0.00179

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!