CVE-2026-46203

What it actually does

This flaw is in the Linux kernel Cadence QuadSPI controller driver. During driver unbind, the driver could access controller registers while the hardware clock was not enabled because the device had not been runtime-resumed before disable logic ran. On affected systems with this controller, a local attacker able to influence driver unbind or device lifecycle operations could trigger unclocked MMIO/register access, potentially causing a kernel fault, crash, or denial of service. The CVSS vector also indicates possible high confidentiality impact, but the most clearly supported impact from the upstream fix description is system instability or kernel failure during device deregistration.

Why it matters to the business

Affected Linux systems using Cadence QuadSPI flash controllers may be vulnerable to local disruption if a user or compromised process can trigger driver unbind paths. The practical business risk is unexpected device crashes, service interruption, or embedded/edge appliance instability. This is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so urgency is lower than for remotely exploitable or actively exploited kernel flaws; however, systems where local users, containers, device-management agents, or maintenance tooling can affect kernel driver lifecycle should prioritize patching because a crash can still cause outage or data availability issues.

How an attack unfolds

An attacker first needs local access to an affected Linux system and enough privilege or delegated capability to interact with kernel device lifecycle controls, such as unbinding the Cadence QuadSPI platform driver or triggering equivalent deregistration behavior. The attacker waits for or causes the controller to be runtime-suspended, then initiates driver unbind. In the vulnerable code path, the driver attempts to disable or access controller registers without first ensuring the controller clock is active. That unclocked register access can produce a bus fault, kernel oops, panic, or device hang. In a successful attack, the attacker causes denial of service of the host or appliance; depending on platform behavior and kernel configuration, crash artifacts may be written to kernel logs, pstore, kdump, or serial console output.

How to fix it

Update the Linux kernel to a version that includes the upstream fix for the Cadence QuadSPI driver change titled "spi: cadence-quadspi: fix unclocked access on unbind." No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution, vendor BSP, embedded platform vendor, or long-term stable kernel branch. If immediate patching is not possible, reduce exposure by restricting access to driver unbind interfaces under /sys, limiting CAP_SYS_ADMIN and other device-management privileges, preventing untrusted users or containers from interacting with host sysfs device controls, and avoiding operational workflows that unload or unbind the Cadence QuadSPI driver on affected systems. On appliances or embedded systems, validate with the hardware vendor that the BSP kernel contains the Cadence QuadSPI runtime-resume-before-disable fix.

How to confirm the fix worked

Confirm exposure by checking whether the system uses the Cadence QuadSPI driver and whether the running kernel includes the fix. Review loaded modules, kernel configuration, device tree entries, and sysfs platform drivers for Cadence QuadSPI or cdns,qspi-nor usage. Validate remediation by installing the vendor-fixed kernel, rebooting into it, and confirming the running kernel package/build corresponds to the patched release. Where safe in a non-production test environment, exercise driver bind/unbind or device removal workflows and confirm they no longer produce kernel oops, external aborts, bus faults, or panic messages. Also confirm that untrusted users and containers cannot write to relevant sysfs unbind paths or otherwise manage host platform drivers.

Typical attack path

1. Gain local access to an affected Linux system that uses the Cadence QuadSPI kernel driver.
2. Obtain sufficient privileges or delegated permissions to trigger platform driver unbind, device removal, or equivalent driver deregistration behavior.
3. Allow or cause the QuadSPI controller to enter a runtime-suspended state.
4. Trigger unbind or deregistration of the Cadence QuadSPI driver.
5. The vulnerable driver path performs register access while the device clock is disabled.
6. The kernel encounters an MMIO/bus fault, oops, panic, or platform hang, causing denial of service and possible crash artifact generation.

How to detect it

To determine whether exploitation or accidental triggering has already occurred, review kernel and system logs for driver unbind activity followed by hardware access faults, external aborts, kernel oops, panic events, or resets involving Cadence QuadSPI. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg archives, auditd logs for sysfs writes, pstore/ramoops records, kdump vmcores, serial console logs, and EDR telemetry that records shell commands or sysfs file writes. Look for writes to platform driver unbind paths near crashes, module unload attempts for the Cadence QuadSPI driver, and kernel stack traces referencing spi-cadence-quadspi or cadence-qspi. Because there is no known public exploit and the issue can be triggered by legitimate maintenance, correlate any indicators with change windows, firmware updates, driver testing, or platform management activity before concluding malicious exploitation.

• /sys/bus/platform/drivers/cadence-qspi/unbind
• /sys/bus/platform/drivers/*/unbind
• spi-cadence-quadspi
• spi-cadence-quadspi.ko
• cadence-qspi
• cdns,qspi-nor
• modprobe -r spi-cadence-quadspi
• rmmod spi-cadence-quadspi
• Kernel panic - not syncing
• Oops:
• Unhandled fault: external abort
• Synchronous External Abort
• imprecise external abort
• Internal error: Oops
• Unable to handle kernel paging request

What your security team should do

• Inventory Linux systems, appliances, and embedded platforms that use Cadence QuadSPI flash controllers or the spi-cadence-quadspi driver.
• Prioritize patching systems where local users, containers, management agents, or field-service tooling can influence driver unbind, module unload, or device lifecycle operations.
• Deploy vendor-provided fixed kernel packages or BSP updates containing the Cadence QuadSPI unbind/runtime-resume fix.
• Restrict access to /sys/bus/platform/drivers/*/unbind and similar device-management interfaces to trusted administrators only.
• Review container and workload configurations to ensure host sysfs, device nodes, and privileged capabilities are not exposed unnecessarily.
• Enable and retain kernel crash evidence such as persistent journald, pstore/ramoops, kdump, serial console logs, or hypervisor console capture on affected platforms.
• Monitor for unexpected driver unbind attempts, kernel oops events, external aborts, and crashes involving Cadence QuadSPI components.
• Treat repeated crashes around QuadSPI unbind or device removal as suspicious until explained by maintenance activity or testing.