Commit e9fbe686 authored by Michael Ellerman's avatar Michael Ellerman

powerpc: Change syscall_get_nr() to return int

The documentation for syscall_get_nr() in asm-generic says:

 Note this returns int even on 64-bit machines. Only 32 bits of
 system call number can be meaningful. If the actual arch value
 is 64 bits, this truncates to 32 bits so 0xffffffff means -1.

However our implementation was never updated to reflect this.

Generally it's not important, but there is once case where it matters.

For seccomp filter with SECCOMP_RET_TRACE, the tracer will set
regs->gpr[0] to -1 to reject the syscall. When the task is a compat
task, this means we end up with 0xffffffff in r0 because ptrace will
zero extend the 32-bit value.

If syscall_get_nr() returns an unsigned long, then a 64-bit kernel will
see a positive value in r0 and will incorrectly allow the syscall
through seccomp.
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
Reviewed-by: default avatarKees Cook <keescook@chromium.org>
parent 1cb9839b
...@@ -22,10 +22,15 @@ ...@@ -22,10 +22,15 @@
extern const unsigned long sys_call_table[]; extern const unsigned long sys_call_table[];
#endif /* CONFIG_FTRACE_SYSCALLS */ #endif /* CONFIG_FTRACE_SYSCALLS */
static inline long syscall_get_nr(struct task_struct *task, static inline int syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
struct pt_regs *regs)
{ {
return TRAP(regs) == 0xc00 ? regs->gpr[0] : -1L; /*
* Note that we are returning an int here. That means 0xffffffff, ie.
* 32-bit negative 1, will be interpreted as -1 on a 64-bit kernel.
* This is important for seccomp so that compat tasks can set r0 = -1
* to reject the syscall.
*/
return TRAP(regs) == 0xc00 ? regs->gpr[0] : -1;
} }
static inline void syscall_rollback(struct task_struct *task, static inline void syscall_rollback(struct task_struct *task,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment