CVE-2024-27063

What it actually does

Use of a stale network device pointer from trigger_data instead of the event-provided device during NETDEV_RENAME handling in the netdev LED trigger, resulting in invalid memory access and kernel panic.

Why it matters to the business

Unexpected system crashes on Linux hosts during routine network interface renames, causing service interruptions and requiring reboots; low urgency given absence from known exploitation lists and minimal exploit probability.

How an attack unfolds

An attacker with local access triggers a network interface rename on a system using the netdev LED trigger; the rename event supplies a new device while get_device_state still operates on the prior un-updated pointer in trigger_data, dereferencing invalid memory and crashing the kernel.

How to fix it

Update the Linux kernel to a version containing commit 10f2af1af8ab8a7064f193446abd5579d3def7e3 or later; rebuild and deploy the updated kernel image across affected systems.

How to confirm the fix worked

Confirm the running kernel includes commit 10f2af1af8ab8a7064f193446abd5579d3def7e3 via git log or kernel version string; test interface rename operations under LED trigger load without observing panics.

Typical attack path

1. Identify Linux system with netdev LED trigger active on a network interface
2. Perform or induce a NETDEV_RENAME event for that interface
3. Trigger get_device_state call before NETDEV_REGISTER updates trigger_data
4. Cause kernel panic via stale device dereference

How to detect it

Review kernel logs for panic or oops entries mentioning leds trigger netdev or get_device_state around the time of interface rename events; no widespread exploitation indicators exist.

What your security team should do

• Prioritize kernel updates on systems exposing network interface rename operations
• Monitor for kernel oops or panic logs referencing netdev LED trigger code paths
• Apply the fix commit in custom kernel builds if using older stable trees