CVE-2026-45883

What it actually does

This is a local Linux kernel availability flaw in the Industrial I/O sca3000 SPI accelerometer driver. During sca3000_probe(), the driver requests a threaded IRQ, but if the later iio_device_register() call fails, the error path does not release the IRQ resource. Repeated failed probe attempts can leak kernel IRQ-related resources, potentially exhausting resources or destabilizing the host. The issue does not provide confidentiality or integrity impact by itself and requires local ability to influence device probing, driver binding, module loading, or related hardware/device configuration paths.

Why it matters to the business

Successful exploitation can cause affected Linux systems using or exposing the sca3000 driver path to become unstable or unavailable, resulting in service interruption, device downtime, or the need for manual recovery/reboot. The risk is lower for systems that do not include, load, or use this driver, and current exploitation likelihood appears low based on the very low EPSS score, lack of KEV listing, lack of known ransomware use, and no reported exploit maturity. Systems with broad local user access, embedded Linux deployments, or hardware environments that use SPI/IIO sensor drivers should prioritize validation and kernel updates during the next maintenance window.

How an attack unfolds

An attacker first obtains local, low-privileged access to a Linux system where the vulnerable kernel and sca3000 driver path are present. The attacker then attempts to repeatedly trigger the sca3000 device probe path while causing iio_device_register() to fail after request_threaded_irq() has already succeeded. Because the driver does not release the IRQ on that failure path, each failed probe may leave kernel resources allocated. Over time, repeated triggering can exhaust IRQ or related kernel resources, causing degraded behavior, driver failures, kernel instability, or denial of service. Exploitation is local and environment-dependent; it generally requires the vulnerable driver to be present and reachable through system configuration, device binding, module handling, or hardware/device-tree/ACPI/SPI enumeration paths.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the upstream fix for the sca3000_probe() error path so that the IRQ is released when iio_device_register() fails. Because no exact fixed package versions were provided, use vendor advisories and kernel changelogs to identify the corrected kernel build for each distribution. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the sca3000 driver if it is not required, preventing unprivileged users from loading modules or binding drivers, restricting access to sysfs driver bind/unbind interfaces, and limiting local shell access to trusted users. Embedded or appliance maintainers should rebuild kernels with the corrected driver code or remove the driver from the kernel configuration if unused.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the sca3000 resource-leak fix. Validate that the vulnerable driver is not loaded or available where it is not needed by checking loaded modules, kernel configuration, and driver paths under sysfs. If the driver is required, test probe failure handling in a controlled non-production environment and verify that failed probe attempts do not leave increasing IRQ allocations or persistent driver resources behind. Review kernel logs after update for sca3000 probe failures, IRQ allocation failures, or repeated bind/unbind activity. Also verify that local users cannot load kernel modules or manipulate SPI/IIO driver binding unless explicitly authorized.

Typical attack path

1. Gain local access to a Linux system running a vulnerable kernel.
2. Confirm the sca3000 driver is available, built into the kernel, or loadable as a module.
3. Identify a way to trigger sca3000_probe(), such as driver binding, module reload, SPI device enumeration, or controlled device configuration in an environment where that is permitted.
4. Induce or rely on a failure of iio_device_register() after request_threaded_irq() succeeds.
5. Repeat the failed probe path to leak IRQ-related kernel resources.
6. Cause resource exhaustion, driver malfunction, kernel instability, or system denial of service.

How to detect it

Look for evidence of repeated failed sca3000 driver probe activity, abnormal IRQ allocation behavior, and attempts to bind, unbind, load, or unload the sca3000 driver. Useful log sources include kernel logs from dmesg, journald/kern.log/messages, auditd records for module loading or sysfs writes, EDR telemetry for modprobe/rmmod activity, and file integrity or command logs covering /sys/bus/spi/drivers/ and /sys/bus/iio/. Because this issue is a resource leak rather than code execution, there may be no unique exploit artifact; detection should focus on repeated local triggering patterns followed by device-driver failures, IRQ exhaustion messages, kernel warnings, hangs, or reboots. In environments with auditd, search for writes to driver bind/unbind files, execution of modprobe or rmmod for sca3000, and bursts of kernel messages referencing sca3000, IIO registration failure, IRQ request failure, or probe failure.

• sca3000
• /sys/bus/spi/drivers/sca3000
• /sys/bus/spi/drivers/sca3000/bind
• /sys/bus/spi/drivers/sca3000/unbind
• sca3000.ko
• modprobe sca3000
• rmmod sca3000
• iio_device_register
• request_threaded_irq
• probe failed
• failed to request irq
• IRQ allocation failed

What your security team should do

• Inventory Linux systems and embedded devices for kernels that include or load the sca3000 Industrial I/O SPI accelerometer driver.
• Prioritize patching on systems where local users have shell access, module-loading paths are available, or SPI/IIO hardware is present.
• Apply the vendor-provided fixed kernel package once available for the relevant distribution or appliance firmware.
• If the driver is unused, disable or blacklist sca3000 as a compensating control.
• Restrict CAP_SYS_MODULE, module loading, and sysfs driver bind/unbind access to trusted administrators only.
• Monitor kernel logs for repeated sca3000 probe failures, IRQ allocation anomalies, and suspicious driver bind/unbind activity.
• Treat exploitation likelihood as currently low, but address during normal kernel maintenance because successful exploitation can affect availability.