Another guest-to-host escape: "Pwnscape" (CVE-2026-99999, CVSS 9.3)

Comments

• deafcon Member

  12:02AM

  Fuck?

  Thanked by 4monsoon73 rpqu forest bugabuga
• Fubuki Member

  12:13AM

  Another day
• rpqu Member

  12:39AM

  Fuck indeed

  Thanked by 5forest mans_xd frodothebearer deafcon bugabuga
• forest Member

  12:59AM edited 1:11AM

  As of this comment, all Debian kernels are vulnerable.

  Switching all VMs to use e1000 would probably mitigate the issue, but would come with a massive performance hit in the form of high CPU overhead for networking and would require a reboot of all guests.

  Maybe adding csum=off,guest_csum=off to the QEMU virtio-net-pci device would mitigate it? But I don't know if that actually prevents a checksummed packet with NEEDS_CSUM from being processed by the vulnerable vNIC checksum offload code or if it just hides that capability from a well-behaved guest.
• servury Member, Patron Provider

  2:21AM

  fuck

  Thanked by 3forest deafcon bugabuga
• ScreenReader Member

  2:34AM

  Y 404?

  • https://web.archive.org/web/20260000000000*/https://pwn.ai/blog/Pwnescape
• forest Member

  2:36AM

  @ScreenReader said:
  Y 404?

  • https://web.archive.org/web/20260000000000*/https://pwn.ai/blog/Pwnescape

  Typo in original. It's https://pwn.ai/blog/pwnescape (lowercase "p").
• rpqu Member

  2:43AM

  @forest said:

  @ScreenReader said:
  Y 404?

  • https://web.archive.org/web/20260000000000*/https://pwn.ai/blog/Pwnescape

  Typo in original. It's https://pwn.ai/blog/pwnescape (lowercase "p").

  @angstrom
• yoursunny Member, IPv6 Advocate

  2:46AM

  GLWR

  R = Reboots

  Thanked by 4rpqu JohnnySac forest averagedatahoarder
• ScreenReader Member

  2:55AM

  @forest said:

  @ScreenReader said:
  Y 404?

  • https://web.archive.org/web/20260000000000*/https://pwn.ai/blog/Pwnescape

  Typo in original. It's https://pwn.ai/blog/pwnescape (lowercase "p").

  gracias https://archive.is/81MXt
• servers_guru Member, Patron Provider

  3:01AM

  Great...
  fleet wide reboot incoming..

  Thanked by 1forest
• JohnnySac Member

  3:03AM

  Ah man, another one
• forest Member

  3:05AM edited 3:06AM

  @servers_guru said:
  Great...
  fleet wide reboot incoming..

  Probably not too difficult to write a livepatch for this particular vuln, actually.

  A reboot is still better though, since it'll be fixing the hundreds of other (albeit less severe) bugs that have surely accumulated.

  And as annoying as these are, it's not like it didn't exist before its discovery. It was always there.
• servers_guru Member, Patron Provider

  3:11AM

  @forest said:

  @servers_guru said:
  Great...
  fleet wide reboot incoming..

  Probably not too difficult to write a livepatch for this particular vuln, actually.

  A reboot is still better though, since it'll be fixing the hundreds of other (albeit less severe) bugs that have surely accumulated.

  And as annoying as these are, it's not like it didn't exist before its discovery. It was always there.

  We have already upgraded most of the fleet following the last few vulnerabilities. But we managed to do it without reboot.

  This time though it won't be possible, not enough spare room on most clusters.

  It seems there is already a kernel fix available so no need for patching.
• brodiechilliam Member

  3:52AM

  @forest said:
  By passing a malformed packet up VirtIO to the checksum offloader in the host kernel, a guest can achieve arbitrary code execution in the host by corrupting the network header. Virtually all KVM providers are affected.

  All affected providers should upgrade as soon as possible.

  ---

  Interesting details about the escape and its discovery:
  https://pwn.ai/blog/Pwnescape
  https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge

  Debian security tracker:
  https://security-tracker.debian.org/tracker/CVE-2026-99999

  And the CVE announcement:
  https://lore.kernel.org/linux-cve-announce/2026101533-CVE-2026-99999-beee@gregkh/T/#u

  Contents of CVE announcement (click to expand)

  From: Greg Kroah-Hartman <[email protected]>
  
  Description
  ===========
  
  In the Linux kernel, the following vulnerability has been resolved:
  
  ipv4: validate checksum_start before completing checksum
  
  If a packet with bad checksum metadata gets into the ipv4 stack,
  skb_checksum_help can corrupt the network header and cause a bunch of
  mischief.
  
  This was discovered and reported by Paulos, and has been reporoduced
  by others independently since.
  
  We really shouldn't allow such packets in, but as a defence
  in depth measure, let's also check before we complete the checksum.
  
  A more complete validation at input is forthcoming, but needs more work.
  
  The Linux kernel CVE team has assigned CVE-2026-99999 to this issue.
  
  
  Severity
  ========
  
    CVSS v3.1: 9.3 CRITICAL
    Vector:    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  
  
  Affected and fixed versions
  ===========================
  
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 5.10.272 with commit a464d950f31c89565cbaae038cc60db04fe01956
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 5.15.223 with commit 0fab003ef4698e0628060a45a48f14b43ba2a40a
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.1.190 with commit 94524b7b32691de2e2ce162c04d6cbc9106e5cbf
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.6.159 with commit a65f69e0f38ffbed1b128029e09097436416dc8b
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.12.113 with commit 32a8b0adaa18e52aaa0b246b5ffe683075354dbb
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.18.57 with commit f3e835af6226f1dd12160cbd696081e9b6155de0
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 7.2.11 with commit c3e33464746166264334641dc850a36eef7e6326
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 7.3-rc7 with commit 6785011f8b16abf40b1e9d8b2e332232b3e68822
  
  Please see https://www.kernel.org for a full list of currently supported
  kernel versions by the kernel community.
  
  Unaffected versions might change over time as fixes are backported to
  older supported kernel versions.  The official CVE entry at
    https://cve.org/CVERecord/?id=CVE-2026-99999
  will be updated if fixes are backported, please check that for the most
  up to date information about this issue.
  
  
  Affected files
  ==============
  
  The file(s) affected by this issue are:
    include/net/ip.h
    net/bridge/netfilter/nf_conntrack_bridge.c
    net/ipv4/ip_output.c
    net/netfilter/nfnetlink_queue.c
    net/netfilter/xt_CHECKSUM.c
    net/xfrm/xfrm_output.c
  
  
  Mitigation
  ==========
  
  The Linux kernel CVE team recommends that you update to the latest
  stable kernel version for this, and many other bugfixes.  Individual
  changes are never tested alone, but rather are part of a larger kernel
  release.  Cherry-picking individual commits is not recommended or
  supported by the Linux kernel community at all.  If however, updating to
  the latest release is impossible, the individual changes to resolve this
  issue can be found at these commits:
    https://git.kernel.org/stable/c/a464d950f31c89565cbaae038cc60db04fe01956
    https://git.kernel.org/stable/c/0fab003ef4698e0628060a45a48f14b43ba2a40a
    https://git.kernel.org/stable/c/94524b7b32691de2e2ce162c04d6cbc9106e5cbf
    https://git.kernel.org/stable/c/a65f69e0f38ffbed1b128029e09097436416dc8b
    https://git.kernel.org/stable/c/32a8b0adaa18e52aaa0b246b5ffe683075354dbb
    https://git.kernel.org/stable/c/f3e835af6226f1dd12160cbd696081e9b6155de0
    https://git.kernel.org/stable/c/c3e33464746166264334641dc850a36eef7e6326
    https://git.kernel.org/stable/c/6785011f8b16abf40b1e9d8b2e332232b3e68822
    https://pwn.ai/blog/Pwnescape
    https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge
  

  not surprised
• brodiechilliam Member

  4:00AM

  @forest said:
  As of this comment, all Debian kernels are vulnerable.

  Switching all VMs to use e1000 would probably mitigate the issue, but would come with a massive performance hit in the form of high CPU overhead for networking and would require a reboot of all guests.

  Maybe adding csum=off,guest_csum=off to the QEMU virtio-net-pci device would mitigate it? But I don't know if that actually prevents a checksummed packet with NEEDS_CSUM from being processed by the vulnerable vNIC checksum offload code or if it just hides that capability from a well-behaved guest.

  good thing i use rhel and ubuntu enterprise
• forest Member

  4:56AM

  @brodiechilliam said:

  @forest said:
  As of this comment, all Debian kernels are vulnerable.

  Switching all VMs to use e1000 would probably mitigate the issue, but would come with a massive performance hit in the form of high CPU overhead for networking and would require a reboot of all guests.

  Maybe adding csum=off,guest_csum=off to the QEMU virtio-net-pci device would mitigate it? But I don't know if that actually prevents a checksummed packet with NEEDS_CSUM from being processed by the vulnerable vNIC checksum offload code or if it just hides that capability from a well-behaved guest.

  good thing i use rhel and ubuntu enterprise

  Fedora just released a fix, but RHEL has not yet and neither has Ubuntu.
• Mainfrezzer Member

  4:58AM edited 4:58AM

  guess all my vps will have some fun, thank god im using emulated devices on my other crap. e1000 for the rescue xD