CVE-2025-68330
Description
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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A NULL-pointer dereference in the Linux kernel's bmc150 accelerometer driver when interrupt support is absent, triggered during buffer operations.
Root
Cause
The bmc150-accel-core.c driver unconditionally calls bmc150_accel_set_interrupt() from IIO buffer setup hooks, even on devices that have no interrupt line configured. This leads to a NULL-pointer dereference — the kernel reads from a null or invalid address (crash at bmc150_accel_set_interrupt+0x98/0x194) — as shown in the official kernel commit description. The bug has existed since the driver's initial commit but only recently became visible, possibly due to a change in runtime PM behavior.
Exploitation
An attacker with local access can trigger the crash by enabling the IIO buffer on a bmc150-based device (e.g., via the enable_store sysfs entry) which invokes the bmc150_accel_buffer_postenable callback and then bmc150_accel_set_interrupt on the runtime PM resume path. No special privileges beyond being able to interact with the IIO subsystem are required; the vulnerability manifests as a denial-of-service kernel panic.
Impact
Successful exploitation results in a kernel crash (NULL-pointer dereference), causing a denial of service on the affected system. There is no evidence of code execution or privilege escalation in the disclosed information.
Mitigation
The fix, introduced by commits c891f504bb66 and cdd4a9e98004 in the stable kernel tree [1][2], stores the IRQ number in the device state structure and checks for its presence before calling the interrupt-related function. Users should apply the latest stable kernel updates or backport the relevant patch. No workaround other than avoiding buffer enable operations on interrupt-less configurations is immediately available.
[1]: https://git.kernel.org/stable/c/c891f504bb66604c822e7985e093cf39b97fdeb0 [2]: https://git.kernel.org/stable/c/cdd4a9e98004bd7c7488311951fa6dbae38b2b80
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
6- git.kernel.org/stable/c/3aa385a9c75c09b59dcab2ff76423439d23673abnvd
- git.kernel.org/stable/c/65ad4ed983fd9ee0259d86391d6a53f78203918cnvd
- git.kernel.org/stable/c/93eaa5ddc5fc4f50ac396afad8ce261102ebd4f3nvd
- git.kernel.org/stable/c/aad9d048a3211c48ec02efa405bf462856feb862nvd
- git.kernel.org/stable/c/c891f504bb66604c822e7985e093cf39b97fdeb0nvd
- git.kernel.org/stable/c/cdd4a9e98004bd7c7488311951fa6dbae38b2b80nvd
News mentions
0No linked articles in our index yet.