Skip to main content

CVE detail

CVE-2026-53365

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.

CVSS 5.5 · MediumBuzz score 18.9

Buzz score

Why this CVE is surfacing

Buzz score total 18.9

This all-time snapshot uses the same composite formula as Trending across a 30-year evidence window, rather than a current rolling window.

Buzz score components · mention 13.9 · diversity 5.0 · KEV 0.0 · OTX 0.0 · PoC 0.0
Mention score
13.9
3 evidence mentions in the snapshot
Diversity score
5.0
1 sources across 1 categories
KEV score
0.0
No KEV entry observed
OTX score
0.0
0 OTX pulses
PoC score
0.0
0 repos · best confidence N/A
Best PoC traction
0
Maximum stars on a matched PoC repo

Why it matters now

Mention timeline

Total mentions
3
within the 30d window
Peak daily
3
highest bucket

Evidence

Source links by recency

Newest mentions first
3 source links · newest first

Exploit code

Public exploit repository references

Public PoC repositories are third-party, potentially unsafe artifacts. Treat their code as untrusted and use it only on authorized systems in an isolated, least-privilege environment. cvebuzz does not execute the code or verify that an exploit works.

0 repository references · best confidence N/A · max 0 stars
No public PoC repositories have been matched yet.

Related records

Similar CVEs

6 related CVEs with shared weakness or product evidence
  • CVE-2026-53364

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate() hci_le_big_terminate() allocates iso_list_data…

    CVSS 5.5 · Medium
    3 mentions
  • CVE-2026-53345

    In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain…

    CVSS 5.5 · Medium
    6 mentions
  • CVE-2026-53308

    In the Linux kernel, the following vulnerability has been resolved: power: supply: max77705: Free allocated workqueue and fix removal order Use devm interface for allocating wor…

    CVSS 5.5 · Medium
    2 mentions
  • CVE-2026-53261

    In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregi…

    CVSS 5.5 · Medium
    4 mentions
  • CVE-2026-53258

    In the Linux kernel, the following vulnerability has been resolved: wifi: fix leak if split 6 GHz scanning fails rdev->int_scan_req is leaked if cfg80211_scan() fails. Note tha…

    CVSS 5.5 · Medium
    4 mentions
  • CVE-2026-53252

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuratio…

    CVSS 5.5 · Medium
    8 mentions