CVE-2026-63970

What it actually does

This is a Linux kernel memory-corruption flaw in the virtio vsock transport zerocopy send path. During fixed-buffer vectored zerocopy sends, a socket buffer can be populated with managed fragment references before the zerocopy user-argument lifetime object is attached. If the operation reaches MAX_SKB_FRAGS and fails partway through, the rollback path frees an skb that has managed fragment metadata but lacks the expected uarg, causing incorrect reference handling in skb_release_data(). In practical terms, a local user able to exercise virtio-vsock traffic can potentially trigger kernel memory corruption, leading to kernel crash, denial of service, or possibly local privilege escalation depending on kernel configuration, allocator state, and exploitability of the resulting memory state.

Why it matters to the business

Systems using Linux virtio/vsock capabilities, especially virtualized workloads and host-guest communication paths, may be exposed to local attacks that can destabilize the kernel or potentially allow a low-privileged local user to gain higher privileges. The main operational risk is unplanned VM or host workload disruption through kernel crashes; the higher-severity risk is compromise of workload isolation if the memory corruption can be weaponized. The CVSS score is high, but EPSS is currently very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized for multi-user Linux systems, virtualization platforms, CI/build workers, developer workstations, and environments where untrusted users or workloads can run local code.

How an attack unfolds

An attacker first needs local code execution on a vulnerable Linux system with access to the virtio vsock path. They create or use an AF_VSOCK socket and drive the virtio_transport_send_pkt_info() zerocopy send path using fixed-buffer vectored I/O patterns that can approach or exceed MAX_SKB_FRAGS. By shaping the send buffers so io_sg_from_iter() partially attaches managed fragments and then returns -EMSGSIZE, the attacker causes the kernel to enter the rollback path. On vulnerable kernels, the skb is freed before it has been bound to the zerocopy uarg lifetime object, so skb_release_data() applies the wrong release behavior for managed fragments. The immediate outcome may be a kernel warning, oops, panic, or memory corruption. A reliable exploit would require grooming kernel memory and controlling object lifetime side effects to convert the bad reference handling into privilege escalation or another security-relevant primitive.

How to fix it

Apply a Linux kernel update that includes the upstream fix changing virtio_transport_alloc_skb() to receive and bind the zerocopy uarg before virtio_transport_fill_skb(). Because no product-specific fixed versions were provided, use the latest security-supported kernel from the relevant Linux distribution, cloud image, appliance vendor, or kernel tree. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by disabling or restricting virtio-vsock functionality where it is not required, limiting local shell/container access to trusted users, constraining untrusted workloads with strong sandboxing, and monitoring for kernel crashes involving vsock, virtio_transport, skb_release_data, or zerocopy send paths. Treat mitigations as temporary because the vulnerable code path is in kernel memory management and cannot be reliably protected at the application layer.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not only the installed package, is a vendor build that contains the fix. Validate with distribution advisories, kernel changelogs, or source inspection showing the virtio-vsock change that passes the uarg into virtio_transport_alloc_skb() and binds it before virtio_transport_fill_skb(). On source-based or custom kernels, confirm the relevant vsock/virtio transport code no longer fills the skb before attaching the zerocopy uarg. Check whether vsock is in use by looking for loaded vsock-related modules and AF_VSOCK consumers. After patching and rebooting, review kernel logs for absence of recurring oops/panic traces referencing virtio_transport_send_pkt_info(), virtio_transport_alloc_skb(), virtio_transport_fill_skb(), io_sg_from_iter(), kfree_skb(), or skb_release_data().

Typical attack path

1. Obtain low-privileged local code execution on a Linux system where virtio vsock is available or enabled.
2. Open or interact with AF_VSOCK/virtio-vsock communication paths.
3. Issue crafted fixed-buffer vectored zerocopy send operations that create many skb fragments and approach MAX_SKB_FRAGS.
4. Trigger partial fragment attachment followed by an -EMSGSIZE failure in io_sg_from_iter().
5. Force the rollback path to free an skb carrying managed fragment references before the zerocopy uarg is bound.
6. Cause kernel memory corruption, typically observed as a crash or oops, and potentially attempt further exploitation for local privilege escalation.

How to detect it

Post-exploitation detection is difficult because successful kernel memory-corruption exploitation may leave few durable artifacts beyond kernel logs, crashes, and unusual local process activity. Review journald, syslog, dmesg, hypervisor console logs, crash dumps, kdump/vmcore artifacts, and EDR telemetry for kernel oops, panic, BUG, WARNING, KASAN, KFENCE, slab, or refcount messages involving virtio vsock and socket-buffer release functions. Correlate crashes with local processes using AF_VSOCK sockets, heavy vectored I/O, io_uring/fixed-buffer I/O, or unexpected guest-host communication. Look for repeated -EMSGSIZE or send failures near the time of kernel warnings, though these may not always be logged. If vmcore capture is enabled, inspect stack traces for virtio_transport_send_pkt_info(), virtio_transport_alloc_skb(), virtio_transport_fill_skb(), io_sg_from_iter(), kfree_skb(), skb_release_data(), or skb_release_all(). Also investigate any unexplained privilege changes, new root-owned files, suspicious setuid binaries, unexpected kernel module loads, or persistence artifacts shortly before or after a relevant kernel crash. There are no known campaign-specific indicators, threat actors, or ransomware use reported for this issue in the supplied data.

• virtio_transport_send_pkt_info
• virtio_transport_alloc_skb
• virtio_transport_fill_skb
• io_sg_from_iter
• skb_release_data
• skb_release_all
• kfree_skb
• SKBFL_MANAGED_FRAG_REFS
• MAX_SKB_FRAGS
• -EMSGSIZE
• AF_VSOCK
• virtio_vsock
• vhost_vsock
• vsock/virtio
• kernel BUG
• kernel panic
• Oops:
• WARNING: CPU:
• KASAN:
• KFENCE:
• BUG: unable to handle kernel
• general protection fault
• refcount_t:
• use-after-free
• slab-out-of-bounds

What your security team should do

• Prioritize patching high-density virtualization hosts, multi-user Linux servers, CI/CD runners, developer systems, and any platform that runs untrusted local code with virtio-vsock enabled.
• Verify the active running kernel after reboot; close tickets only after confirming the fixed kernel is booted.
• Inventory use of AF_VSOCK, virtio_vsock, vhost_vsock, and guest-host communication features to identify exposed systems.
• If patching is delayed, restrict local access, reduce untrusted workload placement, and disable unused vsock functionality where operationally feasible.
• Add monitoring for kernel oops, panic, BUG, WARNING, or slab/KASAN reports involving vsock, virtio_transport, skb_release_data, kfree_skb, io_sg_from_iter, or zerocopy send paths.
• For custom kernels, backport the exact upstream lifetime-ordering fix rather than attempting partial mitigations.
• Track vendor advisories because fixed package versions vary by distribution and were not provided in the vulnerability metadata.
• Given the low EPSS, no KEV listing, and no known public exploit maturity, treat this as important patch hygiene rather than an emergency internet-facing exploitation event unless local untrusted users or workloads are present.