CVE-2026-31658 Fixes Linux altera-tse DMA Memory Leak After dma_map_single Failure

CVE-2026-31658: Linux Kernel Altera TSE Driver Memory Leak Fixed After DMA Mapping Failure​

Published: April 26, 2026
CVE: CVE-2026-31658
Component: Linux kernel networking driver, altera-tse
Affected area: Altera Triple-Speed Ethernet transmit path
Issue type: Memory leak / potential availability impact
Current NVD status: Awaiting enrichment
CVSS: Not yet assessed by NVD at the time of publication
Source: Microsoft Security Response Center listing referencing the kernel.org CVE record

Overview​

CVE-2026-31658 is a newly published Linux kernel vulnerability involving the Altera Triple-Speed Ethernet driver, commonly referred to in the kernel tree as altera-tse. The flaw is located in the transmit routine tse_start_xmit(), where the driver prepares an outgoing network packet for DMA-based transmission.
The problem is narrow but important: if dma_map_single() fails while the driver is preparing the socket buffer, or skb, for transmission, the function returns NETDEV_TX_OK without freeing that skb. In Linux networking driver semantics, returning NETDEV_TX_OK tells the network stack that the packet has been accepted and consumed by the driver. If the driver has not actually queued the packet and also fails to free the buffer, ownership is effectively lost. The packet buffer remains allocated and is never released, creating a memory leak.
The upstream fix is intentionally small. It adds a call to dev_kfree_skb_any() in the DMA mapping failure path before returning from the transmit function. That change ensures that when the driver reports the packet as consumed, the packet buffer is actually released.
This is not a flashy vulnerability. There is no indication from the available record that it allows arbitrary code execution, privilege escalation, or information disclosure. Its realistic security concern is availability: repeated triggering of the faulty path could consume kernel memory over time and potentially contribute to degraded performance, networking instability, or an out-of-memory condition on affected systems.

Technical background​

The Linux kernel networking stack represents packets using socket buffers, usually called sk_buff or simply skb. An skb contains metadata and pointers to the packet data as it moves through the networking stack. When a packet is transmitted through a network interface, the kernel eventually calls the network driver’s transmit callback, commonly implemented as ndo_start_xmit.
For the Altera TSE driver, that transmit callback is tse_start_xmit(). The function is responsible for taking the outgoing packet, preparing it for the hardware, mapping memory so that the device can access the packet contents via DMA, and then handing the packet to the driver’s transmit descriptor machinery.
DMA, or Direct Memory Access, allows a device to read from or write to system memory without the CPU manually copying every byte. Before a device can DMA packet data, the kernel must create a DMA mapping for the relevant memory. In this driver path, that is done with dma_map_single(). The mapping can fail, and kernel drivers are expected to handle that case correctly.
Correct handling matters because the network stack and driver have an ownership contract. Once the driver returns NETDEV_TX_OK, the stack assumes the driver has taken responsibility for the packet. That means the stack will not retry the same packet and will not free the skb itself. If the driver cannot transmit the packet but still returns NETDEV_TX_OK, it must free the skb before returning. Otherwise, the packet buffer is leaked.
That is exactly what CVE-2026-31658 fixes.

What went wrong​

The vulnerable path can be summarized as follows:

• The kernel networking stack passes an outgoing skb to the Altera TSE transmit function.
• tse_start_xmit() attempts to map the packet data for DMA using dma_map_single().
• The DMA mapping operation fails.
• The driver logs a DMA mapping error.
• The function sets its return value to NETDEV_TX_OK.
• The function exits without freeing the skb.

The key issue is the mismatch between the return value and the cleanup behavior. NETDEV_TX_OK means “the driver consumed this packet.” But on this error path, the driver did not transmit it and did not release it. As a result, the buffer remains allocated with no remaining owner that will clean it up.
The fix adds the missing cleanup call before returning:
dev_kfree_skb_any(skb)
That function is appropriate in driver paths because it can be used from different contexts and safely frees the socket buffer. After the fix, when DMA mapping fails, the driver logs the error, frees the packet buffer, returns NETDEV_TX_OK, and exits without leaking the skb.

Why a one-line fix can matter​

At first glance, a one-line change may seem too small to justify a CVE. However, memory lifecycle bugs in kernel code can have serious consequences, especially in paths that may execute repeatedly.
Transmit paths are high-frequency code. A busy interface may handle many packets per second. If an error condition causes one skb to leak each time a packet attempts to transmit, memory consumption can grow quickly. Even if the failure condition is uncommon, the bug is still security-relevant because kernel memory is a shared, critical resource. Losing enough of it can affect unrelated services, trigger reclaim pressure, degrade system responsiveness, or lead to an out-of-memory situation.
The severity depends heavily on whether the affected driver is present and active, whether the system uses hardware that depends on the Altera TSE driver, and whether DMA mapping failures can be induced or occur naturally under the system’s workload and configuration.
In other words, the bug is simple, but the context is privileged and performance-sensitive. Network drivers run inside the kernel, and small accounting mistakes in kernel memory management can become system-wide availability issues.

Affected systems​

CVE-2026-31658 affects Linux systems that include and use the Altera TSE Ethernet driver. The driver is located under the Linux kernel networking driver tree for Altera Ethernet hardware.
This is not a general-purpose vulnerability affecting every Linux network interface. Systems are only practically exposed if they have the vulnerable driver built into the kernel or loaded as a module and are using relevant Altera TSE hardware or compatible FPGA-based Ethernet designs.
The Altera Triple-Speed Ethernet MAC is commonly associated with embedded and FPGA-oriented environments rather than typical consumer desktops or laptops. That means the most likely affected systems include:

• Embedded Linux devices using Altera or Intel FPGA networking designs.
• Industrial or specialized appliances with Altera Triple-Speed Ethernet MAC integration.
• Custom hardware platforms using the Linux altera-tse driver.
• Vendor kernels derived from affected Linux stable branches.
• Development boards or FPGA evaluation platforms where the Altera TSE Ethernet driver is enabled.

Most Windows desktop users are not directly affected unless they are running a Linux environment or appliance kernel that includes this driver. However, Microsoft has listed the CVE through its Security Update Guide because Microsoft products and services can include Linux-based components, including Azure Linux and container-related infrastructure. Administrators should evaluate exposure based on the actual kernel configuration and hardware in use rather than assuming all Linux systems are affected equally.

What administrators should check​

The first question is whether the system uses the vulnerable driver.
On Linux systems, administrators can check whether the driver is present or loaded by looking for the relevant module or driver name. Depending on how the kernel was built, the driver may be compiled as a module or built directly into the kernel image.
Practical checks include:

• Reviewing kernel configuration for Altera TSE support.
• Checking loaded modules for altera_tse or similarly named driver entries.
• Inspecting network interface driver information with tools such as ethtool -i.
• Reviewing device tree configuration on embedded systems.
• Checking vendor kernel changelogs for the upstream fix.
• Confirming whether the deployed kernel includes the patch adding dev_kfree_skb_any() to the DMA mapping failure path in tse_start_xmit().

For appliance, embedded, and FPGA-based deployments, administrators may need to consult the board vendor or BSP maintainer. Many embedded systems use vendor-maintained kernels that lag upstream stable kernels or carry custom backports. A system can appear to be on a familiar version number while still containing vendor-specific changes.

Exposure and exploitability​

The available information does not indicate that CVE-2026-31658 is remotely exploitable in the usual sense. The vulnerable function is in the transmit path, meaning it is triggered when the system sends packets through the affected interface. Remote network traffic received by the interface does not directly enter this code path unless the system is forwarding, bridging, routing, responding, or otherwise generating outbound traffic through the driver.
Even then, the leak occurs only when dma_map_single() fails. DMA mapping failures are error conditions. They may happen because of memory pressure, DMA addressing limitations, IOMMU-related constraints, device-specific mapping problems, or other low-level resource issues. Whether an attacker can reliably cause such failures depends on the platform and configuration.
The most reasonable impact classification is denial of service through memory exhaustion or system degradation. A local user or workload capable of generating outbound traffic through the affected interface might contribute to repeated transmit attempts. If DMA mapping failures occur repeatedly, the leak can accumulate. In constrained embedded systems, even modest leaks can matter because memory budgets are smaller and systems may be expected to run continuously for long periods.
However, administrators should avoid overestimating the issue. There is no public indication in the record that this vulnerability allows code execution, direct privilege escalation, or leakage of sensitive data. It is a resource-management bug in a specific driver error path.

CVSS and NVD status​

At the time of publication, the National Vulnerability Database entry is marked as awaiting enrichment. That means NVD has received the CVE record but has not yet completed its own analysis, including CVSS scoring, affected product enumeration, and weakness classification.
The CVE record currently does not include an NVD CVSS 4.0, CVSS 3.x, or CVSS 2.0 score. Security teams that rely on CVSS-based prioritization should not interpret the lack of a score as meaning the issue is harmless. It simply means NVD has not yet published its assessment.
For operational prioritization, organizations should consider:

• Whether the affected driver is enabled.
• Whether the system uses relevant hardware.
• Whether the system is exposed to untrusted local workloads.
• Whether the system forwards or generates high network traffic.
• Whether the device is memory constrained.
• Whether it is an embedded or long-running appliance.
• Whether vendor patches are available.
• Whether the system is part of a critical network path.

For many general-purpose Linux servers, this CVE may be irrelevant if the driver is not built or loaded. For affected embedded systems, it should be treated as a legitimate stability and availability fix.

Patch history​

The upstream patch was authored by David Carlier and accepted into the Linux networking tree. It was later picked up for stable kernel branches. The patch description identifies the original driver introduction as the fixed-by lineage and marks the change for stable backporting.
The fix is small and low risk: it adds one missing skb free operation in the DMA mapping error path. There is no redesign of the transmit path, no new feature, and no behavioral change during successful transmission. The driver continues to return NETDEV_TX_OK after a DMA mapping failure, but after the patch it frees the packet buffer first.
The referenced stable commits indicate that the fix has been backported across multiple maintained kernel lines. Administrators should use their distribution or vendor-provided kernel updates rather than manually applying upstream patches unless they maintain custom kernels.

Why NETDEV_TX_OK is important here​

In Linux network drivers, transmit return values communicate what the driver did with a packet. NETDEV_TX_OK means the packet was accepted. NETDEV_TX_BUSY means the driver could not accept it and the stack may retry later.
Returning NETDEV_TX_OK after a failure can be valid if the driver intentionally drops the packet and performs the required cleanup. Dropping a packet on an unrecoverable mapping failure is acceptable. Leaking the packet is not.
The vulnerable code path attempted to handle the DMA mapping failure as a consumed packet but omitted the cleanup. That is why the fix does not necessarily change the return value. Instead, it aligns the cleanup behavior with the meaning of the return value.
This distinction is important for understanding why the patch is a memory-management fix rather than a change to network retry behavior. If the driver returned NETDEV_TX_BUSY after a mapping failure, it would imply that the stack may attempt transmission again later. But in many driver error paths, dropping the packet and reporting it consumed is simpler and valid, provided the skb is released.

Potential symptoms​

Most administrators will not see a clear “CVE-2026-31658” error message on affected systems. Symptoms, if the issue is encountered, would likely appear as general memory pressure or network driver instability.
Possible indicators include:

• Repeated kernel log messages about DMA mapping errors from the Altera TSE driver.
• Gradual memory consumption during periods of network transmission.
• Network interface instability under memory pressure.
• Out-of-memory killer activity on embedded systems.
• Degraded throughput or packet loss during transmit failures.
• System instability after prolonged operation under specific workloads.

Because the leak occurs on an error path, the presence of the vulnerable code does not mean every affected system will leak memory during normal operation. The system must encounter DMA mapping failures in the transmit path.
For forensic analysis, kernel logs mentioning tse_start_xmit() or DMA mapping errors in the Altera TSE driver are especially relevant. Memory leak debugging tools, slab accounting, and kernel tracing may help confirm repeated skb leaks, but most administrators should focus on applying the fixed kernel rather than reproducing the issue.

Mitigation​

The recommended mitigation is to update to a kernel version or vendor kernel package that includes the fix for CVE-2026-31658.
For distribution-managed systems, install the latest kernel security update from the operating system vendor. For embedded systems, obtain an updated BSP, firmware image, or kernel package from the device vendor or board support maintainer. For custom kernels, backport the upstream one-line fix to the affected driver and rebuild.
If immediate patching is not possible, temporary risk-reduction steps may include:

• Disabling the affected network interface if it is not required.
• Using an alternative network interface or driver where available.
• Reducing untrusted local access to systems using the affected hardware.
• Monitoring logs for DMA mapping failures.
• Monitoring memory pressure and out-of-memory events.
• Restarting affected appliances during maintenance windows if memory growth is observed.
• Limiting workloads that generate high outbound traffic through the affected interface.

These mitigations do not remove the bug. They only reduce the chance that the vulnerable path is exercised or limit the operational impact until a fixed kernel can be deployed.

Guidance for Microsoft and Azure environments​

The CVE appears in Microsoft’s Security Update Guide because Microsoft tracks vulnerabilities that may affect Microsoft-maintained Linux components and services. The presence of an MSRC entry does not necessarily mean every Windows installation is affected.
Windows client and server systems are not directly affected by this Linux kernel driver issue unless they include or rely on a vulnerable Linux kernel in a relevant deployment scenario. Examples where administrators may need to pay closer attention include Linux virtual machines, Azure Linux images, container hosts, Kubernetes nodes, embedded Linux appliances integrated into Microsoft-managed environments, or custom Linux kernels maintained as part of an enterprise platform.
For Azure and cloud environments, the key operational question is whether the deployed Linux kernel includes the affected driver and whether the relevant hardware path exists. In many virtualized environments, the Altera TSE hardware driver will not be used. However, organizations should still follow vendor guidance because cloud images and container hosts may receive kernel updates that include many CVE fixes regardless of whether every individual driver is used.

Developer lessons​

CVE-2026-31658 is a good example of why kernel error paths deserve the same scrutiny as common success paths. The success path in a transmit routine is usually well tested because it runs constantly. Error paths such as DMA mapping failure may be harder to exercise, especially on development systems with ample resources. But when they are wrong, they often fail in ways that are difficult to diagnose.
The core lesson is ownership clarity. When a function receives a resource, every exit path must clearly transfer, retain, or release ownership. In tse_start_xmit(), once the driver returns NETDEV_TX_OK, the stack will not free the skb. Therefore, if the driver cannot queue the packet, it must free it before returning.
This is a common pattern in kernel networking bugs. The resource is not necessarily complicated, but the interaction between return codes and ownership semantics can be subtle. A single missing free operation can survive for years if the failure path is rare.

Risk assessment​

For typical desktop and server users, the practical risk is likely low because the affected Altera TSE hardware and driver are not commonly used on mainstream PCs. For embedded and FPGA-based deployments, the risk may be more meaningful, especially if devices are memory constrained, long lived, or deployed in environments where local workloads are not fully trusted.
The issue should be prioritized higher when all of the following are true:

• The system uses the Altera TSE driver.
• The affected network interface is active.
• The system is memory constrained.
• The system processes or generates sustained outbound traffic.
• The system is exposed to untrusted users, containers, or workloads.
• The vendor kernel has not yet incorporated the stable fix.

The issue should be prioritized lower when:

• The driver is not built, loaded, or used.
• The system has no Altera TSE hardware.
• The system is not Linux-based.
• The affected interface is disabled.
• The deployed kernel already includes the patch.

Recommended action​

Administrators should review affected Linux systems and confirm whether the Altera TSE driver is present and active. If it is, plan a kernel update through the normal vendor-supported channel. For embedded products, request confirmation from the vendor that the CVE-2026-31658 fix has been included.
Security teams should not rely solely on the absence of an NVD CVSS score. The vulnerability is currently awaiting NVD enrichment, and its operational importance depends more on hardware and driver exposure than on broad internet-facing exploitability.
For most organizations, the correct response is straightforward: identify whether the driver is in use, apply the fixed kernel when available, and monitor embedded or specialized Linux devices that may not receive automatic updates.

Bottom line​

CVE-2026-31658 is a Linux kernel memory leak in the Altera TSE Ethernet driver’s transmit path. When DMA mapping fails, the vulnerable driver returns NETDEV_TX_OK without freeing the packet buffer, causing an skb leak. The fix adds the missing dev_kfree_skb_any() call before returning.
The vulnerability is most relevant to embedded, FPGA, and specialized Linux systems using the Altera Triple-Speed Ethernet driver. It is primarily an availability concern rather than a code execution or data disclosure issue. Systems that do not include or use the altera-tse driver are unlikely to be affected in practice.
Administrators should update affected kernels, verify vendor backports, and pay particular attention to long-running embedded devices where small kernel memory leaks can become operationally significant over time.

---

Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center