Hey,
On 31. Jan 2024, at 16:24, Petr Pisar <ppisar(a)redhat.com>
wrote:
Key information is code=128. That code is probably si_code member described in
sigaction(2). The manual lists a lot of values as constants. 128 value is
SI_KERNEL according to /usr/include/asm-generic/siginfo.h. It is documented
as "sent by the kernel from somewhere". It means the first signal does not
come a user space. It's genuinly generated by kernel. E.g. when the process is
killed for out-of-memory reason. However, in this case, I would expect kernel
to log this event into dmesg. E.g. out-of-memory killer is very verbose in
dmesg.
Strange thing is the second line. It reads that process 3211 (code=0 meads
SI_USER, "sent by kill, sigsend, raise") sent SIGKILL to 3257. It's
questionable how a process 3211 killed with the first signal can still emit
signals. A possible explanation is that the signals are procecessed
asychnously and evolution manages to dispatch the signal to bwrap before kernel
termites evolution because of the first signal. Or I misinterpret the
log.
Throwing some ideas out there, is it possible that evolution runs with a seccomp filter or
other BPF program configured to kill the process on violation, and that’s what’s happening
here?
For software that regularly deals with untrusted input, it doesn’t seem unreasonable that
the developers might have implemented something like that, and a seccomp kill might
actually look like that.
--
Clemens Lang
RHEL Crypto Team
Red Hat