For the benefit of the subscribers to this bug, who may not be following the corresponding e-mail thread in the linux-cifs mailing list:
This bug does not only affect SMB 1.0, but all SMB versions. It will probably bite you if you specify a wsize mount option with a number of bytes which is not a multiple of PAGE_SIZE (usually 4 KiB, but not always). You can find out what the page size on your system is with command "getconf PAGE_SIZE". You do not actually have full control of the write buffer size, as it is the result of a negotiation, so if the server happens to set a maximum that is not a multiple of PAGE_SIZE, and is lower than the maximum you requested, you will probably end up with data corruption. Fortunately, most modern servers appear to send unproblematic values, so that is why this bug was discovered only when connecting to an old SMB 1.0 server. There is a workaround for this bug. In my case, the connection negotiated a wsize of 16580, even though the server should actually default to 16644 bytes (?). I have specified a mount option of wsize=16384, which is the next multiple of 4 KiB downwards, and performed a quick test, and it looks fine. I'll shout here again if my data gets corrupted once more. -- 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: smb1: 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
