Messages in this thread | | | Subject | Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size() | From | Vegard Nossum <> | Date | Fri, 19 Aug 2016 10:30:47 +0200 |
| |
On 08/19/2016 07:25 AM, Michael Kerrisk (man-pages) wrote: > The limit checking in pipe_set_size() (used by fcntl(F_SETPIPE_SZ)) > has the following problems: [...] > @@ -1030,6 +1030,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg) > { > struct pipe_buffer *bufs; > unsigned int size, nr_pages; > + long ret = 0; > > size = round_pipe_size(arg); > nr_pages = size >> PAGE_SHIFT; > @@ -1037,13 +1038,26 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg) > if (!nr_pages) > return -EINVAL; > > - if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) > - return -EPERM; > + account_pipe_buffers(pipe->user, pipe->buffers, nr_pages); > > - if ((too_many_pipe_buffers_hard(pipe->user) || > - too_many_pipe_buffers_soft(pipe->user)) && > - !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) > - return -EPERM; > + /* > + * If trying to increase the pipe capacity, check that an > + * unprivileged user is not trying to exceed various limits. > + * (Decreasing the pipe capacity is always permitted, even > + * if the user is currently over a limit.) > + */ > + if (nr_pages > pipe->buffers) { > + if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) { > + ret = -EPERM; > + goto out_revert_acct; > + } else if ((too_many_pipe_buffers_hard(pipe->user) || > + too_many_pipe_buffers_soft(pipe->user)) && > + !capable(CAP_SYS_RESOURCE) && > + !capable(CAP_SYS_ADMIN)) { > + ret = -EPERM; > + goto out_revert_acct; > + } > + }
I'm slightly worried about not checking arg/nr_pages before we pass it on to account_pipe_buffers().
The potential problem happens if the user passes a very large number which will overflow pipe->user->pipe_bufs.
On 32-bit, sizeof(int) == sizeof(long), so if they pass arg = INT_MAX then round_pipe_size() returns INT_MAX. Although it's true that the accounting is done in terms of pages and not bytes, so you'd need on the order of (1 << 13) = 8192 processes hitting the limit at the same time in order to make it overflow, which seems a bit unlikely.
(See https://lkml.org/lkml/2016/8/12/215 for another discussion on the limit checking)
Is there any reason why we couldn't do the (size > pipe_max_size) check before calling account_pipe_buffers()?
Vegard
| |