CVE-2026-31658

What it actually does

This is a local denial-of-service flaw in the Linux kernel Altera Triple-Speed Ethernet (TSE) network driver. In tse_start_xmit(), if dma_map_single() fails while preparing a packet for DMA transmission, the driver incorrectly returns NETDEV_TX_OK without freeing the associated socket buffer (skb). Because NETDEV_TX_OK tells the networking stack that the packet was consumed, the skb is not reclaimed, causing a kernel memory leak each time the DMA mapping failure path is hit. Repeated failures can exhaust kernel memory and degrade or crash the system.

Why it matters to the business

Systems using the affected Linux kernel driver for Altera TSE network interfaces can become unstable or unavailable if a local user or process can repeatedly trigger the transmit error path. The likely operational impact is service degradation, network disruption, or host crashes due to memory exhaustion. The CVSS score is moderate and EPSS is very low, there is no known KEV listing, no known ransomware use, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, embedded, industrial, FPGA-based, or appliance-style systems using this driver may have higher operational sensitivity because downtime can affect network connectivity or device availability.

How an attack unfolds

An attacker first needs local access with the ability to generate network traffic through an interface backed by the Altera TSE driver. The attacker then creates conditions where dma_map_single() fails during packet transmission, such as sustained transmit pressure combined with memory or DMA resource exhaustion. Each time the vulnerable error path is reached, the driver reports the packet as consumed but does not free the skb, leaking kernel memory. By repeatedly triggering this path, the attacker can gradually consume kernel memory until networking becomes unreliable, processes are killed by the OOM killer, or the host becomes unstable or crashes. There are no known named threat actors or active exploitation campaigns associated with this vulnerability.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the Altera TSE driver, specifically the change that frees the skb with dev_kfree_skb_any() before returning from the dma_map_single() failure path in tse_start_xmit(). No exact fixed package versions were provided, so use the fixed kernel versions supplied by the relevant Linux distribution, appliance vendor, board support package, or long-term-stable kernel branch. Where immediate patching is not possible, reduce exposure by disabling unused Altera TSE interfaces, unloading or blacklisting the altera-tse driver if it is not required, restricting local shell/container access, limiting untrusted users’ ability to generate high-volume traffic, and monitoring memory pressure on affected systems. Mitigations should be treated as temporary because the underlying leak is in kernel driver error handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the patched Altera TSE driver source or vendor advisory fix. On source-based or BSP builds, inspect drivers/net/ethernet/altera/altera_tse_main.c and confirm that the dma_map_single() error path in tse_start_xmit() frees the skb before returning NETDEV_TX_OK. On packaged systems, verify the installed kernel version against the distribution or vendor security advisory for this vulnerability, then reboot into the fixed kernel. Confirm exposure by checking whether the altera-tse driver is loaded or built in, whether Altera TSE network interfaces are present, and whether the system is using affected kernel builds. Functional validation can include controlled transmit testing while monitoring kernel memory, skb slab usage, DMA mapping error logs, and absence of sustained unreclaimed skb growth.

Typical attack path

1. Obtain local access to a system running an affected Linux kernel with the Altera TSE network driver in use.
2. Identify or use a network interface backed by the altera-tse driver.
3. Generate sustained outbound traffic through the affected interface.
4. Apply or wait for conditions that cause DMA mapping failures, such as memory pressure or DMA resource exhaustion.
5. Repeatedly trigger the transmit path so each DMA mapping failure leaks an skb.
6. Continue until kernel memory pressure causes service degradation, OOM events, networking failure, or system crash.

How to detect it

There is no unique public exploit signature for this vulnerability, so detection should focus on evidence of attempted or successful resource exhaustion on systems using the Altera TSE driver. Review kernel logs, system journals, dmesg output, OOM killer events, network driver messages, and monitoring data for repeated DMA mapping failures, unexplained growth in skb-related slab memory, sustained outbound traffic before memory pressure, interface transmit stalls, or crashes. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k, dmesg, netdev statistics, slabinfo, memory-pressure telemetry, and EDR process/network telemetry showing local processes generating abnormal traffic through affected interfaces. In forensic review, correlate the onset of memory growth or OOM events with high transmit volume on an Altera TSE interface. Because normal system memory pressure can produce similar artifacts, treat these indicators as suspicious only when the altera-tse driver is present and skb memory increases repeatedly without recovery.

• altera-tse
• altera_tse
• tse_start_xmit
• drivers/net/ethernet/altera/altera_tse_main.c
• dma_map_single
• DMA mapping failed
• NETDEV WATCHDOG
• Out of memory: Killed process
• oom-killer
• /sys/module/altera_tse
• /proc/slabinfo
• skbuff_head_cache

What your security team should do

• Inventory Linux systems, appliances, embedded devices, FPGA-based platforms, and board support packages that use the Altera TSE Ethernet driver.
• Prioritize patching systems where the altera-tse driver is active and local users, containers, workloads, or services can generate outbound traffic through the affected interface.
• Obtain fixed kernel packages or vendor BSP updates and deploy them during the next maintenance window; accelerate for safety-critical, industrial, or high-availability systems.
• If patching is delayed, disable unused Altera TSE interfaces or unload/blacklist the driver where operationally feasible.
• Restrict local access and reduce the ability of untrusted users or workloads to create sustained traffic or memory pressure on affected hosts.
• Monitor affected systems for increasing kernel memory use, skb slab growth, OOM killer activity, transmit stalls, and DMA mapping failures.
• Because this is not in CISA KEV, has very low EPSS, and has no known exploit maturity, treat it as targeted remediation rather than an emergency internet-wide incident unless the affected driver is deployed in critical production infrastructure.