Hi Hans,
Thanks for the feedback! I've submitted it in patch v3: https://lore.kernel.org/all/20251022200704.2655507-1-danisjiang@gmail.com/.
Best regards, Yuhao
On Wed, Oct 22, 2025 at 4:28 AM Hans de Goede hansg@kernel.org wrote:
Hi Yuhao,
On 22-Oct-25 6:25 AM, Yuhao Jiang wrote:
The switch_brightness_work delayed work accesses device->brightness and device->backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal.
If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight.
Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work before unregistering its backlight resources. This ensures the work completes before the memory is freed.
Fixes: 8ab58e8e7e097 ("ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress") Cc: stable@vger.kernel.org Signed-off-by: Yuhao Jiang danisjiang@gmail.com
Thank you for your patch, this is a good catch.
Changes in v2:
- Move cancel_delayed_work_sync() to acpi_video_bus_unregister_backlight() instead of acpi_video_bus_put_devices() for better logic clarity and to prevent potential UAF of device->brightness
- Correct Fixes tag to point to 8ab58e8e7e097 which introduced the delayed work
- Link to v1: https://lore.kernel.org/all/20251022040859.2102914-1-danisjiang@gmail.com
drivers/acpi/acpi_video.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index 103f29661576..64709658bdc4 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -1869,8 +1869,10 @@ static int acpi_video_bus_unregister_backlight(struct acpi_video_bus *video) error = unregister_pm_notifier(&video->pm_nb);
mutex_lock(&video->device_list_lock);
list_for_each_entry(dev, &video->video_device_list, entry)
list_for_each_entry(dev, &video->video_device_list, entry) {cancel_delayed_work_sync(&dev->switch_brightness_work); acpi_video_dev_unregister_backlight(dev);} mutex_unlock(&video->device_list_lock); video->backlight_registered = false;As you mention in your changelog, the cancel_delayed_work_sync() needs to happen before acpi_video_dev_unregister_backlight().
Since this needs to happen before unregistering things I think it would be more logical to put the cancel_delayed_work_sync(&dev->switch_brightness_work); call inside acpi_video_bus_remove_notify_handler().
So do the cancel in the loop there, directly after the acpi_video_dev_remove_notify_handler(dev) call which removes the handler which queues the work.
E.g. make the loop inside acpi_video_bus_remove_notify_handler() look like this:
mutex_lock(&video->device_list_lock); list_for_each_entry(dev, &video->video_device_list, entry) { acpi_video_dev_remove_notify_handler(dev); cancel_delayed_work_sync(&dev->switch_brightness_work); } mutex_unlock(&video->device_list_lock);This cancels the work a bit earlier, but more importantly this feels like the more logical place to put the cancel call.
Regards,
Hans