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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 15 Oct 2018 16:21:09 +0200
From:   Jann Horn <jannh@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>,
        Miklos Szeredi <miklos@...redi.hu>,
        Jens Axboe <axboe@...nel.dk>, Jens Axboe <axboe@...com>
Cc:     kernel list <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org
Subject: Re: sys_tee() bug: after tee() of partial page, both pipes can merge,
 clobbering each other's data

On Mon, Oct 15, 2018 at 4:13 AM Jann Horn <jannh@...gle.com> wrote:
> I noticed the following behavior; basically, after copying part of a
> normal pipe buffer (anon_pipe_buf_ops) from pipe A to pipe B, both
> pipe A and pipe B can merge new writes into the existing page,
> clobbering each other's data:
>
> ============
> $ cat tee_test.c
> #define _GNU_SOURCE
> #include <fcntl.h>
> #include <unistd.h>
> #include <err.h>
> #include <stdio.h>
>
> int main(void) {
>   int pipe_a[2];
>   if (pipe(pipe_a)) err(1, "pipe");
>   int pipe_b[2];
>   if (pipe(pipe_b)) err(1, "pipe");
>   if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
>   if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
>   if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
>
>   char buf[5];
>   if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
>   buf[4] = 0;
>   printf("got back: '%s'\n", buf);
> }
> $ gcc -o tee_test tee_test.c
> $ ./tee_test
> got back: 'abxx'
> $
> ============
>
> splice_pipe_to_pipe() probably has the same problem?
>
> I'm not sure what the cleanest way to fix this would be. Replace
> anon_pipe_buf_ops with packet_pipe_buf_ops when copying a buffer? Or
> add a new buffer flag for marking a buffer as mergeable, and get rid
> of buf->ops->can_merge?

Actually, I'll just cook up a simple patch myself.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ