linux-kernel - Re: [PATCH] fs: sendfile handles O_NONBLOCK of out

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 7 May 2022 14:52:24 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Andrei Vagin <avagin@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>, stable@...nel.org,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] fs: sendfile handles O_NONBLOCK of out_fd

On Mon, 2 May 2022 00:01:46 -0700 Andrei Vagin <avagin@...il.com> wrote:

> Andrew, could you take a look at this patch?
> 
> Here is a small reproducer for the problem:
> 
> #define _GNU_SOURCE /* See feature_test_macros(7) */
> #include <fcntl.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <errno.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <sys/sendfile.h>
> 
> 
> #define FILE_SIZE (1UL << 30)
> int main(int argc, char **argv) {
>         int p[2], fd;
> 
>         if (pipe2(p, O_NONBLOCK))
>                 return 1;
> 
>         fd = open(argv[1], O_RDWR | O_TMPFILE, 0666);
>         if (fd < 0)
>                 return 1;
>         ftruncate(fd, FILE_SIZE);
> 
>         if (sendfile(p[1], fd, 0, FILE_SIZE) == -1) {
>                 fprintf(stderr, "FAIL\n");
>         }
>         if (sendfile(p[1], fd, 0, FILE_SIZE) != -1 || errno != EAGAIN) {
>                 fprintf(stderr, "FAIL\n");
>         }
>         return 0;
> }
> 
> It worked before b964bf53e540, it is stuck after b964bf53e540, and it
> works again with this fix.

Thanks.  How did b964bf53e540 cause this?  do_splice_direct()
accidentally does the right thing even when SPLICE_F_NONBLOCK was not
passed?

I assume that Al will get to this.  Meanwhile I can toss it
into linux-next to get some exposure and so it won't be lost.