Hi R. Diez,
I had a bit of spare time, and took a closer look. I can reproduce the
issue, and I can see the zeros. It does indeed happen on every copy.
I tried 6.8-rc3, so it is still broken there. I will write to the
maintainer about getting this fixed as soon as I locate the commit that
introduced the issue.
So far I figured out that it has been broken since 6.3-rc1.
I'm currently bisecting between 6.2 and 6.3-rc1, will let you know what
I find in the next couple days.
Thanks,
Matthew
** Summary changed:
- SMB 1 broken in kernel 6.5.0.14.14~22.04.7
+ smb1: wsize blocks of bytes followed with binary zeros on copy, destroying
data
** Changed in: linux (Ubuntu Mantic)
Status: New => In Progress
** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Noble)
Status: New => In Progress
** Changed in: linux (Ubuntu Mantic)
Importance: Undecided => High
** Changed in: linux (Ubuntu Noble)
Importance: Undecided => High
** Changed in: linux (Ubuntu Mantic)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: linux (Ubuntu Noble)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Description changed:
- Hi all:
+ [Impact]
- I upgraded my Ubuntu yesterday and automatically got the newer Linux
- Kernel version 6.5.0-14-generic #14~22.04.1-Ubuntu. Previously, I was
- running kernel version 6.2 .
+ 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.
- I still have a legacy system on the network using SMB protocol version
- 1.0.
+ 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.
- With the new kernel version, copying files does not work reliably
- anymore. Some random byte blocks in the destination files are
- overwritten with binary zeros. It happens quite often.
+ A workaround is to increase wsize, but this only works for small files,
+ as any files larger than wsize will see the bug.
- This is not the first time the Linux guys temporarily break SMB protocol
version 1.0, see for example this bug report of mine:
- https://bugs.launchpad.net/ubuntu/+bug/2033732
+ Most users will want to use the 6.2 HWE kernel until this is fixed.
- I checked package linux-image-generic-hwe-22.04 with Synaptic, and now it
lists just 2 versions:
- 6.5.0.14.14~22.04.7 (jammy-updates)
- 5.15.0.25.27 (jammy)
- Is there a way to go back to the latest 6.2 kernel version?
+ [Testcase]
- How do I prevent Ubuntu from upgrading to 6.5 next time around? I have
searched the Internet, but I haven't
- found yet a usable answer. I don't want to go back all the way to Kernel 5.15
if I can avoid it.
+ Start two VMs, one for the server, and the other, the client.
- Thanks in advance,
- rdiez
+ 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.
** Tags added: seg
--
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 : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
