CVE-2026-80706: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-80706 Overview

CVE-2026-80706 affects the Linux kernel's can/softing driver, specifically the fw_parse() function used to load firmware onto Softing CAN controllers. The parser reads a fixed record header, a payload, and a trailing checksum without validating that these reads stay within the firmware blob. A truncated firmware image can therefore trigger out-of-bounds reads. The same record supplies destination addresses and lengths for writes into Dual-Port RAM (DPRAM), and the existing bounds checks use wrap-prone mixed signed arithmetic or, in the application loader, no bounds check at all.

Critical Impact
A local actor able to supply a malformed firmware blob to the softing CAN driver can trigger out-of-bounds memory access and DPRAM writes, potentially leading to kernel memory corruption on affected systems.

Affected Products

Linux kernel drivers/net/can/softing subsystem
Kernel builds with CONFIG_CAN_SOFTING enabled loading firmware for Softing CAN controllers
Distributions shipping vulnerable kernels prior to the fixes referenced in the mainline and stable trees

Discovery Timeline

2026-08-28 - CVE-2026-80706 published to NVD
2026-08-29 - Last updated in NVD database

Technical Details for CVE-2026-80706

Vulnerability Analysis

The fw_parse() routine in the Softing CAN driver walks a firmware blob composed of sequential records. Each record begins with a fixed-size header, followed by a variable-length payload whose size is declared inside the header, and ends with a trailing checksum. The parser advances through these fields without receiving the end of the firmware buffer as a parameter. When a record is truncated or crafted to declare an oversized payload, the header, payload, and checksum reads can extend past the mapped firmware image, producing out-of-bounds reads of kernel memory.

Beyond the source-side reads, each record also encodes destination addresses and lengths for the DPRAM copy. The generic firmware loader performs its bounds check using mixed signed and unsigned arithmetic that can wrap around, allowing a malformed record to pass the check while pointing outside the mapped DPRAM window. The application loader is more permissive still and does not bound the staging copy at all, allowing writes derived from firmware-controlled fields to reach memory beyond the intended DPRAM region.

Root Cause

The root cause is missing and incorrect boundary validation in a kernel firmware parser. fw_parse() was written without knowledge of the firmware blob length, so record-span validation could not be performed. The generic DPRAM bounds check relied on wrap-prone mixed signed arithmetic, and the application loader omitted destination bounds validation entirely. The fixes pass the firmware end to the parser, validate the full source record, switch generic DPRAM records to a signed wide offset, and validate the application staging span against the mapped DPRAM before copying.

Attack Vector

Exploitation requires local access with sufficient privilege to influence firmware loaded by the softing driver, typically via a crafted firmware image reachable through the kernel firmware search path or by triggering a firmware reload against a Softing CAN device. Remote or unauthenticated exploitation is not applicable. Successful exploitation can corrupt kernel memory through out-of-bounds DPRAM writes or leak kernel data through out-of-bounds reads during parsing.

No public proof-of-concept has been published for CVE-2026-80706. Technical detail is available in the mainline and stable kernel commits, including Kernel Commit 2ee477e and Kernel Commit f6d9a6a.

Detection Methods for CVE-2026-80706

Indicators of Compromise

Kernel log messages from the softing driver reporting firmware parse failures, checksum mismatches, or DPRAM copy errors around firmware load events
Unexpected kernel oops, KASAN reports, or slab corruption warnings referencing fw_parse or softing symbols
Non-standard or unsigned firmware files appearing under /lib/firmware/ paths associated with Softing CAN devices

Detection Strategies

Inventory hosts loading the softing kernel module and correlate against kernel build versions that predate the fix commits
Alert on writes to /lib/firmware/ paths used by the CAN subsystem and on request_firmware events targeting Softing images
Review dmesg and journal telemetry for CAN driver initialization failures following firmware updates or module reloads

Monitoring Recommendations

Forward kernel and audit logs to a centralized analytics platform and build detections around softing firmware load and parse errors
Track loaded kernel module inventory across the fleet and flag hosts that still expose the vulnerable driver after the patch window
Monitor privileged file writes to firmware directories and unexpected insmod, modprobe, or rmmod activity involving CAN modules

How to Mitigate CVE-2026-80706

Immediate Actions Required

Apply the latest stable kernel update from your distribution that includes the referenced can/softing fix commits
Where a patched kernel is not yet available, blacklist the softing module on systems that do not require Softing CAN hardware
Restrict write access to /lib/firmware/ to root and audit any recent modifications to Softing firmware images

Patch Information

The issue is resolved by a series of mainline and stable-tree commits that pass the firmware end pointer into fw_parse(), validate full source record spans, switch the generic DPRAM bounds check to a signed wide offset, and validate the application staging span against the mapped DPRAM before copying. Relevant fixes include Kernel Commit 2ee477e, Kernel Commit 808ed89, Kernel Commit 84c850b, Kernel Commit 856d6cb, Kernel Commit ad331e2, Kernel Commit ae588e5, Kernel Commit d0eac0e, and Kernel Commit f6d9a6a.

Workarounds

Disable or unload the softing module on systems that do not depend on Softing CAN controllers using modprobe -r softing and adding a blacklist entry in /etc/modprobe.d/
Enforce strict permissions on the firmware directory and ensure only trusted, vendor-supplied Softing firmware images are present
Limit administrative access on affected hosts to reduce the population of local accounts capable of triggering firmware load paths

bash

# Prevent the vulnerable driver from loading until the kernel is patched
echo 'blacklist softing' | sudo tee /etc/modprobe.d/blacklist-softing.conf
sudo modprobe -r softing 2>/dev/null || true

# Restrict firmware directory to root ownership and review recent changes
sudo chown -R root:root /lib/firmware
sudo find /lib/firmware -type f -newer /var/log/wtmp -ls