CVE-2026-31487

What it actually does

This is a local Linux kernel use-after-free condition in the SPI bus driver matching path. During driver probing through __driver_attach(), the SPI bus match() callback can read the driver_override pointer without holding the device lock while another local context changes or frees that value through sysfs. The resulting race can dereference freed kernel memory and is expected primarily to cause kernel memory corruption leading to a crash, panic, or system hang. Based on the assigned CVSS vector, the known impact is availability loss rather than confidentiality or integrity compromise.

Why it matters to the business

Successful exploitation can crash affected Linux systems that expose SPI devices, causing outages for embedded systems, appliances, industrial devices, IoT platforms, or servers using SPI-attached hardware. The issue requires local privileges and currently has very low EPSS, no known public exploit maturity, and is not listed in CISA KEV, so it is lower urgency than remotely exploitable kernel flaws; however, kernel crashes can still create operational disruption where local users, containers with unsafe device/sysfs access, or management agents can interact with SPI sysfs entries.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient permission to interact with SPI device sysfs attributes, especially driver_override, or another pathway that can trigger SPI driver binding and matching. The attacker then attempts to race two operations: one path repeatedly changes or clears the SPI device driver_override value, while another triggers driver attachment or reprobe activity that causes __driver_attach() to invoke the SPI bus match() callback. Because the match path can access driver_override without the proper device lock, it may read memory after that pointer has been freed. If the race is won, the kernel can hit a use-after-free, resulting in an oops, panic, watchdog reset, or system hang. There is no evidence from the provided data that this vulnerability is being exploited in the wild or used by ransomware campaigns.

How to fix it

Update to a Linux kernel build that includes the upstream fix replacing the SPI-specific driver_override handling with the generic driver-core driver_override infrastructure, which provides proper locking. Because no exact fixed versions were provided, use the latest stable kernel from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform vendor and confirm that their advisory includes CVE-2026-31487 or the corresponding SPI driver_override locking fix. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting write access to sysfs, preventing untrusted workloads from mounting or writing host /sys, avoiding privileged containers with host device access, and disabling or removing unnecessary SPI device support where operationally feasible.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that contains the SPI driver_override locking fix. Validate exposure by checking whether the system has SPI bus devices under /sys/bus/spi/devices/ and whether untrusted users or workloads can write to driver_override, bind, or unbind sysfs attributes. After patching, verify the active kernel version with uname -a and the installed kernel package version with the platform package manager, then reboot into the fixed kernel. For source-based kernels, review the SPI bus code path and confirm it uses the generic driver-core driver_override infrastructure rather than unlocked SPI-specific access. Review kernel logs after validation testing to ensure no new KASAN use-after-free, kernel oops, or SPI driver binding errors occur.

Typical attack path

1. Gain local access to an affected Linux system with SPI devices present or SPI subsystem enabled.
2. Obtain permissions sufficient to write to SPI sysfs controls such as driver_override or to trigger device/driver binding activity.
3. Identify SPI device paths under /sys/bus/spi/devices/.
4. Repeatedly modify, clear, or replace the driver_override value while concurrently triggering driver probe, unbind, bind, or reprobe operations.
5. Race the unlocked SPI match() callback against driver_override updates until freed memory is dereferenced.
6. Cause a kernel oops, panic, hang, or reboot, resulting in denial of service.

How to detect it

Look for evidence of exploitation or attempted exploitation in kernel and system logs rather than application logs. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd, EDR telemetry, container runtime logs, and crash dump infrastructure such as kdump, apport, abrt, or systemd-coredump. Focus on kernel oops, panic, KASAN use-after-free, general protection faults, page faults, watchdog resets, or unexpected reboots occurring near SPI driver bind, unbind, probe, reprobe, or driver_override activity. If auditd is enabled, search for writes to /sys/bus/spi/devices/*/driver_override and related bind/unbind files, especially repeated writes or concurrent access from shells, scripts, containers, or unfamiliar processes. For containerized environments, investigate privileged containers or workloads with host /sys mounted read-write around the time of the crash. Absence of these artifacts does not prove non-exploitation because a successful denial-of-service attempt may leave only a partial kernel log or no persistent logs if storage was not flushed before reboot.

• /sys/bus/spi/devices/*/driver_override
• /sys/bus/spi/drivers/*/bind
• /sys/bus/spi/drivers/*/unbind
• driver_override
• spi
• __driver_attach
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• BUG: KASAN: use-after-free
• use-after-free
• general protection fault
• Unable to handle kernel paging request
• kernel BUG at
• Kernel panic - not syncing
• Oops:
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• sysfs: cannot create duplicate filename
• audit: * driver_override

What your security team should do

• Prioritize patching affected Linux kernels on systems where local users, containers, automation agents, or third-party software can interact with /sys or SPI devices.
• Inventory systems with SPI enabled by searching for /sys/bus/spi/devices/ and installed kernels older than the vendor-fixed release.
• Treat embedded, appliance, industrial, and edge devices as higher operational risk because a kernel crash may require manual recovery or physical access.
• Restrict privileged containers, hostPath mounts of /sys, CAP_SYS_ADMIN, and direct device access for untrusted workloads.
• Monitor kernel logs for use-after-free, oops, panic, or SPI driver bind/unbind activity until remediation is complete.
• If kernel live patching is available from the vendor and covers this issue, use it as a temporary risk reduction measure but still plan a reboot into a fully fixed kernel.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not in KEV, schedule remediation according to local kernel vulnerability SLAs unless the system has high availability requirements or broad local-user exposure.