Re: [PATCH v7 8/9] leds: st1202: validate LED reg property against channel count
| Newsgroups | org.kernel.vger.linux-leds |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] The driver assigns a sleepable function to the LED subsystem's non-blocking `brightness_set` callback, leading to "scheduling while atomic" kernel panics. -- Note: The format of this review is altered to use a free-form summary instead of inline diff quotes due to recitation restrictions. commit e35dcdba8764dc455863a8cb25600d5218b1d1a5 Author: Manuel Fombuena <[email protected]> leds: st1202: validate LED reg property against channel count The reg property from the device tree is used directly as an array index into chip->leds[] without bounds checking. A value >= ST1202_MAX_LEDS would cause an out-of-bounds write during probe. [Severity: High] This is a pre-existing issue, but does this code cause a "scheduling while atomic" panic when a software trigger like heartbeat or timer is configured? In drivers/leds/leds-st1202.c during st1202_dt_init(), the driver assigns st1202_brightness_set to led->led_cdev.brightness_set. The brightness_set callback is expected to be non-blocking by the LED subsystem core. However, st1202_brightness_set() uses guard(mutex)(&chip->lock) and performs I2C transactions, both of which are blocking operations. When a software trigger fires in a softirq timer context, it calls led_set_brightness_nosleep(), which directly invokes the brightness_set callback. Since the callback attempts to acquire a mutex and perform I2C transfers from this atomic context, it causes a kernel panic. -- Sashiko AI review · https://sashiko.dev/#/patchset/GV1PR08MB8497C0B898789BB73ACE6EE3C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com?part=8