CVE-2024-42128

What it actually does

Use-after-free in the an30259a LED driver where devm_led_classdev_register causes led_classdev_unregister (invoked after module remove) to call led_set_brightness while the mutex protecting it has already been destroyed in the driver's remove routine.

Why it matters to the business

Systems running affected Linux kernels with this LED driver may experience kernel instability or crashes during module unload sequences; the issue affects a narrow set of hardware but requires prompt kernel updates on any impacted distributions to avoid operational disruption.

How an attack unfolds

An attacker with local access triggers repeated load/unload of the an30259a module or equivalent device registration/unregistration paths; the race between unregister's brightness callback and the already-destroyed mutex leads to a use-after-free that can be leveraged for memory corruption.

How to fix it

Update the Linux kernel to a version containing commit 3ead19aa341de89a8c3d88a091d8093ebea622e8 or later; rebuild and deploy the fixed kernel image, then reboot affected systems. Where immediate patching is not feasible, avoid unloading the driver module.

How to confirm the fix worked

Confirm the running kernel contains commit 3ead19aa341de89a8c3d88a091d8093ebea622e8 by inspecting /proc/version or the kernel build log; attempt module load/unload cycles while monitoring for use-after-free warnings in dmesg.

Typical attack path

1. Obtain local execution on a system using the an30259a LED driver
2. Trigger module removal or device unregistration sequence
3. Force the led_set_brightness callback to execute after mutex destruction
4. Exploit the resulting use-after-free for kernel memory corruption or denial of service

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for use-after-free warnings or oops messages referencing an30259a, led_set_brightness, or mutex operations around module unload events; correlate with process activity that performs driver unload.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the an30259a driver
• Add the fixed commit hash to internal patch scanning and SBOM checks
• Monitor kernel mailing lists for related LED driver fixes
• Test module removal behavior in staging environments before production rollout