Hide Forgot
Description of problem: See 'Steps to reproduce'. Version-Release number of selected component (if applicable): kernel-4.18.2-348.el8 How reproducible: Always. Steps to Reproduce: 1. Export d:\share on windows 2. On linux: # mount -t cifs -o username=<name> //<host>/share/subfolder/ /mnt 3. Attempt # mv /mnt/a /mnt/b Actual results: mv fails with ENOENT. Expected results: No failures. Additional info: From the network capture, in kernel-4.18.0-305-19.1.el8_4, we have: 5 0.018803 192.168.0.2 → 192.168.0.3 SMB2 458 Create Request File: user\asdf;SetInfo Request FILE_INFO/SMB2_FILE_RENAME_INFO NewName:user\qwer;Close Request 6 0.027076 192.168.0.3 → 192.168.0.2 SMB2 466 Create Response File: user\asdf;SetInfo Response;Close Response In kernel-4.18.0-348.el8, we have. 6 0.021708 192.168.0.2 → 192.168.0.3 SMB2 458 Create Request File: user\\qwer;SetInfo Request FILE_INFO/SMB2_FILE_RENAME_INFO NewName:user\\asdf;Close Request 7 0.026655 192.168.0.3 → 192.168.0.2 SMB2 466 Create Response File: user\\qwer;SetInfo Response, Error: STATUS_OBJECT_NAME_INVALID;Close Response The path being sent has a double slash in 8.5 that is absent in 8.4.
note that samba gets rid of leading, trailing, or multiple sequential '/' or '\\' characters, so this reproducer will require a windows server
Tested against rawhide (kernel-5.16.0-0.rc4.20211207gitcd8c917a56f2.30.fc36.x86_64), and it's the same situation. The patches against cifs between rc4 and rc6 (current upstream) don't show this bug correction. $ git log --oneline v5.16-rc4..HEAD -- fs/cifs/ 9de0737d5ba0 cifs: fix ntlmssp auth when there is no key exchange So I believe that upstream has this bug. Also, it seems that any mount where the prepath has more than one '\' between directories is affected, e.g. # mount -t cifs -o username=user //192.168.0.3/share/subfolder//subsub /mnt # touch /mnt/a # mv /mnt/a /mnt/b mv: cannot move '/mnt/a' to '/mnt/b': No such file or directory
Patch upstream: https://patchwork.kernel.org/project/cifs-client/patch/20211215030831.24058-1-trbecker@gmail.com/
v2 of the patch submitted. https://patchwork.kernel.org/project/cifs-client/patch/20211217182022.589857-1-trbecker@gmail.com/ I've found that multiple delimiters between UNC and prepath (//<unc>////<prepath) failed to mount the share. Also, there's a possible memory leak in the code that should be fixed now. Test script that I've been using. ~~~ #!/bin/bassh SERVER=192.168.0.3 UNC=//$SERVER/Users PATH1=user PATH2=Videos USER=user PASS='p4ssw0rd' umount /mnt echo 7 > /proc/fs/cifs/cifsFYI echo "func build_path_from_dentry_optional_prefix +p" > /sys/kernel/debug/dynamic_debug/control dmesg -C rm -fr /tmp/{cifs.pcap,streams.txt,dmesg.txt} tcpdump -i eth0 -w /tmp/cifs.pcap host $SERVER & tcpdump_pid=$! function testfn { echo Testing with DEVICE=$1 mount -t cifs -o username=$USER,pass="$PASS" $1 /mnt touch /mnt/a mv /mnt/a /mnt/b rm /mnt/a /mnt/b 2>/dev/null umount /mnt } testfn $UNC/$PATH1 testfn $UNC//$PATH1 testfn $UNC/$PATH1/ testfn $UNC/$PATH1/$PATH2/ testfn $UNC/$PATH1//$PATH2 testfn $UNC///$PATH1////$PATH2/// echo 0 > /proc/fs/cifs/cifsFYI echo "func build_path_from_dentry_optional_prefix -p" > /sys/kernel/debug/dynamic_debug/control kill $tcpdump_pid dmesg > /tmp/dmesg.txt for stream in $(tshark -r /tmp/cifs.pcap -Y smb2 -T fields -e tcp.stream | sort -u) ; do echo ===== $stream ===== tshark -r /tmp/cifs.pcap -Y tcp.stream==$stream done > /tmp/streams.txt ~~~ All tests passing on v2
Patch accepted upstream, hash a31080899d5fdafcccf7f39dd214a814a2c82626. Merge request opened for rhel-8, https://gitlab.com/redhat/rhel/src/kernel/rhel-8/-/merge_requests/1857 Setting the severity. This bug happens on upgrade, under specific conditions, breaking the proper function of systems that where working previously, so I feel like this is good for 'urgent'. Feel free to change it appropriately.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: kernel security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:1988