> On Aug 26, 2025, at 5:11 PM, Cheyenne Wills <[email protected]> wrote: > > Thank you Jeff and Marc for identifying the area that was causing a > problem. > > The cause is a little more subtle than described.
I disagree. > The Linux 6.14 commit (5be1fa8abd7b049f51e6e98e75a37eef5ae2c296) that > was responsible for the OpenAFS commit > (0306f3fdac736e15620f5802bdce510d25bb2450) added a new parameters for > the dop.d_revalidate() function. The new parameter, 'name', is, as > mentioned a qstr, but the string that it points to is NUL > terminated as well (according to Linux's porting documentation). The qstr.name is NUL terminated to prevent broken code from running off the end of the allocated memory. > However the length of the qstr does match the "strlen" of the entire > string -- which is the root cause of the problem. The qstr.len might be the same length as strlen(qstr.name) but it is not in all cases and in particular it is not in the case which is leaking full paths via DNS queries. > Prior to the 0306f3fdac73 commit, OpenAFS's d_validate routine was using > the d_name.name from the dentry parameter. Using the d_name.name from > the dentry parameter fixes the behavior (basically it reverts part of > the 0306f3fdac73 change). I'm working on a patch for OpenAFS to > correct the problem. Using the d_name.name might prevent the leakage of full paths but doing so is wrong because the d_name.name field is not stable. You cannot even be sure that it has the right value when the openafs module is entered. The qstr is the value that the openafs module is being asked to revalidate. Jeffrey Altman _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
