17 May
2026
17 May
'26
10:12 p.m.
Hmmm. Well, I guess we now know that the list is not just an echo chamber!
I am patching that vulnerable Debian to see if the copy fail sploit
still works. The first script didn't have `os.splice` that was added
into a later python. The script does a socket open. It just seems like
the Dom U should be protected. Hmmm.
On Sun, May 17, 2026 at 02:52:00PM -0700, Kevin Brisson wrote:
Windows 11 pro is a superior product.
On Sun, May 17, 2026 at 2:27 PM Brian E. Lavender <[1]brian(a)brie.com>
wrote:
It turns out that the Dom U is still vulnerable. I was able to
exploit
an unpatched guest. So much for that theory.
On Sun, May 17, 2026 at 01:48:29PM -0700, Brian E. Lavender wrote:
--
Brian Lavender
[16]https://www.brie.com/brian/
"There are two ways of constructing a software design. One way is
to
This is not KVM. This is Xen.
It is time to imagine multiple kernels share and collaborate. That
is
the whole point of para virtualization. When you
boot a guest in
paravirtualized mode, it says "Oh, I am a guest, I will let the
hypervisor kernel do the work." Below is some output from a guest
kernel
booting. Notice how it detects it's just a
guest, and it's letting
the
host kernel (Dom 0) do the work. It looks like
Xen is managing the
mmu.
so I am willing to bet that if the Dom0 is
patched, it will
mitigate.
I need to grab the code to exploit and see if
this is true. I
think the
question is if this data structure is somehow
defined in a table
maintained by the guest.
[ 0.000000] Linux version 6.1.0-48-amd64
([2]debian-kernel(a)lists.debian.org) (gcc-12 (Debian
12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Deb
ian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian
6.1.172-1 (2026-05-15)
[ 0.000000] Command line:
root=UUID=718446e1-8c8b-46d8-88ff-ac3fd707ebda ro pti=off
console=hvc0 root=/dev/xvda2 ro
[ 0.000000] ACPI in unprivileged domain
disabled
[ 0.000000] Released 0 page(s)
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff]
usable
[ 0.000000] Xen: [mem
0x00000000000a0000-0x00000000000fffff]
reserved
[ 0.000000] Xen: [mem
0x0000000000100000-0x000000007fffffff]
usable
[ 0.000000] NX (Execute Disable) protection:
active
[ 0.000000] DMI not present or invalid.
[ 0.000000] Hypervisor detected: Xen PV
[snip]
[ 0.615786] Booting kernel on Xen
[ 0.615788] Xen version: 4.20.3-pre (preserve-AD)
[snip]
[ 0.623442] xen: PV spinlocks enabled
[ 0.623452] PV qspinlock hash table entries: 256 (order: 0,
4096 bytes, linear)
[snip]
[ 0.659881] xen:events: Using FIFO-based ABI
[ 0.659909] rcu: srcu_init: Setting srcu_struct sizes based on
contention.
[ 0.660029] Console: colour dummy device 80x25
[ 0.660247] printk: console [tty0] enabled
[ 0.660885] printk: console [hvc0] enabled
[ 0.660954] clocksource: xen: mask: 0xffffffffffffffff
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.660982] Xen: using vcpuop timer interface
[ 0.660992] installing Xen timer for CPU 0
[snip]
[ 0.750926] VPMU disabled by hypervisor.
[snip]
[ 0.752944] installing Xen timer for CPU 1
[snip]
[ 0.842354] xen:grant_table: Grant tables using version 1
layout
[ 0.842398] Grant table initialized
[ 0.842597] DMA: preallocated 256 KiB GFP_KERNEL pool for
atomic allocations
[ 0.842686] DMA: preallocated 256 KiB
GFP_KERNEL|GFP_DMA pool
for atomic allocations
[ 0.857200] DMA: preallocated 256 KiB
GFP_KERNEL|GFP_DMA32 pool
for atomic allocations
[snip]
[ 0.859176] PCI: setting up Xen PCI frontend stub
[ 0.859205] PCI: pci_cache_line_size set to 64 bytes
[ 0.862141] kprobes: kprobe jump-optimization is enabled. All
kprobes are optimized if possible.
[ 0.885503] ACPI: Interpreter disabled.
[ 0.885544] xen:balloon: Initialising balloon driver
[ 0.897269] iommu: Default domain type: Translated
[ 0.897269] iommu: DMA domain TLB invalidation policy: lazy
mode
[snip]
Brian
On Sat, May 16, 2026 at 09:06:20AM -0700, Gary wrote:
> There is also KVM, which may handle system calls differently.
Don't know.
>
> But, the flaw is in kernel memory management. There is nothing
changed "in" the system calls per se. I can't imagine how
multiple
instances could share the same kernel memory, or module to
manipulate it.
>
> Specifically crypto/aglif_aead.c has to be patched to change how
it uses local memory. This is used by a kernel module that the
system calls use.
>
>
>
> On Fri, May 15, 2026 at 02:51:56PM -0700, Brian E. Lavender
wrote:
> > I think your analysis to patch
everywhere may be mistaken.
> >
> >
[3]https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_
does_Xen_process_System_Calls_on_para-virtualized_guest?
"Xen maintains two IDT's, one global IDT
(its own) and other per domain
> > IDT. Xen uses global IDT to register
the entire trap handler
except for
> > system call handler (int 0x80). When a
VM gets scheduled, its
system
> > call handler (from per domain IDT
table) is registered with
the
> > processor. Hence when a domain/VM
executes a system call, its
own
> > handler is executed. "
> >
> > IDT - Interrupt Descriptor Table (IDT)
> >
> > [4]https://xint.io/blog/copy-fail-linux-distributions
> >
> > So, the scheduler puts in the IDT for the guest. The guest
does a socket
> > open for copy/fail CVE. It seems that
the socket system call
will be
> > implemented by the Xen host hypervisor.
Therefore, the patched
hypervisor
> > will mark it dirty and the
vulnerabiltiy mitigated.
> >
> > Anybody want to try and find a contradiction?
> >
> > Brian
> >
> > On Sat, May 02, 2026 at 10:09:55AM -0700, Gary wrote:
> > > It's a flaw in the kernel, so you have to patch the kernel
in anything that can run a shell where you don't want privilege
escalation.
> > >
> > > Which I would think is everywhere.
> > >
> > > Have you seen any info on patch availability or what
versions of Fedora and other distros will have available patches?
> > >
> > > I saw some instructions where you can disable a kernel
module using modprobe to avoid the vulnerability. There was no
information on what functionality was affected by making the
change. It sounded like it reverted to doing the copy correctly,
which would be a relatively easy and low impact fix.
> > >
> > >
> > >
> > > On Fri, May 01, 2026 at 05:54:26PM -0700, Brian E. Lavender
wrote:
> > > > I take it most have heard
about the copy fail
vulnerability if you have
> > > > local shell?
> > > >
> > > >
[5]https://arstechnica.com/security/2026/04/as-the-most-severe-linux
-threat-in-years-surfaces-the-world-scrambles/
> > > >
> > > > I wonder if you patch the hypervisor when using PV guests
if you have to
> > > > update the guests too?
> > > >
> > > >
> > > > --
> > > > Brian Lavender
> > > > [6]https://www.brie.com/brian/
> > > >
> > > > "There are two ways of constructing a software design. One
way is to
> > > > make it so simple that there
are obviously no
deficiencies. And the other
> > > > way is to make it so
complicated that there are no obvious
deficiencies."
> > > >
> > > > Professor C. A. R. Hoare
> > > > The 1980 Turing award lecture
> > > > _______________________________________________
> > > > Lug-nuts mailing list -- [7]lug-nuts(a)bigbrie.com
> > > > To unsubscribe send an email to
[8]lug-nuts-leave(a)bigbrie.com
> > >
> > > --
> > > -Gary
> > >
> > > It is a simple thing to make things complex,
> > > a complex thing to make things simple.
> > >
> > >
> > >
> > > _______________________________________________
> > > Lug-nuts mailing list -- [9]lug-nuts(a)bigbrie.com
> > > To unsubscribe send an email to
[10]lug-nuts-leave(a)bigbrie.com
> >
> > --
> > Brian Lavender
> > [11]https://www.brie.com/brian/
> >
> > "There are two ways of constructing a software design. One way
is to
> > make it so simple that there are
obviously no deficiencies.
And the other
> > way is to make it so complicated that
there are no obvious
deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
_______________________________________________
Lug-nuts mailing list -- [12]lug-nuts(a)bigbrie.com
To unsubscribe send an email to [13]lug-nuts-leave(a)bigbrie.com
--
-Gary
It is a simple thing to make things complex,
a complex thing to make things simple.
_______________________________________________
Lug-nuts mailing list -- [14]lug-nuts(a)bigbrie.com
To unsubscribe send an email to [15]lug-nuts-leave(a)bigbrie.com
make it so simple that there are obviously no
deficiencies. And
the other
way is to make it so complicated that there are
no obvious
deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
_______________________________________________
Lug-nuts mailing list -- [17]lug-nuts(a)bigbrie.com
To unsubscribe send an email to [18]lug-nuts-leave(a)bigbrie.com
--
Brian Lavender
[19]https://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other
way is to make it so complicated that there are no obvious
deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
_______________________________________________
Lug-nuts mailing list -- [20]lug-nuts(a)bigbrie.com
To unsubscribe send an email to [21]lug-nuts-leave(a)bigbrie.com
References
1. mailto:brian@brie.com
2. mailto:debian-kernel@lists.debian.org
3.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_p…
4. https://xint.io/blog/copy-fail-linux-distributions
5.
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in…
6. https://www.brie.com/brian/
7. mailto:lug-nuts@bigbrie.com
8. mailto:lug-nuts-leave@bigbrie.com
9. mailto:lug-nuts@bigbrie.com
10. mailto:lug-nuts-leave@bigbrie.com
11. https://www.brie.com/brian/
12. mailto:lug-nuts@bigbrie.com
13. mailto:lug-nuts-leave@bigbrie.com
14. mailto:lug-nuts@bigbrie.com
15. mailto:lug-nuts-leave@bigbrie.com
16. https://www.brie.com/brian/
17. mailto:lug-nuts@bigbrie.com
18. mailto:lug-nuts-leave@bigbrie.com
19. https://www.brie.com/brian/
20. mailto:lug-nuts@bigbrie.com
21. mailto:lug-nuts-leave@bigbrie.com
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
--
Brian Lavender
https://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture