linux-kernel - Re: [REPOST PATCH v3 0/2] vfs: fix a mount table handling problem

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]

Message-ID: <bf2a24ee-fa0d-d93e-ba6a-f814a5f8641c@themaw.net>
Date:   Wed, 21 Sep 2022 13:35:48 +0800
From:   Ian Kent <raven@...maw.net>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Siddhesh Poyarekar <siddhesh@...plt.org>,
        David Howells <dhowells@...hat.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Carlos Maiolino <cmaiolino@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [REPOST PATCH v3 0/2] vfs: fix a mount table handling problem


On 21/9/22 12:38, Ian Kent wrote:
>
> On 21/9/22 09:20, Theodore Ts'o wrote:
>> On Tue, Sep 20, 2022 at 03:26:17PM +0800, Ian Kent wrote:
>>> Whenever a mount has an empty "source" (aka mnt_fsname), the glibc
>>> function getmntent incorrectly parses its input, resulting in reporting
>>> incorrect data to the caller.
>>>
>>> The problem is that the get_mnt_entry() function in glibc's
>>> misc/mntent_r.c assumes that leading whitespace on a line can always
>>> be discarded because it will always be followed by a # for the case
>>> of a comment or a non-whitespace character that's part of the value
>>> of the first field. However, this assumption is violated when the
>>> value of the first field is an empty string.
>>>
>>> This is fixed in the mount API code by simply checking for a pointer
>>> that contains a NULL and treating it as a NULL pointer.
>> Why not simply have the mount API code disallow a zero-length "source"
>> / mnt_fsname?
>
> Hi Ted,
>
>
> I suppose but it seems to me that, for certain file systems, mostly
>
> pseudo file systems, the source isn't needed and is left out ... so
>
> disallowing a zero length source could lead to quite a bit of breakage.

There's handling consistency too.


Ideally any empty string parameter will print "(none)" when listing

the proc mount tables. Mostly that happens in the proc code because

the field is NULL so if an empty string is specified due to having

to provide a positional parameter or for some other reason then

handling it by setting the zero length string to NULL in the mount

API is conveniently central. We could fix it in the proc code too

but then we might see cases get missed over time and we sacrifice

an opportunity to improve consistency.


To my mind continuing to allow it and dealing with what needs to be

done to make that work consistently seemed like the better long

term approach.


So based on that logic, sticky speaking, the ext patch shouldn't

retain the zero length string check but for now ...


>
>
> Ian
>