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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ