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 _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel