CVE-2026-53308

What it actually does

This is a Linux kernel use-after-free in the MAX77705 power-supply driver. The driver previously allocated a workqueue and registered interrupt handlers with mismatched teardown ordering: during probe failure or device removal, the workqueue could be destroyed before the interrupt handler was released. If an interrupt fires in that window, the interrupt handler can schedule work on a freed workqueue, causing kernel memory corruption. The most likely technical outcomes are kernel crash, system instability, or denial of service; in theory, a carefully timed and controlled use-after-free in kernel context could contribute to privilege escalation, but the described race is narrow, hardware-specific, and no public exploit maturity is reported.

Why it matters to the business

Organizations running Linux systems with hardware that uses the MAX77705 power-management/power-supply driver could experience unexpected crashes or instability during driver initialization, removal, hardware fault handling, or device power-state changes. The exposure is likely limited to specific embedded, mobile, or specialized Linux platforms rather than general-purpose servers. EPSS is very low, it is not listed in CISA KEV, and there is no known ransomware association, so this should usually be treated as a targeted reliability and hardening issue rather than an internet-scale emergency.

How an attack unfolds

An attacker would need access to a system where the vulnerable MAX77705 driver is present and active, and they would need a way to influence device probing, driver removal, hardware fault behavior, or interrupt generation. The attacker attempts to create a race where the driver teardown path frees the workqueue while the interrupt handler remains registered. If an interrupt arrives during that short interval, the interrupt handler schedules work against memory that has already been freed. This can corrupt kernel memory or crash the system. Practical exploitation is constrained by hardware dependency, timing, and access requirements, and no mature public exploitation is indicated by the provided data.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the MAX77705 power-supply driver fix changing the workqueue allocation/teardown to managed cleanup with correct release ordering. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, device vendor, or long-term-stable kernel branch. Where immediate patching is not possible, reduce exposure by disabling or unloading the MAX77705 driver only on systems that do not require that hardware, preventing untrusted users from loading/unloading kernel modules, restricting physical or debug access to affected devices, and avoiding unnecessary driver bind/unbind or hotplug operations in production.

How to confirm the fix worked

Confirm the running kernel or vendor kernel source contains the backported MAX77705 driver fix for managed workqueue cleanup and corrected interrupt/workqueue removal ordering. Inventory systems for the presence of the driver by checking kernel configuration, loaded modules, and device-tree or platform bindings for MAX77705 hardware. Validate that patched kernels boot normally and that MAX77705 power-supply status changes do not generate kernel warnings, KASAN reports, workqueue errors, or oops messages. On systems without MAX77705 hardware or without the driver built/loaded, practical exposure is minimal, but patching remains recommended through normal kernel maintenance.

Typical attack path

1. Identify a Linux device using the MAX77705 power-supply driver.
2. Gain local, privileged, physical, or hardware-adjacent capability sufficient to trigger driver probe failure, device removal, module unload, or power/interrupt events.
3. Force or wait for the vulnerable teardown sequence where the workqueue is destroyed before the interrupt handler is fully released.
4. Trigger a MAX77705-related interrupt during the race window.
5. Cause the interrupt handler to queue work on freed memory.
6. Induce kernel instability, crash, or potentially leverage memory corruption if additional exploit primitives are available.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, persistent system journals, crash dumps, pstore/ramoops records, KASAN/KFENCE reports, and availability monitoring. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, vmcore crash dumps, pstore entries, and device health telemetry. Search for MAX77705 driver messages near kernel oopses, workqueue failures, interrupt handling anomalies, use-after-free reports, or unexplained reboots. Because exploitation requires a narrow race and hardware-specific conditions, log evidence is more likely to appear as kernel crashes or memory-safety diagnostics than as a clear attacker signature. Correlate suspicious crashes with module unloads, driver unbinds, probe failures, power-supply events, debug/maintenance activity, or physical access windows.

• max77705
• power: supply: max77705
• power_supply_changed
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• KFENCE: use-after-free
• BUG: unable to handle kernel paging request
• kernel BUG at kernel/workqueue
• workqueue: use-after-free
• workqueue max77705
• IRQ handler type mismatch
• genirq
• Disabling IRQ
• Oops:
• Kernel panic - not syncing
• /sys/bus/platform/drivers/max77705
• /sys/class/power_supply

What your security team should do

• Prioritize patching affected embedded, mobile, appliance, or specialized Linux platforms where the MAX77705 power-supply driver is present and active.
• Ask Linux distribution, device, and appliance vendors for the kernel build that includes the MAX77705 workqueue cleanup fix if fixed package versions are not listed internally.
• Treat internet-facing infrastructure as lower priority unless it actually contains this hardware and driver; focus first on devices where physical access, debug access, or untrusted local code execution is plausible.
• Restrict kernel module loading/unloading and device bind/unbind operations to trusted administrators.
• Monitor kernel logs for MAX77705, workqueue, interrupt, KASAN, or kernel oops messages until patched fleets are verified.
• For products or appliances maintained internally, backport the upstream fix rather than attempting operational workarounds.