Answer in brief
CVE-2026-43502 records a High severity (CVSS 7.8) vulnerability in net/rds: handle zerocopy send cleanup before the message is queued. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-43502 records a High severity (CVSS 7.8) vulnerability in net/rds: handle zerocopy send cleanup before the message is queued. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <e9aefdc5c53fe9aed108c14e3d155710a1bb14c9 || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <46662f7dc59475995609bf3e9d27eb36f4acf26f || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <1e262db7675e27f42c3f3f47d6011855f4454f24 || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <21d70744e6d3bbf9293aa1ee6fba7c53ad75275e || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <3abc8983b2bae3f487f77d9da5527d7d6b210d46 || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <14ef6fd18db2494098b21e0471bf27a1d8e9993e || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <0f5c185fc79a59ee9991234dd6d2a3e5afa6e75b || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <44b550d88b267320459d518c0743a241ab2108fa | e9aefdc5c53fe9aed108c14e3d155710a1bb14c9, 46662f7dc59475995609bf3e9d27eb36f4acf26f, 1e262db7675e27f42c3f3f47d6011855f4454f24, 21d70744e6d3bbf9293aa1ee6fba7c53ad75275e, 3abc8983b2bae3f487f77d9da5527d7d6b210d46, 14ef6fd18db2494098b21e0471bf27a1d8e9993e, 0f5c185fc79a59ee9991234dd6d2a3e5afa6e75b, 44b550d88b267320459d518c0743a241ab2108fa |
| Linux/Linuxgeneric | 4.17 | Not reported |
Published upstream
May 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 26, 2026
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.
Quoted source text, attributed separately from HOL analysis.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <e9aefdc5c53fe9aed108c14e3d155710a1bb14c9 || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <46662f7dc59475995609bf3e9d27eb36f4acf26f || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <1e262db7675e27f42c3f3f47d6011855f4454f24 || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <21d70744e6d3bbf9293aa1ee6fba7c53ad75275e || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <3abc8983b2bae3f487f77d9da5527d7d6b210d46 || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <14ef6fd18db2494098b21e0471bf27a1d8e9993e || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <0f5c185fc79a59ee9991234dd6d2a3e5afa6e75b || >=0cebaccef3acbdfbc2d85880a2efb765d2f4e2e3 <44b550d88b267320459d518c0743a241ab2108fa | e9aefdc5c53fe9aed108c14e3d155710a1bb14c9, 46662f7dc59475995609bf3e9d27eb36f4acf26f, 1e262db7675e27f42c3f3f47d6011855f4454f24, 21d70744e6d3bbf9293aa1ee6fba7c53ad75275e, 3abc8983b2bae3f487f77d9da5527d7d6b210d46, 14ef6fd18db2494098b21e0471bf27a1d8e9993e, 0f5c185fc79a59ee9991234dd6d2a3e5afa6e75b, 44b550d88b267320459d518c0743a241ab2108fa |
| Linux/Linuxgeneric | 4.17 | Not reported |
Published upstream
May 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 26, 2026
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.
Quoted source text, attributed separately from HOL analysis.