Kernel Mantainers are using AI and the kernel is panicking!

16 views
Skip to first unread message

jo...@jocadbz.xyz

unread,
Aug 21, 2025, 1:13:45 PMAug 21
to tec...@googlegroups.com

So turns out using AI on the kernel has finally led to the first major bug that Linus didn't saw.

If you're using CAP_SYS_RESOURCE, modern systemd, the following hexadecimal fucking crashes the lastest LTS kernel (6.12.43).
40 b7 40 c1 e7 18 83 ef 08 57 57 31 ff 40 b7 07 31 c0 b0 a0 48 89 e6 0f 05 5e ff ce 31 ff b0 21 0f 05

But why you ask?

The AI-generated code incorrectly sets RLIMIT_NOFILE to a value higher than nr_open, meaning that the process is allowed to allocate more file descriptors locally than system-wide, which, I already think you realized by now, is not allowed and panics the kernel.

Relevant snippet from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/kernel/sys.c?h=v6.12.43#n1477: (I'm borrowing lore.kernel's css, hope it doesn't fuck up for you guys...)
	if (new_rlim) {
		if (new_rlim->rlim_cur > new_rlim->rlim_max)
			return -EINVAL;
		if (resource == RLIMIT_NOFILE &&
				new_rlim->rlim_max > sysctl_nr_open)
			return -EPERM;
	}

There are a few more specific things but the core problem is that.
You can see the commit being introduced here: https://lore.kernel.org/all/202508181244...@linuxfoundation.org/

Absolutely hilarious honestly. Even funnier, the person who commited this is an engineer at Nvidia apparently.


Reply all
Reply to author
Forward
0 new messages