[lewisgoddard]

The Problem

sysupdate writes the new usr verity signature over the old one without clearing the rest of the partition. If the new signature is shorter, the end of the old one is left behind. The partition then no longer parses, and the system can't mount /usr. Falling back to the previous boot entry fails the same way, because every signature partition is parsed at boot.

This used to be harmless because repart padded the split signature artifact to the full partition size. Since systemd 259.6 (in resolute-updates as 259.9 since Oct 19), repart trims that padding (systemd/systemd@b54ef83414). Upstream treats the overwrite as a sysupdate bug (systemd/systemd#43567). They fixed it with PartitionZeroFill= in 262.1, which isn't in the 259 we ship.

Our signatures change length because just genkey creates a new certificate every build with a random serial. About 1 in 256 serials encode one byte shorter because they start with 8x 0 bits, which makes the signature 1718 bytes instead of 1722.

History

• The jq change: on 2026-04-12, jq fixed CVE-2026-33948 ("Fix NUL truncation in the JSON parser", 6374ae0bcd) by rejecting input that contains NUL bytes.
• repart's response: ten days later, PR repart: trim NUL bytes from verity sig split artifact systemd/systemd#41771 trimmed the NULs from the split file, "so it's a valid text file". The PR doesn't consider sysupdate, which writes that same file into a partition.
• The sysupdate fallout: that gap is repart strips the NUL padding from the split verity-sig artifact, so a shorter signature leaves the previous one's tail behind systemd/systemd#43567, fixed months later in sysupdate (262.1).
• The stable backport: the trim was also backported to 259.6. So a cleanup for people running jq on these files changed what sysupdate writes to disk, within a stable release.

TL;DR

A series of changes has left us with Ubuntu Resolute carrying a sysupdate that breaks signed boots if the new key is ever shorter, so we need to make sure ours are always the same length by not letting the first bits be eight 0s.

[jumpyvi]

lgtm

[github-actions]

Installer builds for 226b63d

Do not use these installers for production systems. They are intended for testing purposes only. They will update to the latest PR build, which will break your install eventually.

Arch	ISO	Checksum
amd64	elementaryos-9.0-proposed-x86-64.20261023001449.iso	sha256
arm64	elementaryos-9.0-proposed-arm64.20261023001501.iso	sha256