Xen Security Advisory CVE-2026-79604 / XSA-512
version 3
oxenstored: Unbounded accumulation of watches
Oxenstored maintains two datastructures about watches; one global trie,
and one hashtable tracked per domain. When a xenbus reconnect is
requested, watches are not cleared out of the global trie.
A guest can cause unbounded memory usage in oxenstored. This can lead
to a system-wide DoS.
This is the XAPI oxenstored patch.
https://xenbits.xenproject.org/xsa/advisory-512.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Xen Security Advisory CVE-2026-79604 / XSA-512
version 3
oxenstored: Unbounded accumulation of watches
Oxenstored maintains two datastructures about watches; one global trie,
and one hashtable tracked per domain. When a xenbus reconnect is
requested, watches are not cleared out of the global trie.
A guest can cause unbounded memory usage in oxenstored. This can lead
to a system-wide DoS.
This is the Xen oxenstored patch.
https://xenbits.xenproject.org/xsa/advisory-512.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Xen Security Advisory CVE-2026-79603 / XSA-511
version 3
Unconditionally do TLB flushing ahead of page scrubbing
x86 PV guests can free memory pages while still keeping a stale TLB entry
pointing to them. A TLB flush is only issued by Xen (if needed) when the
page is re-used. Since it's possible for the page to be scrubbed ahead of
the TLB flush, there's a window where a PV guest can modify an already
scrubbed page.
Deployments using `xsm=silo scrub-domheap` with the aim of not allowing the
exchange of information amongst guests are not effective in the presence of
PV guests.
https://xenbits.xenproject.org/xsa/advisory-511.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Xen Security Advisory CVE-2026-79602 / XSA-510
version 3
x86: improper handling of HVM emulation return codes
A guest with a PCI device assigned that has at least a BAR on the IO port
space can trigger a BUG() in Xen.
Passing through a PCI device with at least one BAR in IO address space to
unprivileged HVM guests can result in a Denial of Service (DoS) affecting
the entire host.
https://xenbits.xenproject.org/xsa/advisory-510.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Xen Security Advisory CVE-2026-62437 / XSA-509
version 3
x86: DMs may cause mem leak by IRQ binding
When guests are terminated, various pieces of cleanup need carrying out.
The cleaning up of PCI devices which were assigned to guests, and the
associated removal of tracking structures for IRQs used by the devices
occurs relatively early in the process. Unfortunately after that point
the guest about to be terminated could cause its device model (DM) to
re-establish such tracking structures, by having it bind one or more IRQs
anew. While some of those tracking structures would still be cleaned up
later on, at least one would not be.
A HVM guest with one or more PCI devices assigned can cause a memory leak
in the hypervisor, possibly leading to Denial of Service (DoS) of the
entire host.
https://xenbits.xenproject.org/xsa/advisory-509.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
some of the tests produce invalid yaml, which is rejected by yaml-cpp
0.9.0. accordingly, we replace it with some of the correct syntax for
a multiline array.
Co-authored-by: OPNA2608 <opna2608@protonmail.com>
spaghettikart takes the *source* of yaml-cpp and plugs it into the
build, so it applied a cmake 4 patches where it was previously
necessary. now that we update to yaml-cpp 0.9.0, which builds with cmake
4 directly, this is no longer necessary.
starship-sf64 takes the *source* of yaml-cpp and plugs it into the
build, so it applied a cmake 4 patches where it was previously
necessary. now that we update to yaml-cpp 0.9.0, which builds with cmake
4 directly, this is no longer necessary.
openresty installs under $out/nginx, $out/luajit and $out/lualib, none
of which the strip list covers, so its binaries kept their debug info
and the closure pulled in gcc and the -dev output of every dependency.
Assisted-by: Claude:claude-fable-5-1
8d6d3999f9 (#545717) started copying modules into the build directory
before configure runs, so no module source path reaches the binary
anymore and there has been nothing to strip since.
Assisted-by: Claude:claude-fable-5-1
Each module is copied to a directory named after its store path, and
nginx bakes that path into the binary. Use stripHash for the copy, and
disallow references to the modules themselves instead of to their src.
Assisted-by: Claude:claude-fable-5-1
