CVE-2025-68330: BMC150 IRQ Dereference Fix in Linux Kernel

A recently recorded Linux kernel vulnerability, tracked as CVE-2025-68330, fixes a longstanding but newly manifesting defect in the BMC150 accelerometer driver (drivers/iio/accel/bmc150). The problem stems from an irq-assumption regression in bmc150-accel-core.c where the driver unconditionally attempted to configure interrupts during certain buffer and runtime-PM paths even when no IRQ was present — producing NULL-pointer dereferences and kernel oopses on affected systems. Upstream maintainers patched the driver by storing the IRQ number in the device state and guarding interrupt setup on that value; the change has been landed and backported into stable trees. This article explains what happened, why it matters, how operators and integrators should respond, and where residual risks remain.

Background / Overview​

The BMC150 is an accelerometer commonly supported in Linux through the IIO (Industrial I/O) subsystem; its accelerator driver exposes buffered readings and optional IRQ-based triggers. The vulnerability — summarized in multiple vulnerability databases and distribution advisories — arises because the driver code calls bmc150_accel_set_interrupt unconditionally in the IIO buffer setup and runtime-PM resume code paths. When a board or kernel configuration provides no interrupt (IRQ) for that device, the unconditional call may dereference a NULL pointer and crash the kernel during a buffer enable or runtime resume operation. Multiple public trackers recorded the same call trace and diagnosis for CVE-2025-68330. This is a classic defensive-programming omission: code that assumes the presence of hardware resources without storing or checking the actual resource handle (IRQ number) and then uses that handle later. Upstream maintenance discussion and the patch commentary make the corrective approach clear: store the IRQ number in the device state struct and use it as the canonical indicator of IRQ availability before attempting interrupt setup or teardown. That minimal change aligns with kernel conventions and reduces the regression surface.

---

How the bug manifests: technical anatomy​

The vulnerable path​

• The IIO buffer setup sequence runs post-enable hooks (iio_buffer_setup_ops) that prepare the device for buffered sampling.
• On runtime-PM resume or when enabling buffers, the driver invoked bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable without verifying whether an IRQ is configured for the device.
• If the device had no IRQ (irq <= 0 or inadvertently unset), the subsequent dereference inside the set_interrupt routine led to a NULL pointer dereference and kernel oops (panic-like kernel fault).
• The crash stack traces recorded in public advisories show a consistent pattern: the oops originates at bmc150_accel_set_interrupt, with the caller chain coming from buffer_postenable → __iio_update_buffers → enable_store → kernfs_fop_write_iter.

Why this regressed now (practical observation)​

Upstream observers noted the offending pattern “seems to have been in the driver since the beginning” but only began manifesting recently. The exact reason for the timing is not fully confirmed in public records; plausible hypotheses include kernel internal refactors (changes to runtime-PM or IIO buffer initialization ordering), different default device-tree / platform binding behaviors in newer kernels, or distribution-level config changes that removed IRQ wiring in some builds. This explanation is consistent with maintainers’ caution that the bug is old but only recently visible, and the maintainers decided the safest fix was to make IRQ handling explicit and defensive. This timeline and the uncertainty about the trigger are recorded in the kernel mailing threads and CVE summaries; treat any single-cause assertion as speculative until vendor or maintainer analysis publishes a definitive root cause.

---

The upstream fix: what changed​

The upstream patch is intentionally narrow and follows common kernel idioms:

• Add an int irq; member to the struct bmc150_accel_data (the device state struct).
• During probe/initialization, when request_threaded_irq is called only if a valid IRQ number exists, store the returned/assigned IRQ number into data->irq.
• Replace any ad-hoc "has_irq" boolean or unconditional calls with guards that check data->irq (or irq > 0) before calling bmc150_accel_set_interrupt or attempting interrupt-related operations.
• Minor code churn, no change to the device's functional behavior when IRQs are present.

This change reduces NULL-dereference risk and brings the driver into line with the pattern used by many other IIO drivers. The patch was proposed, reviewed on the iio/stable mailing lists, and applied to the fixes-togreg branch and stable trees; reviewers recommended storing the IRQ number (an integer) rather than a boolean to match common patterns.

---

Impact assessment: who and what is affected​

• Affected component: Linux kernel driver for BMC150 accelerometer (drivers/iio/accel/bmc150).
• Practical impact: local availability (kernel oops / crash) when the driver attempts to enable buffered IIO reads or on runtime-PM resume and the device lacks a valid IRQ.
• Attackability: There is no indication this vulnerability enables remote code execution or privilege escalation directly. It is primarily a kernel stability/availability issue, potentially exploitable by local unprivileged users or misconfigured userspace that can toggle buffers or sysfs entries that trigger the code path. Distribution and vendor trackers uniformly designate the issue as a medium-risk correctness bug rather than a remote exploit vector.

Special notes for environments:

• Embedded boards and SoC images that include the BMC150 driver (and where device-tree bindings may or may not wire an IRQ) have the highest exposure.
• Desktop/server distributions that build the driver into kernels but never probe the device (or where device-tree/ACPI prevents probe) are less likely to be affected.
• Cloud images, appliance kernels, or custom BSPs should be inventoried for the presence of the driver and for whether kernels include the upstream stable patch.

---

Verifying whether you’re affected​

• Check your running kernel and module tree:
• Run uname -r to identify kernel version.
• Inspect your kernel config and modules: grep for CONFIG_IIO and drivers/iio built into the kernel.
• Look for the device driver and IRQ binding:
• dmesg | grep -i bmc150 or journalctl -k | grep -i bmc150 to find probe logs.
• Check /proc/interrupts or device-tree source (if accessible) for whether an IRQ is associated with the accelerometer node.
• Reproduce or hunt for OOPS traces:
• Search kernel logs for stack traces mentioning bmc150_accel_set_interrupt and buffer postenable stack frames.
• Confirm the upstream commit/backport:
• Verify whether your kernel package changelog or vendor advisory references the stable commit or the CVE mapping. Distribution trackers and the NVD list the CVE and the generic fix description; vendor packages should reference the upstream commit when backported.

If you find kernel oops logs that match the call stack described earlier, treat the host as impacted until the kernel is updated or rebuilt with the upstream patch.

---

Mitigation and remediation guidance​

• Primary remediation: upgrade your kernel to a version that contains the upstream stable commit for the bmc150 driver. Apply distribution-provided kernel updates or vendor backports that explicitly list CVE-2025-68330 or the upstream commit IDs in their changelog entries. Distributions including Ubuntu, SUSE and others have published mappings and advisories that track this CVE.
• If immediate kernel updates are impractical:
• Unload or blacklist the bmc150 module (if built as a module): echo "blacklist bmc150_accel" > /etc/modprobe.d/blacklist-bmc150.conf and reboot. This removes the driver and avoids the crash at the cost of disabling the device.
• Prevent userspace writes to IIO sysfs buffer entries; restrict access to sysfs nodes for IIO devices (permissions, SELinux/LSM policies) to reduce the likelihood that unprivileged users can trigger the vulnerable path.
• In embedded BSPs you control: if you build kernel images locally, apply the upstream patch to your tree and rebuild the kernel; the patch is intentionally small and designed to be easy to backport.
• Post-patch validation:
• Reboot into the updated kernel and reproduce the buffer enable sequence and runtime-PM resume operations that previously caused the oops.
• Monitor dmesg/journalctl for the absence of bmc150-stack traces and validate /proc/interrupts shows expected IRQ wiring where applicable.

Steps for integrators and vendors:

• Map upstream commit IDs to your kernel branch and backport if necessary.
• Run hardware soak tests on representative boards that use the BMC150 device-tree nodes.
• Publish the patch in your vendor advisory with explicit kernel package versions and revalidation steps.

---

Strengths of the upstream fix​

• The fix is minimal and low-risk: it follows a well-known kernel pattern (store IRQ number in state, check before use). Minimal changes reduce regression potential.
• The change is defensive and explicitly documents IRQ availability in the device state rather than relying on implicit assumptions.
• Backport-friendly: the patch is easy to apply to stable trees and vendor kernels, and that is reflected in the patch workflow and maintainers’ acceptance.

Potential risks and residual concerns​

• Long-tail devices: OEMs and embedded vendors with slow patch pipelines may still ship kernels without the fix. Devices in the field could remain exposed for months.
• Diagnostic gaps: if hosts automatically reboot on oops, telemetry and crash dumps may be lost; operators should ensure crash-dump collection for forensics and triage.
• Unknown trigger windows: upstream maintainers acknowledged it’s not fully clear why the crash began manifesting recently. Until the exact interaction is pinned down, other drivers with similar assumptions might surface analogous regressions after kernel refactors. Treat this CVE as a signal that assumptions about hardware resources should be audited in driver code.

---

Practical checklist for administrators (quick action list)​

• Inventory:
• Identify Linux builds that include drivers/iio/accel/bmc150.
• Locate hosts (embedded, desktop, cloud images) where BMC150 is likely to be present.
• Patch:
• Apply vendor/distribution kernel updates that map to CVE-2025-68330 or contain the upstream stable commit.
• Short-term mitigations:
• Unload/blacklist the driver if not needed.
• Restrict sysfs write access to IIO buffer and enable controls.
• Verify:
• After patching, validate absence of oopses and confirm devices function as expected.
• Document:
• Record mapping from upstream commit to your package versions and publish rollback and test procedures for future backports.

---

Why developers and maintainers should care​

This CVE reinforces several enduring lessons for kernel and driver maintainers:

• Always store and check resource handles (IRQ numbers, GPIO descriptors, regulator handles) in the device state structure and use those canonical fields when deciding whether to perform resource-specific operations.
• Defensive programming (null checks, explicit guards) is essential — even for long-standing drivers — because changes elsewhere in the kernel or platform bindings can reveal latent assumptions.
• Small, surgical fixes are preferable for stability; they ease testing and backporting and reduce the chance of introducing regressions.

The upstream response — a small, well-reviewed change to store and check the IRQ number — exemplifies the right balance between correctness and low regression risk.

---

Closing analysis and final recommendations​

CVE-2025-68330 is a medium-severity, availability-focused Linux kernel vulnerability affecting the BMC150 accelerometer driver. The underlying defect is a missing defensive check around interrupt handling and was patched upstream by storing the IRQ number in the device state and guarding interrupt setup on that value. The patch is minimal and low-risk, and distributions and maintainers have mapped the fix into their stable trees.
Operators should prioritize inventory and patching where BMC150 is present—particularly embedded and SoC device fleets. If a kernel update is not immediately available, blacklisting the driver or tightening sysfs permissions are practical interim mitigations. Vendors and integrators should backport the minimal upstream fix and include it in their next kernel refresh, while auditors should treat driver code paths that assume hardware resources as candidates for defensive hardening.
Treat any assertion about why the bug began to manifest recently as provisional unless an authoritative maintainer post confirms the specific trigger. The public record documents the technical fix and paths to remediation clearly, but the exact timing of manifestation remains an operational detail under investigation in upstream discussions. This vulnerability is an instructive reminder that even seemingly trivial assumptions in low-level drivers can cause system-wide failures — and that small, well-scoped defensive changes are often the most practical and reliable way to restore robustness across diverse build and deployment environments.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center