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

From: Ian Kent
Date: Wed Sep 21 2022 - 00:38:56 EST



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.


Ian