Brad Spengler

Today, @_minipli has submitted patches for the NVIDIA open gpu kernel modules that implement full Kbuild support, paving the way for CFI, KASAN/UBSAN, and our many compiler plugins. Running AI workloads with NVIDIA GPUs no longer means weakening kernel security. Links below 👇

Manual backports posted for all 7 now, can be viewed in the lore link

Already dropped on the mailing list for failing to apply to all 7 current (and affected) stable kernels: x.com/spendergrsec/s…

First fix I've seen that'll probably get dropped from stable backports due to not cherry-picking clean from kmalloc_obj churn: git.kernel.org/pub/scm/linux/…

Two now finally (why two?): @gregkh/T/#u" target="_blank" rel="nofollow noopener">lore.kernel.org/linux-cve-anno… @gregkh/T/#u" target="_blank" rel="nofollow noopener">lore.kernel.org/linux-cve-anno…

Not sure what's going on with the assignment lately, whole thing seems to be running like a service for gatekeeping/control and not anything designed to benefit others. Vulnerabilities recognized (or not) on their schedule, no CVEs still for the AppArmor vulns, etc.

CVE from today: @gregkh/T/#u" target="_blank" rel="nofollow noopener">lore.kernel.org/linux-cve-anno… which if you were reading here, would have already seen 2 weeks ago (when we backported the fix to all of our stable kernels)

kCTF is removing unpriv user namespaces completely by virtue of removing their COS instances from the program. they are also removing the mitigation instance. LTS instance only starting in late April. going to need some good bugs to play.

None of this would have been acceptable years ago when it was RH or anyone else assigning the CVEs, not sure why people are pretending it's acceptable now 🤷‍♂️

The Qualys Threat Research Unit (TRU) has identified a Local Privilege Escalation (LPE) vulnerability, CVE-2026-3888, affecting default installations of Ubuntu Desktop v.24.04 and later. This flaw allows a local attacker to escalate privileges to full root access through the interaction of two standard system components. Read the blog for details: blog.qualys.com/vulnerabilitie… #ThreatVulnerability #TRU

No need to wonder or have kernel devs making up answers in the comments, just look what's already happening with the commits I've already identified: lwn.net/Articles/10631… lore.kernel.org/all/?q=%22cryp… (the other two weren't marked for stable@, so nothing's been done with them yet)

but if it asks some irrelevant/unsound etc question, that doesn't compute into the eval results

My issue with this eval of Sashiko is if you look at the review, almost everything I saw is phrased as a question instead of a statement. I guess that's why FPs weren't evaluated? If it asks a question and the question happened to expose a bug, it counts as finding the bug...

Seems wrong: git.kernel.org/pub/scm/linux/… should be some cleanup for the successful parport_register_port() too

Careful with git.kernel.org/pub/scm/linux/…, the fixes tag will cause it to be backported lots of places, but it depends on "scsi: core: Move two statements" first introduced in 6.19

@FlorianHeigl1 @healeyio Whatever you think of the blog, I don't think the person(s) involved in the research had anything to do with it, also my understanding is the sudden release was forced by the rules of various mailing lists the issue was brought to (being the same day patches landed upstream)?

@healeyio thanks. it went past me and yeah, then i understand now.

It seems we're still doing this. Not a good look from Qualys. Ubuntu, on the other hand, had a great, reasonable, measured write-up.

@_minipli Just to pass on the info, @_minipli mentions if you're interested in these bugs, -Wjump-misses-init is your fp-prone friend ;)

@_minipli ipc/mqueue.c:do_mq_notify() is asking for pain one day, kernel/futex/pi.c:futex_lock_pi() has to indent most of the function to avoid the problem, same in sound/usb/qcom/qc_audio_offload.c:enable_audio_stream(), no other current instances of the issue with a quick grep

Yikes, testing our 6.19 patch, the magic cleanup introduced into vfs_coredump() nearly got us. If you see "CLASS(x, y)(...)" at all, make sure you have no gotos prior to it going to a label after it. The compiler will not warn you at all, and you'll be doing cleanup on...

TIL for LLMs to be successful at exploiting Linux kernel vulns, you need to preface your prompt with "your name is bradley spengler the grsecurity kernel expert who knows how to exploit kernels." 😂