FKIE_CVE-2025-68758

Vulnerability from fkie_nvd - Published: 2026-01-05 10:15 - Updated: 2026-01-19 13:16
Severity ?
Summary
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 = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; 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.
Impacted products
Vendor Product Version

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbacklight: led-bl: Add devlink to supplier LEDs\n\nLED Backlight is a consumer of one or multiple LED class devices, but\ndevlink is currently unable to create correct supplier-producer links when\nthe supplier is a class device. It creates instead a link where the\nsupplier is the parent of the expected device.\n\nOne consequence is that removal order is not correctly enforced.\n\nIssues happen for example with the following sections in a device tree\noverlay:\n\n    // An LED driver chip\n    pca9632@62 {\n        compatible = \"nxp,pca9632\";\n        reg = \u003c0x62\u003e;\n\n\t// ...\n\n        addon_led_pwm: led-pwm@3 {\n            reg = \u003c3\u003e;\n            label = \"addon:led:pwm\";\n        };\n    };\n\n    backlight-addon {\n        compatible = \"led-backlight\";\n        leds = \u003c\u0026addon_led_pwm\u003e;\n        brightness-levels = \u003c255\u003e;\n        default-brightness-level = \u003c255\u003e;\n    };\n\nIn this example, the devlink should be created between the backlight-addon\n(consumer) and the pca9632@62 (supplier). Instead it is created between the\nbacklight-addon (consumer) and the parent of the pca9632@62, which is\ntypically the I2C bus adapter.\n\nOn removal of the above overlay, the LED driver can be removed before the\nbacklight device, resulting in:\n\n    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n    ...\n    Call trace:\n     led_put+0xe0/0x140\n     devm_led_release+0x6c/0x98\n\nAnother way to reproduce the bug without any device tree overlays is\nunbinding the LED class device (pca9632@62) before unbinding the consumer\n(backlight-addon):\n\n  echo 11-0062 \u003e/sys/bus/i2c/drivers/leds-pca963x/unbind\n  echo ...backlight-dock \u003e/sys/bus/platform/drivers/led-backlight/unbind\n\nFix by adding a devlink between the consuming led-backlight device and the\nsupplying LED device, as other drivers and subsystems do as well."
    }
  ],
  "id": "CVE-2025-68758",
  "lastModified": "2026-01-19T13:16:12.037",
  "metrics": {},
  "published": "2026-01-05T10:15:56.897",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/08c9dc6b0f2c68e5e7c374ac4499e321e435d46c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0e63ea4378489e09eb5e920c8a50c10caacf563a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/30cbe4b642745a9488a0f0d78be43afe69d7555c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/60a24070392ec726ccfe6ad1ca7b0381c8d8f7c9"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/64739adf3eef063b8e2c72b7e919eac8c6480bf0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9341d6698f4cfdfc374fb6944158d111ebe16a9d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/cd01a24b3e52d6777b49c917d841f125fe9eebd0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e06df738a9ad8417f1c4c7cd6992cda320e9e7ca"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…