Answer in brief
CVE-2026-53365 records a Unknown severity vulnerability in vsock/virtio: fix zerocopy completion for multi-skb sends. 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.
A CVSS score is not reported in the current record. 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 | >=581512a6dc939ef122e49336626ae159f3b8a345 <293fe8f2d1b5ac464ca16a8eba09571bbbb34ba9 || >=581512a6dc939ef122e49336626ae159f3b8a345 <76b995bc57bd90cb6e954e1966fbd8786da47f0d || >=581512a6dc939ef122e49336626ae159f3b8a345 <b3155f2b78db21e99256bcf7eb902f24ff6d5338 || >=581512a6dc939ef122e49336626ae159f3b8a345 <ae38d9179190a956e2a87a69ef1dd6f451b51c4d | 293fe8f2d1b5ac464ca16a8eba09571bbbb34ba9, 76b995bc57bd90cb6e954e1966fbd8786da47f0d, b3155f2b78db21e99256bcf7eb902f24ff6d5338, ae38d9179190a956e2a87a69ef1dd6f451b51c4d |
| Linux/Linuxgeneric | 6.7 | Not reported |
Published upstream
Jul 13, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 13, 2026
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 ("vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting") but was pre-existing.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-53365 records a Unknown severity vulnerability in vsock/virtio: fix zerocopy completion for multi-skb sends. 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.
A CVSS score is not reported in the current record. 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 | >=581512a6dc939ef122e49336626ae159f3b8a345 <293fe8f2d1b5ac464ca16a8eba09571bbbb34ba9 || >=581512a6dc939ef122e49336626ae159f3b8a345 <76b995bc57bd90cb6e954e1966fbd8786da47f0d || >=581512a6dc939ef122e49336626ae159f3b8a345 <b3155f2b78db21e99256bcf7eb902f24ff6d5338 || >=581512a6dc939ef122e49336626ae159f3b8a345 <ae38d9179190a956e2a87a69ef1dd6f451b51c4d | 293fe8f2d1b5ac464ca16a8eba09571bbbb34ba9, 76b995bc57bd90cb6e954e1966fbd8786da47f0d, b3155f2b78db21e99256bcf7eb902f24ff6d5338, ae38d9179190a956e2a87a69ef1dd6f451b51c4d |
| Linux/Linuxgeneric | 6.7 | Not reported |
Published upstream
Jul 13, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 13, 2026
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 ("vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting") but was pre-existing.
Quoted source text, attributed separately from HOL analysis.