2022-06-17 05:17:09

by Ian Kent

[permalink] [raw]
Subject: [PATCH 0/2] vfs: fix a couple of mount table handling problems

First, 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.

Second, when a filesystem is mounted with a name that starts with
a # the glibc finction getmentent() will interpret the leading #
as a comment so that the mount line will not appear in the output.

This is fixed by adding a # to the to be translated string in
fs/proc_namespace.c:mangle().

Signed-off-by: Ian Kent <[email protected]>
---

Ian Kent (1):
vfs: parse: deal with zero length string value

Siddhesh Poyarekar (1):
vfs: escape hash as well


fs/fs_context.c | 10 +++++++---
fs/proc_namespace.c | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)

--
Ian Kent


2022-06-17 05:46:38

by Ian Kent

[permalink] [raw]
Subject: [PATCH 2/2] vfs: escape hash as well

From: Siddhesh Poyarekar <[email protected]>

When a filesystem is mounted with a name that starts with a #:

# mount '#name' /mnt/bad -t tmpfs

this will cause the entry to look like this (leading space added so
that git does not strip it out):

#name /mnt/bad tmpfs rw,seclabel,relatime,inode64 0 0

This breaks getmntent and any code that aims to parse fstab as well as
/proc/mounts with the same logic since they need to strip leading spaces
or skip over comment lines, due to which they report incorrect output or
skip over the line respectively.

Solve this by translating the hash character into its octal encoding
equivalent so that applications can decode the name correctly.

Signed-off-by: Siddhesh Poyarekar <[email protected]>
Signed-off-by: Ian Kent <[email protected]>
---
fs/proc_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/proc_namespace.c b/fs/proc_namespace.c
index 49650e54d2f8..846f9455ae22 100644
--- a/fs/proc_namespace.c
+++ b/fs/proc_namespace.c
@@ -86,7 +86,7 @@ static void show_mnt_opts(struct seq_file *m, struct vfsmount *mnt)

static inline void mangle(struct seq_file *m, const char *s)
{
- seq_escape(m, s, " \t\n\\");
+ seq_escape(m, s, " \t\n\\#");
}

static void show_type(struct seq_file *m, struct super_block *sb)


2022-06-28 13:16:40

by Christian Brauner

[permalink] [raw]
Subject: Re: [PATCH 2/2] vfs: escape hash as well

On Fri, Jun 17, 2022 at 01:09:09PM +0800, Ian Kent wrote:
> From: Siddhesh Poyarekar <[email protected]>
>
> When a filesystem is mounted with a name that starts with a #:
>
> # mount '#name' /mnt/bad -t tmpfs
>
> this will cause the entry to look like this (leading space added so
> that git does not strip it out):
>
> #name /mnt/bad tmpfs rw,seclabel,relatime,inode64 0 0
>
> This breaks getmntent and any code that aims to parse fstab as well as
> /proc/mounts with the same logic since they need to strip leading spaces
> or skip over comment lines, due to which they report incorrect output or
> skip over the line respectively.
>
> Solve this by translating the hash character into its octal encoding
> equivalent so that applications can decode the name correctly.
>
> Signed-off-by: Siddhesh Poyarekar <[email protected]>
> Signed-off-by: Ian Kent <[email protected]>
> ---

Reviewed-by: Christian Brauner (Microsoft) <[email protected]>