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  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, 1 Aug 2020 10:39:00 -0700
From:   Linus Torvalds <>
To:     Tetsuo Handa <>,
        Andrea Arcangeli <>
Cc:     syzbot <>,
        syzkaller-bugs <>,
        linux-fsdevel <>,
        Linux Kernel Mailing List <>,
        Al Viro <>
Subject: Re: INFO: task hung in pipe_read (2)

On Sat, Aug 1, 2020 at 8:30 AM Tetsuo Handa
<> wrote:
> Waiting for response at .

I think handle_userfault() should have a (shortish) timeout, and just

The code is overly complex anyway, because it predates the "just return RETRY".

And because we can't wait forever when the source of the fault is a
kernel exception, I think we should add some extra logic to just say
"if this is a retry, we've already done this once, just return an

This is a TEST PATCH ONLY. I think we'll actually have to do something
like this, but I think the final version might need to allow a couple
of retries, rather than just give up after just one second.

But for testing your case, this patch might be enough to at least show
that "yeah, this kind of approach works".

Andrea? Comments? As mentioned, this is probably much too aggressive,
but I do think we need to limit the time that the kernel will wait for
page faults.

Because userfaultfd has become a huge source of security holes as a
way to time kernel faults or delay them indefinitely.


Download attachment "patch" of type "application/octet-stream" (1829 bytes)

Powered by blists - more mailing lists