In the Linux kernel, the following vulnerability has been resolved:
leds: trigger: netdev: Fix kernel panic on interface rename trig notify
Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link
speed mode") in the various changes, reworked the way to set the LINKUP
mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck
NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function.
This changed the logic where, in the previous implementation the dev
from the trigger event was used to check if the carrier was ok, but in
the new implementation with the generic function, the dev in
trigger_data is used instead.
This is problematic and cause a possible kernel panic due to the fact
that the dev in the trigger_data still reference the old one as the
new one (passed from the trigger event) still has to be hold and saved
in the trigger_data struct (done in the NETDEV_REGISTER case).
On calling of get_device_state(), an invalid net_dev is used and this
cause a kernel panic.
To handle this correctly, move the call to get_device_state() after the
new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER
case) and correctly parse the new dev.
Security readout for executives and security teams
Plain-English summary
CVE-2024-27063 is a Linux kernel flaw that can crash the kernel when a network interface is renamed while the netdev LED trigger state is being updated. The business impact is availability loss, not proven data theft. Public sources do not provide CVSS, confirmed exploitation, or distribution-specific package guidance.
Executive priority
Treat as a targeted availability risk. It does not currently justify emergency response based on the provided evidence, but kernel crashes can affect critical services, so include it in normal kernel patch cycles with higher priority for sensitive infrastructure.
Technical view
The issue is in the Linux kernel LED netdev trigger. A logic change caused state checks to use an old net_device pointer during interface rename handling, leading to invalid net_dev use and possible kernel panic. Stable kernel commit references are provided, but source data does not map them to every vendor package.
Likely exposure
Exposure is most likely on Linux systems running affected kernel versions or kernels containing the referenced regressing commit, especially where netdev LED triggers and interface rename events occur. The bundle lists Linux 6.5, 6.6.24, 6.7.12, 6.8.3, and 6.9 as affected data points.
Exploitation context
The provided sources describe a kernel panic condition, but do not state active exploitation, attacker requirements, remote reachability, or public exploit availability. KEV is false in the source bundle, so active exploitation should not be assumed.
Researcher notes
The key condition is stale net_device use during NETDEV_REGISTER handling after a rename notification. Validate exposure by correlating affected kernel lineage with the LED netdev trigger code path. The source bundle lacks CVSS, CWE, exploitability details, and vendor package mappings.
Mitigation direction
Apply Linux kernel or distribution updates that include the referenced stable fixes.
Check vendor advisories for exact fixed package versions before rollout.
Prioritize internet infrastructure, appliances, and systems sensitive to availability loss.
Where patching is delayed, reduce unnecessary interface rename operations if operationally feasible.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and embedded systems.
Check whether deployed kernels include the referenced stable fix commits.
Identify systems using the LED netdev trigger component or network interface renaming workflows.
Review crash logs for kernel panic events around netdev rename activity.
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-27063 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.