CVE-2025-68330 in Linux
Summary
by MITRE • 12/22/2025
In the Linux kernel, the following vulnerability has been resolved:
iio: accel: bmc150: Fix irq assumption regression
The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts:
Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read
PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4
This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why.
Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 12/23/2025
The vulnerability CVE-2025-68330 represents a critical null pointer dereference issue within the Linux kernel's iio subsystem, specifically affecting the bmc150 accelerometer driver. This flaw exists in the bmc150-accel-core.c file where the driver unconditionally invokes the bmc150_accel_set_interrupt() function during buffer setup operations including runtime power management resume paths. The issue manifests when devices lack interrupt capabilities, leading to kernel panics with NULL pointer dereference errors at virtual address 00000001, indicating a fundamental failure in interrupt handling logic that has persisted since the driver's initial implementation.
The technical root cause stems from improper interrupt state management within the driver's architecture, where the code fails to properly check for interrupt availability before attempting to configure interrupt handlers. This pattern violates standard kernel driver development practices and creates a dangerous condition where the system attempts to dereference a null interrupt descriptor pointer. The error occurs during the buffer post-enablement phase when the kernel attempts to manage IIO buffer operations, specifically during the __iio_update_buffers function call chain that leads to the problematic bmc150_accel_set_interrupt function. The call trace demonstrates a clear execution path from runtime PM resume handling through buffer setup to the ultimate failure point, indicating this is not a transient issue but a fundamental architectural flaw in interrupt management.
The operational impact of this vulnerability is severe as it can cause complete system crashes or kernel oops when the affected driver is loaded on hardware that does not support interrupts. This affects embedded systems and devices using the bmc150 accelerometer sensor where interrupt capabilities may be disabled or unavailable due to hardware design constraints or power management considerations. The vulnerability affects any Linux kernel version containing this driver code and could be exploited by malicious actors to cause denial of service attacks against systems relying on IIO subsystem for sensor data collection. Systems using the bmc150 accelerometer in automotive applications, industrial monitoring systems, or mobile devices could experience unexpected crashes or system instability, potentially leading to safety-critical failures depending on the deployment environment.
The fix implements proper interrupt state tracking by storing the IRQ number in the driver's state structure, following established patterns used in other kernel drivers within the IIO subsystem. This approach aligns with CWE-476 which addresses NULL pointer dereferences and represents a standard defensive programming technique for interrupt management in kernel space. The solution follows ATT&CK framework concept T1499.004 which involves system disruption through kernel-level modifications, but in this case the fix prevents the disruption rather than causing it. The recommended mitigation involves updating to the patched kernel version where the interrupt state is properly checked before function calls, ensuring that the driver only attempts interrupt configuration when hardware support is actually present. This fix pattern also aligns with kernel security best practices outlined in the Linux Kernel Security documentation and helps prevent similar regressions in other drivers that might make similar assumptions about interrupt availability.