From: Kees Cook

Sent: 17 June 2020 20:58
On Wed, Jun 17, 2020 at 03:35:20PM +0000, David Laight wrote:

quoted

From: Kees Cook

quoted

Sent: 16 June 2020 04:25

For both pidfd and seccomp, the __user pointer is not used. Update
__fd_install_received() to make writing to ufd optional. (ufd
itself cannot checked for NULL because this changes the SCM_RIGHTS
interface behavior.) In these cases, the new fd needs to be returned
on success.  Update the existing callers to handle it. Add new wrapper
fd_install_received() for pidfd and seccomp that does not use the ufd
argument.

...>

quoted

 static inline int fd_install_received_user(struct file *file, int __user *ufd,
 					   unsigned int o_flags)
 {
-	return __fd_install_received(file, ufd, o_flags);
+	return __fd_install_received(file, true, ufd, o_flags);
+}

Can you get rid of the 'return user' parameter by adding
	if (!ufd) return -EFAULT;
to the above wrapper, then checking for NULL in the function?

Or does that do the wrong horrid things in the fail path?

Oh, hm. No, that shouldn't break the failure path, since everything gets
unwound in __fd_install_received if the ufd write fails.

Effectively this (I'll chop it up into the correct patches):

Yep, that's what i was thinking...

Personally I'm not sure that it matters whether the file is left
attached to a process fd when the copy_to_user() fails.
The kernel data structures are consistent either way.
So sane code relies on catching SIGSEGV, fixing thigs up,
and carrying on.
(IIRC the original /bin/sh code called sbrk() in its SIGSEGV
handler instead of doing the limit check in malloc()!)

The important error path is 'failing to get an fd number'.
In that case the caller needs to keep the 'file *' or close it.

I've not looked at the code, but I wonder if you need to pass
the 'file *' by reference so that you can consume it (write NULL)
and return an error.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)