I take it most have heard about the copy fail vulnerability if you have local shell?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you have to update the guests too?
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you have to update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
I think your analysis to patch everywhere may be mistaken.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr... "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)
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you have to update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
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.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr... "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)
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you have to update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
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 (debian-kernel@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.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr... "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)
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you have to update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
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:
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 (debian-kernel@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.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr... "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)
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you have to update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Windows 11 pro is a superior product.
On Sun, May 17, 2026 at 2:27 PM Brian E. Lavender brian@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:
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 (
debian-kernel@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.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr...
"Xen maintains two IDT's, one global IDT (its own) andother 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)
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you
have to
update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
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@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: > 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@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@bigbrie.com > > > > > To unsubscribe send an email to [8]lug-nuts-leave@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@bigbrie.com > > > > To unsubscribe send an email to [10]lug-nuts-leave@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@bigbrie.com > > > To unsubscribe send an email to [13]lug-nuts-leave@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@bigbrie.com > > To unsubscribe send an email to [15]lug-nuts-leave@bigbrie.com > > -- > Brian Lavender > [16]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 -- [17]lug-nuts@bigbrie.com > To unsubscribe send an email to [18]lug-nuts-leave@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@bigbrie.com To unsubscribe send an email to [21]lug-nuts-leave@bigbrie.comReferences
- mailto:brian@brie.com
- mailto:debian-kernel@lists.debian.org
- https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr...
- https://xint.io/blog/copy-fail-linux-distributions
- https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
I patched the vulnerable virtual machine and the exploit doesn't work anymore.
On Sun, May 17, 2026 at 03:12:20PM -0700, Brian E. Lavender wrote:
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@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: > 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@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@bigbrie.com > > > > > To unsubscribe send an email to [8]lug-nuts-leave@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@bigbrie.com > > > > To unsubscribe send an email to [10]lug-nuts-leave@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@bigbrie.com > > > To unsubscribe send an email to [13]lug-nuts-leave@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@bigbrie.com > > To unsubscribe send an email to [15]lug-nuts-leave@bigbrie.com > > -- > Brian Lavender > [16]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 -- [17]lug-nuts@bigbrie.com > To unsubscribe send an email to [18]lug-nuts-leave@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@bigbrie.com To unsubscribe send an email to [21]lug-nuts-leave@bigbrie.comReferences
- mailto:brian@brie.com
- mailto:debian-kernel@lists.debian.org
- https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr...
- https://xint.io/blog/copy-fail-linux-distributions
- https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
I am terrible top poster.
The exploit creates a socket. It just seems like the call should go to the DOM 0 (hypervisor).
snippet from the exploit.
``` a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();splice(f, w, o, offset_src=0);splice(r, u.fileno(), o) ```
On Sun, May 17, 2026 at 03:26:10PM -0700, Brian E. Lavender wrote:
I patched the vulnerable virtual machine and the exploit doesn't work anymore.
On Sun, May 17, 2026 at 03:12:20PM -0700, Brian E. Lavender wrote:
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@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: > 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@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@bigbrie.com > > > > > To unsubscribe send an email to [8]lug-nuts-leave@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@bigbrie.com > > > > To unsubscribe send an email to [10]lug-nuts-leave@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@bigbrie.com > > > To unsubscribe send an email to [13]lug-nuts-leave@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@bigbrie.com > > To unsubscribe send an email to [15]lug-nuts-leave@bigbrie.com > > -- > Brian Lavender > [16]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 -- [17]lug-nuts@bigbrie.com > To unsubscribe send an email to [18]lug-nuts-leave@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@bigbrie.com To unsubscribe send an email to [21]lug-nuts-leave@bigbrie.comReferences
- mailto:brian@brie.com
- mailto:debian-kernel@lists.debian.org
- https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr...
- https://xint.io/blog/copy-fail-linux-distributions
- https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
The exploit has to do with how data is written to a socket in the kernel crypto funtionality. The attack is possible because as an optimization, the call and the payload occupied the same memory space. The patch is to revert this to prior behavior where the call and the payload are written to different memory locations.
On Sun, May 17, 2026 at 03:29:03PM -0700, Brian E. Lavender wrote:
I am terrible top poster.
The exploit creates a socket. It just seems like the call should go to the DOM 0 (hypervisor).
snippet from the exploit.
a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();splice(f, w, o, offset_src=0);splice(r, u.fileno(), o)On Sun, May 17, 2026 at 03:26:10PM -0700, Brian E. Lavender wrote:
I patched the vulnerable virtual machine and the exploit doesn't work anymore.
On Sun, May 17, 2026 at 03:12:20PM -0700, Brian E. Lavender wrote:
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@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: > 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@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@bigbrie.com > > > > > To unsubscribe send an email to [8]lug-nuts-leave@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@bigbrie.com > > > > To unsubscribe send an email to [10]lug-nuts-leave@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@bigbrie.com > > > To unsubscribe send an email to [13]lug-nuts-leave@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@bigbrie.com > > To unsubscribe send an email to [15]lug-nuts-leave@bigbrie.com > > -- > Brian Lavender > [16]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 -- [17]lug-nuts@bigbrie.com > To unsubscribe send an email to [18]lug-nuts-leave@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@bigbrie.com To unsubscribe send an email to [21]lug-nuts-leave@bigbrie.comReferences
- mailto:brian@brie.com
- mailto:debian-kernel@lists.debian.org
- https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr...
- https://xint.io/blog/copy-fail-linux-distributions
- https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
- https://www.brie.com/brian/
- mailto:lug-nuts@bigbrie.com
- mailto:lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Each VM has to maintain it's own state. You can't keep that in common at the hypervisor level. At least, I think, it would be extremely inefficient to try. Each of my VM instances must have it's own kernel instance, since they don't all have the same kernel version. There may be a lot of things that interact with the hardware, like system calls, in the hypervisor, but the basic kernels have to be independent.`
On Sun, May 17, 2026 at 01:48:29PM -0700, Brian E. Lavender wrote:
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 (debian-kernel@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.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr... "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)
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you have to update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Using fedora but notvm's, never did work.
On Sun, May 17, 2026 at 6:50 PM Gary saclug@garymcglinn.com wrote:
Each VM has to maintain it's own state. You can't keep that in common at the hypervisor level. At least, I think, it would be extremely inefficient to try. Each of my VM instances must have it's own kernel instance, since they don't all have the same kernel version. There may be a lot of things that interact with the hardware, like system calls, in the hypervisor, but the basic kernels have to be independent.`
On Sun, May 17, 2026 at 01:48:29PM -0700, Brian E. Lavender wrote:
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 (
debian-kernel@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.
https://wiki.xenproject.org/wiki/Xen_FAQ_Design_and_in_Depth#How_does_Xen_pr...
"Xen maintains two IDT's, one global IDT (its own) andother 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)
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?
https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-...
I wonder if you patch the hypervisor when using PV guests if you
have to
update the guests too?
-- 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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@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 _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-
Brian E. Lavender -
Gary -
Kevin Brisson -
Linus Sphinx