CVE-2024-49955

What it actually does

Double call to battery_hook_unregister() after an error during hook registration causes use-after-free on the list head, resulting in a kernel crash.

Why it matters to the business

Local denial-of-service on Linux systems that register battery hooks, potentially causing unplanned reboots or kernel panics on servers and workstations with ACPI battery support.

How an attack unfolds

An attacker with local access triggers an error path when adding a battery hook; the kernel automatically unregisters the hook but the provider later calls unregister again, dereferencing freed memory and crashing the system.

How to fix it

Upgrade the Linux kernel to a version containing commit 76fb2cbf01571926da8ecf6876cc8cb07d3f5183 or later; apply the stable backport for the running kernel series and reboot.

How to confirm the fix worked

Verify the running kernel contains commit 76fb2cbf01571926da8ecf6876cc8cb07d3f5183; confirm battery hook registration error paths no longer trigger double-unregister by reviewing dmesg after simulated hook failures.

Typical attack path

1. Obtain local user access on a vulnerable Linux kernel
2. Load or trigger a battery hook provider that returns an error on add
3. Cause the automatic unregister followed by the provider's unregister call
4. Trigger the use-after-free dereference leading to kernel panic

How to detect it

Search kernel logs for battery hook registration failures followed immediately by oops or panic traces referencing battery_hook_unregister; examine crash dumps for use-after-free on list_head structures in ACPI battery code.

What your security team should do

• Prioritize kernel updates on all systems exposing ACPI battery interfaces
• Monitor EPSS and exploit maturity; schedule patching within normal change windows given low EPSS
• Test battery hook providers in staging environments before deploying the fixed kernel
• Review downstream package rebuilds that include the stable commit