[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191231220724.GA118765@mit.edu>
Date: Tue, 31 Dec 2019 17:07:24 -0500
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: linux-ext4@...r.kernel.org
Subject: Inconsistent use of string/non_strings in mmp_struct
While clearing some compiler in e2fsprogs, I noticed that we are a bit
inconsistent about the mmp_nodename and mmp_bdevname fields, and
whether they are guaranteed to be null terminated or not. The kernel
is using them in some printf contexts where it's assumed they are null
terminated; but in other places, we have been filling them such that
if the string is exactly 64 or 32 bytes, they will *not* necessarily
be null terminated.
This is potentially a problem both in the kernel as well as in
e2fsprogs. I propose that we solve this problem by assuming that they
*are* null terminated. But that means that if there are node names
which are exactly 64 bytes long, or block device names which are
exactly 32 bytes long, badness could happen.
On the other hand, we kind of have this problem already, since in the
kernel, we are using memcmp when comparing mmp_nodename, but in
e2fsprogs userspace, we are using gethostbyname and there is no
guarantee that bytes beyond the terminating NULL have been cleared.
As a result I'm not sure the interlock between e2fsprogs and the
kernel works in all cases anyway.
Or we could go the other way, and try to fix all of the locations
which are accessing and writing mmp_nodename and mmp_bdevname so that
they are considered non-strings which are NULL padded.
Andreas, do you have any preferences here?
- Ted
Powered by blists - more mailing lists