Hi Vegard,
On 08/19/2016 08:30 PM, Vegard Nossum wrote:
> 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()?
No reason that I can see. Just a little more work to be done in the
code, I think.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
