** Description changed: [ Impact ] The smbd process servicing a client that renames an open file which has a RHW lease will crash, and this can lead to the file missing data that was being written to it. It has been reported to happen with Gimp and Xed, a text editor from Linux Mint, when running on a 6.8.0 kernel like the one shipped with Ubuntu 24.04. A simpler reproducer was found, and is being used in the test plan. [ Test Plan ] The test plan requires one noble VM, which will be acting as the client that can trigger the bug on the server, and a plucky LXD (no need to be a VM, but one can be used too). # Prepare the plucky server to be tested lxc launch ubuntu-daily:plucky p-server lxc shell p-server apt update && apt install samba -y mkdir -m 1777 /test printf "ubuntusecret\nubuntusecret\n" | smbpasswd -a ubuntu cat >> /etc/samba/smb.conf <<EOF [test] path = /test writable = yes guest ok = no EOF systemctl restart smbd # ignore "no such file" error, -F will take care of that tail -F /var/log/samba/log.n-crasher # Prepare the client that will trigger the server crash lxc launch ubuntu-daily:noble n-crasher --vm lxc shell n-crasher apt update && apt install -y cifs-utils export IP=<IP_FROM_SERVER_UNDER_TEST> mount -t cifs -o rw,user=ubuntu,pass=ubuntusecret,uid=$(id -u),gid=$(id -g),forceuid,forcegid //$IP/test /mnt # Trigger the crash. Run this on the client: cat > /mnt/bug & mv /mnt/bug /mnt/oops # On the server terminal, you should see the crash: tail: '/var/log/samba/log.n-crasher' has appeared; following new file [2025/06/17 20:55:25.255706, 0] lib/util/fault.c:178(smb_panic_log) =============================================================== [2025/06/17 20:55:25.255869, 0] lib/util/fault.c:179(smb_panic_log) (...) With the samba packages from proposed, the server should not crash. [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? - - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. - - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + Unfortunately, the patch (or collection of patches) is quite extensive. + While fixing the issue, upstream found other places where a similar + problem could occur, and fixed those as well, which let to some bit of + refactoring. + + On the plus side, this huge set of patches applies cleanly, with no + offsets even. And is exactly what upstream attached to the reported bug + as being a backport for this version of samba. + + In terms of a minimal fix for an SRU, this is the challenge now. If we + try to extract just the exact patch that fixes the exact problem + reported in this bug, we will be missing other similar crashes in the + code. Not to mention the risk of introducing mistakes on our end. I + believe it's safer to stick to this set of patches as is. + + With that in mind, with such a large change many things could go wrong. + What helps to mitigate this regression potential is: + + a) We have a non-trivial test coverage over many different aspects of samba (but many are left out still): + - basic samba share access with smbclient and CIFS, authenticated and anonymous + - provisioning of a samba active directory domain controller + - joining a samba server to the active directory domain + - said joined server tests include domain users authentication test via kerberos, home directory creation + - simple Group Policy Object test with a MOTD policy (but server only) + - worth pointing out, however, that the scenario this bug is fixing is not one that these tests catch. + + b) These changes are present in samba 4.22, the current stable release, + but we have no ubuntu release with that yet (questing will be the first) + + c) Upstream added tests for this bug, in their test suite (included in + this SRU, but we don't run them), which they run (link needed: I don't + have one) + [ Other Info ] While working with the reproducer, we found that ubuntu focal, jammy, and noble, acting as the CIFS client, can trigger the crash on the server. We suspect it's some behavior in the cifs module in those kernels that triggers the bug. That behavior must have changed in some later kernel, because using oracular or plucky as the CIFS client no longer triggers the crash on the server. + + The above kind of explains why it was so hard to reproduce, and I was + initially surprised that, if true (and it was true), why this bug had + not been reported by many more people. + [ Original Description ] Release version: 25.04 Package vers: 2:4.21.4+dfsg-1ubuntu3 My server is an i5-6500 with 64GB RAM, a 250G boot SSD (ext4), 2x 1TB SSDs in RAID1 (btrfs) and 2x 8TB HDDs in RAID 1 (btrfs). I had 24.10 installed and samba had no problems. I upgraded to 25.04 and samba now segfaults every time I modify a file. Creating a file is fine that I can tell. Steps to reproduce: 1. Create a blank file called test.txt and save it. It saves and opens fine. 2. Edit the file remotely then save (I am using xed on linux mint for text files). 3. Close the file, then reopen. It will pop up with an error and act if it's 'corrupt'. It will not read until the service is restarted. 4. Open the file on the server using nano. It will have your changes in it as if it saved just fine. 5. Restart smbd service. The file will load with the changes until it is edited again. 6. See log file which will show a segfault error occurred. I figured something got messed up during the update, so I cleaned my boot SSD and reinstalled a fresh ubuntu 25.04 release. First and only thing I installed was samba after mounting the storage disks and the error still happens. Reinstalled 24.10 and there are no issues. Files load, edit, and save just fine. Attached the log entry below generated from the /var/log/samba/log.(client) file. Currently I do not have 25.04 installed as I need my server working but will try to update with as much info as I can as needed. --- [2025/04/24 06:55:33.944945, 0] lib/util/fault.c:178(smb_panic_log) =============================================================== [2025/04/24 06:55:33.945041, 0] lib/util/fault.c:179(smb_panic_log) INTERNAL ERROR: Signal 11: Segmentation fault in smbd (smbd[192.168.2.) (client [192.168.2.248]) pid 1362 (4.21.4-Ubuntu-4.21.4+dfsg-1ubuntu3) [2025/04/24 06:55:33.945049, 0] lib/util/fault.c:186(smb_panic_log) If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting [2025/04/24 06:55:33.945055, 0] lib/util/fault.c:191(smb_panic_log) =============================================================== [2025/04/24 06:55:33.945060, 0] lib/util/fault.c:192(smb_panic_log) PANIC (pid 1362): Signal 11: Segmentation fault in 4.21.4-Ubuntu-4.21.4+dfsg-1ubuntu3 [2025/04/24 06:55:33.945338, 0] lib/util/fault.c:303(log_stack_trace) BACKTRACE: 31 stack frames: #0 /usr/lib/x86_64-linux-gnu/samba/libgenrand-private-samba.so.0(log_stack_trace+0x35) [0x7f3a9af49515] #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-private-samba.so.0(smb_panic+0x15) [0x7f3a9af49d25] #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-private-samba.so.0(+0x2dca) [0x7f3a9af49dca] #3 /lib/x86_64-linux-gnu/libc.so.6(+0x45810) [0x7f3a9ac45810] #4 /usr/lib/x86_64-linux-gnu/samba/libcli-smb-common-private-samba.so.0(smb2_lease_key_equal+0x9) [0x7f3a9a4cdb49] #5 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(+0xcdcef) [0x7f3a9b3c4cef] #6 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(share_mode_forall_entries+0x1bf) [0x7f3a9b43dcef] #7 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(share_mode_forall_leases+0x66) [0x7f3a9b436956] #8 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(+0xcddd2) [0x7f3a9b3c4dd2] #9 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_smb2_request_process_setinfo+0x881) [0x7f3a9b3c5791] #10 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_smb2_request_dispatch+0x1aba) [0x7f3a9b3a99ba] #11 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_smb2_request_dispatch_immediate+0x57) [0x7f3a9b3aad07] #12 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_immediate_handler+0x278) [0x7f3a9b0c5f88] #13 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_immediate+0x22) [0x7f3a9b0c60b2] #14 /lib/x86_64-linux-gnu/libtevent.so.0(+0x10d80) [0x7f3a9b0cad80] #15 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f04) [0x7f3a9b0bff04] #16 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x99) [0x7f3a9b0c1cf9] #17 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x2b) [0x7f3a9b0c1e2b] #18 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f84) [0x7f3a9b0bff84] #19 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_process+0x870) [0x7f3a9b395ec0] #20 smbd: client [192.168.2.248](+0xa886) [0x60fe86845886] #21 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_fd_handler+0xe3) [0x7f3a9b0c5be3] #22 /lib/x86_64-linux-gnu/libtevent.so.0(+0x1107f) [0x7f3a9b0cb07f] #23 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f04) [0x7f3a9b0bff04] #24 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x99) [0x7f3a9b0c1cf9] #25 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x2b) [0x7f3a9b0c1e2b] #26 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f84) [0x7f3a9b0bff84] #27 smbd: client [192.168.2.248](main+0x14fc) [0x60fe868431dc] #28 /lib/x86_64-linux-gnu/libc.so.6(+0x2a338) [0x7f3a9ac2a338] #29 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7f3a9ac2a3fb] #30 smbd: client [192.168.2.248](_start+0x25) [0x60fe86843d15] [2025/04/24 06:55:33.945425, 0] source3/lib/util.c:686(call_panic_action) call_panic_action: Calling panic action [/usr/share/samba/panic-action 1362] [2025/04/24 06:55:33.947236, 0] source3/lib/util.c:709(call_panic_action) call_panic_action: action returned status 0 [2025/04/24 06:55:33.947286, 0] source3/lib/dumpcore.c:318(dump_core) coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern --- Thank you :) --- ProblemType: Bug ApportVersion: 2.32.0-0ubuntu5 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail DistroRelease: Ubuntu 25.04 InstallationDate: Installed on 2025-05-10 (0 days ago) InstallationMedia: Ubuntu-Server 25.04 "Plucky Puffin" - Release amd64 (20250415.2) Package: samba 2:4.21.4+dfsg-1ubuntu3 PackageArchitecture: amd64 ProcEnviron: LANG=en_CA.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcVersionSignature: Ubuntu 6.14.0-15.15-generic 6.14.0 Tags: plucky Uname: Linux 6.14.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True
** Description changed: [ Impact ] The smbd process servicing a client that renames an open file which has a RHW lease will crash, and this can lead to the file missing data that was being written to it. It has been reported to happen with Gimp and Xed, a text editor from Linux Mint, when running on a 6.8.0 kernel like the one shipped with Ubuntu 24.04. A simpler reproducer was found, and is being used in the test plan. [ Test Plan ] The test plan requires one noble VM, which will be acting as the client that can trigger the bug on the server, and a plucky LXD (no need to be a VM, but one can be used too). # Prepare the plucky server to be tested lxc launch ubuntu-daily:plucky p-server lxc shell p-server apt update && apt install samba -y mkdir -m 1777 /test printf "ubuntusecret\nubuntusecret\n" | smbpasswd -a ubuntu cat >> /etc/samba/smb.conf <<EOF [test] path = /test writable = yes guest ok = no EOF systemctl restart smbd # ignore "no such file" error, -F will take care of that tail -F /var/log/samba/log.n-crasher # Prepare the client that will trigger the server crash lxc launch ubuntu-daily:noble n-crasher --vm lxc shell n-crasher apt update && apt install -y cifs-utils export IP=<IP_FROM_SERVER_UNDER_TEST> mount -t cifs -o rw,user=ubuntu,pass=ubuntusecret,uid=$(id -u),gid=$(id -g),forceuid,forcegid //$IP/test /mnt # Trigger the crash. Run this on the client: cat > /mnt/bug & mv /mnt/bug /mnt/oops # On the server terminal, you should see the crash: tail: '/var/log/samba/log.n-crasher' has appeared; following new file [2025/06/17 20:55:25.255706, 0] lib/util/fault.c:178(smb_panic_log) =============================================================== [2025/06/17 20:55:25.255869, 0] lib/util/fault.c:179(smb_panic_log) (...) With the samba packages from proposed, the server should not crash. [ Where problems could occur ] Unfortunately, the patch (or collection of patches) is quite extensive. While fixing the issue, upstream found other places where a similar problem could occur, and fixed those as well, which let to some bit of - refactoring. + refactoring (see comment #7 at + https://bugzilla.samba.org/show_bug.cgi?id=15608#c7). On the plus side, this huge set of patches applies cleanly, with no offsets even. And is exactly what upstream attached to the reported bug as being a backport for this version of samba. In terms of a minimal fix for an SRU, this is the challenge now. If we try to extract just the exact patch that fixes the exact problem reported in this bug, we will be missing other similar crashes in the code. Not to mention the risk of introducing mistakes on our end. I believe it's safer to stick to this set of patches as is. With that in mind, with such a large change many things could go wrong. What helps to mitigate this regression potential is: a) We have a non-trivial test coverage over many different aspects of samba (but many are left out still): - basic samba share access with smbclient and CIFS, authenticated and anonymous - provisioning of a samba active directory domain controller - joining a samba server to the active directory domain - said joined server tests include domain users authentication test via kerberos, home directory creation - simple Group Policy Object test with a MOTD policy (but server only) - worth pointing out, however, that the scenario this bug is fixing is not one that these tests catch. b) These changes are present in samba 4.22, the current stable release, but we have no ubuntu release with that yet (questing will be the first) c) Upstream added tests for this bug, in their test suite (included in this SRU, but we don't run them), which they run (link needed: I don't have one) - [ Other Info ] While working with the reproducer, we found that ubuntu focal, jammy, and noble, acting as the CIFS client, can trigger the crash on the server. We suspect it's some behavior in the cifs module in those kernels that triggers the bug. That behavior must have changed in some later kernel, because using oracular or plucky as the CIFS client no longer triggers the crash on the server. The above kind of explains why it was so hard to reproduce, and I was initially surprised that, if true (and it was true), why this bug had not been reported by many more people. - [ Original Description ] Release version: 25.04 Package vers: 2:4.21.4+dfsg-1ubuntu3 My server is an i5-6500 with 64GB RAM, a 250G boot SSD (ext4), 2x 1TB SSDs in RAID1 (btrfs) and 2x 8TB HDDs in RAID 1 (btrfs). I had 24.10 installed and samba had no problems. I upgraded to 25.04 and samba now segfaults every time I modify a file. Creating a file is fine that I can tell. Steps to reproduce: 1. Create a blank file called test.txt and save it. It saves and opens fine. 2. Edit the file remotely then save (I am using xed on linux mint for text files). 3. Close the file, then reopen. It will pop up with an error and act if it's 'corrupt'. It will not read until the service is restarted. 4. Open the file on the server using nano. It will have your changes in it as if it saved just fine. 5. Restart smbd service. The file will load with the changes until it is edited again. 6. See log file which will show a segfault error occurred. I figured something got messed up during the update, so I cleaned my boot SSD and reinstalled a fresh ubuntu 25.04 release. First and only thing I installed was samba after mounting the storage disks and the error still happens. Reinstalled 24.10 and there are no issues. Files load, edit, and save just fine. Attached the log entry below generated from the /var/log/samba/log.(client) file. Currently I do not have 25.04 installed as I need my server working but will try to update with as much info as I can as needed. --- [2025/04/24 06:55:33.944945, 0] lib/util/fault.c:178(smb_panic_log) =============================================================== [2025/04/24 06:55:33.945041, 0] lib/util/fault.c:179(smb_panic_log) INTERNAL ERROR: Signal 11: Segmentation fault in smbd (smbd[192.168.2.) (client [192.168.2.248]) pid 1362 (4.21.4-Ubuntu-4.21.4+dfsg-1ubuntu3) [2025/04/24 06:55:33.945049, 0] lib/util/fault.c:186(smb_panic_log) If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting [2025/04/24 06:55:33.945055, 0] lib/util/fault.c:191(smb_panic_log) =============================================================== [2025/04/24 06:55:33.945060, 0] lib/util/fault.c:192(smb_panic_log) PANIC (pid 1362): Signal 11: Segmentation fault in 4.21.4-Ubuntu-4.21.4+dfsg-1ubuntu3 [2025/04/24 06:55:33.945338, 0] lib/util/fault.c:303(log_stack_trace) BACKTRACE: 31 stack frames: #0 /usr/lib/x86_64-linux-gnu/samba/libgenrand-private-samba.so.0(log_stack_trace+0x35) [0x7f3a9af49515] #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-private-samba.so.0(smb_panic+0x15) [0x7f3a9af49d25] #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-private-samba.so.0(+0x2dca) [0x7f3a9af49dca] #3 /lib/x86_64-linux-gnu/libc.so.6(+0x45810) [0x7f3a9ac45810] #4 /usr/lib/x86_64-linux-gnu/samba/libcli-smb-common-private-samba.so.0(smb2_lease_key_equal+0x9) [0x7f3a9a4cdb49] #5 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(+0xcdcef) [0x7f3a9b3c4cef] #6 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(share_mode_forall_entries+0x1bf) [0x7f3a9b43dcef] #7 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(share_mode_forall_leases+0x66) [0x7f3a9b436956] #8 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(+0xcddd2) [0x7f3a9b3c4dd2] #9 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_smb2_request_process_setinfo+0x881) [0x7f3a9b3c5791] #10 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_smb2_request_dispatch+0x1aba) [0x7f3a9b3a99ba] #11 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_smb2_request_dispatch_immediate+0x57) [0x7f3a9b3aad07] #12 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_immediate_handler+0x278) [0x7f3a9b0c5f88] #13 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_immediate+0x22) [0x7f3a9b0c60b2] #14 /lib/x86_64-linux-gnu/libtevent.so.0(+0x10d80) [0x7f3a9b0cad80] #15 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f04) [0x7f3a9b0bff04] #16 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x99) [0x7f3a9b0c1cf9] #17 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x2b) [0x7f3a9b0c1e2b] #18 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f84) [0x7f3a9b0bff84] #19 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-private-samba.so.0(smbd_process+0x870) [0x7f3a9b395ec0] #20 smbd: client [192.168.2.248](+0xa886) [0x60fe86845886] #21 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_fd_handler+0xe3) [0x7f3a9b0c5be3] #22 /lib/x86_64-linux-gnu/libtevent.so.0(+0x1107f) [0x7f3a9b0cb07f] #23 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f04) [0x7f3a9b0bff04] #24 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x99) [0x7f3a9b0c1cf9] #25 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x2b) [0x7f3a9b0c1e2b] #26 /lib/x86_64-linux-gnu/libtevent.so.0(+0x5f84) [0x7f3a9b0bff84] #27 smbd: client [192.168.2.248](main+0x14fc) [0x60fe868431dc] #28 /lib/x86_64-linux-gnu/libc.so.6(+0x2a338) [0x7f3a9ac2a338] #29 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7f3a9ac2a3fb] #30 smbd: client [192.168.2.248](_start+0x25) [0x60fe86843d15] [2025/04/24 06:55:33.945425, 0] source3/lib/util.c:686(call_panic_action) call_panic_action: Calling panic action [/usr/share/samba/panic-action 1362] [2025/04/24 06:55:33.947236, 0] source3/lib/util.c:709(call_panic_action) call_panic_action: action returned status 0 [2025/04/24 06:55:33.947286, 0] source3/lib/dumpcore.c:318(dump_core) coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern --- Thank you :) --- ProblemType: Bug ApportVersion: 2.32.0-0ubuntu5 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail DistroRelease: Ubuntu 25.04 InstallationDate: Installed on 2025-05-10 (0 days ago) InstallationMedia: Ubuntu-Server 25.04 "Plucky Puffin" - Release amd64 (20250415.2) Package: samba 2:4.21.4+dfsg-1ubuntu3 PackageArchitecture: amd64 ProcEnviron: LANG=en_CA.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcVersionSignature: Ubuntu 6.14.0-15.15-generic 6.14.0 Tags: plucky Uname: Linux 6.14.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2108981 Title: samba segfaults when renaming a file with open RHW lease To manage notifications about this bug go to: https://bugs.launchpad.net/samba/+bug/2108981/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
