linux-kernel - Re: [PATCH 7/7] pipe: read buffer limits atomically

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Jan 2018 14:27:42 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Willy Tarreau <w@....eu>,
        Mikulas Patocka <mpatocka@...hat.com>,
        "Luis R . Rodriguez" <mcgrof@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH 7/7] pipe: read buffer limits atomically

On Sun, Jan 7, 2018 at 9:35 PM, Eric Biggers <ebiggers3@...il.com> wrote:
> From: Eric Biggers <ebiggers@...gle.com>
>
> The pipe buffer limits are accessed without any locking, and may be
> changed at any time by the sysctl handlers.  In theory this could cause
> problems for expressions like the following:
>
>     pipe_user_pages_hard && user_bufs > pipe_user_pages_hard
>
> ... since the assembly code might reference the 'pipe_user_pages_hard'
> memory location multiple times, and if the admin removes the limit by
> setting it to 0, there is a very brief window where processes could
> incorrectly observe the limit to be exceeded.
>
> Fix this by loading the limits with READ_ONCE() prior to use.
>
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>

Acked-by: Kees Cook <keescook@...omium.org>

-Kees

> ---
>  fs/pipe.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/fs/pipe.c b/fs/pipe.c
> index 774cafd947dc..2e2349602815 100644
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
> @@ -605,12 +605,16 @@ static unsigned long account_pipe_buffers(struct user_struct *user,
>
>  static bool too_many_pipe_buffers_soft(unsigned long user_bufs)
>  {
> -       return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft;
> +       unsigned long soft_limit = READ_ONCE(pipe_user_pages_soft);
> +
> +       return soft_limit && user_bufs > soft_limit;
>  }
>
>  static bool too_many_pipe_buffers_hard(unsigned long user_bufs)
>  {
> -       return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard;
> +       unsigned long hard_limit = READ_ONCE(pipe_user_pages_hard);
> +
> +       return hard_limit && user_bufs > hard_limit;
>  }
>
>  static bool is_unprivileged_user(void)
> @@ -624,13 +628,14 @@ struct pipe_inode_info *alloc_pipe_info(void)
>         unsigned long pipe_bufs = PIPE_DEF_BUFFERS;
>         struct user_struct *user = get_current_user();
>         unsigned long user_bufs;
> +       unsigned int max_size = READ_ONCE(pipe_max_size);
>
>         pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL_ACCOUNT);
>         if (pipe == NULL)
>                 goto out_free_uid;
>
> -       if (pipe_bufs * PAGE_SIZE > pipe_max_size && !capable(CAP_SYS_RESOURCE))
> -               pipe_bufs = pipe_max_size >> PAGE_SHIFT;
> +       if (pipe_bufs * PAGE_SIZE > max_size && !capable(CAP_SYS_RESOURCE))
> +               pipe_bufs = max_size >> PAGE_SHIFT;
>
>         user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
>
> --
> 2.15.1
>



-- 
Kees Cook
Pixel Security