Q: "Why have you suddenly been reworking coredumping, Christian?"
A: "Because I'm a clown and also I had it with all the CVEs because we provide a **** API for userspace."

So now that @torvalds merged the pidfs and initial coredump work things are already better but I have more work there.

In other news, there's two new CVEs in userpace that should be gone completely by installing a pidfd into the umh or by using the coredump socket.

[1]: https://www.qualys.com/2025/05/29/apport-coredump/apport-coredump.txt

[2]: https://blog.qualys.com/vulnerabilities-threat-research/2025/05/29/qualys-tru-discovers-two-local-information-disclosure-vulnerabilities-in-apport-and-systemd-coredump-cve-2025-5054-and-cve-2025-4598

@ljs @torvalds I think APIs age and like many things in life they often age badly simply because no one could predict the use cases they would be subjected to. It will happen to mine as well I'm sure.

So I'm being a bit playful with the "**** API" here. I don't hate it, I just think it ran its course and we've not done something to replace it.

@brauner @ljs @torvalds no API is so bad that it couldn't be replaced with a worse one!

@ljs @vbabka @brauner @torvalds hail satan!!!

@brauner @torvalds haha this toot is now linked from a lwn article so everyone will find out you're a clown!

I have done custom backports of the patches to install a pidfd into the legacy usermodehelper coredump handler for v6.12, v6.6, v6.1, v5.14, v5.10, and v5.4.

So that all those kernels can defend against the Qualys vulnerabilities reported earlier this week in:

https://www.qualys.com/2025/05/29/apport-coredump/apport-coredump.txt

@gregkh should hopefully have not too much pain with these backports now. Otherwise it would've been rather unpleasant to do them.

Testing is of course very welcome!

https://lore.kernel.org/linux-fsdevel/20250602-eilte-experiment-4334f67dc5d8@brauner/T/#m03e7e205c913101dc452c391bf283661049ca494

@brauner @gregkh just a bit of a theoretical question, would the 4.x kernel be affected?

I guess you would recommend all 4.x kernel based devices to loose their internet privileges

@aho @gregkh I don't think we have the pidfd infrastructure on kernels that old. I don't remember when I did that work first tbh. So on such kernels one solution would be to add a custom patch that installs a FD to /proc/<PID>/ for the crashing process into the coredump handler.

@aho @gregkh that would be a completely custom patch and it would obviously only work if stuff such as apport/systemd-coredump would make use of this. And I doubt they would be open to use custom functionality of really old kernels.

@brauner @gregkh I think that can be a bit difficult as even if I can build the right kernel, it's the problem to get it into the device.

@aho @brauner Your "4.x" kernel is filled with so so so so so many unfixed security issues that this one is the very least of your problems.

Good news is that anyone using such a kernel can easily get root access so that they can patch the thing to not run a 4.x kernel anymore :)

@gregkh @brauner you have a good point there, didn't think of that, was more in the path of replacing old stuff with new ones.

Think I have a TV with 2.6 kernel, in case someone would be interested it sometimes don't turn on the screen, you need to turn it off and then on again, but it's yours for anyone who want to fetch it in southern part of Scandinavia.
Manual with schematics and remote.

@brauner @torvalds haha a new lwn article even quotes it!