[OpenAFS-devel] Kernel BUG on Linux 6.5.3

[Michael Laß]

Hi,

Thanks for the update. That sounds good!

Am Freitag, dem 15.09.2023 um 22:11 -0400 schrieb MS Vitale:
> Hi Michael,
> 
> Just a quick note to let you know that we were able to duplicate this.
> The root cause is an interaction between Linux 6.5 CONFIG_FORTIFY_SOURCE=
=y string helpers and
> a recent change in OpenAFS 1.8.10 to use strlcpy, which is now fortified =
in your kernel.
> 

Ah, I guess this is related to Linux commit df8fc4e934c12b (kbuild:
Enable -fstrict-flex-arrays=3). With that, the name field in DirEntry
is not handled as a flexible array anymore but the size of 16 is
actually enforced by strlcpy.

> OpenAFS has always managed the name string for directory entries in a ver=
y quirky but
> ultimately memory-safe way.  However, due to the new interaction des=
cribed above,
> Fortify now sees any directory entry name longer that 16 chars as a buffe=
r overrun.
> In your case, this is triggered during cache manager initialization by th=
e first cell
> in CellServDB with a cell name longer than 16 characters.
> 
> I have fixed the specific kernel BUG you reported, and was able to bring =
up a
> working cell.  However, there are several additional paths where sim=
ilar issues in "long"
> directory entry names are still present.  Therefore, I'm still worki=
ng on finding and fixing those.
> I'll let you know when I think I've fixed them all and have something in =
gerrit for you to try.

Wouldn't the following be a relatively simple fix? I briefly tested it
(only on the client side) and it seemed to behave well. But of course,
my testing here is very limited.


diff --git a/src/dir/dir.h b/src/dir/dir.h
index f5c8eef42..a6ac70510 100644
--- a/src/dir/dir.h
+++ b/src/dir/dir.h
@@ -57,7 +57,7 @@ struct DirEntry {
     char length;               /* currently unused */
     unsigned short next;
     struct MKFid fid;
-    char name[16];
+    char name[];
 };
 
 struct DirXEntry {



Best regards,
Michael