Direct naar de inhoud
⚡ Kritieke cyberalerts voor jouw sector & systemen — direct in je inbox. Aanmelden →
cybernieuws.nl Cybersecurity en informatiebeveiling nieuws alerts live · 5 min 165 bronnen 1 kritiek 16 vandaag
CVE's Videos Dagbriefing

← Terug naar CVE-database

CVE-2025-68758

NONE Gepubliceerd:

Beschrijving NL

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

backlight: led-bl: Add devlink to supplier LEDs

LED Backlight is a consumer of one or multiple LED class devices, but
devlink is currently unable to create correct supplier-producer links when
the supplier is a class device. It creates instead a link where the
supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree
overlay:

// An LED driver chip
pca9632@62 {
compatible = "nxp,pca9632";
reg = ;

// ... addon_led_pwm: led-pwm@3 {
reg = ;
label = "addon:led:pwm";
};
};

backlight-addon {
compatible = "led-backlight";
leds = ;
brightness-levels = ;
default-brightness-level = ;
};

In this example, the devlink should be created between the backlight-addon
(consumer) and the pca9632@62 (supplier). Instead it is created between the
backlight-addon (consumer) and the parent of the pca9632@62, which is
typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the
backlight device, resulting in:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
... Call trace:
led_put+0xe0/0x140
devm_led_release+0x6c/0x98

Another way to reproduce the bug without any device tree overlays is
unbinding the LED class device (pca9632@62) before unbinding the consumer
(backlight-addon):

echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind
echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind

Fix by adding a devlink between the consuming led-backlight device and the
supplying LED device, as other drive rs and subsystems do as well.

Origineel (Engels) tonen

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

backlight: led-bl: Add devlink to supplier LEDs

LED Backlight is a consumer of one or multiple LED class devices, but
devlink is currently unable to create correct supplier-producer links when
the supplier is a class device. It creates instead a link where the
supplier is the parent of the expected device.

One consequence is that removal order is not correctly enforced.

Issues happen for example with the following sections in a device tree
overlay:

// An LED driver chip
pca9632@62 {
compatible = "nxp,pca9632";
reg = ;

// ...

addon_led_pwm: led-pwm@3 {
reg = ;
label = "addon:led:pwm";
};
};

backlight-addon {
compatible = "led-backlight";
leds = ;
brightness-levels = ;
default-brightness-level = ;
};

In this example, the devlink should be created between the backlight-addon
(consumer) and the pca9632@62 (supplier). Instead it is created between the
backlight-addon (consumer) and the parent of the pca9632@62, which is
typically the I2C bus adapter.

On removal of the above overlay, the LED driver can be removed before the
backlight device, resulting in:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
...
Call trace:
led_put+0xe0/0x140
devm_led_release+0x6c/0x98

Another way to reproduce the bug without any device tree overlays is
unbinding the LED class device (pca9632@62) before unbinding the consumer
(backlight-addon):

echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind
echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind

Fix by adding a devlink between the consuming led-backlight device and the
supplying LED device, as other drivers and subsystems do as well.

References