[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist

From: Christian Borntraeger
Subject: Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Date: Tue, 29 Nov 2022 10:52:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0

Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert:
* Marc Hartmayer (mhartmay@linux.ibm.com) wrote:
"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:

* Marc Hartmayer (mhartmay@linux.ibm.com) wrote:
The virtiofsd currently crashes on s390x. This is because of a
`sigreturn` system call. See audit log below:

type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 
subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 
arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" 
GID="root" ARCH=s390x SYSCALL=sigreturn

I'm curious; doesn't that mean that some signal is being delivered and
you're returning?  Which one?

code=0x80000000 means that the seccomp action SECCOMP_RET_KILL_PROCESS
is taken => process is killed by a SIGSYS signal (31) [1].

At least, that’s my understanding of this log message.

[1] https://man7.org/linux/man-pages/man2/seccomp.2.html

But isn't that the fallout rather than the cause ? i.e. seccomp
is sending a SIGSYS because the process used sigreturn, my question
is why did the process call sigreturn in the first place - it must
have received a signal to return from?

Good question. virtiofsd seems to prepare itself for

int fuse_set_signal_handlers(struct fuse_session *se)
     * If we used SIG_IGN instead of the do_nothing function,
     * then we would be unable to tell if we set SIG_IGN (and
     * thus should reset to SIG_DFL in fuse_remove_signal_handlers)
     * or if it was already set to SIG_IGN (and should be left
     * untouched.
    if (set_one_signal_handler(SIGHUP, exit_handler, 0) == -1 ||
        set_one_signal_handler(SIGINT, exit_handler, 0) == -1 ||
        set_one_signal_handler(SIGTERM, exit_handler, 0) == -1 ||
        set_one_signal_handler(SIGPIPE, do_nothing, 0) == -1) {
        return -1;

Given that rt_sigreturn was already on the seccomp list it seems
to be expected that those handlers are called.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]