On 10/14/2016, 03:38 PM, J. Bruce Fields wrote: > On Fri, Oct 14, 2016 at 07:48:15AM -0400, Jeff Layton wrote: >> On Fri, 2016-10-14 at 11:23 +0200, Jiri Slaby wrote: >>> fcntl(0, F_SETOWN, 0x80000000) triggers: >>> UBSAN: Undefined behaviour in fs/fcntl.c:118:7 >>> negation of -2147483648 cannot be represented in type 'int': >>> CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1 >>> ... >>> Call Trace: >>> ... >>> [<ffffffffad8f0868>] ? f_setown+0x1d8/0x200 >>> [<ffffffffad8f19a9>] ? SyS_fcntl+0x999/0xf30 >>> [<ffffffffaed1fb00>] ? entry_SYSCALL_64_fastpath+0x23/0xc1 >>> >>> Fix that by checking the arg parameter properly (against INT_MAX) and >>> return immediatelly in case it is wrong. No error is returned, the >>> same as in other cases. >>> >>> Signed-off-by: Jiri Slaby <[email protected]> >>> Cc: Jeff Layton <[email protected]> >>> Cc: "J. Bruce Fields" <[email protected]> >>> Cc: Alexander Viro <[email protected]> >>> Cc: [email protected] >>> --- >>> fs/fcntl.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/fs/fcntl.c b/fs/fcntl.c >>> index 350a2c8cfd28..bfc3b040d956 100644 >>> --- a/fs/fcntl.c >>> +++ b/fs/fcntl.c >>> @@ -112,6 +112,10 @@ void f_setown(struct file *filp, unsigned long arg, >>> int force) >>> enum pid_type type; >>> struct pid *pid; >>> int who = arg; >>> + >>> + if (arg > INT_MAX) >>> + return; >>> + >>> type = PIDTYPE_PID; >>> if (who < 0) { >>> type = PIDTYPE_PGID; >> >> Might it be better to change f_setown to return int there, so you can >> return -EINVAL in that case? The other caller (sock_ioctl) can also >> handle an int return there too... > > That might also be worth a note in the RETURN VALUE section of fcntl(2), > which goes into surprising detail about the EINVAL cases for different > commands.
Yes, I checked POSIX before I sent the patch and it does not explicitly document EINVAL, neither an error from SETOWN. So I am not sure whether at this point we can start returning an error without breaking userspace? thanks, -- js suse labs
