CVE-2024-35882: SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP
Jan Schunk reports that his small NFS servers suffer from memory
exhaustion after just a few days. A bisect shows that commit
e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single
sock_sendmsg() call") is the first bad commit.
That commit assumed that sock_sendmsg() releases all the pages in
the underlying bio_vec array, but the reality is that it doesn't.
svc_xprt_release() releases the rqst's response pages, but the
record marker page fragment isn't one of those, so it is never
released.
This is a narrow fix that can be applied to stable kernels. A
more extensive fix is in the works.
Security readout for executives and security teams
Plain-English summary
Affected Linux NFS servers using RPC over TCP can slowly lose memory because the kernel fails to release a page fragment after sending responses. Memory may become exhausted after days, disrupting service. The issue affects availability, not data confidentiality or integrity.
Executive priority
Prioritize remediation for exposed or critical NFS servers because prolonged operation can exhaust memory and interrupt service. Treat internal, monitored systems as scheduled high-priority patching rather than an emergency, absent evidence of active exploitation.
Technical view
A regression introduced by Linux commit e18e157bb5c8 incorrectly assumed sock_sendmsg() released every page in a bio_vec. svc_xprt_release() frees response pages but not the RPC record-marker fragment, causing a gradual server-side leak. The cited stable-kernel commits implement a narrow correction.
Likely exposure
Exposure is concentrated on Linux systems running affected kernel versions and serving SUNRPC workloads, especially NFS over TCP. The supplied affected-version data includes 6.6, 6.6.26, 6.8.5, and 6.9, but its range representation is ambiguous; verify distribution-specific kernel status.
Exploitation context
The CVSS 3.1 assessment is 7.5: network-accessible, low complexity, no privileges or user interaction, with high availability impact. The record is not in KEV, and the supplied sources provide no evidence of active exploitation or a public exploit.
Researcher notes
The failure is a reference-release mismatch involving the RPC-over-TCP record-marker page fragment. The report attributes the regression to e18e157bb5c8 and describes the published change as a narrow stable-kernel fix. Exact affected ranges cannot be reconstructed confidently from the supplied normalized version list.
Mitigation direction
Update to a vendor-supported kernel containing the applicable cited stable fix.
Check distribution advisories because packaged kernel versions may not map directly to upstream numbering.
Prioritize internet-reachable or business-critical NFS servers using RPC over TCP.
Monitor memory until patched and restart affected services or systems if operationally necessary.
Validation and detection
Inventory kernel versions on systems providing NFS or other SUNRPC services over TCP.
Compare kernel builds against vendor advisories and the cited upstream stable commits.
Review memory trends and exhaustion events on relevant servers.
Confirm memory remains stable under representative RPC-over-TCP workloads after updating.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35882 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.