• Tycho Andersen's avatar
    riscv: fix seccomp reject syscall code path · af33d243
    Tycho Andersen authored
    If secure_computing() rejected a system call, we were previously setting
    the system call number to -1, to indicate to later code that the syscall
    failed. However, if something (e.g. a user notification) was sleeping, and
    received a signal, we may set a0 to -ERESTARTSYS and re-try the system call
    again.
    
    In this case, seccomp "denies" the syscall (because of the signal), and we
    would set a7 to -1, thus losing the value of the system call we want to
    restart.
    
    Instead, let's return -1 from do_syscall_trace_enter() to indicate that the
    syscall was rejected, so we don't clobber the value in case of -ERESTARTSYS
    or whatever.
    
    This commit fixes the user_notification_signal seccomp selftest on riscv to
    no longer hang. That test expects the system call to be re-issued after the
    signal, and it wasn't due to the above bug. Now that it is, everything
    works normally.
    
    Note that in the ptrace (tracer) case, the tracer can set the register
    values to whatever they want, so we still need to keep the code that
    handles out-of-bounds syscalls. However, we can drop the comment.
    
    We can also drop syscall_set_nr(), since it is no longer used anywhere, and
    the code that re-loads the value in a7 because of it.
    
    Reported in: https://lore.kernel.org/bpf/CAEn-LTp=ss0Dfv6J00=rCAy+N78U2AmhqJNjfqjr2FDpPYjxEQ@mail.gmail.com/Reported-by: default avatarDavid Abdurachmanov <david.abdurachmanov@gmail.com>
    Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
    Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    af33d243
ptrace.c 4.4 KB