Windows version of SMB host: Windows Server 2022 Standard x64 Kernel: 6.3.13(upstream) CONFIG_CIFS_DFS_UPCALL In the function cifs_inval_name_dfs_link_error(), a check was added for tcon->origin_fullpath (3ae872de410751fe5e629e04da491a632d95201c). I believe it's unnecessary because when mounting a dfs name without ASCII characters, we always fail at this check and exit the function, leading to dfs namespaces not being mounted Steps to reproduce: 1. At Windows, create DFS namespace with name containing non-ASCII symbols (for example дфс) 2. mount -t cifs \\\\<smb_server>\\дфс /tmp/dfs -o domain=...,user=...,password=... result: mount error(2): No such file or directory Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) CIFS debug log: [Mon Jul 22 11:00:24 2024] CIFS: Status code returned 0xc0000033 STATUS_OBJECT_NAME_INVALID [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/smb2maperror.c: Mapping SMB2 status code 0xc0000033 to POSIX err -2 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/dfs_cache.c: dfs_cache_noreq_update_tgthint: path: \test.local\дфс [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: __cifs_put_smb_ses: ses_count=2 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: __cifs_put_smb_ses: ses ipc: \\test.local\IPC$ [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: cifs_put_tcon: tc_count=1 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: VFS: in cifs_put_tcon as Xid: 17 with uid: 0 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/smb2pdu.c: Tree Disconnect [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/fscache.c: cifs_fscache_release_super_cookie: (0x0000000000000000) [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: __cifs_put_smb_ses: ses_count=1 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: __cifs_put_smb_ses: ses ipc: \\DC.test.local\IPC$ [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: VFS: in __cifs_put_smb_ses as Xid: 18 with uid: 0 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/smb2pdu.c: disconnect session 00000000360c6881 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: __cifs_put_smb_ses: ses_count=1 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: __cifs_put_smb_ses: ses ipc: \\test.local\IPC$ [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: VFS: in __cifs_put_smb_ses as Xid: 19 with uid: 0 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/smb2pdu.c: disconnect session 00000000db1ddbb6 [Mon Jul 22 11:00:24 2024] CIFS: fs/smb/client/connect.c: VFS: leaving cifs_mount_put_conns (xid = 13) rc = 0 [Mon Jul 22 11:00:24 2024] CIFS: VFS: cifs_mount failed w/return code = -2
Created attachment 306605 [details] pcap file for wireshark
Created attachment 306606 [details] dmesg
Created attachment 306607 [details] patch
Please check if 6.10 (or 6.11-rc1 once it's out on Monday) is still affected
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #4) > Please check if 6.10 (or 6.11-rc1 once it's out on Monday) is still affected Alright, I will definitely check
(In reply to Gleb Korobeynikov from comment #5) > (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from > comment #4) > > Please check if 6.10 (or 6.11-rc1 once it's out on Monday) is still > affected > > Alright, I will definitely check Checked on 6.11-rc1. The reproduction issue happens identically.
(In reply to Gleb Korobeynikov from comment #6) > Checked on 6.11-rc1. The reproduction issue happens identically. Thx; I'd like to forward this by mail; can I CC you? this would expose your email to the public
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #7) > (In reply to Gleb Korobeynikov from comment #6) > > > Checked on 6.11-rc1. The reproduction issue happens identically. > > Thx; I'd like to forward this by mail; can I CC you? this would expose your > email to the public Yes, of course
Hi Gleb, Thanks for the report and reproducer. Sorry for the delay as I've been quite busy with some other stuff. The patch looks good as that check will always be true for a new @tcon during mount as @tcon->origin_fullpath will only get set after tree connecting to last share as well as checking if prefix paths are fully accessible from it. The problem seems worst than that because even with your patch, I still can't access any directories under the mounted share: # mount.cifs //w22-root1.zelda.test/дфс /mnt/1 -o domain=zelda.test,user=xxx,password=yyy,nohandlecache # ls /mnt/1 dir # cd /mnt/1/dir -bash: cd: /mnt/1/dir: No such file or directory Or if mounting the DFS share with a prefix path: # mount.cifs //w22-root1.zelda.test/дфс/dir /mnt/1 -o domain=zelda.test,user=xxx,password=yyy,nohandlecache mount error(2): No such file or directory Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) I've tested it with Windows 11 client and I don't see any STATUS_OBJECT_NAME_INVALID errors being returned from server when accessing directories and DFS links under the mounted share, which really indicates another bug in cifs.ko that we haven't handled, yet. By comparing the network traces from Windows 11 and cifs.ko client, I've noticed that cifs.ko is sending the filenames (e.g. w22-root1.zelda.test\дфс\...) in SMB2_CREATE requests with some trailing NULL bytes, which might explain why we're getting those weird STATUS_OBJECT_NAME_INVALID errors. This is happening only with DFS shares because we append the filenames with tree name for DFS path normalization as required by MS-SMB2.
(In reply to Paulo Alcantara from comment #9) > Hi Gleb, > > Thanks for the report and reproducer. Sorry for the delay as I've > been quite busy with some other stuff. > > The patch looks good as that check will always be true for a new @tcon > during mount as @tcon->origin_fullpath will only get set after tree > connecting to last share as well as checking if prefix paths are fully > accessible from it. > > The problem seems worst than that because even with your patch, I > still can't access any directories under the mounted share: > > # mount.cifs //w22-root1.zelda.test/дфс /mnt/1 -o > domain=zelda.test,user=xxx,password=yyy,nohandlecache > # ls /mnt/1 > dir > # cd /mnt/1/dir > -bash: cd: /mnt/1/dir: No such file or directory > > Or if mounting the DFS share with a prefix path: > > # mount.cifs //w22-root1.zelda.test/дфс/dir /mnt/1 -o > domain=zelda.test,user=xxx,password=yyy,nohandlecache > mount error(2): No such file or directory > Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel > log messages (dmesg) > > I've tested it with Windows 11 client and I don't see any > STATUS_OBJECT_NAME_INVALID errors being returned from server when > accessing directories and DFS links under the mounted share, which > really indicates another bug in cifs.ko that we haven't handled, yet. > > By comparing the network traces from Windows 11 and cifs.ko client, > I've noticed that cifs.ko is sending the filenames > (e.g. w22-root1.zelda.test\дфс\...) in SMB2_CREATE requests with some > trailing NULL bytes, which might explain why we're getting those weird > STATUS_OBJECT_NAME_INVALID errors. This is happening only with DFS > shares because we append the filenames with tree name for DFS path > normalization as required by MS-SMB2. Hi Paulo, Thank you for your response! Will you accept my patch with always positive verification for the new @tcon->origin_fullpath? I'll try to test this with Windows 11, I'll check the traces.
Hi Gleb, bugzilla-daemon@kernel.org writes: > Thank you for your response! Will you accept my patch with always positive > verification for the new @tcon->origin_fullpath? It's not up to me deciding whether or not to apply it as I'm not the upstream CIFS maintainer, but I'd rather have that check replaced with struct TCP_Server_Info *server = tcon->ses->server; ... spin_lock(&server->srv_lock); if (!server->leaf_fullpath) { spin_unlock(&server->srv_lock); return 0; } spin_unlock(&server->srv_lock); to avoid having this workaround executed in non-DFS paths. Can you test if the above also works for you? If so, please send a formal patch and I'll gladly review it. Thanks!
No objections to the patch idea so far but let's see it on the mailing list so can get review feedback
(In reply to Paulo Alcantara from comment #11) > Hi Gleb, > > bugzilla-daemon@kernel.org writes: > > > Thank you for your response! Will you accept my patch with always positive > > verification for the new @tcon->origin_fullpath? > > It's not up to me deciding whether or not to apply it as I'm not the > upstream CIFS maintainer, but I'd rather have that check replaced with > > struct TCP_Server_Info *server = tcon->ses->server; > ... > spin_lock(&server->srv_lock); > if (!server->leaf_fullpath) { > spin_unlock(&server->srv_lock); > return 0; > } > spin_unlock(&server->srv_lock); > > to avoid having this workaround executed in non-DFS paths. > > Can you test if the above also works for you? If so, please send a > formal patch and I'll gladly review it. > > Thanks! I'll check and write you the result.
Also duplicate here? https://bugzilla.kernel.org/show_bug.cgi?id=215440
Created attachment 306700 [details] proposed patch Paulo, this check helped me. I'm attaching this patch.
I have merged the patch into cifs-2.6.git for-next tentatively (as we wait for any additional testing or review feedback)
*** Bug 215440 has been marked as a duplicate of this bug. ***
Any updates on whether the patches addressed all the problems (and can be closed) - or whether additional fixes are needed.