CVE-2026-97952 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
sunvdc: unmap LDC cookies when the descriptor send fails
__send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never
visits it either. The map table entries are leaked permanently.
Since commit a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot.
It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025.
Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in the Linux kernel's sunvdc driver represents a critical resource management flaw within the virtual disk subsystem for SPARC systems utilizing Logical Domains (LDoms). The core issue resides in the __send_request function, which is responsible for preparing and transmitting I/O requests to the hypervisor via the LDC channel. Under normal operation, this process involves mapping request pages into the LDC channel's map table using ldc_map_sg, populating a descriptor with necessary metadata, marking it as VIO_DESC_READY, and finally signaling the hardware or virtual interface by ringing the doorbell through __vdc_tx_trigger. The vulnerability emerges when the final step of triggering transmission fails. In such error scenarios, the current implementation only logs an error message but neglects to clean up previously allocated resources. Specifically, the descriptor remains in a READY state with its associated memory mappings still active, and crucially, the producer index is not advanced to reflect that no valid request was sent. This oversight creates a persistent leak of map table entries because these entries are typically released only when the peer completes the descriptor or during specific reset procedures that rely on walking the range between consumer and producer indices.
The operational impact of this flaw is severe, particularly under conditions of high system load where transient failures such as EAGAIN become more frequent following recent kernel updates designed to prevent infinite loops in vio_ldc_send. Since the LDC channel utilizes a fixed-size map table with limited capacity, typically containing 8192 entries per channel, each failed transmission permanently consumes one entry without releasing it. Over time, this leads to significant fragmentation of the available mapping space. Because memory allocators often provide contiguous ranges for multi-segment requests, the system begins to fail larger I/O operations first as free contiguous blocks diminish. Eventually, ldc_map_sg fails entirely due to lack of space, rendering the virtual disk non-functional until a reboot occurs. This situation effectively results in a denial of service condition where legitimate storage access is blocked indefinitely without administrative intervention or system restart.
Furthermore, this vulnerability exacerbates issues related to retry mechanisms designed for handling transient errors like EAGAIN. When a request fails with EAGAIN, the driver attempts to requeue and resend it. However, because the previous mapping was never unmapped on failure, each retry attempt remaps pages over existing cookies without cleaning up the old mappings. This behavior rapidly accelerates the depletion of map table entries, leading to memory exhaustion at an accelerated rate proportional to the retry frequency. The orphaned mappings remain in the kernel's address space but are inaccessible and unreclaimable by standard mechanisms until the channel is reset or the system reboots. This creates a scenario where normal recovery logic inadvertently accelerates resource starvation, making automated resilience strategies counterproductive and potentially harmful to system stability.
From a technical classification perspective, this flaw aligns with CWE-401, which describes missing release of memory after successful allocation, leading to resource exhaustion. It also relates to CWE-756, the use of incorrect or non-existent reference in an object context, as the driver fails to properly manage the lifecycle of mapped resources when the transmission step fails. In terms of attack vectors and defensive considerations, this vulnerability can be leveraged for denial-of-service attacks by inducing repeated I/O errors that trigger the leak path repeatedly. The ATT&CK framework categorizes such resource exhaustion techniques under T1496, Resource Hijacking, specifically within the context of computational cycle or memory consumption to degrade service availability. Security analysts and system administrators should monitor LDC channel map table utilization metrics if available through hypervisor tools, as gradual depletion may serve as an early indicator of this issue in production environments running affected kernel versions.
Mitigation strategies primarily involve applying the upstream kernel patch that corrects the error handling path within __send_request. The fix ensures that when doorbell triggering fails, the driver properly unmaps the cookies associated with the request and resets the descriptor status to FREE, thereby preventing permanent leakage of map table entries. An important exception is handled for ENOTCONN errors, where the port has already been reset by lower-level functions; in this case, touching the stale descriptor could cause further instability, so no rollback is performed as the underlying resources have already been reallocated or torn down. Administrators should ensure that their systems are updated to include these corrections and consider implementing monitoring for I/O error rates on virtual disk interfaces to detect potential resource exhaustion early. Additionally, reviewing application-level retry logic to avoid aggressive requeuing during transient failures can help reduce pressure on the LDC map table while waiting for full kernel patches to be deployed across all nodes in a logical domain configuration.