On Mi, 07.05.25 13:51, Mickaël Salaün (mic@xxxxxxxxxxx) wrote: > What if the task send a "fake" coredump and just after that really > coredump? There could be a race condition on the server side when > checking the coredump property of this pidfd. > > Could we add a trusted header to the coredump payload that is always > written by the kernel? This would enable to read a trusted flag > indicating if the following payload is a coredumped generated by the > kernel or not. With my systemd hat on I must say I don't really care if the coredump is "authentic" or not. The coredump is untrusted data anyway, it needs to be quarantined from systemd-coredump's PoV, there's no security value in distinguishing if some random user's process was sent to the handler because the user called raise(SIGSEGV) or because the user called connect() to our socket. The process is under user control in almost all ways anyways, they can rearrange its internals in almost any way already, play any games they want. It's of very little value if the receiving side can determine if the serialization of potential complete garbage was written out by the kernel or by the process' own code. Moreover, in systemd-coredump we these days collect not only classic ELF coredumps passed to us by the kernel, but also other forms of crashes. For example if a Python program dies because of an uncaught exception this is also passed to systemd-coredump, and treated the same way in regards to metadata collection, logging, storage, recycling and so on. Conceptually a python crash like that and a process level crash are the same thing for us, we treat them the same. And of course, Python crashes like this are *inherently* a userspace concept, hence we explicitly want to accept them. Hence even if we'd be able to distinguish "true" from "fake" coredumps we'd still not care or change our behaviour much, because we are *as* *much* interested in user-level crashes as in kernel handled crashes. Lennart -- Lennart Poettering, Berlin
