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  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:   Thu, 13 Aug 2020 12:41:55 -0600
From:   Jens Axboe <>
To:     Jann Horn <>, Alessio Balsini <>
Cc:     Miklos Szeredi <>,
        Nikhilesh Reddy <>,
        Akilesh Kailash <>,
        David Anderson <>,
        Eric Yan <>,
        Martijn Coenen <>,
        Palmer Dabbelt <>,
        Paul Lawrence <>,
        Stefano Duo <>,
        Zimuzo Ezeozue <>,
        kernel-team <>,
        linux-fsdevel <>,
        kernel list <>
Subject: Re: [PATCH v6] fuse: Add support for passthrough read/write

On 8/12/20 12:29 PM, Jann Horn wrote:
>> +       passthrough_inode = file_inode(passthrough_filp);
>> +
>> +       iocb->ki_filp = passthrough_filp;
> Hmm... so we're temporarily switching out the iocb's ->ki_filp here? I
> wonder whether it is possible for some other code to look at ->ki_filp
> concurrently... maybe Jens Axboe knows whether that could plausibly
> happen?

I looked into the io_uring use case, and we're using req->file (which is
the same as kiocb->ki_filp) after submission for the polled-IO case.
That's IOCB_HIPRI, not poll(2) related. So it's not safe for that case,
but that probably isn't supported by fuse. But something to keep in

In general, kiocb->ki_filp is used for setup, and then at IO completion.
That use case appears safe, as long as the ki_filp is restored before
->ki_complete() is called.

Only other exception should be the poll handlers. They arm at setup
time, which is still fine, but re-arm if we get triggered and the file
is still not ready. I _think_ this case is still fine without having
seen all of the bits for this use case, as we haven't actually called
read/write_iter at that point on it.

But in general, I'd say it looks a bit iffy to be fiddling with ki_filp.
Maybe use a new kiocb and stack them like that instead?

Jens Axboe

Powered by blists - more mailing lists