CVE-2025-37842 Can Panic Linux on NXP QuadSPI Devices

The issue was assigned by the Linux kernel CVE team on May 9, 2025, although NVD’s record received later enrichment and was last modified on June 17, 2026. That distinction matters for vulnerability-management teams seeing a fresh scanner alert today: this is not a newly disclosed bug or a newly released upstream fix. It is a CVE record whose affected-version and CPE data matured after the original kernel patches had already shipped.

The affected code is

, the kernel driver for Freescale/NXP QuadSPI controllers. The Linux kernel maintainers say the defect was introduced in Linux 5.2 and can cause a kernel panic when an affected controller is detached. The published reproducer unbinds the controller at platform address

on an NXP i.MX8MQ system.

For administrators, the real task is to separate Linux fleets that merely report a vulnerable kernel version from the much smaller group of embedded devices where the driver and hardware are actually in use.

A removal-path bug in a hardware-specific SPI driver​

The kernel bug is a resource-lifetime error. The FSL QuadSPI driver used Linux device-managed allocation and registration helpers—

APIs—to acquire clocks, IRQs, memory resources, and register its SPI controller. Those helpers are designed to release what they own automatically when the device goes away.

The same driver also retained a legacy

callback that manually disabled the hardware, shut down clocks, and destroyed a mutex. During device detach, that callback ran before the device-managed cleanup actions. As the Linux kernel CVE announcement explains, that release order could lead to a panic.

The upstream correction removes the standalone

callback and registers the driver-specific shutdown routine with

. That puts the custom hardware cleanup into the same managed lifetime model as the other resources. In practical terms, the fix makes the controller shutdown happen once, in a defined order, instead of manually tearing down pieces of a device whose managed resources are also about to be released.

This is important for embedded deployments because QuadSPI is normally connected to serial NOR flash. On an appliance or industrial i.MX design, flash may hold firmware assets, boot components, or persistent system data. The reported failure is a kernel panic rather than silent storage corruption, but an unexpected crash can still mean an outage, watchdog reboot, interrupted workload, or filesystem recovery on the next boot.

NXP’s Linux documentation identifies

as its Quad SPI driver, while the kernel’s own maintainer records tie that file to the Freescale Quad SPI subsystem. That hardware dependency is absent from NVD’s generic Linux kernel CPE, which is why a scanner result alone cannot tell an administrator whether a host is materially exposed.

The CVSS score overstates the everyday attack surface​

NVD assigns CVE-2025-37842 a CVSS 3.1 score of 5.5, rated Medium, with local access, low complexity, low privileges required, and high availability impact. The availability assessment is fair: the documented outcome is a kernel panic.

But the supplied proof of concept also reveals the operational constraint. It writes a platform-device identifier into the driver’s

attribute under

. On standard Linux systems, writable sysfs control attributes are normally restricted to root or a deliberately delegated privileged service. The kernel’s sysfs documentation describes write-only attributes as root-write by default.

So this is not a flaw an unprivileged application would normally use to crash arbitrary Linux hardware. It becomes relevant where a local account, container management process, diagnostic tool, device-update agent, or provisioning framework has been granted the authority to unbind platform drivers. That is a meaningful administrative boundary, but it is far narrower than the generic phrase “local attacker” can suggest in a dashboard.

The practical security case is therefore twofold:

• A privileged operator or service can accidentally trigger a production outage while conducting device maintenance, hardware recovery, or driver rebinding.
• An attacker who has already obtained the ability to manipulate driver binding may use the bug for denial of service on an affected embedded device.

For ordinary Windows PCs, Windows Server hosts, and conventional x86 Linux virtual machines, this CVE does not apply simply because a Linux kernel is installed. WSL2 systems are likewise not the natural target: the published trigger is tied to an NXP i.MX8MQ platform device and the FSL QuadSPI driver, not a virtualized storage controller exposed by standard WSL configurations. The Windows relevance is primarily for teams using Windows workstations to build, deploy, or manage NXP-based embedded Linux images.

The CPE exists, but it cannot identify the systems that matter​

NVD’s CPE configuration covers four upstream kernel-version ranges:

• Linux 5.2 through versions before 6.6.105.
• Linux 6.7 through versions before 6.12.36.
• Linux 6.13 through versions before 6.13.12.
• Linux 6.14 through versions before 6.14.3.

That is a valid way to express the upstream kernel history, including long-term stable branches that received the patch later. It is also necessarily imprecise. The CPE is

, not a hardware-qualified identifier for an i.MX8MQ board, a Freescale QuadSPI controller, or a distribution package that enables

.

CPE cannot reliably encode the conditions that decide operational exposure here:

1. The kernel must contain the affected driver, whether built in or as a module.
2. The machine must have compatible FSL/NXP QuadSPI hardware described to the kernel.
3. The driver must bind to that hardware.
4. A process must be able to cause the device’s detach or unbind path to execute.

This is why the correct answer to “Are we missing a CPE?” is no—but the existing CPE should be treated as a broad discovery signal, not proof of impact. Adding another generic kernel CPE would not improve precision. A platform-specific CPE is unlikely to solve the problem either, because boards, SoCs, kernels, device trees, and vendor images do not map cleanly to one global product identifier.

Security teams should use their software bill of materials, kernel configuration, device-tree inventory, and hardware asset records to close that gap. An i.MX fleet running a vendor-maintained 5.10 or 6.1 long-term kernel deserves investigation even if its distribution does not use the upstream version numbering shown in NVD. Conversely, a server fleet with matching kernel versions but no FSL QuadSPI controller should be documented as not affected rather than patched solely for this issue.

The first fix had a cleanup flaw of its own​

There is a detail missing from a bare CVE reading: the initial lifetime-management fix itself required a follow-up correction before stable releases shipped.

After the

conversion was introduced, kernel developer Kevin Hao identified two probe-error paths that could still run manual cleanup after managed cleanup had already occurred. The follow-up patch, titled “spi: fsl-qspi: Fix double cleanup in probe error path,” removes those redundant cleanup calls.

That follow-up is not a reason to reject the listed fixed kernel releases. Stable release records for Linux 6.6.105, 6.12.36, 6.13.12, and 6.14.3 show both the CVE fix and the double-cleanup correction included together. The upstream Linux 6.15 line also contains the corrected implementation.

It does mean administrators should avoid the tempting but risky shortcut of cherry-picking only the CVE-named change into an old vendor kernel. The Linux kernel CVE team explicitly advises updating to a maintained stable release rather than applying individual commits in isolation. Here, the warning is unusually concrete: the first patch changed cleanup ownership, and a second patch was needed to make error handling consistent with that ownership model.

What affected-device owners should verify​

Organizations responsible for NXP i.MX products should first identify whether their deployed kernel has the FSL QuadSPI driver enabled and bound. A kernel configuration entry such as

, the presence of

, or an active

platform driver are better starting points than a CPE match alone.

The safe remediation threshold in upstream terms is Linux 6.6.105, 6.12.36, 6.13.12, 6.14.3, or Linux 6.15 and later. Distribution and board-support-package kernels must be checked against their vendor’s patch history, because a version string such as 5.10 or 6.1 does not prove either vulnerability or safety after backports.

Teams that cannot update immediately should restrict access to sysfs driver bind and unbind controls, review device-management scripts that detach platform devices, and avoid manually unbinding the

controller on affected images. The immediate consequence is straightforward: on an i.MX system using this driver, an otherwise routine device-detach action can still turn into a full kernel crash until the corrected stable kernel is deployed.