I had some difficulty with the test kernel, because the installation command wanted to remove the running kernel, so I got a warning about it. I think there was some kind of conflict with the normal 6.5.0-15 kernel. In the meantime, the kernel has been upgraded to 6.5.0-17, so I removed all older versions and tried again, and I think I managed to do it in the end:
$ uname -a Linux rdiez-L2017 6.5.0-15-generic #15~22.04.1+TEST2049634v20240208b1-Ubuntu SMP PREEMPT_DYNAMIC Th x86_64 x86_64 x86_64 GNU/Linux This is the output from "journalctl --dmesg --follow": Feb 11 12:31:25 rdiez-L2017 kernel: FS-Cache: Loaded Feb 11 12:31:25 rdiez-L2017 kernel: Key type cifs.spnego registered Feb 11 12:31:25 rdiez-L2017 kernel: Key type cifs.idmap registered Feb 11 12:31:25 rdiez-L2017 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Feb 11 12:31:25 rdiez-L2017 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Feb 11 12:31:25 rdiez-L2017 kernel: CIFS: Attempting to mount //<redacted> This is the output from mount -l: //<redacted> on /home/rdiez/MountPoints/<redacted> type cifs (rw,noexec,relatime,vers=1.0,cache=strict,username=<redacted>,domain=<redacted>,uid=1000,noforceuid,gid=0,noforcegid,addr=<redacted>,file_mode=0666,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=61440,wsize=16384,bsize=1048576,echo_interval=4,actimeo=1,closetimeo=1,user=<redacted>) I didn't specify "wsize" (I never did), so it looks like it has automatically negotiated the wsize down to 16 KiB for that SMB 1.0 connection. I then copied my test text file to and from the server, and there was no data corruption this time. So the patch is a step forwards. I am still concerned though that the work-around the patch implements is needlessly unreliable, misleading and risks data corruption at the smallest user's mistake, despite repeated reasoning in the mailing list. I hope the kernel cifs guys find the real bug and fix it properly, so that this patch can be reverted soon. By the way, during data transfer, I also get many errors like this: Feb 11 12:41:01 rdiez-L2017 kernel: CIFS: VFS: SMB signature verification returned error = -13 Feb 11 12:41:11 rdiez-L2017 kernel: CIFS: VFS: SMB signature verification returned error = -13 ... I looked more carefully this time, and it happens when I read data back from the server. It looks like there is one such warning per read block, according to the negotiated rsize. But these errors are "normal" over the years. I am guessing that the SMB 1.0 support is not very well polished. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data Status in linux package in Ubuntu: In Progress Status in linux source package in Mantic: In Progress Status in linux source package in Noble: In Progress Bug description: [Impact] Upon installing the 6.5 HWE kernel on Jammy, users with a custom wsize set will see data destruction when copying files from their systems onto a cifs smb 1.0 mount. wsize defaults to 65535 bytes, but when set to smaller values, like 16850, users will see blocks of 16850 bytes copied over, followed by 3900 binary zeros, followed by the next block of data followed by more binary zeros. A workaround is to increase wsize, but this only works for small files, as any files larger than wsize will see the bug. Most users will want to use the 6.2 HWE kernel until this is fixed. [Testcase] Start two VMs, one for the server, and the other, the client. Server ------ $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client ------ $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu,vers=1.0,wsize=16850 //192.168.122.172/sambashare ~/share $ ( set -o pipefail && head --bytes=$(( 55 * 1000 )) /dev/zero | openssl enc -aes-128-ctr -nosalt -pass "pass:my-seed" -iter 1 | hexdump --no-squeezing --format '40/1 "%02x"' --format '"\n"' >"testdata.txt" ) $ sha256sum testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 testdata.txt Now copy the file to the share. Client ------ $ cp testdata.txt share/ Server ------ $ sha256sum sambashare/testdata.txt 9e573a0aa795f9cd4de4ac684a1c056dbc7d2ba5494d02e71b6225ff5f0fd866 sambashare/testdata.txt The SHA256 hash is different. If you view the file with less, you will find a block of wsize=16850 bytes, then 3900 bytes of binary zeros, followed by another wsize=16850 bytes, then 3900 bytes of binary zeros, etc. An example of a broken file is: https://launchpadlibrarian.net/712573213/testdata-back-from-server.txt [Where problems could occur] [Other info] Currently bisecting. Introduced in 6.3-rc1. Currently broken on mainline 6.8-rc3. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
