Triage 2026-11-04

LP: #2133632 wg-quick segfaults when running in LXC -- apparmor note

Package	apparmor
Release	D
Status	Confirmed
Prio	Undecided
Assignee	—
Updated	2026-09-05
Flags	reply pending expiring

Notes

Description

On Ubuntu 25.10 running inside a Proxmox LXC container, any direct execution 
of wg-quick (e.g. "wg-quick up wg0") results in a SIGSEGV. The same command 
works perfectly when invoked via "bash /usr/bin/wg-quick up wg0".

Cause:
wg-quick has an AppArmor profile (/etc/apparmor.d/usr.bin.wg-quick). When 
wg-quick is execve()'d directly, LXC’s AppArmor+seccomp enforcement switches 
to the wg-quick profile which denies some operations (likely ip/nft/sysctl), 
causing the process to be killed and reported as a segmentation fault.

Placing the profile in complain mode fixes the issue:
"aa-complain wg-quick"

Disabling the profile also fixes it:
"aa-disable wg-quick"

Running wg-quick via bash bypasses the profile switch, so it works.

Expected:
wg-quick should not segfault in LXC environments. (Note, I did not reproduce the crash in docker, I do not have a non-virtualized ubuntu 25.10 to test in)

Actual:
wg-quick segfaults due to AppArmor enforcement on direct exec only.

Reproduction:
- Proxmox 8.x host
- Ubuntu 25.10 LXC container
- Install wireguard-tools
- Provide wg0.conf
- Run "wg-quick up wg0" → SIGSEGV
- Run "bash /usr/bin/wg-quick up wg0" → works normally

```
root@twentyfive-ten-test:~# lsb_release -rd
Description:    Ubuntu 25.10
Release:        25.10
```

```
root@twentyfive-ten-test:~# apt-cache policy apparmor 
apparmor:
  Installed: 5.0.0~alpha1-0ubuntu8.1
  Candidate: 5.0.0~alpha1-0ubuntu8.1
  Version table:
 *** 5.0.0~alpha1-0ubuntu8.1 500
        500 http://archive.ubuntu.com/ubuntu questing-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     5.0.0~alpha1-0ubuntu8 500
        500 http://archive.ubuntu.com/ubuntu questing/main amd64 Packages
root@twentyfive-ten-test:~# apt-cache policy wireguard
wireguard:
  Installed: 1.0.20210914-3ubuntu2
  Candidate: 1.0.20210914-3ubuntu2
  Version table:
 *** 1.0.20210914-3ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu questing/universe amd64 Packages
        100 /var/lib/dpkg/status
root@twentyfive-ten-test:~# apt-cache policy wireguard-tools
wireguard-tools:
  Installed: 1.0.20210914-3ubuntu2
  Candidate: 1.0.20210914-3ubuntu2
  Version table:
 *** 1.0.20210914-3ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu questing/main amd64 Packages
        100 /var/lib/dpkg/status
```

AI analysis

Not analysed.

LP: #2172904 pasta is not allowed to receive signals from libvirt due to apparmor note

Package	libvirt
Release	D
Status	New
Prio	Undecided
Assignee	—
Updated	2026-11-04
Flags	reply pending

Notes

Description

This is similar to https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2154379 but now libvirtd cannot send signals to passt on Ubuntu 26.04 when VM is stopped:

kernel: audit: type=1400 audit(1793749636.263:332): apparmor="DENIED" operation="signal" class="signal" profile="passt" pid=1706 comm="rpc-libvirtd" requested_mask="receive" denied_mask="receive" signal=term peer="libvirtd"
kernel: audit: type=1400 audit(1793749636.263:331): apparmor="DENIED" operation="signal" class="signal" profile="libvirtd" pid=1706 comm="rpc-libvirtd" requested_mask="send" denied_mask="send" signal=term peer="passt"
libvirtd[1706]: Failed to terminate process 8846 with SIGTERM: Permission denied

Reproduce:

0) If you need kvm then add your user to kvm group, do not add your user to libvirt group
1) You need to connect to libvirt in session mode (usually qemu:///session)
2) Create some VM
3) Enable passt backend for user-mode networking (<backend type="passt"/>) and forward some port:

<interface type="user">
  <mac address="52:54:00:00:00:00"/>
  <model type="virtio"/>
  <backend type="passt"/>
  <portForward proto="tcp">
    <range start="8080" to="80"/>
  </portForward>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>

4) start VM
5) stop VM
6) if you start VM again it will fail because tcp port is in use by previous instance of passt

The previous passt instance wasn't stopped due to apparmor.

Versions:

passt                                            0.0~git20260120.386b5f5-1
libvirt-daemon                                   12.0.0-1ubuntu5.5
apparmor                                         5.0.2-0ubuntu1~26.04.1

AI analysis

Route	new
Suggested status	Triaged
Suggested importance	Medium
Per series	resolute: Triaged, stonking: Triaged, tenacious: Triaged
Suggested tags	server-todo

Analysis

AppArmor blocks libvirtd (qemu:///session, monolithic daemon profile) from sending SIGTERM to passt running under the passt package's standalone profile, because neither profile carries the required signal rules. The orphaned passt keeps the forwarded TCP port bound, so the VM cannot be restarted. Both denials are logged verbatim in the report ("apparmor=\"DENIED\" operation=\"signal\" ... signal=term peer=passt/libvirtd" and "Failed to terminate process 8846 with SIGTERM: Permission denied").

**Root cause (analysed):** upstream libvirt commit https://gitlab.com/libvirt/libvirt/-/commit/7a39b04d683f only added `signal (receive) set=("term") peer=libvirtd|virtqemud` inside the *nested* passt subprofile of src/security/apparmor/libvirt-qemu. In session mode virt-aa-helper does not apply, so passt runs under its own standalone profile, which duplicates libvirt's file rules (per its own comment "Duplicate libvirt-specific rules here as long as this is not solved in libvirt's profile itself") but omits the signal rules; and Ubuntu's confined libvirtd additionally lacks the `signal (send) peer=passt` rule. A pre-existing profile gap — confirmed **not** a regression from libvirt 12.0.0-1ubuntu5.5 → 5.6 (packaging-only changes, AppArmor profiles untouched). Sibling bug 2154379 (pasta/podman) proposes the same one-line pattern but cannot be upstreamed by its reporter.

**Not a duplicate:** LP #1324393 (expired), #1655111 (qemu-bridge-helper, fixed), #1348698 (2014 LXC/dhclient) are same-class but different-cause; no fix exists in libvirt (≤12.6.0) or passt (≤0.0~git20261002, even in Debian) for this bug.

**Fix:** two-sided and coordinated. (1) libvirt: add `signal (send) set=("term") peer=passt,` next to the `/usr/bin/passt Cx -> passt,` rule in src/security/apparmor/libvirt-qemu (diff in the fix phase; verified patch_applies: `fuzz` on both resolute and devel). (2) **Required companion passt change**: add `signal (receive) set=("term") peer=/usr/sbin/libvirtd, peer=libvirtd, peer=virtqemud` to contrib/apparmor/usr.bin.passt in the existing duplicated-rules block — without BOTH profiles the signal stays denied, so a libvirt upload alone will not fix it. Both patches must be upstreamed (see upstream_suggestion); fix should land in tenacious (devel) first.

Proposed fix

--- a/src/security/apparmor/libvirt-qemu
+++ b/src/security/apparmor/libvirt-qemu
@@ -211,7 +211,13 @@
   /usr/lib/@{multiarch}/libswtpm_libtpms.so mr,
 
   # support for passt network back-end
   /usr/bin/passt Cx -> passt,
+
+  # passt might also run under the standalone passt profile shipped by the
+  # passt package instead of the nested profile below, e.g. when started by
+  # an unprivileged session instance of the daemon: allow terminating it in
+  # that case too.
+  signal (send) set="("term") peer=passt,   
 
   profile passt {
     /usr/bin/passt r,

Checked by the host (patches applied):

devel: fuzz
resolute: fuzz

References

SRU candidates

resolute: Reported affected series (26.04 LTS, libvirt 12.0.0); needs the two-sided libvirt + passt AppArmor signal-rule fix backported once developed.
stonking: libvirt 12.6.0-1ubuntu4 carries the same apparmor profiles and passt has the same standalone profile without signal rules; equally affected.

SRU feasibility not assessed; at the triager's discretion.

Upstream

Two upstreams: (1) libvirt MR adding `signal (send) set=("term") peer=passt,` to the passt support in src/security/apparmor/libvirt-qemu, so the daemon can terminate passt when it runs under the standalone passt-package profile (qemu:///session case). (2) passt patch adding the three `signal (receive) set=("term") peer=/usr/sbin/libvirtd|libvirtd|virtqemud` rules to contrib/apparmor/usr.bin.passt in the existing "Duplicate libvirt-specific rules here" block — mirrors the pasta/podman one-liner attached to LP #2154379, which that reporter is prohibited from upstreaming, so an Ubuntu engineer should submit it.

Thought process

precheck (done): route new: not handled by the team yet
validate-report (done): verdict bug: AppArmor signal mediation rules are missing from both the libvirtd profile (shipped by libvirt) and the passt profile (shipped by passt), so libvirtd cannot SIGTERM passt when a session-mode VM is stopped; the orphaned passt keeps the forwarded port bound and the VM cannot be restarted. The denials are quoted verbatim, so the report is actionable as-is. (tools: submit_validation; 4433 in / 13165 out tokens)
search (done): 3 Launchpad candidates from 5 queries, 0 Debian candidates, 3 changelog hits
search-upstream (done): No matching issue or merged fix found in libvirt's upstream GitLab tracker; the passt bug tracker at bugs.passt.top is a Bugzilla instance not supported by the available search tools, so its contents could not be checked. The closest related item is MR 493 "Allow passt to create user namespaces", which is a different AppArmor/passt permission issue. (tools: upstream_info x2, gitlab_search x9, github_search, fetch_url x2, bugzilla_search, submit_upstream_search; 68454 in / 1032 out tokens)
search-other-distros (done): No fix found in other distributions: Fedora (SELinux, not AppArmor) and Arch (AppArmor not enabled by default) have no matching reports, and Gentoo's libvirt AppArmor bugs cover unrelated profile gaps (ovmf, seavgabios, leases helper) with nothing about passt signal rules, so the missing libvirtd↔passt signal rules appear unreported outside Ubuntu/Debian. (tools: bugzilla_search x11, gitlab_search x6, submit_distro_search; 42762 in / 5393 out tokens)
assess-existing (done): Bug 2172904 is new, not a duplicate, and nothing fixes it in any series yet. Root cause is documented in passt's own profile (contrib/apparmor/usr.bin.passt): for qemu:///session guests libvirt's per-VM AppArmor mechanism (virt-aa-helper) does not apply, so passt runs under its own standalone profile, which duplicated libvirt's file-path rules but NOT the signal rules that upstream libvirt's nested passt profile has had since commit 7a39b04d683f (signal (receive) set=("term") peer=libvirtd/virtqemud); on Ubuntu the confined monolithic libvirtd additionally has no signal (send) rule for peer=passt, so both denials fire and the orphaned passt keeps the forwarded port bound. Fix state: resolute is unfixed (the only newer libvirt there, 12.0.0-1ubuntu5.6 in -updates, is HWE postrm changes only; passt has no update in resolute at all), and stonking/tenacious are equally unfixed — libvirt 12.6.0-1ubuntu4 carries src/security/apparmor/* identical to resolute's 12.0.0, and passt 0.0~git20260728 still has no signal rules (even Debian's newest passt 0.0~git20261002 lacks them, though it fixed other profile gaps such as the missing attach_disconnected flag from LP #2165771). The fix is small but two-sided (passt: receive rules from libvirtd/virtqemud; libvirt: send rule to passt) and must be developed and upstreamed to both projects; resolute (reported, LTS) and stonking are SRU candidates, with the fix landing in tenacious (devel) first. The apparmor package only enforces the shipped profiles; the older Launchpad candidates (1324393 expired, 1655111 qemu-bridge-helper, 1348698 dhclient/LXC from 2014) are different-era or different-cause members of the same "AppArmor blocks libvirtd signals" class, not duplicates. (tools: lp_get_bug x5, lp_search_bugs x4, debian_bugs x4, debian_bug x3, pkg_versions, pkg_changelog x5, fetch_patch x5, source_diff x3, submit_assessment; 378683 in / 45023 out tokens)
check-regression (done): not confirmed: Compared libvirt 12.0.0-1ubuntu5.5 → 12.0.0-1ubuntu5.6 in resolute (changelog and full source diff). The update is purely packaging: a postrm hook for the base/HWE purge race (LP: #2164849), an ubuntu-virt dependency version constraint, and removal of generated maintscript/.install files (now generated at build time via debian/rules). No AppArmor profile content changed (etc/apparmor.d/* untouched), no passt-related code or signal-handling code changed, so nothing in this update can explain the missing AppArmor signal rules between the libvirtd and passt profiles. The report itself cites libvirt-daemon 12.0.0-1ubuntu5.5 — the version before the suspect update — and the passt profile is shipped by the separate passt package, both indicating the missing signal rules predate the 5.6 upload. This is a pre-existing AppArmor profile gap for the passt backend, not a regression from the 5.6 update. (tools: pkg_changelog, source_diff x2, submit_regression; 25777 in / 2835 out tokens)
analyze-source (skipped): a fix is already known
propose-fix (done): diff (resolute fuzz, devel fuzz): Root cause: AppArmor signal mediation needs permission on both sides, and the report logs both independent denials: the libvirtd profile has no `signal (send) set=("term") peer=passt` rule, and the standalone passt profile (shipped by the passt package) contains no signal rules at all. libvirt's own passt support (upstream commit 7a39b04d683f, verified: it only adds `signal (receive) set=("term") peer=/usr/sbin/libvirtd|libvirtd|virtqemud` inside the NESTED passt subprofile of src/security/apparmor/libvirt-qemu) does not cover passt running under its standalone profile — which is exactly the qemu:///session case, and which passt's own usr.bin.passt anticipates by duplicating libvirt's file rules ("Duplicate libvirt-specific rules here as long as this is not solved in libvirt's profile itself") while omitting the signal rules. Result: SIGTERM is denied, passt is orphaned and keeps the forwarded TCP port bound. Proposed libvirt-side fix (diff above): add `signal (send) set=("term") peer=passt,` next to the `/usr/bin/passt Cx -> passt,` rule in src/security/apparmor/libvirt-qemu — the fragment where upstream keeps all passt support and which is part of libvirt's daemon profiles (passt's profile comment confirms the subprofile is "part of libvirt's profile"). Verified with patch_applies against resolute and devel: the hunk applies on both refs (fuzz 1; on resolute it lands at offset -6, i.e. the same block 6 lines earlier). The anchor lines are unique in the file, so it cannot be misapplied. IMPORTANT — a matching passt-package change is REQUIRED and cannot be done in libvirt: add to contrib/apparmor/usr.bin.passt (passt source package), in the existing duplicated-rules block right after `owner @{run}/libvirt/qemu/passt/* rw,`: signal (receive) set=("term") peer=/usr/sbin/libvirtd, signal (receive) set=("term") peer=libvirtd, signal (receive) set=("term") peer=virtqemud, exactly mirroring libvirt's nested passt subprofile. Until BOTH profiles allow it, the signal stays denied (the two audit lines in the report are independent denials), so the libvirt upload alone will not fix the bug — coordinate a companion passt SRU/task for resolute (and devel). I read passt's current profile in its source tree (that block exists, with no signal rules anywhere in the file), but did not run patch_applies against the passt package since this phase's fix is for libvirt. The same one-line receive-rule pattern is what sibling bug 2154379 proposes for pasta/podman (reporter cannot upstream it themselves). (tools: fetch_patch, source_file x9, verify_url, patch_applies, submit_fix; 195871 in / 67900 out tokens)
write-report (done): status Triaged (tools: submit_report; 6593 in / 1094 out tokens)

LP: #2172911 HAProxy 2.4.30-0ubuntu0.22.04.3 rejects truncated resposens note

Package	haproxy
Release	D
Status	Invalid
Prio	Undecided
Assignee	—
Updated	2026-11-04
Flags	reply pending

Notes

Description

On our Ubuntu 22.04 servers HAProxy got updated via the unattended security updates to version 2.4.30-0ubuntu0.22.04.3.
This caused most of our servers to be unreachable.
HAProxy displayed 502 errors for most of our backends.
Downgrading to 2.4.30-0ubuntu0.22.04.2 made the problem go away.

The analysis that follows now was done with the help of an LLM, I can only say for sure that downgrading the package fixed it.
However I'm happy to provide any additional information or logs (on a private channel).

--- LLM Generated ---

Environment

- Ubuntu 22.04 (jammy), two HAProxy hosts, both affected
- haproxy 2.4.30-0ubuntu0.22.04.3, installed by unattended-upgrades
- HTTP mode, frontend with "alpn h2,http/1.1", default tune.bufsize (16384)
- Backends: nginx with PHP applications (HTTP/1.1, plain HTTP on port 80), plus one backend over TLS ("ssl verify none")

What happened

  Total events captured on [04/Nov/2026:07:13:02.080] : 62614

Every backend entry shows the same signature: state MSG_CHUNK_SIZE, with an empty buffer.
Three examples (client IPs and server names masked):

[04/Nov/2026:07:12:58.031] backend password_safe (#16): invalid response
  frontend default (#3), server backend1 (#1), event #62497, src x.x.x.x:53977
  buffer starts at 0 (including 0 out), 16384 free,
  len 0, wraps at 0, error at position 0
  H1 connection flags 0x80002200, H1 stream flags 0x00004810
  H1 msg state MSG_CHUNK_SIZE(26), H1 msg flags 0x00001756
  H1 chunk len 0 bytes, H1 body len 0 bytes :

[04/Nov/2026:07:08:30.193] backend drupal_production (#8): invalid response
  frontend default (#3), server backend2 (#1), event #54538, src x.x.x.x:59006
  buffer starts at 0 (including 0 out), 16384 free,
  len 0, wraps at 0, error at position 0
  H1 connection flags 0x80002200, H1 stream flags 0x00004890
  H1 msg state MSG_CHUNK_SIZE(26), H1 msg flags 0x00001756
  H1 chunk len 0 bytes, H1 body len 2162 bytes :

[04/Nov/2026:07:13:01.986] backend highsystem (#12): invalid response
  frontend default (#3), server backend3 (#1), event #62613, src x.x.x.x:50018
  buffer starts at 0 (including 0 out), 16384 free,
  len 0, wraps at 0, error at position 0
  H1 connection flags 0x80002200, H1 stream flags 0x00004810
  H1 msg state MSG_CHUNK_SIZE(26), H1 msg flags 0x00001716
  H1 chunk len 0 bytes, H1 body len 391 bytes :

Analysis

The .3 package contains the fix for CVE-2026-110354 (debian/patches/CVE-2026-110354.patch, src/h1_htx.c).
Upstream (2.6 commit 68609955873ff845220b7a7cf22147d3617a0b42, "BUG/MAJOR: h1-htx: report an error on a too long chunk-size line") sets a parse error in
h1_parse_msg_data only when all of these are true:

1. nothing was parsed,
2. the parser is in the chunk-size state,
3. the input buffer is full.

In every captured error, conditions 1 and 2 match, but the buffer is empty ("len 0", "16384 free").
Condition 3 is not true, but the error fires anyway.
Our conclusion is that the "buffer is full" condition does not work correctly in the 2.4 backport.
As a result, any chunked response fails when the next chunk-size line has not arrived yet.
This happens in the normal case, when a backend streams its output.

Example 1 fails before any body byte.
Example 2 fails after 2162 body bytes, so later chunks are affected too, not only the first one.
Example 3 is a TLS backend, so the backend transport makes no difference.

There is no upstream 2.4 commit for this fix, because 2.4 is EOL.
The upstream commit message also says that 2.6 and 2.8 cannot hit the original loop.
We did not inspect the Ubuntu patch itself.

What we tested

- dpkg.log: the upgrade from .2 to .3 happened at 03:26, and the first 502s appeared after it.
- "show errors" on the admin socket: all backend errors are "invalid response" in MSG_CHUNK_SIZE with an empty buffer (see above).
- Response headers, checked directly against the backends:
  - an affected backend (PHP application): "Transfer-Encoding: chunked"
  - an unaffected backend: "Content-Length: 54"
  Only backends that send chunked responses appear in "show errors".
- The client network made no difference: internal and external clients failed on the same backends.
- Downgrade: apt install haproxy=2.4.30-0ubuntu0.22.04.2 on both hosts. The 502s stopped at once. Both hosts now hold haproxy at .2.

AI analysis

Route	new
Suggested status	Duplicate
Suggested tags	none
Duplicate of	LP: #2172897

Analysis

Bug 2172911 reports that the jammy haproxy security update 2.4.30-0ubuntu0.22.04.3 (USN-8972-1) breaks valid HTTP/1.1 chunked responses — HAProxy returns 502 "invalid response" with H1 msg state MSG_CHUNK_SIZE(26) on an empty buffer; Content-Length backends are unaffected, and downgrading to 2.4.30-0ubuntu0.22.04.2 stops it. The reporter acknowledged in comment 1 that this duplicates bug 2172897, and the symptoms, version, analysis and workaround match that master bug exactly; bugs 2172905, 2172907 and 2172979 are also duplicates of it. So the correct disposition is Duplicate of 2172897 (the current Invalid status loses the linkage).

Root cause (per the assessment and reporter analysis): the Ubuntu backport of the CVE-2026-110354 fix (upstream 2.6 commit 68609955873ff845220b7a7cf22147d3617a0b42, "BUG/MAJOR: h1-htx: report an error on a too long chunk-size line", in debian/patches/CVE-2026-110354.patch, src/h1_htx.c) adds a `!buf_room_for_htx_data(srcbuf)` check that misfires on the empty/released input buffer that HAProxy 2.4's mux-h1 holds while waiting for the next chunk-size line. The identical hunk exists in upstream master (2e4ba6a570809bcfb4e2ba04948e64e5d07622b3, released in 3.5-dev9), so the misfire condition may also exist upstream, though no upstream follow-up fix was found; whether newer branches release empty buffers like 2.4 is unverified.

State on the master bug 2172897 (Confirmed, assigned to mdeslaur, Ubuntu security): a proposed one-line guard patch (attachment 1 / comments 3–4, require `b_size(srcbuf)` before reporting the error) is built and tested on top of .22.04.3 but not merged/released, and a fixed package was uploaded to the ubuntu-security-proposed PPA on 2026-11-04 (comment 13) pending testing before release to jammy-security. No fix is in the jammy archive yet (jammy -security/-updates still publish 2.4.30-0ubuntu0.22.04.3). Noble (2.8.30-0ubuntu0.24.04.2) is reported unaffected (bug 2172897 comment 2). This is being handled by the Ubuntu security team as a security regression update rather than a classic SRU, so no separate server-team action is needed beyond tracking 2172897.

Suggested comment

Thanks for the thorough report and analysis. As you noted in your comment, this matches bug 2172897, so we will track the issue there; please follow that bug for updates.

References

SRU candidates

jammy: jammy is affected by the regression in 2.4.30-0ubuntu0.22.04.3 (USN-8972-1); a corrected package already exists in the ubuntu-security-proposed PPA (bug 2172897 comment 13) and needs testing and release to jammy-security. Being handled by the Ubuntu security team as a security regression update rather than a classic SRU.

SRU feasibility not assessed; at the triager's discretion.

Upstream

The upstream master version of the chunk-size line fix (commit 2e4ba6a570809bcfb4e2ba04948e64e5d07622b3, in 3.5-dev9) contains the identical `!buf_room_for_htx_data(srcbuf)` condition that misfires on empty buffers in 2.4; upstream should be informed so they can evaluate whether newer branches also release empty input buffers and guard the check accordingly.

Thought process

precheck (done): route new: not handled by the team yet
validate-report (done): verdict bug: A specific, well-analysed fault in Ubuntu: the jammy haproxy -security update 2.4.30-0ubuntu0.22.04.3 breaks chunked HTTP responses (502 "invalid response" in MSG_CHUNK_SIZE with an empty buffer), consistent with a faulty backport of the CVE-2026-110354 fix. The reporter states in comment 1 that it duplicates bug 2172897, so it should be marked Duplicate of that bug (not left plain Invalid, which loses the linkage); the later duplicate-check phase should confirm. (tools: lp_get_bug, submit_validation; 22659 in / 11833 out tokens)
search (done): 4 Launchpad candidates from 4 queries, 0 Debian candidates, 0 changelog hits
search-upstream (done): Upstream has no report or follow-up fix for the MSG_CHUNK_SIZE 502 regression (GitHub issue search is unavailable for haproxy/haproxy, and commit searches found no correction to the chunk-size check); the offending code is verbatim identical in the upstream 2.6 backport (6860995...) and in upstream master (2e4ba6a57080, released in 3.5-dev9), so the regression appears to originate upstream, not in the Ubuntu packaging — likely worth reporting upstream with the reporter's reproducer. (tools: github_search x9, fetch_patch x3, gitlab_search, submit_upstream_search; 46011 in / 3565 out tokens)
search-other-distros (skipped): upstream has a fix
assess-existing (done): Bug 2172911 is a duplicate of bug 2172897, the master report for the jammy haproxy 2.4.30-0ubuntu0.22.04.3 (USN-8972-1) regression: the Ubuntu backport of the CVE-2026-110354 fix (upstream 2.6 commit 68609955873ff845220b7a7cf22147d3617a0b42, "BUG/MAJOR: h1-htx: report an error on a too long chunk-size line") misfires on an empty/released input buffer in 2.4, so valid HTTP/1.1 chunked responses are rejected with "invalid response" in MSG_CHUNK_SIZE (502s or truncated 200s). The reporter acknowledged the duplicate in comment 1, and the symptoms, version, cause analysis and workaround (downgrade to .22.04.2) match 2172897 exactly; bugs 2172905, 2172907 and 2172979 are already duplicates of it. The master bug is Confirmed, assigned to mdeslaur (Ubuntu security), has a deterministic reproducer, a proposed one-line guard patch (require b_size(srcbuf) before reporting the error), and a fixed package uploaded to the ubuntu-security-proposed PPA on 2026-11-04 awaiting testing before release to jammy-security. No fix has reached the jammy archive yet; noble (2.8.30-0ubuntu0.24.04.2) is reported unaffected. Note: 2172911 is currently marked Invalid, but Duplicate of 2172897 is the correct disposition. (tools: lp_get_bug x5, fetch_patch, debian_bugs, verify_url, submit_assessment; 64927 in / 5140 out tokens)
check-regression (skipped): settled by existing reports
analyze-source (skipped): settled by existing reports
propose-fix (skipped): settled by existing reports
write-report (done): status Duplicate (tools: submit_report; 6250 in / 1096 out tokens)

LP: #2172964 frr: CVE-2024-55553 backport stops RPKI revalidation after the first VRP update (noble, jammy) and breaks the RPKI module (focal ESM) note

Package	frr
Release	DNJF
Status	In Progress
Prio	Medium
Assignee	john-breton
Updated	2026-11-04
Flags	reply pending

Notes

Description

Summary
-------
The CVE-2024-55553 security updates ("bgpd: Validate only affected RPKI
prefixes instead of a full RIB") were derived from an unofficial upstream
backport for FRR 7.5 (FRRouting/frr commit 2fa79333, never merged into any
upstream branch). That backport removes the thread_add_read() call at the
top of bgpd_sync_callback() in bgpd/bgp_rpki.c and does not re-add it. The
upstream fix (b0800bfdf04b) and its stable/10.x backports keep the re-arm.

As a result, bgpd reads a single record from the internal RTR-to-bgpd socket
after start-up and never reads it again. Changes to the RPKI VRP set are no
longer applied to routes already received.

On focal (ESM Apps), the backport additionally calls functions that do not
exist in FRR 7.2.1 (bgp_table_subtree_lookup, bgp_dest_has_bgp_path_info_data).
The module builds with implicit-declaration warnings, and bgpd_rpki.so has
unresolved symbols, so "bgpd -M rpki" fails to load the module and exits.

Impact
------
noble, jammy: route origin validation fails to open after any VRP change. A
route that becomes RPKI Invalid stays installed and advertised despite an
inbound "match rpki invalid" deny, until "clear bgp ... soft in" or a bgpd
restart. Routes arriving after the change are still validated correctly.

focal (ESM Apps): bgpd configured with the rpki module (-M rpki) does not
start, so BGP is unavailable on those systems.

Affected versions
-----------------
noble:  8.4.4-1.1ubuntu6.3 up to and including 8.4.4-1.1ubuntu6.7
jammy:  8.1-1ubuntu1.12 up to and including 8.1-1ubuntu1.16
focal:  7.2.1-1ubuntu0.2+esm3 up to and including 7.2.1-1ubuntu0.2+esm4 (ESM Apps)

Steps to reproduce (noble, jammy)
---------------------------------
1. Configure bgpd with -M rpki, an RPKI cache, an eBGP neighbor with
   "soft-reconfiguration inbound" and an inbound route-map that denies
   "match rpki invalid".
2. Once routes are received, change the cache's VRP set so that an
   accepted route becomes Invalid.
3. "show rpki prefix-table" shows the new VRPs, but the route stays best
   and advertised. "show thread cpu" shows bgpd_sync_callback invoked
   once for the lifetime of the process.
4. "clear bgp <afi> <safi> <peer> soft in" corrects it.

Steps to reproduce (focal ESM Apps)
-----------------------------------
1. Install frr and frr-rpki-rtrlib 7.2.1-1ubuntu0.2+esm4.
2. Run: /usr/lib/frr/bgpd -M rpki -u frr -g frr -d
   -> 'loading module "rpki" failed: ...', exit status 1.

Fix
---
noble, jammy: restore
  thread_add_read(bm->master, bgpd_sync_callback, NULL,
                  rpki_sync_socket_bgpd, NULL);
as the first statement of bgpd_sync_callback().

focal: port the revalidation code to the FRR 7.2.1 bgp_node API, and
restore the same re-arm.

Related upstream
----------------
https://github.com/FRRouting/frr/issues/24001 reports a similar symptom on
FRR 10.x with different causes (proposed fix:
https://github.com/FRRouting/frr/pull/24131, not merged). One of those causes
is older than the CVE fix and exists in these releases too: a route the
inbound policy denied, and which has no other path, is not re-accepted when
it becomes Valid. Fixing this regression does not change that behaviour.

Reported by Andrew H. Bond.

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (none):** All activity in the window is the assignee (john-breton) filing and organizing his own bug: series nominations, self-assignment, and setting all tasks to In Progress. He is actively working on it; there is nothing new for the team to act on.

Thought process

precheck (done): route update: status In Progress; assigned to john-breton
review-update (done): none: All activity in the window is the assignee (john-breton) filing and organizing his own bug: series nominations, self-assignment, and setting all tasks to In Progress. He is actively working on it; there is nothing new for the team to act on. (tools: lp_get_bug, submit_update_review; 9600 in / 572 out tokens)

LP: #2168803 QEMU 8.2.2 guests crash by exhausting vm.max_map_count with coroutines note

Package	qemu
Release	DTSRN
Status	In Progress
Prio	High
Assignee	whershberger, kicchou
Updated	2026-11-04
Flags	reply pending

Notes

Description

[ Impact ]

QEMU 8.2.2's coroutine pool implementation can cause the QEMU process's VMA count to hit the Linux vm.max_map_count limit (`65530` in Jammy, `1048576` in Noble), causing QEMU to abort with "failed to allocate memory for stack" or "failed to set up stack guard page" during coroutine creation. This eventually causes running guests to crash.

A VM with 32 vCPUs and two virtio-blk disks gets a theoretical maximum VMA mappings of 1122816, higher than the Noble kernel default. See the model in section {1} of 'Other info' for detail on how we calculate this number. In practice the number of coroutines and thus VMAs that will actually be allocated is typically much smaller since the total number of allocated coroutines depends on concurrent IO, thus forcing an increase in the size of the thread-local caches. Many small IOs all at once drain both the thread-local and global pools, causing more coroutines to be allocated. Coroutine growth after VM start is hypothesized to behave logarithmically.

This behavior was introduced in upstream 4c41c69e05fe28c (v7.0.0-rc0) and therefore only affects Ubuntu 24.04.

The reporter experienced crashes while running Noble's QEMU in a container on a 5.15 kernel (with the old `vm.max_map_count=65530`). Even with a relatively modest VM configuration (36 vCPUs, 1-3 disks), we’ve observed numbers of cached VMAs in the 30,000 - 70,000 range.

Crashes are expected to be significantly less likely with Noble's sysctl config since reaching its default vm.max_map_count of 1048576 would require a significant fraction of the total allocated coroutines to be active concurrently (or a 10x increase in the number of vCPUs). Crashes with the default Noble configuration have not been reported, but are certainly possible with large guests.

While crashes can be worked around by adjusting the sysctl, this is still a resource leak that can leave a large number of unused coroutines allocated but unusable. 86a637e4810 allows for significantly better reuse of those cached idle coroutines (2,000 - 5,000 as opposed to the 30,000 - 70,000 cited above). This new coroutine caching implementation allows for drastically larger VMs for Noble users in the near future (think 100+ vCPUs, multiple disks, and IOThreads) without needing to change the 1048576 VMA limit from the default in that release.

For instance, current ARM CPUs have 192 cores on a single package, and dual socket systems can have 384 CPUs. It's not infeasible that core count could double within 5 years, and Noble will still be supported (through ESM) by then. Users with such systems will likely want to dedicate 100+ vCPUs to a single guest. The drastically improved caching should mean that no Noble user would need to consider increasing the default 1048576 vm.max_map_count limit with the caching change per our current understanding of how coroutines are cached.

[ Test Plan ]

1. Run the upstream iotests (in a virtual machine) to exercise coroutines (not
all of these tests are run during package build):

```sh
gbp pq switch
sudo apt build-dep ./
sudo apt install seabios ipxe-qemu

make -f debian/rules configure-qemu

# Binaries needed for iotests
ninja -C b/qemu modules
make -f debian/rules build-x86-optionrom
cp -a b/optionrom/*.bin /usr/share/seabios/* /usr/lib/ipxe/qemu/* b/qemu/qemu-bundle/usr/share/qemu/

make -C b/qemu/ check-block
cd b/qemu/
./tests/qemu-iotests/check -qcow2
# Expected failures 151 281 307 graph-changes-while-io
```

2. Run the Ubuntu Server team's qemu-migration-test [1]

3. The following procedure reproduces mmap exhaustion:

```sh
lxc launch ubuntu:noble --vm -c limits.cpu=8 -c limits.memory=16GiB n0
```

```sh
sudo apt install libvirt-daemon-system virtinst cloud-image-utils

cat > user-data <<EOF
#cloud-config
password: ubuntu
chpasswd:
  expire: false
ssh_pwauth: true
package_update: true
packages:
  - fio
EOF

wget https://cloud-images.ubuntu.com/daily/server/noble/current/noble-server-cloudimg-amd64.img

sudo cp noble-server-cloudimg-amd64.img /var/lib/libvirt/images/testvm-root.qcow2
sudo qemu-img create -f raw /var/lib/libvirt/images/testvm-data.raw 10G
sudo cloud-localds /var/lib/libvirt/images/testvm-cidata.iso user-data

sudo virt-install \
  -n testvm \
  --machine pc-i440fx-8.2 \
  --os-variant=ubuntu24.04 \
  --ram=8192 --vcpus=16 \
  --import \
  --disk path=/var/lib/libvirt/images/testvm-root.qcow2,bus=virtio,cache=writethrough \
  --disk path=/var/lib/libvirt/images/testvm-data.raw,bus=virtio,cache=none,driver.io=io_uring \
  --disk path=/var/lib/libvirt/images/testvm-cidata.iso,device=cdrom,bus=ide \
  --graphics none \
  --network network=default
```

Shut down the VM and throttle IO to increase the number of concurrently in-flight iops (simulates `cache='none'`):
```sh
sudo virsh blkdeviotune testvm vdb --total-iops-sec 2000 --current
```

To observe the crash, reduce the max map count to the Jammy value
```sh
sudo sysctl -w vm.max_map_count=65530
```

On the host, monitor the number of maps with:
```sh
pid=$(pidof qemu-system-x86_64)
while sleep 1; do sudo grep -c '' /proc/$pid/maps; done
```

Produce substantial concurrently active coroutines on the main thread:
```sh
while true; do
  sudo fio --name=main_thread \
    --ioengine=io_uring \
    --direct=1 \
    --runtime=10 \
    --time_based=1 \
    --rw=randread \
    --bs=4k \
    --iodepth=128 \
    --numjobs=256 \
    --group_reporting \
    --filename=/dev/vdb
done
```

Simultaneously produce a small amount of IO on the vCPU threads:
```sh
sudo fio --name=vcpu_threads \
  --filename=/dev/sr0 \
  --ioengine=libaio \
  --direct=1 \
  --rw=read \
  --bs=4k \
  --size=1M \
  --runtime=720 \
  --time_based=1
```

Patched behavior:

/proc/pid/maps levels off and stays consistent through the fio run. (With these
parameters we observed approximately 11507).

Unpatched behavior:

/proc/pid/maps increases with each fio on /dev/sr0 until the VM crashes with one of:

- failed to allocate memory for stack: Cannot allocate memory
- failed to set up stack guard page: Cannot allocate memory

With a higher vm.max_map_count and the parameters above, `wc -l /proc/$qemu_pid/maps` has been observed at 87569.

4. Performance regression test (results should be provided both before & after):

```sh
for bs in 4k 128k; do
  for iodepth in 1 8 16 32 64; do
    sudo fio --output-format=json \
      --output=fio-$bs-$iodepth.json \
      --ioengine=libaio \
      --direct=1 \
      --numjobs=$(nproc) \
      --runtime=30 \
      --ramp_time=5 \
      --time_based=1 \
      --rw=randread \
      --bs=$bs \
      --iodepth=$iodepth \
      --name=job1 \
      --filename=/dev/vdb
  done
done
```

[1] https://code.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/+git/qemu-migration-test

[ Where problems could occur ]

The patches restructure the way coroutines are allocated and deallocated. Coroutines are used extensively in the QMP/HMP protocol implementation, block drivers and live migrations; this change is somewhat fundamental to QEMU's coroutine infrastructure. If the change were wrong/broken, it could cause:
- failing block device drivers, causing failed boots or broken I/O operations within affected guests
- incorrect/strange behavior when interacting with a QEMU process over QMP/HMP
- failed/broken live migrations
- performance regressions as the patch introduces a lock in the coroutine pool hot path (coroutine_pool_get)

Upstream has two follow-ups to the refactor, 9352f80cd926fe2dde7c89b93ee33bb0356ff40e and 25bc7d16fa96b0ff881c83ed225ea380fe427c78. 9352f80cd will be included in the upload; 25bc7d16fa fixes a false-positive compiler warning.

86a637e4 parses the contents of `/proc/sys/vm/max_map_count` incorrectly [1]. This means that without Hector's linked follow-up, the patch removes any limitation on the maximum size of the coroutine idle pool.

The introduction of a read() from procfs will introduce an apparmor denial for VMs using libvirt's AppArmor security driver [2]. If AppArmor is active for a VM, this change will remove any limitation of the maximum size of the coroutine idle pool.

If [1] and [2] are also applied, workloads which require many coroutines may experience a performance regression (as the patches set a hard limit on the size of the coroutine pool, so coroutines needed above the pool size are allocated/deallocated on demand). The coroutine pool size is a function of `vm.max_map_count`, so increasing the max map count is the recommended workaround:

```
sysctl -w vm.max_map_count=1048576
```

It's likely that workloads running into this performance regression would also have been affected by the original bug.

[1] https://lists.gnu.org/archive/html/qemu-devel/2026-10/msg01192.html
[2] https://gitlab.com/libvirt/libvirt/-/commit/85e07fb1ceee7943879f8a374cabfa8ab858a3c6

[ Other Info ]
{1}

We can model the coroutine pool size as a function of VM properties. There are 3 kinds of threads which run coroutines (have non-empty thread-local pools): the main thread, vCPU threads, and iothreads.

In (unpatched) QEMU 8.2.2 the theoretical maximum of idle coroutines in each thread-local pool is given by: (see hw/block/virtio-blk.c:1638)

pool_max_size = 64 + Σ (1 to i of virtio-blk devices) (num_queues_i × queue_size_i / 2)

Defaults:
queue_size_i = 256 (hw/block/virtio-blk.c:1722)
num_queues_i = vCPUs (hw/virtio/virtio-pci.c:2466)

The global pool is twice as large as `pool_max_size` (util/qemu-coroutine.c:102); since thread-local pools steal the global pool, they may have at most 2 × pool_max_size coroutines:

theoretical maximum mappings = 2 × (vCPUs + iothreads + 2) × 2 × pool_max_size

Noble's QEMU 8.2.2 keeps a thread-local list of coroutines `alloc_pool` (util/qemu-coroutine.c:40); this list can grow to thousands or even tens of thousands of coroutines _for each thread_. Each coroutine has two VMAs created with mmap(2). If there are enough threads available to the QEMU process, the number of coroutines may cause the total number of mappings to exceed `vm.max_map_count`, causing the QEMU process to fail to allocate memory and crash.

- - - -
{2}

QEMU's coroutines are a userspace threading implementation. They are used frequently in QEMU's virtual disk drivers.

Each coroutine creates two anonymous mappings with mmap(2). When a coroutine terminates it is cached in a global "release pool"; once that is full (2 x max pool size), terminated coroutines are cached in a thread-local "alloc pool" (up to the max pool size, per thread). When the thread-local pool is empty, the global pool is moved to a thread-local pool. Pooled coroutines are only freed once both pools are full.

From upstream, this bug occurs because "per-thread pools can grow to tens of thousands of coroutines. Each coroutine causes 2 virtual memory areas to be created. Eventually vm.max_map_count is reached and memory-related syscalls fail. The per-thread pool sizes are non-uniform and depend on past coroutine usage in each thread, so it's possible for one thread to have a large pool while another thread's pool is empty."

The new approach "does not leave large numbers of coroutines pooled in a thread that may not use them again. In order to perform well it amortizes the cost of global pool accesses by working in batches of coroutines instead of individual coroutines."

- - - -
{3}

Source patches for SRU. We will not be adding [3] to the SRU, as it only fixes a cosmetic issue:
[1] Upstream commit (coroutine: cap per-thread local pool size): https://gitlab.com/qemu-project/qemu/-/commit/86a637e4
[2] Upstream commit (coroutine: reserve 5,000 mappings): https://gitlab.com/qemu-project/qemu/-/commit/9352f80c
[3] Upstream commit (util/coroutine: fix -Werror=maybe-uninitialized false-positive): https://gitlab.com/qemu-project/qemu/-/commit/25bc7d

RHEL9 carries [1] and [2] already (86a637e4 and 9352f80c). They are present in the CentOS Stream 9 repositories:
[4] CentOS Stream 9 Patch 176 (coroutine: cap per-thread local pool size): https://gitlab.com/redhat/centos-stream/src/qemu-kvm/-/commit/98ea1c9ee22d75dbe4f5060ccdf8164418ffe44b
[5] CentOS Stream 9 Patch 177 (coroutine: reserve 5,000 mappings): https://gitlab.com/redhat/centos-stream/src/qemu-kvm/-/commit/dd639ab6336c9bae2a40fe857036a432e0077319

Additionally, the following bugs were identified in 86a637e4 [1] which have led us to create two follow-up patches upstream. [6] fixes the reading of `/proc/sys/vm/max_map_count` and [7] deals with lowering the fallback limit of pooled coroutines to align with Linux's default 65530 VMA limit:
[6] https://gitlab.com/qemu-project/qemu/-/commit/431dfff912e97d5ed63be0952a1ab3638e63c71c
[7] https://gitlab.com/qemu-project/qemu/-/commit/188e69beb03c8adca0a4cc894b492aa136ec3926

Finally, the reading of /proc/sys/vm/max_map_count needs to be explicitly allowed in libvirt's AppArmor template. Upstream has fixed this in [8], but it still needs to be SRUed to Noble in [0]:
[8] Missing libvirt AppArmor rule upstream fix: https://gitlab.com/libvirt/libvirt/-/commit/85e07fb1ceee7943879f8a374cabfa8ab858a3c6
[9] LP bug tracking libvirt AppArmor rule SRU: https://bugs.launchpad.net/bugs/2170732

Ubuntu releases newer than Noble are added to track the string parsing [6] and coroutine fallback limit [7] SRU. The necessary AppArmor change [9] is already present in those releases.

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (none):** The only activity in the window is a description edit by whershberger, one of the assignees, on this In Progress bug — routine work by the engineer already handling it. No new comments, questions, or information that require triage action.

Thought process

precheck (done): route update: status In Progress; assigned to whershberger, kicchou; ahasenack commented on 2026-11-03
review-update (done): none: The only activity in the window is a description edit by whershberger, one of the assignees, on this In Progress bug — routine work by the engineer already handling it. No new comments, questions, or information that require triage action. (tools: submit_update_review; 3295 in / 1726 out tokens)

LP: #2095441 S390x build of openjdk crashes with the segmentation fault note

Package	qemu
Release	D
Status	Invalid
Prio	Undecided
Assignee	bugproxy
Updated	2026-11-04
Flags	reply pending

Notes

Description

See https://launchpadlibrarian.net/771962104/buildlog_ubuntu-plucky-s390x.openjdk-23_23.0.2+7~us1-0ubuntu1~ppa2_BUILDING.txt.gz

The issue is present on launchpad builder version of QEMU (jammy):
qemu binaries: 1:6.2+dfsg-2ubuntu6.22
libvirt-daemon-driver-qemu: 8.0.0-1ubuntu7.10

The crash (though different) is present in 1:8.2.2+ds-0ubuntu1.4 (noble).

The issue is not present when testing on actual hardware.
The issue is not present in 1:9.0.2+ds-4ubuntu5.1 (oracular)

AI analysis

Route	update
Suggested status	Invalid
Suggested importance	High
Suggested tags	server-triage-discuss

Analysis

## The bug

openjdk s390x builds and JVM CI tests (e.g. craft-parts autopkgtests) crash intermittently on Launchpad s390x builders — QEMU/KVM guests on hosts exposing the 'gs' (guarded storage) facility — while identical builds pass on real hardware. The guest observes a partially-updated vector register across a vl/vaf/vst sequence in `JVMState::adapt_position`, tripping the JVM guarantee `Vector addition did not work: locoff 10 stkoff 21 monoff 21 scloff 21 endoff 21 adj -4 — result: locoff 6 stkoff 17 monoff 19 scloff 17 endoff 17` (one 32-bit element of a 128-bit vector left stale). This is a real, still-live defect — the crash reappeared on resolute on 2026-11-04 — but the evidence places the root cause in the **linux** package (host kernel arch/s390 KVM), not qemu, so the qemu task should stay **Invalid** and the bug should be routed to the kernel team.

## What was found

- **No duplicate**: [LP #2095441](https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2095441) is the only tracker; the Debian candidates found are unrelated (x86/riscv64 crashes, CVEs), and no qemu changelog entry in any series references LP: #2095441 (681 entries checked).
- **qemu userspace audited clean in both affected series** (this exonerates qemu):
- jammy 1:6.2+dfsg-2ubuntu6.22: KVM_SYNC_VRS paths in `target/s390x/kvm/kvm.c` (put 490-496, get 663-666) copy all 32 vector registers, both 64-bit halves, symmetrically; GSCB memcpy at 586-588/713-714. noble 1:8.2.2+ds-0ubuntu1.4 is the same code (put 492-498, get 623-626).
- QEMU's bundled `struct kvm_sync_regs` (`linux-headers/asm-s390/kvm.h`, noble:263 / jammy:246) matches the kernel UAPI layout; `gscb` sits at the very end of the struct, far from the `vrs` area — no offset-mismatch clobber is possible.
- TCG paths equally clean: `vaf` expands to `tcg_gen_gvec_add` (`target/s390x/tcg/translate_vx.c.inc:1293`); vl/vst use whole 64-bit halves — no partial-element mechanism.
- **The bug's own evidence isolates the host kernel**: identical qemu 6.2 and guest image crash on host kernel 5.15.0-122 and pass on 5.15.0-130, and the crash correlates with the host 'gs' facility — conditions that only matter under KVM, where the host kernel saves/restores guest FPU/vector state around SIE entry/exit (and enables KVM_SYNC_GSCB). Root cause: linux package, arch/s390 KVM guest FPU/vector save/restore and its guarded-storage handling. **Confidence is medium**: the exact kernel function is unverified (linux source unreadable in this environment) and the builders' exact qemu/libvirt command line is not in the bug, so the KVM-vs-TCG conclusion rests on the bug's own data.
- **Workarounds mask the symptom only**: the openjdk-21/-25 tasks were closed Fix Released via `-fno-slp-tree-vectorize` build flags (21.0.13.0.3+1-1 / 25.0.5.0.3+1-1, currently published only in tenacious; exact changelog wording unverified — git-ubuntu returned HTTP 403), yet the crash resurfaced on resolute on 2026-11-04. Other workarounds: `-march=z10`, `-XX:-ReduceAllocationMerges`, `-XX:+StopTieredAtLevel=1`.
- **Upstream OpenJDK context**: the crashing code came in with commit 7957994273e20d541b8f2a873781be7fedf712f1 (8273695) but only manifests under emulation; JDK-8381257 is the suspected JVM-side trigger, JDK-8355570 tracks moving the codegen baseline to z13. Reproducer: jtreg `compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java` built with `-march=z13 -mtune=z15` on a QEMU s390x guest on a 'gs'-capable host.
- The early note that oracular 1:9.0.2+ds-4ubuntu5.1 seemed unaffected is weak evidence of a qemu fix — the crash is highly timing-sensitive and resurfaced on newer stacks. No regression check was run (`regression` is null), so no `regression-update` tag.

## Recommendation

1. **Keep the qemu task Invalid** — qemu userspace is clean; do not report to qemu upstream.
2. **Route to linux** (this is the action needing the team): add a linux task to this bug — it is the only tracker, and with qemu Invalid and the openjdk tasks Fix Released the defect otherwise loses its home. Ask the kernel team to audit arch/s390 KVM guest FPU/vector save/restore around SIE entry/exit and the guarded-storage (GSCB/KVM_SYNC_GSCB) handling, and to confirm whether the fix present in host 5.15.0-130 is also in the noble 6.8 kernel — the resolute reappearance suggests newer kernels may still be affected.
3. **Builder-side mitigation to test** (config only, no package change): launch the guest without guarded storage, e.g. `-cpu host,gs=off`, to confirm the correlation and avoid the crash.
4. IBM is already engaged (bugproxy assignee, LTC 211220 per the `bugnameltc-211220` tag); coordinate the kernel-side investigation through them and linux-s390/KVM upstream.

No qemu change is proposed (fix kind: none; `fix_applies` is empty for all series). The `server-triage-discuss` tag is for the routing step and the kernel-side open questions, not for the qemu verdict, which is well supported.

Suggested comment

Thanks for the detailed analysis. We audited qemu's s390x code in both affected series — the KVM_SYNC_VRS get/put paths in target/s390x/kvm/kvm.c (all 32 vector registers, both 64-bit halves, symmetric), the bundled struct kvm_sync_regs layout and the TCG vector paths — and found no way qemu userspace could leave a guest vector element partially updated. Together with your host-kernel comparison (identical qemu 6.2 and guest image failing on host 5.15.0-122, passing on 5.15.0-130) and the 'gs' correlation, this points at the host kernel's arch/s390 KVM guest FPU/vector save/restore rather than qemu, so the qemu task stays Invalid and we are routing the defect to the linux package. As a builder-side confirmation (and mitigation), could you try launching the guest without the guarded-storage facility, e.g. `-cpu host,gs=off`?

References

Upstream

Do not report this to qemu upstream — the qemu userspace code is clean and the qemu task should stay Invalid. Route the finding to the Linux s390/KVM maintainers (linux-s390@vger.kernel.org, kvm@vger.kernel.org; IBM LTC 211220 is already engaged via bugproxy): guest vector-register corruption under KVM on 'gs'-capable hosts — one 32-bit element of a 128-bit vector left stale between vl/vaf/vst in JVMState::adapt_position, reproducible with the openjdk jtreg test compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java built with -march=z13 -mtune=z15, host-kernel sensitive (5.15.0-122 fails, 5.15.0-130 passes with identical qemu 6.2 and guest image). Ask them to audit arch/s390 KVM guest FPU/vector save/restore around SIE entry/exit and its guarded-storage (GSCB / KVM_SYNC_GSCB) handling, and to confirm whether the fix present in 5.15.0-130 is also in the noble 6.8 kernel.

Thought process

precheck (done): route update: status Fix Released; assigned to bugproxy; fheimes commented on 2025-04-03
review-update (done): escalate: The reporter reproduced the issue on resolute (s390x) with a detailed analysis pointing at vector register save/restore during context switch as root cause, changing the original qemu/openjdk build-flags story and adding a new affected series. The bug must be re-triaged with the kernel/s390x angle. (tools: submit_update_review; 5240 in / 151 out tokens)
validate-report (done): verdict bug: A specific, well-researched fault: vector stores in QEMU s390x guests corrupt JVM offsets in openjdk builds, reproducing only under QEMU (not on hardware). Reported against qemu with jammy/noble builder versions; openjdk tasks track upstream fixes, but the root cause appears to be in QEMU's s390x vector handling. (tools: submit_validation; 9301 in / 1078 out tokens)
search (done): 0 Launchpad candidates from 5 queries, 10 Debian candidates, 0 changelog hits
search-upstream (done): No matching report or fix was found upstream: QEMU's GitLab issue tracker (searched with the verbatim 'Vector addition did not work' guarantee text, 'adapt_position', and several s390x vector/guarded-storage/'gs' symptom terms), the QEMU GitHub commit history, and kernel Bugzilla all came up empty for this s390x vector-register corruption under emulation. The nearest s390x/Java items in QEMU's tracker (issue 655 'Java crashes on s390x VM with SIGILL/ILL_PRVOPC at __kernel_getcpu+0x8', issue 319 'Openjdk11+ fails to install on s390x', issue 2054 'chacha20-s390 broken in 8.2.0 in TCG on s390x') describe different symptoms and are older, so this bug appears to be unreported upstream and likely needs a fresh upstream QEMU report. (tools: gitlab_search x12, bugzilla_search x2, github_search, submit_upstream_search; 88808 in / 8100 out tokens)
search-other-distros (done): No matching reports or fixes were found in Fedora, Arch or Gentoo trackers for this QEMU s390x vector-register corruption under emulation; nothing found outside Launchpad and Debian, consistent with the upstream search suggesting this needs a fresh upstream QEMU report. (tools: bugzilla_search x7, gitlab_search, submit_distro_search; 14700 in / 472 out tokens)
assess-existing (done): LP #2095441 is the only tracker for this defect: the provided Debian candidates are unrelated (x86/riscv64 crashes, CVEs) and fresh Launchpad/Debian searches for s390x vector-register or guarded-storage corruption found nothing else, so there is no duplicate; IBM is engaged via bugproxy (internal LTC 211220, per the bugnameltc-211220 tag). Nothing is fixed in qemu in any series: the qemu (Ubuntu) task is Invalid and no qemu changelog entry references LP: #2095441 (681 entries checked, no hit). The openjdk-21 and openjdk-25 tasks were closed Fix Released via the maintainer's -fno-slp-tree-vectorize build workaround, with the janitor citing 21.0.13.0.3+1-1 and 25.0.5.0.3+1-1 — versions currently published only in tenacious (the openjdk changelogs themselves could not be read; git-ubuntu returned HTTP 403, so the exact workaround wording is unverified). That workaround only masks the symptom for openjdk builds: the crash reappeared on resolute on 2026-11-04, and the newest analysis (JVMState::adapt_position disassembly showing the vl/vaf/vst loop update only some of the five offsets) suspects kernel vector-register save/restore on 'gs'-capable hosts rather than qemu userspace, consistent with the earlier host-kernel difference (LP host 5.15.122 failing vs test host 5.15.130 passing); no matching linux bug or kernel fix was found. Upstream OpenJDK suspects JDK-8381257 as the JVM-side culprit, and JDK-8355570 tracks moving the codegen baseline to z13; further workarounds exist: -march=z10, -XX:-ReduceAllocationMerges, or -XX:+StopTieredAtLevel=1 (C2 disabled). The early observation that oracular 1:9.0.2+ds-4ubuntu5.1 was unaffected is weak evidence of a qemu fix, since the crash is highly timing-sensitive and later resurfaced on newer stacks. (tools: lp_get_bug x2, lp_search_bugs x15, debian_bugs x3, pkg_changelog x12, verify_url x3, pkg_versions x2, submit_assessment; 325327 in / 28041 out tokens)
check-regression (skipped): no recent update to suspect
analyze-source (done): confidence medium: Read LP #2095441 in full, including the latest analysis (comment 26: the vl/vaf/vst loop in JVMState::adapt_position leaves one 32-bit vector element stale, suspected vector save/restore during context switch) and the host-kernel comparison (comment 5: identical qemu 6.2 + guest image crashes on host kernel 5.15.0-122, passes on 5.15.0-130). Audited qemu's s390x KVM register sync (kvm_arch_put/get_registers, KVM_SYNC_VRS and KVM_SYNC_GSCB) at noble (8.2.2) and jammy (6.2): correct and symmetric, all 32 vector registers, both halves. Compared QEMU's bundled linux-headers/asm-s390/kvm.h (struct kvm_sync_regs) at both series against the known kernel UAPI layout: no offset mismatch that could clobber the vrs area. Checked the TCG vector paths (vaf → tcg_gen_gvec_add at translate_vx.c.inc:1293; vl/vst via whole 64-bit halves): no partial-element mechanism. Could NOT read the host-kernel side: the linux source package is unavailable via git-ubuntu in this environment (top-level listing and file reads all fail), so the exact faulty function in arch/s390 KVM (guest FPU/vector save/restore around SIE, guarded-storage handling) remains unverified. Also unverified: the builders' exact QEMU/libvirt command line and guest CPU model (not in the bug), so the KVM (vs TCG) conclusion rests on the bug's own evidence — host-kernel-version sensitivity and host 'gs' feature sensitivity, both of which only matter under KVM. (tools: lp_get_bug, source_list x6, source_file x13, submit_analysis; 586654 in / 53606 out tokens)
propose-fix (done): none: Proposing no qemu change (kind: none): the root cause is not in the qemu package, so any qemu diff would not address it. What I checked: (1) Re-verified the analysis in the qemu source — target/s390x/kvm/kvm.c at noble (1:8.2.2+ds-0ubuntu1.4) copies all 32 vector registers, both 64-bit halves, in kvm_arch_put_registers (lines 492-498) and reads them back symmetrically in kvm_arch_get_registers (lines 623-626) under KVM_SYNC_VRS; jammy (1:6.2+dfsg-2ubuntu6.22) is identical (put 490-496, get 663-666). There is no partial-update path for guest vector registers in qemu userspace. (2) Re-verified the bundled UAPI copy linux-headers/asm-s390/kvm.h at noble: struct kvm_sync_regs has vrs[32][2] unioned with fprs[16] near the front, with gscb[4] inside the sdnx union at the very end — no QEMU-vs-kernel offset mismatch could clobber the vector area. (3) The analysis also audited the TCG vector paths (vaf → tcg_gen_gvec_add at translate_vx.c.inc:1293; vl/vst via whole 64-bit halves): no partial-element mechanism. The bug's own evidence isolates the host kernel: identical qemu 6.2 and guest image crash on host kernel 5.15.0-122 but pass on 5.15.0-130, and the crash correlates with the host 'gs' (guarded storage, facility 129) feature — conditions that only matter under KVM, where guest vector state is saved/restored by the host kernel around SIE entry/exit. Conclusion: the fault is in the linux package (arch/s390 KVM guest FPU/vector save/restore and its guarded-storage handling), not qemu; the qemu task should stay Invalid and the bug should be routed to the linux package. Per the bug data, jammy hosts are already fixed by kernel >= 5.15.0-130; the linux maintainers need to confirm the corresponding fix in the noble 6.8 kernel. The exact faulty kernel function remains unverified because the linux source package is not available via git-ubuntu in this environment. Builder-side mitigation to test (config only, no package change): launch the guest without the guarded-storage facility (-cpu host,gs=off or a CPU model without 'gs') to confirm the correlation and avoid the crash. (tools: source_file x3, verify_url x2, submit_fix; 36797 in / 12378 out tokens)
write-report (done): status Invalid (tools: submit_report; 8238 in / 28671 out tokens)

LP: #2172317 python3-tornado 6.5.4-0.1ubuntu0.2 breaks Jupyter Notebook note

Package	python-tornado
Release	DSRN
Status	Confirmed
Prio	Undecided
Assignee	yomonokio
Updated	2026-11-04
Flags	reply pending

Notes

Description

With python3-tornado 6.5.4-0.1ubuntu0.2 installed Jupyter Notebook fails with the following error:

    Traceback (most recent call last):
      File "/usr/lib/python3/dist-packages/tornado/web.py", line 1881, in _execute
        result = await result
                 ^^^^^^^^^^^^
      File "/usr/lib/python3/dist-packages/tornado/web.py", line 2816, in get
        self.absolute_path = self.validate_absolute_path(self.root, absolute_path)
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3/dist-packages/notebook/base/handlers.py", line 843, in validate_absolute_path
        return super().validate_absolute_path(root, absolute_path)
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3/dist-packages/tornado/web.py", line 3021, in validate_absolute_path
        absolute_path = self._resolve_symlink_target(absolute_path)
      File "/usr/lib/python3/dist-packages/tornado/web.py", line 3086, in _resolve_symlink_target
        allowed_directory = os.path.realpath(self.allowed_symlink_directory)
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AttributeError: 'FileFindHandler' object has no attribute 'allowed_symlink_directory'

Rolling back to 6.5.4-0.1 allows Jupyter to start again.

ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: python3-tornado 6.5.4-0.1ubuntu0.2
ProcVersionSignature: Ubuntu 7.0.0-38.38-generic 7.0.14
Uname: Linux 7.0.0-38-generic x86_64
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: amd64
CasperMD5CheckResult: pass
Date: Tue Oct 27 14:06:31 2026
InstallationDate: Installed on 2026-05-11 (169 days ago)
InstallationMedia: Ubuntu-Server 26.04 "Resolute Raccoon" - Release amd64 (20260420.1)
ProcEnviron:
 LANG=en_GB.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm
 XDG_RUNTIME_DIR=<set>
SourcePackage: python-tornado
UpgradeStatus: No upgrade log present (probably fresh install)

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (none):** Since the team's last comment (which already incorporated the reproducer and fix commit from earlier comments), the only new activity is yomonokio self-assigning the noble/resolute/stonking tasks and a subscription from davemckain — no new information or questions. The bug is already tagged server-todo, regression-update and assigned to a developer, so no one needs to act.

Thought process

precheck (done): route update: assigned to yomonokio; graysonwolf commented on 2026-10-30
review-update (done): none: Since the team's last comment (which already incorporated the reproducer and fix commit from earlier comments), the only new activity is yomonokio self-assigning the noble/resolute/stonking tasks and a subscription from davemckain — no new information or questions. The bug is already tagged server-todo, regression-update and assigned to a developer, so no one needs to act. (tools: submit_update_review; 3919 in / 4262 out tokens)

LP: #2167823 AppArmor denies QEMU to read /sys/devices/pci0000:00/0000:00:01.2/uevent note

Package	libvirt
Release	DR
Status	Fix Committed
Prio	Undecided
Assignee	hectorcao
Updated	2026-11-04
Flags	reply pending verification needed

Notes

Description

[ Impact ]

Attaching or hot-plugging a USB device to a guest as a <hostdev> fails under
the default libvirt-qemu AppArmor confinement.

The existing AppArmor rule only grants read access to everything *under* a
usb[0-9]* directory:

    /sys/devices/**/usb[0-9]*/** r,

The parent controller's uevent sits above usb[0-9]* and is therefore not
covered, so the access is denied:

    apparmor="DENIED" operation="open" class="file"
    profile="libvirt-<uuid>"
    name="/sys/devices/pci0000:00/0000:00:01.2/uevent"
    comm="qemu-system-x86" requested_mask="r" denied_mask="r"

As a result USB <hostdev> attach/hotplug does not work out of the box.

[ Test Plan ]

1) Download a Ubuntu Cloud Image
   $ wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
   and start a VM with virsh from the domain definition [2]

2) Check VM running with:
   $ virsh list

3) virsh attach-device --domain ubuntu-cloud-vm --file dev.xml

dev.xml contains an example of the USB the device, it usually works on all PC
but if that does not, please tune it for the host system you are testing on.

A - Before the fix:
------

Access denied:
(this is an exemple of the dmesg log message)

audit: type=1400 audit(1784186108.556:533): apparmor="DENIED" operation="open" class="file" profile="libvirt-c13c2cda-4558-4fca-9146-9f2f8075d432" name="/sys/devices/pci0000:00/0000:00:01.2/uevent" pid=23339 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0

B - After the fix:
----

No more apparmor access denied warning.
The attach might success or fail (but for other reasons)

[ Where problems could occur ]

The change only adds a single read-only AppArmor rule:

    /sys/devices/**/uevent r,

to the libvirt-qemu profile, granting QEMU read access to sysfs uevent
files across the device tree. uevent files only expose non-sensitive device
metadata (driver name, modalias, PCI IDs, DEVTYPE, etc.), so the widened
access is limited to that metadata and does not grant access to any other
sysfs attribute.

Any regression would be confined to AppArmor confinement of QEMU processes
started by libvirt:
 - In the unlikely event the rule were malformed, the libvirt-qemu profile
   could fail to load/reload, which would be immediately visible at guest
   start. The rule has been validated by loading the profile and successfully
   starting guests.
 - The rule only broadens read access; it cannot cause previously-working
   functionality to be denied.

[ Other Info ]

 * Noble (24.04) is not affected: USB hostdev attach already succeeds there.
 * Forwarded upstream:
   - https://gitlab.com/libvirt/libvirt/-/work_items/896
   - https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/STRKGEF4HSYTDAZHBEUQADPM3S4IIGHN/
 * Fix carried as:
   d/p/ubuntu-aa/lp2167823-apparmor-allow-reading-uevent-for-usb-hostdev.patch

----

1) Download a Ubuntu Cloud Image
   $ wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
   and start a VM with virsh from the domain definition [2]

2) Check VM running with:
   $ virsh list

3) virsh attach-device --domain ubuntu-cloud-vm --file dev.xml

dev.xml contains an example of the USB the device, it usually works on all PC
but if that does not, please tune it for the host system you are testing on.

Access denied:
(this is an exemple of the dmesg log message)

audit: type=1400 audit(1784186108.556:533): apparmor="DENIED" operation="open" class="file" profile="libvirt-c13c2cda-4558-4fca-9146-9f2f8075d432" name="/sys/devices/pci0000:00/0000:00:01.2/uevent" pid=23339 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0

Original bug description
---

Operating system: Ubuntu 26.04 LTS
Architecture: x86_64
kernel version: Linux ubuntu 7.0.0-28-generic
libvirt version: 12.0.0
Hypervisor and version: qemu-system-x86 10.2.1+ds-1ubuntu3.2

Start a VM and attach an usb host device:

virsh attach-device --domain subVmTest1 --file /tmp/usbhostedxml
Contents of the `/tmp/usbhostedxml`:
<hostdev mode='subsystem' type='usb'>
  <source>
    <vendor id='0x1d6b'/>
    <product id='0x0001'/>
  </source>
</hostdev>

AppArmor denial:
audit: type=1400 audit(1784186108.556:533): apparmor="DENIED" operation="open" class="file" profile="libvirt-c13c2cda-4558-4fca-9146-9f2f8075d432" name="/sys/devices/pci0000:00/0000:00:01.2/uevent" pid=23339 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0

[1] vm.xml

<domain type='kvm'>
  <name>ubuntu-cloud-vm</name>
  <memory unit='GiB'>2</memory>
  <currentMemory unit='GiB'>2</currentMemory>
  <vcpu placement='static'>2</vcpu>

  <os>
    <type arch='x86_64'>hvm</type>
    <boot dev='hd'/>
  </os>

  <features>
    <acpi/>
    <apic/>
  </features>

  <cpu mode='host-passthrough'/>
  <clock offset='utc'/>

  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>

  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>

    <!-- Main OS Disk (Ubuntu Cloud Image) -->
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/ubuntu/ubuntu-24.04-server-cloudimg-amd64.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>

    <interface type='user'>
      <model type='virtio'/>
    </interface>

    <!-- Serial console for 'virsh console' access -->
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>

  </devices>
</domain>

[2] dev.xml

<hostdev mode='subsystem' type='usb'>
  <source>
    <address bus='1' device='1'/>
  </source>
</hostdev>

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (none):** The only new activity is the standard SRU verification request comment from the uploader announcing that the fix (12.0.0-1ubuntu5.7) landed in resolute-proposed; the bug correctly stays Fix Committed with verification-needed-resolute until the reporter verifies it. No action needed beyond waiting for verification.

Thought process

precheck (done): route update: status Fix Committed, Fix Released; assigned to hectorcao; hectorcao commented on 2026-10-19; tag verification-needed-resolute
review-update (done): none: The only new activity is the standard SRU verification request comment from the uploader announcing that the fix (12.0.0-1ubuntu5.7) landed in resolute-proposed; the bug correctly stays Fix Committed with verification-needed-resolute until the reporter verifies it. No action needed beyond waiting for verification. (tools: submit_update_review; 3744 in / 115 out tokens)

LP: #2169887 UEFI guests without nvram fail to start after edk2 2025.11-3ubuntu7.2: autoselect picks memory-mapped amdsev firmware, virt-aa-helper rejects it note

Package	edk2
Release	DSR
Status	Fix Committed
Prio	Undecided
Assignee	hectorcao
Updated	2026-11-04
Also affects	edk2-hwe:Fix Committed@hectorcao, libvirt:Fix Committed@hectorcao, libvirt-hwe:In Progress@hectorcao
Flags	reply pending verification needed

Notes

Description

[Impact]

Since edk2 2025.11-3ubuntu7.2 (LP: #2160129), 60-edk2-x86_64-amdsev.json
maps OVMF.amdsev.fd with "device": "memory". On Resolute, a UEFI guest that
relies on libvirt firmware autoselection, with Secure Boot disabled and no
per-VM nvram, now selects that descriptor on a non-SEV Intel host. libvirt
uses it as a rom loader, virt-aa-helper rejects the path, and the domain
fails to start with a misleading AppArmor error:

  error: Failed to start domain 'lp-repro-efi'
  error: internal error: cannot load AppArmor profile 'libvirt-eb9cc8c8-f1f5-427c-9408-1645f8032f08'

libvirtd log:

  internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr
  /usr/lib/libvirt/virt-aa-helper -c -u libvirt-eb9cc8c8-f1f5-427c-9408-1645f8032f08)
  unexpected exit status 1: virt-aa-helper: error: /usr/share/ovmf/OVMF.amdsev.fd
  virt-aa-helper: error: skipped restricted file
  virt-aa-helper: error: invalid VM definition

The guest requests no confidential-computing features. Our production
guests with the same firmware request (UEFI, secure-boot disabled, no
nvram) started normally before 7.2; failures began with the 7.2 upgrade.

Still reproduces with edk2 2025.11-3ubuntu7.3 and libvirt
12.0.0-1ubuntu5.5 (current resolute-updates).

[Test Plan]

The fix has 2 folds for 2 packages: edk2 and libvirt

Install libvirt
$ apt install -y libvirt-daemon-system libvirt-clients

Create vm.xml domain definition:
$ cat vm.xml
<domain type="qemu">
<name>lp-repro-efi</name>
<memory unit="MiB">512</memory>
<vcpu>1</vcpu>
<os firmware="efi">
<type arch="x86_64" machine="q35">hvm</type>
<firmware>
<feature enabled="no" name="secure-boot"/>
</firmware>
</os>
<features>
<acpi/>
</features>
<devices/>
</domain>

$ virsh define vm.xml
$ virsh domxml-to-native qemu-argv --domain lp-repro-efi

The output is the generated qemu command and should contain in the faulty system:
...
-bios /usr/share/ovmf/OVMF.amdsev.fd
...

Try to start the VM:
$ virsh start lp-repro-efi
error: Failed to start domain 'lp-repro-efi'
error: internal error: cannot load AppArmor profile 'libvirt-00a88774-3b55-4284-a292-666687f18ac3'

With EDK2 and libvirt with proposed fixes:

$ virsh domxml-to-native qemu-argv --domain lp-repro-efi
...-blockdev '{"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE_4M.fd",..

Try to start the VM will no longer cause a apparmor issue:
$ virsh start lp-repro-efi

[Where problems could occur]

The change affects only AppArmor permissions generated for ROM loaders.
These loaders are read-only, so granting them readonly access preserves the
existing restriction on writable access to protected firmware paths. Other
loader types and their readonly settings are unchanged.

[Other Info]

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (none):** The only new activity is the standard automated SRU acceptance notices for edk2-hwe and libvirt landing in resolute-proposed; the bug is already assigned and awaiting verification (verification-needed-resolute), so no further action is needed yet.

Thought process

precheck (done): route update: status Fix Committed, Fix Released, In Progress; assigned to hectorcao; hectorcao commented on 2026-10-19; tag verification-needed-resolute
review-update (done): none: The only new activity is the standard automated SRU acceptance notices for edk2-hwe and libvirt landing in resolute-proposed; the bug is already assigned and awaiting verification (verification-needed-resolute), so no further action is needed yet. (tools: submit_update_review; 3948 in / 134 out tokens)

LP: #2172818 winbind accumulates thousands of rpcd_lsad workers and uses 5.2 GiB RAM note

Package	samba
Release	D
Status	Confirmed
Prio	Undecided
Assignee	—
Updated	2026-11-04
Flags	reply pending

Notes

Description

Package/version: Samba 4.23.6-Ubuntu-4.23.6+dfsg-1ubuntu2.2
Server role: standalone server
Services: smbd active; winbind active; samba-ad-dc inactive

Description

On my Ubuntu file server, winbind.service accumulated 1,379 rpcd_lsad worker processes over approximately four days. The service used 5.2 GiB of memory and had 1,385 tasks. At the time, smbstatus -p showed no connected SMB clients.

All workers were children of samba-dcerpcd, itself running under winbind.service. Each worker showed approximately 3.4 MiB PSS (about 4.6 GiB combined). Restarting winbind immediately reduced the service to four tasks and 13 MiB of memory, with one rpcd_lsad worker.

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (comment):** The reporter asked two direct questions after the team's last comment: whether uninstalling apparmor-profiles is needed/safe, and whether the bug should be re-targeted to that package. A short reply confirming the narrower workaround (disable just the profile) and the re-target to apparmor-profiles moves the bug forward.

Suggested comment

Thanks for the follow-up. Yes, apparmor-profiles is an optional package, which explains why your other machine without it is unaffected. You don't need to uninstall it: disabling just the samba-rpcd profile (e.g. with aa-disable) is enough as a workaround — the trade-off is that those samba processes then run without that AppArmor confinement. And since the profile ships in apparmor-profiles, we'll re-target this bug to that package while we investigate why the profile triggers the rpcd_lsad process growth.

Thought process

precheck (done): route update: ahasenack commented on 2026-11-03
review-update (done): comment: The reporter asked two direct questions after the team's last comment: whether uninstalling apparmor-profiles is needed/safe, and whether the bug should be re-targeted to that package. A short reply confirming the narrower workaround (disable just the profile) and the re-target to apparmor-profiles moves the bug forward. (tools: submit_update_review; 3676 in / 6179 out tokens)

LP: #2172897 haproxy 2.4.30-0ubuntu0.22.04.3: CVE-2026-110354 backport causes intermittent 502 (PH) on valid chunked responses note

Package	haproxy
Release	D
Status	Confirmed
Prio	Undecided
Assignee	mdeslaur
Updated	2026-11-04
Flags	reply pending

Notes

Description

Release: Ubuntu 22.04 LTS (jammy)
Package: haproxy 2.4.30-0ubuntu0.22.04.3 (jammy-security, USN-8972-1)
Previous version: 2.4.30-0ubuntu0.22.04.2 (works)

[Impact]
After upgrading from .2 to .3, a large share (roughly 50-70%) of requests
through HAProxy started failing with HTTP 502. It affected every HTTP/1.1
backend that sends chunked responses (Apache/PHP, Node.js, and a git smart-HTTP
server in our case). The backends themselves were unchanged and healthy.
Downgrading to 2.4.30-0ubuntu0.22.04.2 fixed it immediately.

[Symptoms]
- HAProxy log: status 502 with termination state "PHNN" (proxy aborted while
  processing the server response), Tr = -1, on all affected backends.
- "show errors" (via the master CLI) shows every event as "invalid response" with:
      H1 msg state MSG_CHUNK_SIZE(26)
      H1 chunk len 0 bytes, H1 body len <full body size> bytes
      len 0, error at position 0
  i.e. the whole body had already been received, and the error happens while
  waiting for the next chunk-size line (typically the final "0" chunk).
- Intermittent: it depends on whether the next chunk-size line arrives in the
  same read as the preceding chunk data.

[Analysis (from reading the source; not reproduced in a test harness)]
debian/patches/CVE-2026-110354.patch adds to h1_parse_msg_data() in src/h1_htx.c:

    if (!ret && !ofs && !buf_room_for_htx_data(srcbuf)) {
            (*dsthtx)->flags |= HTX_FL_PARSING_ERROR;
            ...
    }
This is meant to detect "chunk-size line longer than a full buffer". But in
2.4, mux-h1 releases the input buffer once all received data has been parsed
(src/mux_h1.c, h1_process_input(): "if (!b_data(&h1c->ibuf))
h1_release_buf(h1c, &h1c->ibuf);"). A released buffer has size 0, so
buf_room_for_htx_data() returns 0 (b_room() == 0).

When a chunked response is parsed up to the end of a chunk's data and the next
chunk-size line has not arrived yet, the parser is in H1_MSG_CHUNK_SIZE with an
empty (released) input buffer. On the next pass, h1_parse_chunk_size() returns 0
(incomplete, correct), ofs is 0, and buf_room_for_htx_data() is 0. The new check
therefore treats the missing buffer as a FULL buffer and reports a parsing
error, so a valid response becomes a 502.

The upstream commit message notes that "no loop can be experienced on 2.8 and
2.6", which suggests older branches were not affected by the original issue
the way 3.x is, and that the backport needs branch-specific adaptation. (Not
checked: whether noble's 2.8.30-0ubuntu0.24.04.2 behaves the same way.)

[Suggested fix]
Only treat the line as too long when there really is a full buffer, e.g.
require a non-empty, allocated source buffer (b_size(srcbuf) != 0 and
b_data(srcbuf) != 0, or b_full()) before reporting the error. Alternatively,
drop the backport on 2.4 if the original loop cannot occur there.

[Workaround]
Downgrade to 2.4.30-0ubuntu0.22.04.2 and hold it:
    apt install --allow-downgrades haproxy=2.4.30-0ubuntu0.22.04.2
    apt-mark hold haproxy

[Regression potential]                                                   
High for any jammy HAProxy fronting HTTP/1.1 servers that use chunked
transfer-encoding, which is very common.

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (none):** Since the team's last comment (fix for the USN-8972-1 regression uploaded to the security team PPA, reporters asked to test), the only new activity is "me too" affect marks and subscriptions; the same symptom on the same jammy version. The bug is assigned to mdeslaur, fix pending release, so no human action is needed.

Thought process

precheck (done): route update: assigned to mdeslaur
review-update (done): none: Since the team's last comment (fix for the USN-8972-1 regression uploaded to the security team PPA, reporters asked to test), the only new activity is "me too" affect marks and subscriptions; the same symptom on the same jammy version. The bug is assigned to mdeslaur, fix pending release, so no human action is needed. (tools: submit_update_review; 6383 in / 2923 out tokens)

LP: #2165160 SPF handling in Exim4 incorrectly quotes the email address note

Package	exim4
Release	DSRN
Status	Fix Committed
Prio	Undecided
Assignee	hectorcao
Updated	2026-11-04
Flags	reply pending verification needed

Notes

Description

[ Impact ]

The exim4-config package ships an optional SPF check in the recipient ACL
(/etc/exim4/conf.d/acl/30_exim4-config_check_rcpt, enabled via the
CHECK_RCPT_SPF macro together with the spf-tools-perl package). It calls the
external spfquery.mail-spf-perl helper via Exim's ${run} expansion:

    condition = ${run{/usr/bin/spfquery.mail-spf-perl \
                   --ip ${quote:$sender_host_address} \
                   --scope mfrom \
                   --identity ${quote:$sender_address}} ...

The envelope sender is wrapped in ${quote:...}, ${run} splits its command string into arguments *before* expansion rather than after. As a result, the double quotes that ${quote:} inserts around the address are passed to spfquery literally, e.g. the --identity argument becomes:

    "user@example.com"

spfquery cannot parse a domain out of the quoted string, so instead of
returning the real SPF verdict it returns "none" (exit code 6) for every
message. Because the ACL only rejects on exit code 1 (fail), the deny can
never fire: SPF enforcement is silently non-functional for everyone who has
enabled CHECK_RCPT_SPF. No mail is ever rejected or marked on the basis of
SPF, and every message is stamped "Received-SPF: none" regardless of the
sender's actual SPF policy.

[ Test Plan ]

On an affected system:

1. Install the SPF helper and enable the check:
     $ sudo apt install spf-tools-perl
     $ echo 'CHECK_RCPT_SPF=1' | sudo tee -a /etc/exim4/exim4.conf.localmacros
     $ sudo update-exim4.conf

2. Simulate an inbound SMTP session from a known-good sender IP
   (209.85.128.1 is a genuine Google outbound host) using a sender whose
   domain publishes SPF:

     exim4 -d -bhc 209.85.128.1 <<'EOF'
     helo me
     mail from:<someone@gmail.com>
     rcpt to:<postmaster@localhost>
     quit
     EOF

3. In the debug output, inspect the "direct command after expansion" block
   and the generated Received-SPF header.

   Without the fix (broken):
     argv[6] = '"someone@gmail.com"'        <- literal quotes
     Received-SPF: none ...                  <- wrong; gmail.com publishes SPF

   With the fix (correct):
     argv[6] = 'someone@gmail.com'
     Received-SPF: pass ...                  <- real gmail.com policy evaluated

   gmail.com always publishes an SPF record, so a result of "none" is itself
   proof the query failed. A "pass" (from a legitimate Google IP) confirms
   spfquery is now evaluated correctly.

[ Where problems could occur ]

The change only removes the two ${quote:...} wrappers from the spfquery
command line; the ACL decision logic (deny on fail, defer on temperror, the
Received-SPF header mapping, and the error-logging warn) is unchanged.

- The affected block is behind the CHECK_RCPT_SPF macro, which is undefined
  by default, so the default configuration is unaffected and the vast
  majority of installations see no change at all.

- Only sites that have explicitly enabled CHECK_RCPT_SPF and installed
  spf-tools-perl are touched. For them the change is strictly a fix: a
  previously dead check begins functioning. Such sites should be aware that
  SPF rejection will now actually take effect, so a misconfigured local SPF
  setup could start rejecting mail that was previously (incorrectly) always
  accepted.

- This is a configuration-file (conffile) change only; no binary or daemon
  behaviour is altered.

[ Other Info ]


-----
/etc/exim4/conf.d/acl/30_exim4-config_check_rcpt installed by exim4-config.

Line 289:  --identity ${quote:$sender_address}} \

This puts "" around the email address and the IP address and then Exim itself puts '' around each parameter so the email_address becomes '"user@example.co.uk"'.  This causes spfquery to fail.

You can verify this with:

$ '/usr/bin/spfquery.mail-spf-perl' '--ip' '"1.1.1.1"' '--identity' '"user@example.co.uk"'

Corrected:

$ '/usr/bin/spfquery.mail-spf-perl' '--ip' '1.1.1.1' '--identity' 'user@example.co.uk'

For best effect, use a valid email address.

Fix (remove the ${quote: functions):

   condition = ${run{/usr/bin/spfquery.mail-spf-perl \
                   --ip $sender_host_address \
                   --scope mfrom \
                   --identity $sender_address} \
                   {no}{${if eq {$runrc}{1}{yes}{no}}}}

If you use a static exim4.conf, this ACL will surface the issue:

warn   condition = ${run{/usr/bin/spfquery.mail-spf-perl --ip $sender_host_address --identity $sender_address}{yes}{yes}}
logwrite  = Output of spfquery: $value rc: $runrc

Test with:

$ exim4 -d -bhc 1.1.1.1
helo me
mail from:user@example.co.uk
rcpt to:user@example.co.uk

(scroll back up until you find the result of the command expansion and the logwrite)

Docs:
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html (search for ${run)

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: exim4-config 4.97-4ubuntu4.7
ProcVersionSignature: Ubuntu 6.8.0-138.138-generic 6.8.12
Uname: Linux 6.8.0-138-generic x86_64
ApportVersion: 2.28.3-0ubuntu0.1
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Wed Aug 26 17:03:23 2026
PackageArchitecture: all
SourcePackage: exim4
UpgradeStatus: Upgraded to noble on 2025-04-14 (499 days ago)

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Update review (none):** The new events are just the standard SRU acceptance comments for noble-proposed (4.97-4ubuntu4.9) and resolute-proposed (4.99.1-1ubuntu1.6); the status and verification-needed tags are already correct and nothing new requires a human.

Thought process

precheck (done): route update: status Fix Committed, Fix Released; assigned to hectorcao; hectorcao commented on 2026-10-06; tag verification-needed-noble, verification-needed-resolute
review-update (done): none: The new events are just the standard SRU acceptance comments for noble-proposed (4.97-4ubuntu4.9) and resolute-proposed (4.99.1-1ubuntu1.6); the status and verification-needed tags are already correct and nothing new requires a human. (tools: submit_update_review; 4358 in / 134 out tokens)

LP: #2153488 Backport openvpn for stonking cycle note

Package	openvpn
Release	DRNJ
Status	Fix Released
Prio	Undecided
Assignee	lvoytek
Updated	2026-11-04
Flags	reply pending

Notes

Description

This bug tracks an update for the OpenVPN package, moving to versions:

* Resolute (26.04): OpenVPN 2.7.7
* Noble (24.04): OpenVPN 2.6.23

These updates include bug fixes following the SRU special case documentation at https://documentation.ubuntu.com/sru/en/latest/reference/exception-OpenVPN-Updates

Note that openvpn does not have an accepted micro-release exception. However, the SRU team has agreed to consider further releases given a full knowledge and possible mitigation of backwards-incompatible changes. See https://lists.ubuntu.com/archives/ubuntu-release/2023-July/005688.html

[Upstream Changes]

2.7.1-2.7.7

Bug Fixes:

Fix usage of --lport inside a connection block.
Avoid breaking private-key passphrases of length >= 64.
Fix obscure ASSERT() crash on TCP connects with TAP and no IP config.
Make DCO work on Linux on big-endian systems.
Fix --management-query-passwords together with --auth-user-pass file.
Fix use-after-free of DNS options on client connect.
Fix memory leak in dns_server_addr_parse.
Improve multi-socket UDP event handling.
Fix port-share and multi-socket interaction.
Ensure a pushed tun-mtu is no lower than TUN_MTU_MIN.
Refuse incoming HARD RESET packets with a non-zero packet id.
Correctly calculate packet id size with the epoch data format.
Correct the minimum packet length check for 802.1Q tagged packets.
Make key state desync recoverable.
Make --x509-username-field work with mbedTLS.
Avoid letting --stale-routes-check delete permanent routes.
Do not adjust UDP checksum if zero.
Avoid resetting the HMAC key on every packet.
Do not queue control ciphertext while a packet is still queued.
Validate netlink replies against the request.

CVE Fixes - already available as patches in Ubuntu:

CVE-2026-35058: Server ASSERT() on a malformed packet with a valid tls-crypt-v2 key.
CVE-2026-40215: Race condition in the TLS handshake that could leak packet data from a previous handshake.
CVE-2026-11771: 1-byte buffer overrun on NTLMv2 proxy responses.
CVE-2026-12932: Memory leak in tls-crypt-v2 client key handling.
CVE-2026-12996: Use-after-free in ack_write_buf().
CVE-2026-13117: Use-after-free in tls_wrap_reneg().
CVE-2026-13122: Server crash on a malformed auth-token with --auth-gen-token external-auth.
CVE-2026-13698: Memory leak from tls-crypt-v2 keys being set up twice.
CVE-2026-84471: Possible double-free in the lame duck case (check_session_buf_not_used).
CVE-2026-84732: Unbounded reliable TLS timeout / acks for packets that cannot be outstanding.

2.6.20-2.6.23

Bug Fixes:

Stop periodic bytecount output when management client disconnects.
Make DCO work on big-endian architectures.
Fix DCO kernel notifications getting lost.
Fix use-after-free of DNS options on client connect.
Ensure a pushed tun-mtu is no lower than TUN_MTU_MIN.
Refuse incoming HARD RESET packets with a non-zero packet id.
Correct the minimum packet length check for 802.1Q tagged packets.
Make key state desync recoverable.
Do not trust the peer's request to resend the wrapped client key.

CVE Fixes match above - already available as patches in Ubuntu:

The upstream changelog is available at https://community.openvpn.net/ReleaseHistory
Detailed release notes:
https://github.com/OpenVPN/openvpn/blob/release/2.7/Changes.rst
https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst

[Test Plan]

DEP-8 Tests:
server-setup-with-ca - creates and tests an OpenVPN server setup with its own certificate authority
server-setup-with-static-key - creates and tests an OpenVPN server setup using a static key for authentication

See https://documentation.ubuntu.com/sru/en/latest/reference/exception-OpenVPN-Updates/#qa for additional testing information.

[Regression Potential]

Upstream has an extensive build and integration test suite. So regressions would likely arise from a change in interaction with Ubuntu-specific integrations.

Backwards-incompatible changes:

Going through commits in 2.6.x, I found no backwards-incompatible changes for noble.

As for 2.7.x, I found one change that could cause existing configs to be denied:
In 2.7.4 no-op --enable-strict and --enable-strict-options configure flags were removed.

[Other Info]

Previous backports:
(LP: #2127658)
(LP: #2073318)
(LP: #2040467)
(LP: #2004676)

AI analysis

Route	update
Suggested status	no-change
Suggested tags	none

Analysis

**Verdict: process.** This is an SRU/backport tracking bug for openvpn micro-releases (2.7.7 for Resolute, 2.6.23 for Noble), filed by a team member as their own work item with a full test plan and regression analysis.

Thought process

precheck (done): route update: status Fix Released, In Progress; assigned to lvoytek
review-update (done): escalate: The security team (enr0n) linked CVE-2026-84790 and set noble/resolute to Incomplete, noting the CVE-2026-84790.patch added in the October security uploads (2.6.19-0ubuntu0.24.04.5, 2.7.0-1ubuntu1.4) appears to be dropped from the backport uploads without any changelog mention — my changelog search confirms only the security uploads reference the CVE. This needs re-triage: the assignee must verify whether upstream 2.6.23/2.7.7 include the null-byte certificate-subject fix, or restore the patch before these SRUs can proceed. (tools: lp_get_bug, pkg_changelog x2, submit_update_review; 9853 in / 2034 out tokens)
validate-report (done): verdict process: This is an SRU/backport tracking bug for openvpn micro-releases (2.7.7 for Resolute, 2.6.23 for Noble), filed by a team member as their own work item with a full test plan and regression analysis. (tools: submit_validation; 5298 in / 154 out tokens)

Triage 2026-11-04

Launchpad 13

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

AI analysis

GitHub 1

Description

AI analysis

Discourse 1

Description

AI analysis

Proposed 3

Description

AI analysis

Description

AI analysis

Description

AI analysis

Repo	canonical/ubuntu-static-reports-operator
Release	—
Status	merged
Prio	—
Assignee	—
Updated	2026-11-04

Category	project/server
Release	—
Status	1 changed
Prio	—
Assignee	—
Updated	2026-11-04

Versions	3.14.7-3 → 3.14.8-1
Release	—
Status	blocked
Prio	—
Assignee	—
Updated	2026-10-30

Versions	8.20.0-2ubuntu11.1 → 8.23.0-1ubuntu1
Release	—
Status	blocked
Prio	—
Assignee	—
Updated	2026-10-30

Versions	5.0.2-1build2 → 5.0.2-1build3
Release	—
Status	blocked
Prio	—
Assignee	—
Updated	2026-10-31