Re: Kernel BUG on Linux 6.5.3

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 very quirky but
> ultimately memory-safe way.  However, due to the new interaction described above,
> Fortify now sees any directory entry name longer that 16 chars as a buffer overrun.
> In your case, this is triggered during cache manager initialization by the 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 similar issues in "long"
> directory entry names are still present.  Therefore, I'm still working 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