Gnome has defaulted to Wayland for a long time, so it sounded more like you had an issue with a different desktop environment, not X11 vs Wayland

Gnome isn’t orthogonal to Wayland.

You’d need to check if you were using the X11 or Wayland session of Gnome

I would generally just set the RPATH to $ORIGIN in the ELF file

lsof just reads from /proc and gives you formatted output

https://github.com/lsof-org/lsof/blob/master/lib/dialects/linux/dproc.c#L297

You should probably enable debian-security at least…

They’re on 6.12.101

I will say the Rust stdlib seems to make TOCTOU bugs really easy to make for filesystem operations

But, yes, Ubuntu switching to a test project hurts it

BSDs are also monolithic kernels, just like Linux, macOS, and Windows NT

FreeBSD has been trying to make it easier to run as a desktop OS by supporting the Linux APIs so they can use the WiFi and Graphics drivers from Linux

OpenBSD handles security by supporting fewer features. E.g. they do not support Bluetooth as it’s an insecure protocol, and they disabled SMT due to the hardware bugs in AMD/Intel/ARM - so they are more secure, but slower

They’ll get loaded, even without root

Edit: to be clear, this advice is specific to Ubuntu. If you come across this and need advice for a different distro, message me or reply to this

Yes.

Ubuntu doesn’t follow upstream kernels, so they will have to make a custom backport for 6.17 to fix the kernel

It’s very unlikely you need the module that has the bug, so the mitigation should work for you

Just double check lsmod | grep aead

As long as that module is not loaded, and you have the kmod update that adds /etc/modprobe.d/disable-algif.conf you’re protected

The kmod change makes it so the affected module cannot be loaded, it was their initial workaround

The ones I was watching look like there’s an update as of an hour ago, but there wasn’t at the time of the post

Need to check Raspbian still, being on self hosting

They aren’t available on all releases - the people that found the issue didn’t really follow responsible disclosure, so distros didn’t have time to fix it

They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out

Giving a better solution is certainly useful.

I’d used initcall_debug before, but not initcall_blacklist

I’m working off the knowledge that OP is using a rolling release, so is likely fixed by that for them. (Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I’d expect Bazzite to have it too. If they’re using Debian Sid/Testing, it’s both fixed and a module)

If you’re using something else, this eBPF filter is probably your best bet https://github.com/Dabbleam/CVE-2026-31431-mitigation

Yeah… It seems like they only reached out to the kernel, and not to any distros…

They also disclosed after 37 days rather than the more standard 90 days for everyone to patch

Check uname -r

If you’re on 6.19.12 or newer (7.0.1 if they’ve already bumped to 7) you’re definitely safe

For others, it looks fixed in 6.18.22 6.12.85 6.6.137 6.1.170 5.15.204

If you don’t have a safe kernel, A better solution referenced below than a module blacklist is to set initcall_blacklist=algif_aead_init in your kernel boot parameters. There is not a generic way to do this across distros, so you will need to look it up for your case

~~If you don’t have the updated kernel, you can echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf and reboot.

That ensures the buggy module cannot be loaded until you have an updated kernel~~

Wait. So the flaw was in uutils, and this article reported it as a systemd bug…?

Debian on my personal computers and servers.

Ubuntu on my work desktop, RHEL on work’s servers

I wouldn’t consider Debian “Canonical”-y, it’s just what they happened to pick as their upstream.

I tried some of the atomic distros, but ran into too many problems. When I buy a new computer, I sometimes have to run Opensuse Tumbleweed or Arch to get new enough hardware support… Too lazy to rebuild my kernel and mesa at home

The software manager they’re using already looks like GNOME 3+

Why do people keep referencing this like it was merged…

It was specifically rejected