[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <165871154975.22404.9637671230578653457.stgit@donald.themaw.net>
Date: Mon, 25 Jul 2022 09:17:16 +0800
From: Ian Kent <raven@...maw.net>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: 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: [PATCH v3 0/2] vfs: fix a mount table handling problem
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.
Changes:
v3: added patch to fix zero length string access violation caused after
fs parser patch is applied.
v2: fix possible oops if conversion functions such as fs_param_is_u32()
are called.
Signed-off-by: Ian Kent <raven@...maw.net>
---
Ian Kent (2):
ext4: fix possible null pointer dereference
vfs: parse: deal with zero length string value
fs/ext4/super.c | 4 ++--
fs/fs_context.c | 17 ++++++++++++-----
fs/fs_parser.c | 16 ++++++++++++++++
include/linux/fs_context.h | 3 ++-
4 files changed, 32 insertions(+), 8 deletions(-)
--
Ian
Powered by blists - more mailing lists