CVE-2026-90125 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix request buffer leak in smb2_new_read_req()
smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between:
rc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, (void **) &req, total_len); if (rc) return rc;
if (server == NULL) return -ECONNABORTED; [...]
rdata->mr = smbd_register_mr(server->smbd_conn, &rdata->subreq.io_iter, true, need_invalidate); if (!rdata->mr) return -EAGAIN;
On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case.
The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning:
wdata->mr = smbd_register_mr(...); if (!wdata->mr) {
rc = -EAGAIN; goto async_writev_out; }
Commit b7972092199f ("cifs: smbd: Retry on memory registration failure") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other.
Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident.
Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting.
Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata.
The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
This vulnerability represents a resource management flaw within the Linux kernel’s Common Internet File System (CIFS) client implementation, specifically affecting the SMB2 protocol handling for asynchronous read operations. The core technical issue resides in the function smb2_new_read_req(), which is responsible for initializing and allocating request buffers required for network communication with an SMB server. During this process, the function calls smb2_plain_req_init() to allocate a buffer of the specified total length. However, the code structure contains two potential early exit points before the allocated buffer pointer is assigned to the output variable buf that tracks ownership for cleanup routines. Specifically, if smb2_plain_req_init fails or if the server context is determined to be null, the function returns an error code without freeing the previously allocated memory. This creates a direct memory leak where kernel heap space is consumed but never returned to the system pool because the caller assumes no allocation occurred when these specific errors are encountered.
The operational impact of this vulnerability extends beyond simple resource exhaustion due to the retry logic inherent in network file systems. When smb2_new_read_req returns an error, particularly -EAGAIN which indicates a temporary condition such as memory registration failure for Direct Memory Access (DMA) operations via SMB Direct, the calling function smb2_async_readv() treats this as a replayable error. Consequently, it marks the subrequest with NETFS_SREQ_NEED_RETRY and loops back to attempt the operation again. Because each retry triggers a new allocation in smb2_new_read_req that is leaked on failure, repeated connection issues or transient DMA registration failures can lead to rapid kernel memory consumption. This behavior effectively creates a denial of service condition against local system resources, potentially leading to out-of-memory scenarios for the kernel space if left unchecked over time. The vulnerability is further exacerbated by the fact that smb2_should_replay() may short-circuit retry limits on hard mounts, allowing unbounded attempts and thus continuous leakage until system stability is compromised.
From a classification perspective, this flaw aligns with CWE-401, which describes missing release of memory after effective usage, as well as CWE-772, the lack of releasing resources before exiting an error path. The attack vector involves triggering specific network conditions that cause SMB Direct memory registration to fail repeatedly, such as manipulating connection states or exploiting race conditions in server availability. In terms of MITRE ATT&CK mapping, this vulnerability can be leveraged for resource exhaustion attacks against Linux-based file servers or clients running CIFS mounts, falling under the category of Impact via Denial of Service. It is important to note that this issue is isolated to the asynchronous read path; synchronous SMB2_read operations are unaffected because they pass a null rdata structure which guards the problematic memory registration block from executing.
The resolution involves restructuring the error handling logic within smb2_new_read_req() to ensure that any allocated buffer is properly released before returning an error code, mirroring the correct behavior already present in the write path functions like smb2_async_writev(). The fix ensures consistent resource management across both read and write operations, preventing leaks regardless of which specific initialization step fails. For system administrators and developers maintaining Linux kernels with CIFS support, applying this patch is critical to maintain long-term stability during network fluctuations. Mitigation strategies include ensuring the kernel is updated to a version containing this fix, monitoring for unusual memory growth in processes handling SMB connections, and verifying that retry limits are appropriately configured to prevent excessive replay attempts if immediate patching is not feasible.