A recent vulnerability discovered in the Linux kernel posed a serious threat to many systems. This issue, identified as CVE-2024-27063, was related to the leds: trigger: netdev component and led to kernel panic upon a network interface rename trig being notified. This article will discuss the root cause of this vulnerability, the solution implemented to fix it, and the implications on the overall kernel security.

The Vulnerability

The vulnerability arose from two distinct commits in Linux kernel development. The first, d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") introduced a series of changes reworking the way the LINKUP mode is set in the kernel. The second, cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") moved the LINKUP mode to a generic function.

This change in logic led to potential issues and kernel panic in some cases. In the old implementation, the device from the trigger event was used to check if the carrier was OK. However, in the new implementation with the generic function, the device in trigger_data was used instead.

This led to a problematic situation where the device in trigger_data still referenced the old data while the new device (passed from the trigger event) had to be held and saved in the trigger_data struct. When calling get_device_state(), an invalid net_dev was used, causing a kernel panic.

Solution

To address this vulnerability, the call to get_device_state() was moved after the new net_dev was correctly set in trigger_data (in the NETDEV_REGISTER case). This ensured that the new device was parsed correctly and eliminated the likelihood of a kernel panic.

For a better understanding, the following code snippet presents the essential change made to fix this vulnerability:

// Old implementation: 
...
if (!led_dev->trigger_data || led_dev->get_device_state != get_device_state)
...
  get_device_state(new_dev);
...

// New implementation:
...
if (!led_dev->trigger_data || led_dev->get_device_state != get_device_state)
...
else {
  led_dev->trigger_data = new_dev;
  get_device_state(new_dev);
}

Implications

The successful resolution of CVE-2024-27063 reinforces the importance of constant vigilance and ongoing development in the Linux kernel. This specific vulnerability could have led to severe disruptions in various systems that rely on Linux. By identifying and addressing this issue, developers have helped maintain the overall security and stability of the kernel.

References

1. Linux kernel repository - commit d5e01266e7f5
2. Linux kernel repository - commit cee4bd16c319

Timeline

Published on: 05/01/2024 13:15:50 UTC
Last modified on: 05/29/2024 05:27:53 UTC