CVE-2024-27021: r8169: fix LED-related deadlock on module removal
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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel reliability vulnerability in the Realtek r8169 network driver. A bug in LED cleanup can deadlock the system when the driver module is removed. The main business risk is disruption during driver unload, maintenance, or kernel/module changes on affected hosts, not confirmed remote compromise.
Executive priority
Treat as routine patch management unless affected systems are operationally sensitive or frequently reload network drivers. Prioritize servers where a kernel deadlock would cause downtime during maintenance.
Technical view
The r8169 driver used device-managed LED registration tied to the network device. During module removal, that cleanup path can create an RTNL-related deadlock. The kernel fix avoids device-managed LED functions and explicitly unregisters LED class devices safely.
Likely exposure
Exposure is likely limited to Linux systems running affected kernel builds with the r8169 Realtek Ethernet driver present. The source bundle lists Linux 6.8-era affected versions and references stable kernel fixes and Fedora kernel announcements.
Exploitation context
The bundle does not show active exploitation, and KEV is false. The described trigger is module removal, suggesting local operational or maintenance conditions rather than internet-facing attack exposure. No CVSS score or CWE is provided.
Researcher notes
Evidence supports a deadlock bug fixed in Linux stable commits, but the bundle lacks CVSS, detailed version ranges, exploitability analysis, and broad vendor coverage. Avoid assuming remote exploitability or privilege escalation from the provided data.
Mitigation direction
Update to a vendor kernel containing the referenced stable r8169 fixes.
Apply relevant distribution kernel advisories, including Fedora updates where applicable.
Avoid unnecessary r8169 module unload or reload operations until patched.
Check vendor guidance if using custom or backported kernels.
Validation and detection
Inventory Linux kernel versions against vendor fixed-package status.
Identify hosts using the r8169 driver for Realtek Ethernet devices.
Confirm kernel source or changelog includes the referenced stable commits.
Review maintenance logs for hangs during r8169 unload or network driver changes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-27021 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.