linux-kernel - Re: [PATCH] vfs: fix bug when opening a file with O_DIRECT on a file system that does not support it will leave an empty file

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]

Message-ID: <YdOru5u/Vs2+ns7B@zeniv-ca.linux.org.uk>
Date:   Tue, 4 Jan 2022 02:06:51 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Qinghua Jin <qhjin_dev@....com>
Cc:     Colin Ian King <colin.king@...onical.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: fix bug when opening a file with O_DIRECT on a file
 system that does not support it will leave an empty file

On Tue, Jan 04, 2022 at 09:53:58AM +0800, Qinghua Jin wrote:
> Colin Ian King reported the following
> 
> 1. create a minix file system and mount it
> 2. open a file on the file system with O_RDWR | O_CREAT | O_TRUNC | O_DIRECT
> 3. open fails with -EINVAL but leaves an empty file behind.  All other open() failures don't leave the
> failed open files behind.
> 
> The reason is because when checking the O_DIRECT in do_dentry_open, the inode has created, and later err
> processing can't remove the inode:
> 
>         /* NB: we're sure to have correct a_ops only after f_op->open */
>         if (f->f_flags & O_DIRECT) {
>                 if (!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO)
>                         return -EINVAL;
>         }
> 
> The patch will check the O_DIRECT before creating the inode in lookup_open function.

NAK.  You are looking at ->a_ops of the parent directory.  Which might have nothing
whatsoever to do with that of a regular file created in it.

IOW, you've removed the check on the file we are opening and replaced it with
random check that just happens to yield negative on minixfs.