CVE-2026-90394

What it actually does

Use-after-free in the sc2731_charger driver when the platform device is removed: the USB notifier and charger detection path schedule delayed work on info->work, but the remove handler unregisters the notifier without canceling pending or running work before the devm-allocated driver data is freed.

Why it matters to the business

Kernel instability, crashes, or memory corruption on systems using this charger hardware when the driver module is unloaded or the device is hot-removed, potentially affecting embedded or mobile Linux deployments.

How an attack unfolds

An attacker with local access triggers repeated module load/unload or device insertion/removal sequences to race the work item against the freed driver data structure, leading to use-after-free memory corruption; no named threat actors or public exploits are known.

How to fix it

Apply the upstream fix that sets platform drvdata and cancels the work after notifier unregistration; rebuild and deploy the corrected kernel for affected configurations.

How to confirm the fix worked

Confirm the presence of the cancel-work call after notifier unregistration in the sc2731_charger remove path; test module removal under load to ensure no pending work references freed memory.

Typical attack path

1. Obtain local access to a system exposing the sc2731 charger
2. Repeatedly load/unload the power-supply driver or trigger device removal
3. Race the scheduled work against the freed info structure
4. Leverage resulting UAF for memory corruption or denial of service

How to detect it

Inspect kernel logs for oops or panic traces referencing sc2731_charger, workqueue, or use-after-free in power-supply code paths after device or module removal events.

What your security team should do

• Prioritize kernel updates containing the cancel-work fix on systems that include this charger driver
• Monitor for kernel oops/panics involving workqueue or power-supply structures
• Restrict local module loading privileges where feasible