How do I know it's plagiarized AI slop that evaded upstream reviewers? The well-written commit message is riddled with basic errors that nobody who actually produced the code through testing it would make: first, it does a setrlimit of RLIMIT_NOFILE that's higher than...

the nr_open it just set. That will fail immediately regardless of privilege level in setrlimit at: #n1477 class="text-blue-500 hover:underline" target="_blank" rel="noopener noreferrer">https://git.kernel.org/pub/scm...

Next, it tries to dup2 with a fd *higher* than the resource limit it just set, that too will fail immediately early in dup2 regardless of privilege level without calling alloc_fdtable or doing any allocations here: #n1357 class="text-blue-500 hover:underline" target="_blank" rel="noopener noreferrer">https://git.kernel.org/pub/scm...

It really looks like an LLM was just pointed at: https://git.kernel.org/pub/scm... and it failed to understand the system limitations and the relationship between the different values, but spit something out that "looked" similar, complete with the dup'd fd being offset by 64 from nr_open

But the important point is that this was supposedly code to reproduce a specific bug, a real one I had already tweeted about in January. But the bogus test tests nothing at all, it will simply fail 100% of the time without ever testing what it claimed. Worse than that...

because the "developer" didn't go through a real process producing the code and commit, slapping a stable@ on it, they never looked at what would happen to that commit on older kernels. It patched a function (alloc_fdtable()) that was changed in 6.13 to return ERR_PTR values...

On earlier kernels, alloc_fdtable() returns NULL on all errors, and callers will dereference any non-NULL return value. So when it got cherry-picked clean despite the obvious difference visible in diff context, you end up with a vuln in a core syscall.

There's no point in reporting this stuff because the vulnerability is simple: stable maintainers using AI who have no idea what they're doing and are using it as a substitute for the work everyone else assumes they've performed It'll keep happening until that bug's fixed.

@spendergrsec I'm surprised Linus didn't catch this and proceed to crash out on it

@FurbyPerson Oh no, that'd only be reserved for an 'outsider' who did the exact same thing.

@spendergrsec Hey Brad, this is really interesting. Can you point to the commit that caused this bug?

Hey... quick question, why are anime catgirls blocking my access to the Linux kernel? 😸 https://lock.cmpxchg8b.com/anu...

AMD accidentally posted FSR4's Source Code and then tried to delete it all LOL The repo https://github.com/GPUOpen-Lib... Commit history https://github.com/GPUOpen-Lib...

Virtualization almost didn’t happen. The entire concept of emulating multiple operating systems on commodity hardware; particularly x86, wasn’t taken seriously. Three students took a 1970s idea, published a “impractical” paper, and created the giant that is VMware:

*sigh* is it time for this meme again