CVE-2026-31489

What it actually does

This is a Linux kernel memory-management flaw in the Meson SPICC SPI controller driver. The driver registers an SPI controller using device-managed cleanup, which already releases the controller reference during teardown. The remove path also calls spi_controller_put(), causing the same controller reference to be released twice. A local attacker who can trigger device removal, driver unbind, module teardown, or equivalent platform-device cleanup may be able to cause a use-after-free, refcount corruption, kernel crash, or potentially kernel-mode code execution depending on allocator state and hardening features. The CVSS vector indicates local access with low privileges, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels on hardware that includes the Meson SPICC SPI controller may be exposed to local privilege escalation or denial-of-service risk. In practical terms, a user or compromised local process could potentially crash the system or attempt to gain elevated control. The issue is not known to be exploited in the wild, is not in CISA KEV, has no known public exploit maturity, and has a very low, stable EPSS score, so broad internet-scale exploitation is unlikely; however, kernel vulnerabilities remain high-impact on shared, embedded, appliance, and multi-user systems.

How an attack unfolds

An attacker first needs local execution on a system running an affected Linux kernel with the Meson SPICC driver present and the relevant controller device active or removable. The attacker then attempts to trigger the driver's remove path, commonly through platform-driver unbind, device teardown, module unload, hotplug-like lifecycle events, or another path that invokes meson_spicc_remove(). During cleanup, the device-managed SPI controller registration releases the controller reference automatically, and the explicit spi_controller_put() call releases it again. That double-put can corrupt kernel reference state and may produce a use-after-free. A basic exploit would aim for a reliable kernel panic; a more advanced exploit would attempt heap grooming around the freed object to gain control over kernel memory and escalate privileges.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Meson SPICC driver double-put condition. No exact fixed package versions were provided, so organizations should obtain patched kernels from their Linux distribution, device vendor, appliance vendor, or kernel maintenance branch and verify that the remove path no longer calls spi_controller_put() after devm_spi_register_controller() cleanup. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the Meson SPICC driver if the hardware function is not required, preventing untrusted users from accessing driver unbind/module-management interfaces, restricting CAP_SYS_ADMIN and root-equivalent access, and avoiding dynamic driver unload/unbind workflows on affected systems.

How to confirm the fix worked

Confirm remediation by checking that deployed kernel packages include the vendor fix for the Meson SPICC double-put bug. On source-based or custom kernels, inspect the meson-spicc driver remove path and verify that the redundant spi_controller_put() call has been removed when devm_spi_register_controller() is used. At runtime, confirm the host is running the patched kernel version, rebooted into that kernel, and no older vulnerable kernel remains in production use. If testing is safe in a non-production environment, exercise driver bind/unbind or device teardown while monitoring dmesg for refcount warnings, KASAN use-after-free reports, kernel oopses, or panics.

Typical attack path

1. Obtain local code execution on a host running an affected Linux kernel.
2. Confirm the system includes or has loaded the Meson SPICC SPI controller driver.
3. Identify a way to trigger device or driver removal, such as platform-driver unbind, module unload, or device lifecycle teardown.
4. Trigger the remove path so the SPI controller reference is released by devm cleanup and then released again explicitly.
5. Leverage the resulting refcount corruption or use-after-free to crash the kernel or attempt privilege escalation.
6. If successful, maintain elevated access or use the crash to disrupt system availability.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal entries, crash dumps, and audit logs for evidence of Meson SPICC driver removal followed by memory-corruption symptoms. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, pstore/ramoops records, kdump/vmcore analysis, auditd logs for writes to sysfs driver bind/unbind files, and EDR telemetry showing privileged shell commands that unload or unbind platform drivers. Look for kernel warnings such as refcount underflow, use-after-free, KASAN reports, general protection faults, NULL pointer dereferences, or panics temporally associated with meson-spicc, SPI controller teardown, platform-driver unbind, or module removal. There are no known public exploit-specific payload indicators, so detection should focus on vulnerable-driver lifecycle activity and kernel memory-corruption artifacts.

• meson-spicc
• spi-meson-spicc
• meson_spicc_remove
• spi_controller_put
• devm_spi_register_controller
• /sys/bus/platform/drivers/meson-spicc/unbind
• /sys/bus/platform/drivers/meson-spicc/bind
• BUG: KASAN: use-after-free
• refcount_t: underflow
• refcount_t: addition on 0
• Unable to handle kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• platform driver meson-spicc
• spi_controller_release

What your security team should do

• Inventory Linux systems, embedded devices, and appliances using Amlogic/Meson platforms or the Meson SPICC SPI controller driver.
• Prioritize patching systems where untrusted users, containers with elevated capabilities, local shell users, or third-party workloads can execute code.
• Apply vendor kernel updates that include the Meson SPICC driver fix, then reboot to ensure the patched kernel is active.
• If patching is delayed, disable or blacklist the Meson SPICC driver where operationally safe and restrict access to driver unbind, module unload, and privileged device-management interfaces.
• Monitor kernel logs for crashes, refcount warnings, KASAN reports, and suspicious driver unbind activity involving meson-spicc.
• Treat unexpected kernel panics on affected hardware as potentially security-relevant until logs and crash dumps are reviewed.
• Because this issue is not currently KEV-listed and has low EPSS, handle it through normal kernel patch governance unless affected systems are multi-user, internet-managed, safety-critical, or high-availability appliances.