Re: [regression 6.1.80+] "CIFS: VFS: directory entry name would overflow frame end of buf" and invisible files under certain conditions and at least with noserverino mount option

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Paulo,

On Thu, Apr 18, 2024 at 10:47:01AM -0300, Paulo Alcantara wrote:
> Salvatore Bonaccorso <carnil@debian.org> writes:
> 
> > On Wed, Apr 17, 2024 at 07:58:56PM -0300, Paulo Alcantara wrote:
> >> Hi Salvatore,
> >> 
> >> Salvatore Bonaccorso <carnil@debian.org> writes:
> >> 
> >> > In Debian we got two reports of cifs mounts not functioning, hiding
> >> > certain files. The two reports are:
> >> >
> >> > https://bugs.debian.org/1069102
> >> > https://bugs.debian.org/1069092
> >> >
> >> > On those cases kernel logs error
> >> >
> >> > [   23.225952] CIFS: VFS: directory entry name would overflow frame end of buf 00000000a44b272c
> >> 
> >> I couldn't reproduce it.  Does the following fix your issue:
> >> 
> >> diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
> >> index 4c1231496a72..3ee35430595e 100644
> >> --- a/fs/smb/client/smb2pdu.c
> >> +++ b/fs/smb/client/smb2pdu.c
> >> @@ -5083,7 +5083,7 @@ smb2_parse_query_directory(struct cifs_tcon *tcon,
> >>  		info_buf_size = sizeof(struct smb2_posix_info);
> >>  		break;
> >>  	case SMB_FIND_FILE_FULL_DIRECTORY_INFO:
> >> -		info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO);
> >> +		info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO) - 1;
> >>  		break;
> >>  	default:
> >>  		cifs_tcon_dbg(VFS, "info level %u isn't supported\n",
> >> 
> >> If not, please provide network trace and verbose logs.
> >
> > Yes that appears to fix the issue.
> 
> Thanks for quickly testing it.  So the above change indicates that we're
> missing 35235e19b393 ("cifs: Replace remaining 1-element arrays") in
> v6.1.y.
> 
> Can you test it now with 35235e19b393 backported without the above
> change?

Done. From the experiment in the avialable setup this seems to indeed
fix the issue. The commit can mostly be cherry-picked with one manual
whitespace caused fixup.

> > But as you say you are not able to reproduce the issue, I guess we
> > need to try to get it clearly reproducible first to see we face no
> > other fallouts?
> 
> I couldn't reproduce it in v6.9-rc4.  Forgot to mention it, sorry.

Ack understand.

> Yes, further testing would be great to make sure we're not missing
> anything else.

I'm still failing to provide you a recipe with a minimal as possible
setup, but with the instance I was able to reproduce the issue the
regression seems gone with cherry-picking 35235e19b393 ("cifs: Replace
remaining 1-element arrays") .

Regards,
Salvatore