Linux Kernel Hardening: Ten Years Deep

Talk by @kees about the relevance of various Linux kernel vulnerability classes and the mitigations that address them.

Video: https://www.youtube.com/watch?v=c_NxzSRG50g
Slides: https://static.sched.com/hosted_files/lssna2025/9f/KSPP%20Ten%20Years%20Deep.pdf

All the slides at this meeting talk about how much time and effort "AI" would help us save, and all I want to do is point out how much time and effort I've sunk so far into keeping AI crawlers from DDoS'ing our infra.

@gregkh linters literally do their job better than a speculation machine

@ptesarik That's what `drivers/staging/` is for, we just took 10+ patches for that subsystem from new submitters yesterday. That's much easier to accomplish than trying to parse the output of an "AI tool" :)

@liw We assign 13 CVEs for Linux every single day. "Fame and fortune" is not something that happens for any of those reports, as a CVE is trivial to get if you actually want to just fix a kernel bug for real.

Days since an "AI found security bug" turned out to be totally false due to the inability of the tool to actually parse C code: 0

I'm seeing multiple of these type of "reports" per week now for Linux. Why do people think that an LLM can somehow do better than a compiler and also not even test their proposed changes to verify they even do anything?

{sigh}

@codonell @brauner Yes, just add them at the end.

And we don't use the "(cherry picked from..." text in the kernel for stable backports, we do a much larger "commit XXXXXX upstream" at the top of the changelog text to make it easier for tools to catch.

@brauner @codonell That is correct, in the kernel we do NOT clear any of them out, only add new ones as that would "erase" the work that the original developers/reviewers did on the original change, which isn't a kind thing to do in my opinion.

@nitrokey Thanks, will do!

The second hardest thing in working in an open source developer community is learning who to ignore, be it in patch reviews or other places.

The hardest thing in working in an open source community is realizing that you are the one that everyone is ignoring.

@totenlegionChris As the other key works, AND the command line tool test passes with the bad key, yes, the device nodes are correct.

@brauner Yeah, but they are out of stock :(

@brauner No idea, I just went and ordered a few more, and some solokeys as I really would like to just use USB C and not have a A->C converter to lug around.

Dear lazyweb. One of my nitrokey 3 devices seems to have “stopped working” when attempting to access the key in it. Running the command line tools seems to say all is good (i.e. nitrocpy nk3 test says all is fine) but yet ssh seems to hate it with an error of:

ssh_sk_sign: fido_dev_get_assert: FIDO_ERR_NO_CREDENTIALS

and it never even attempts to let me “push the button”.

It’s running the latest firmware. Any hints on what to attempt/test to debug this or should I just give up on the thing?

My backup key is working just fine, so it’s not the USB kernel code on my system that is the issue for once :)

@aho "Don't panic and just follow standard security reporting guidelines".

Yet another thing I never thought I would be doing as a kernel developer, talking about EU regulations with open source finance people...

@joshbressers indeed. I just find that pURL advocates sometimes forget this gap and there are even online forms now where the pURL is a mandatory field, which have prevented for example me to enter curl in some places because curl nor libcurl have no pURL. So I keep having to remind people...

341 of the 733 changes[1] picked up for #Linux 6.15.3 could theoretically have made it into #kernel 6.15-rc6[2], as they were committed to some subsystem tree by then already.

Those are the changes that @gregkh meant when he recently wrote "[…] might also spur maintainers/developers to get fixes into -final a bit more as well :)"[3] (screenshotted).

[1] https://lore.kernel.org/all/2025061942-premiere-surreal-fa53@gregkh/

[2] And thus could have seen two weeks of testing before 6.15 was released – instead of about 3 days that 6.15.3-rc1 was out.

[3] https://lore.kernel.org/all/2025061030-latticed-capacity-dc94@gregkh/

#LinuxKernel

The solo maintainer for libxml2 is no longer accepting embargoed vulnerability reports, citing the unsustainable burden as an unpaid volunteer. Security issues will be treated like any other bug report moving forward.

https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports #opensource #cybersecurity h/t @joshbressers

Reporting a „possible memory leak“ in a 7 year old curl version, because the RSS jumps from 6.2 to 7 MB once.

Could be.

But, dear reporter, we can only try our best to be a better curl *today*. There is no changing the past (hence the name).

We outstretch our hands to you! Come and live with us in the present! Let the ancestors rest and rejoyce among the living!

#curl