On Mon, Dec 21, 2020 at 8:14 AM David Howells <dhowells@xxxxxxxxxx> wrote:
>
> CONFIG_FORTIFIED_SOURCE=y now causes an oops in strnlen() from afs (see
> attached patch for an explanation). Is replacing the use with memchr() the
> right approach? Or should I be calling __real_strnlen() or whatever it's
> called?
Ugh. No.
> AFS has a structured layout in its directory contents (AFS dirs are
> downloaded as files and parsed locally by the client for lookup/readdir).
> The slots in the directory are defined by union afs_xdr_dirent. This,
> however, only directly allows a name of a length that will fit into that
> union. To support a longer name, the next 1-8 contiguous entries are
> annexed to the first one and the name flows across these.
I htink the right fix would be to try to create a type that actually
describes that.
IOW, maybe the afs_xdr_dirent union could be written something like
union afs_xdr_dirent {
struct {
u8 valid;
u8 unused[1];
__be16 hash_next;
__be32 vnode;
__be32 unique;
u8 name[];
} u;
u8 extended_name[32];
} __packed;
instead, and have a big comment about how "name[]" is that
"16+overflow+next entries" thing?
I didn't check how you currently use that ->name thing (not a good
identifier to grep for..), so you might want some other model - like
using a separate union case for this "unconstrained name" case.
In fact, maybe that separate union struct is a better model anyway, to
act as even more of documentation about the different cases..
Linus
