CVE-2024-27412 in Linux
Summary
by MITRE • 05/17/2024
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq27xxx-i2c: Do not free non existing IRQ
The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq().
But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to:
[ 190.310742] ------------[ cut here ]------------
[ 190.310843] Trying to free already-free IRQ 0
[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310
Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring probe() to fix this.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 12/17/2025
The vulnerability identified as CVE-2024-27412 represents a critical resource management flaw within the Linux kernel's power supply subsystem, specifically affecting the bq27xxx i2c battery driver. This issue manifests when the system attempts to unbind a battery management driver that was never properly initialized with an interrupt request, creating a scenario where the kernel tries to free an IRQ that was never allocated. The root cause stems from an inconsistent implementation between the driver's probe and remove functions, where the probe function correctly handles cases where no IRQ is available, but the remove function does not perform this same validation.
The technical flaw occurs in the bq27xxx_battery_i2c_remove() function which unconditionally calls free_irq(client->irq) without first verifying whether an IRQ was actually allocated during the probe phase. When an i2c client device lacks an interrupt line, client->irq is set to zero, but the remove function proceeds to attempt freeing IRQ 0, which represents a special case in the Linux kernel's interrupt handling system. This operation triggers a kernel warning message indicating that the system is attempting to free an already-free IRQ, ultimately leading to potential system instability and kernel panic conditions during driver unbinding operations.
This vulnerability directly relates to CWE-457: Use of Uninitialized Variables and CWE-476: NULL Pointer Dereference, as it involves improper handling of a null or zero-valued interrupt identifier. The flaw impacts the kernel's interrupt management subsystem and can be categorized under ATT&CK technique T1059.003 for kernel-level code execution and T1484.001 for privilege escalation through kernel exploits. The operational impact extends beyond simple driver unloading, potentially affecting system stability during hot-plug operations or when battery management drivers are dynamically removed from the kernel space.
The mitigation strategy involves implementing a simple but critical conditional check in the bq27xxx_battery_i2c_remove() function that mirrors the existing logic present in the bq27xxx_battery_i2c_probe() function. This requires adding an if (client->irq) condition before calling free_irq(client->irq) to ensure that interrupt resources are only freed when they were actually allocated during the probe phase. This fix ensures proper resource management and prevents the kernel from attempting to free invalid interrupt identifiers, maintaining system stability during driver lifecycle operations and preventing potential denial-of-service conditions that could occur during normal system operation or device removal scenarios.