Re: Strange DNS SRV traffic resulting from stat() in 1.8.13.2

> On Aug 26, 2025, at 5:11=E2=80=AFPM, Cheyenne Wills =
<[email protected]> wrote:
>=20
> Thank you Jeff and Marc for identifying the area that was causing a
> problem.
>=20
> The cause is a little more subtle than described. =20

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=20=

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.=20

The qstr.len might be the same length as strlen(qstr.name) but it is not=20=

in all cases and in particular it is not in the case which is leaking =
full=20
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