linux-kernel - Re: Mount options may be silently discarded

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, 28 Sep 2020 19:17:33 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Dmitry Kasatkin <dmitry.kasatkin@...il.com>
Cc:     David Laight <David.Laight@...lab.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Mount options may be silently discarded

On Mon, Sep 28, 2020 at 09:00:54PM +0300, Dmitry Kasatkin wrote:

> But why "we" should allow "discarding" failed part instead of failing
> with EFAULT as a whole?

Because there might very well be absolutely legitimate users of mount(2)
passing it something smaller than 4Kb immediately followed by an unmapped
area.

What can mount(2) do?  It can't go up to the first \0 and stop there,
thanks to filesystems (NFS) that want to get struct some_shite filled
by userland.  It can't require the entire 4Kb from the pointer passed
to mount(2) to be mapped and readable, simply because passing it
a string literal for e.g. ext4 mount can violate that requirement,
not to mention the result of strdup(3)/asprintf(3)/etc.

And it can't even tell which semantics to use by looking at the
filesystem type - NFS allows both the string and binary structure for
options.