CVE-2026-43502
Description
In the Linux kernel, the following vulnerability has been resolved:
net/rds: handle zerocopy send cleanup before the message is queued
A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket.
The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue.
Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages.
This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In the Linux kernel's RDS, a zerocopy send failure before message queuing can cause incorrect cleanup, leading to potential use-after-free or memory corruption.
Vulnerability
In the Linux kernel's net/rds subsystem, a zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path in rds_message_purge() incorrectly infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. The vulnerability affects Linux kernel versions prior to the commits that introduced the fix (e.g., 21d70744e6d3, 3abc8983b2ba, 44b550d88b26, 0f5c185fc79a).
Exploitation
An attacker would need to trigger a zerocopy send that fails after page pinning but before the message is queued. This requires the ability to perform RDS zerocopy sends, which typically demands local access or specific network capabilities. The exact sequence is not detailed in the available description, but the race window occurs during send failure cleanup when the message is not yet associated with a socket.
Impact
The improper cleanup can lead to incorrect page accounting and potential use-after-free or memory corruption, as the notifier (op_mmp_znotifier) is not properly handled. This could result in system instability or privilege escalation.
Mitigation
The fix is included in the Linux kernel stable commits referenced in the advisory. Users should update to a kernel containing one of the following commits: 21d70744e6d3, 3abc8983b2ba, 44b550d88b26, or 0f5c185fc79a. No workaround is mentioned in the available sources.
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
1021d70744e6d33abc8983b2ba0f5c185fc79a14ef6fd18db244b550d88b2621d70744e6d314ef6fd18db20f5c185fc79a44b550d88b263abc8983b2baVulnerability mechanics
Root cause
"Incorrect cleanup logic in rds_message_purge() uses rm->m_rs to determine zerocopy state, so a zerocopy send that fails before the message is queued is cleaned up as if it owned normal payload pages, leading to inconsistent page reference accounting."
Attack vector
An attacker who can trigger RDS zerocopy sends (e.g., via the RDS protocol from a local or adjacent host) can cause a send to fail after user pages are pinned but before the message is attached to the sending socket. Because the purge path in rds_message_purge() infers zerocopy state from rm->m_rs rather than from op_mmp_znotifier, the cleanup treats the pinned pages as normal payload pages, corrupting page reference counts. This can lead to a use-after-free or memory corruption when the pages are later released or reused.
Affected code
The vulnerability is in the RDS (Reliable Datagram Sockets) subsystem of the Linux kernel, specifically in the rds_message_purge() function. The patch modifies the cleanup logic to capture op_mmp_znotifier up front and use it as the discriminator for zerocopy cleanup instead of relying on rm->m_rs.
What the fix does
The patch captures op_mmp_znotifier up front in rds_message_purge() and uses it as the sole discriminator for zerocopy cleanup. If the message is already associated with a socket (rm->m_rs is set), the existing completion path is kept. Otherwise, the pinned page accounting is dropped directly and the notifier is released before putting the payload pages. This ensures that early send failure cleanup follows the same zerocopy lifetime rules as the normal queued completion path, preventing the inconsistent page reference handling that could lead to use-after-free.
Preconditions
- networkAttacker must be able to trigger RDS zerocopy send operations (local or adjacent host access to RDS protocol).
- inputAttacker must cause a zerocopy send to fail after user pages are pinned but before the message is queued on the sending socket.
Generated on May 21, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- git.kernel.org/stable/c/0f5c185fc79a59ee9991234dd6d2a3e5afa6e75bnvd
- git.kernel.org/stable/c/14ef6fd18db2494098b21e0471bf27a1d8e9993envd
- git.kernel.org/stable/c/21d70744e6d3bbf9293aa1ee6fba7c53ad75275envd
- git.kernel.org/stable/c/3abc8983b2bae3f487f77d9da5527d7d6b210d46nvd
- git.kernel.org/stable/c/44b550d88b267320459d518c0743a241ab2108fanvd
News mentions
0No linked articles in our index yet.