@simonzerafa @alexanderkjall the Linux kernel security team did not tell distros

@fun @alexanderkjall It's minified rather than obfuscated, I think they did that just so they could say it was only 732 bytes.

It's also likely that they just asked an LLM to minify it, given that the whole article was so obviously AI-generated and not even proofread (it originally claimed to have been tested on RHEL 14.3, which does not exist)

@kemona_halftau cat --version

@0x6e6174 install termux and do it the normal way?

@kemona_halftau @Houl if there are multiple of these bots now at some point there's going to be a meow-loop

@kemona_halftau I wonder why you used a BOM with UTF-8 though. I'm assuming it's a weird microsoft/dotnet thing

@kemona_halftau it can't be worse than some of the other code I've seen (like a struct in C with 287 numbered boolean members because the author apparently must have forgotten about arrays)

@kemona_halftau for some reason performance in Firefox/LibreWolf is really terrible. I was getting 15-17 FPS on the fastest graphics setting and then I tried in Epiphany/GNOME Web and got >25 FPS on the fabulous graphics setting

also is there a way to listen on a unix socket instead of a TCP port?

@kemona_halftau for reasons™ (dotnet isn’t bootstrappable so it’s not packaged in guix) I’m running dotnet stuff on a server that doesn’t often reboot so stuff cluttering up /tmp is annoying. as a workaround I’ll wrap it in a user/mount namespace and give it its own private /tmp (which of course would break anything that relies on a shared /tmp if I use it for dotnet run but I don’t think OpenDiepix5 does that anyway):

/* SPDX-License-Identifier: GPL-3.0-or-later */

#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>
#include <sched.h>
#include <errno.h>
#include <sys/mount.h>

void write_proc_maps(uid_t uid, gid_t gid) {
  FILE *fp;

  fp = fopen("/proc/self/setgroups", "w");
  if (fp) {
    fprintf(fp, "deny");
    fclose(fp);
  } else perror("fopen setgroups");

  fp = fopen("/proc/self/uid_map", "w");
  if (fp) {
    fprintf(fp, "%d %d 1", uid, uid);
    fclose(fp);
  } else perror("fopen uid_map");

  fp = fopen("/proc/self/gid_map", "w");
  if (fp) {
    fprintf(fp, "%d %d 1", gid, gid);
    fclose(fp);
  } else perror("fopen gid_map");
}

int main(int argc, char **argv) {
  if (argc < 2) {
    fprintf(stderr, "Error: Not enough arguments: %d.\n", argc);
    return 1;
  }
  uid_t uid = geteuid();
  gid_t gid = getegid();
  if (unshare(CLONE_NEWUSER | CLONE_NEWNS)) {
    perror("unshare");
    return errno;
  }
  write_proc_maps(uid, gid);
  if (mount("none", "/tmp", "tmpfs", 0, NULL)) {
    perror("mount");
    return errno;
  }
  execvp(argv[1], &argv[1]);
  perror("execvp");
  return errno;
}

@kemona_halftau do you know if there's a way to make dotnet not litter my /tmp with temporary files that it never cleans up?

OpenWrt is still vulnerable to copyfail and doesn’t compile algif_aead as a module or include BPF-LSM support

Edit: it does, in fact, compile algif_aead as a module (kmod-crypto-user)

If you are as annoyed as me about the fancy CVE-2026-31431 website not actually mentioning what Kernel versions to update to (only mentioning the commit rev), I translated this for you by looking through the releases manually and checking if they contain the fix.

The following upstream kernel tags contain the fix:

6.6.137+
6.12.85+
6.18.22+
6.19.12+
7.0+

But of course your distro might also apply the patches on any other version, and they will hopefully provide that information.

Edit: added 6.6/6.12 versions

Quickly dove into the copy.fail exploit.

1. Yes, it's real.
2. Current chain can write any arbitrary content to any user-readable file (into the page cache).
3. Current chain relies on an available target suid binary that you can open() as a lowpriv user.
4. Current exploit relies on that binary being /bin/su and then being able to execve(/bin/sh, 0, 0) (which doesn't work on alpine, etc.). The former is easily replaced in the code. The latter needs a rebuilt payload ELF (also easy).

Want to make your system immune to copyfail (CVE-2026-31431) but compiled your kernel with CONFIG_CRYPTO_USER_API_AEAD=y so you can’t disable the module and don’t want to reboot? Use BPF-LSM to block AF_ALG sockets from being created!

/* SPDX-License-Identifier: GPL-2.0-or-later OR MIT */

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

#define EPERM 1
#define AF_ALG 38

char LICENSE[] SEC("license") = "Dual MIT/GPL";

SEC("lsm/socket_create")
int BPF_PROG(socket_create_block_af_alg, int family, int type, int protocol, int kern, int ret)
{
  if (ret) return ret;          /* don't override a previous denial */
  if (family == AF_ALG) return -EPERM;
  return 0;
}

Compile with clang -Wall -Wextra -Wno-unused-parameter -g -O2 -target bpf -c -o nocopyfail.o nocopyfail.c and load with bpftool prog load nocopyfail.o /sys/fs/bpf/nocopyfail autoattach (as root).

@famfo debian stable/oldstable/oldoldstable seems to still be vulnerable, no new kernel updates... I'll just prevent algif_aead from loading for now

@famfo why, is there a new privilege escalation vulnerability?

@fun @fossdd if someone revives GTK2 then hexchat can be revived too