CVE-2026-64168

What it actually does

This is a Linux kernel driver flaw in the Spreadtrum SPI controller driver. If DMA setup fails during device probe, the driver falls back to PIO mode but may later attempt to release DMA channels without first confirming that DMA was successfully enabled. On a later probe error path, this can dereference an error pointer or release an invalid/already-released DMA channel, causing a kernel oops, panic, or device-driver crash. The practical impact is primarily local denial of service on systems that include and load the affected SPI driver; there is no indication of remote code execution or active exploitation.

Why it matters to the business

Affected systems may crash or become unstable during hardware initialization, driver binding, reprobe, or related error conditions, potentially causing service interruption for appliances, embedded Linux devices, mobile/SoC platforms, or specialized systems using the Spreadtrum SPI controller. Because EPSS is very low, the issue is not in CISA KEV, and no public exploit maturity is reported, broad internet-scale exploitation is unlikely; however, organizations operating affected hardware should still treat it as a reliability and availability risk, especially for production embedded devices where reboots or kernel panics can interrupt operations.

How an attack unfolds

An attacker would need a path to influence the affected kernel driver’s probe or reprobe behavior on hardware using the Spreadtrum SPI controller. The vulnerable condition occurs when DMA setup fails, the driver falls back to PIO mode, and then a subsequent late probe error causes cleanup logic to run. Because the cleanup path does not sufficiently check whether DMA was actually enabled before releasing DMA resources, the kernel may dereference an error pointer or attempt an invalid release. In realistic scenarios, exploitation is most likely local and availability-focused: a user with sufficient privileges to unbind/rebind the device, manipulate driver loading, alter device-tree/platform configuration, or otherwise trigger probe failure conditions could cause a kernel crash. There is currently no indication that this vulnerability is being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel version or vendor kernel build that includes the fix for the Spreadtrum SPI driver cleanup path. The corrective change ensures the driver checks the DMA enabled state before releasing DMA channels on late probe errors. No exact fixed package versions were provided in the input, so organizations should consult their Linux distribution, device vendor, Android/BSP vendor, or kernel-maintenance channel for the patched kernel release. Where immediate patching is not possible, reduce exposure by disabling unused affected hardware support, preventing untrusted users from loading/unloading kernel modules or rebinding platform devices, restricting access to debugfs/sysfs interfaces that can influence driver binding, and applying standard kernel hardening controls.

How to confirm the fix worked

Confirm that the running kernel includes the patched Spreadtrum SPI driver code path and that vendor advisories mark the installed kernel as fixed. On source-based or internally maintained kernels, verify that the driver only releases DMA channels when DMA was successfully enabled. Validate exposure by checking whether the affected driver is present, built, or loaded, and whether the system uses compatible Spreadtrum SPI hardware. After patching, test driver probe/reprobe and DMA-failure error paths in a controlled environment where feasible, and confirm that late probe failures no longer produce kernel oops, panic, or invalid DMA release messages.

Typical attack path

1. Identify a Linux system that includes the affected Spreadtrum SPI controller driver and relevant hardware or platform configuration.
2. Obtain local access with enough privileges to influence driver loading, device binding, reprobe, or related hardware initialization paths.
3. Trigger or induce DMA setup failure during the SPI driver probe path.
4. Cause a later probe error so the vulnerable cleanup path executes.
5. The driver attempts to release DMA resources even though DMA was not successfully enabled, resulting in an error-pointer dereference or invalid channel release.
6. The kernel logs an oops or panic, potentially crashing the system or disrupting the affected device.

How to detect it

To determine whether exploitation or accidental triggering has already occurred, review kernel logs, persistent journal records, crash dumps, pstore/ramoops data, and device-management logs for SPI probe failures followed by kernel oops or panic events. Useful sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, `/sys/fs/pstore/`, kdump/vmcore records, and embedded-device crash telemetry. Focus on systems with Spreadtrum/Unisoc SoC hardware or kernels that include the `spi-sprd` driver. Look for sequences where DMA setup fails for the SPI controller, the driver falls back to PIO or continues probing, and a later cleanup path produces an invalid pointer dereference, NULL/error-pointer dereference, DMA channel release warning, kernel oops, or panic. Because no public exploit indicators are known, detection should be behavior-based rather than actor- or payload-based.

• spi-sprd
• sprd spi
• Spreadtrum SPI
• DMA setup failed
• fall back to PIO
• fallback to PIO
• Unable to handle kernel paging request
• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• kernel panic
• Oops:
• Internal error: Oops
• dma_release_channel
• devm_spi_register_controller
• /sys/fs/pstore/
• /proc/vmcore
• /var/crash/
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching for embedded, mobile, appliance, or SoC-based Linux systems that use the Spreadtrum SPI controller driver.
• Confirm whether affected kernel configurations include the Spreadtrum SPI driver, even if no general-purpose servers are believed to be exposed.
• Track vendor kernel advisories and BSP updates because fixed versions may differ from upstream Linux kernel releases.
• Restrict local administrative capabilities that allow kernel module loading, driver unbind/rebind, device-tree manipulation, or debugfs/sysfs hardware control.
• Monitor kernel logs for oops, panic, DMA release errors, or repeated SPI probe failures on systems with the affected hardware.
• Do not treat this as an urgent internet-exposed remote exploitation issue unless additional product-specific evidence shows remote triggerability.