Bug 15181 - Crash when uploading files from macOS Monterey 12.6
Summary: Crash when uploading files from macOS Monterey 12.6
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.16.5
Hardware: x64 Linux
: P5 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-15 18:24 UTC by Alain Nussbaumer
Modified: 2022-09-23 02:19 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alain Nussbaumer 2022-09-15 18:24:25 UTC
Context
I run a Samba server under Archlinux (latest version).
The version of Samba is 4.16.5 and is the latest version at the time of writing available in the Archlinux distribution.
I transfer files from macOS Monterey 12.6 to this Archlinux box.
Before the version of Monterey 12.6, the upload of any files through the Samba shares was working flawlessly.

Current situation
With the latest version of macOS Monterey 12.6, whenever I try to upload big files - I didn’t, however, find the exact size that triggers problem - onto the Archlinux box, the Samba server starts crashing repeatedly.

Steps to reproduce
1. Connect to the Samba share, located on the Archlinux, from macOS Monterey 12.6
2. Start copying a file big enough to cause problem: e.g. 400 Mo.
3. The smbd server crashes repeatedly.

The error shows as follow in the logs
[2022/09/14 19:17:08.722164,  0] ../../lib/util/fault.c:183(smb_panic_log)
  PANIC (pid 11682): assert failed: !fsp_is_alternate_stream(fsp) in 4.16.5
[2022/09/14 19:17:08.722247,  0] ../../lib/util/fault.c:245(log_stack_trace)
  BACKTRACE:
   #0 log_stack_trace + 0x41 [ip=0x7f61ba7624e1] [sp=0x7ffccc712150]
   #1 smb_panic + 0xe [ip=0x7f61ba76286e] [sp=0x7ffccc712a80]
   #2 file_find_fd + 0x124f [ip=0x7f61ba98fb5f] [sp=0x7ffccc712a90]
   #3 string_replace_allocate + 0x1077 [ip=0x7f61b55cac67] [sp=0x7ffccc712ac0]
   #4 inherit_access_posix_acl + 0x242 [ip=0x7f61baa0b232] [sp=0x7ffccc712b10]
   #5 vfs_not_implemented_init + 0x62a3 [ip=0x7f61baa6b963] [sp=0x7ffccc712b80]
   #6 create_directory + 0xada [ip=0x7f61ba9f6afa] [sp=0x7ffccc712f20]
   #7 create_file_default + 0x337 [ip=0x7f61ba9f8667] [sp=0x7ffccc713130]
   #8 string_replace_allocate + 0x9b9 [ip=0x7f61b55e81a9] [sp=0x7ffccc7132b0]
   #9 smbd_smb2_request_process_create + 0xd54 [ip=0x7f61baa302e4] [sp=0x7ffccc713410]
   #10 smbd_smb2_request_dispatch + 0x14a2 [ip=0x7f61baa27de2] [sp=0x7ffccc713570]
   #11 reply_smb20ff + 0x467 [ip=0x7f61baa29f57] [sp=0x7ffccc713610]
   #12 tevent_common_invoke_fd_handler + 0x96 [ip=0x7f61ba586986] [sp=0x7ffccc7136b0]
   #13 tevent_common_loop_timer_delay + 0xb08 [ip=0x7f61ba58a738] [sp=0x7ffccc7136e0]
   #14 tevent_common_fd_set_close_fn + 0x7ad [ip=0x7f61ba58292d] [sp=0x7ffccc713740]
   #15 _tevent_loop_once + 0x96 [ip=0x7f61ba584e96] [sp=0x7ffccc713760]
   #16 tevent_common_loop_wait + 0x1c [ip=0x7f61ba584f9c] [sp=0x7ffccc713790]
   #17 tevent_common_fd_set_close_fn + 0x81d [ip=0x7f61ba58299d] [sp=0x7ffccc7137b0]
   #18 smbd_process + 0x83c [ip=0x7f61baa13c6c] [sp=0x7ffccc7137d0]
   #19 _start + 0x1ddc [ip=0x5619ed906c9c] [sp=0x7ffccc713870]
   #20 tevent_common_invoke_fd_handler + 0x96 [ip=0x7f61ba586986] [sp=0x7ffccc713940]
   #21 tevent_common_loop_timer_delay + 0xb08 [ip=0x7f61ba58a738] [sp=0x7ffccc713970]
   #22 tevent_common_fd_set_close_fn + 0x7ad [ip=0x7f61ba58292d] [sp=0x7ffccc7139d0]
   #23 _tevent_loop_once + 0x96 [ip=0x7f61ba584e96] [sp=0x7ffccc7139f0]
   #24 tevent_common_loop_wait + 0x1c [ip=0x7f61ba584f9c] [sp=0x7ffccc713a20]
   #25 tevent_common_fd_set_close_fn + 0x81d [ip=0x7f61ba58299d] [sp=0x7ffccc713a40]
   #26 main + 0x1d07 [ip=0x5619ed904d27] [sp=0x7ffccc713a60]
   #27 __libc_init_first + 0x90 [ip=0x7f61ba3b9290] [sp=0x7ffccc713d90]
   #28 __libc_start_main + 0x8a [ip=0x7f61ba3b934a] [sp=0x7ffccc713e30]
   #29 _start + 0x25 [ip=0x5619ed904ee5] [sp=0x7ffccc713e80]
[2022/09/14 19:17:08.737350,  0] ../../source3/lib/dumpcore.c:317(dump_core)
  coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern
[2022/09/14 19:17:08.944274,  0] ../../source3/modules/vfs_default.c:3450(vfswrap_sys_acl_set_fd)
  PANIC: assert failed at ../../source3/modules/vfs_default.c(3450): !fsp_is_alternate_stream(fsp)
[2022/09/14 19:17:08.944314,  0] ../../lib/util/fault.c:172(smb_panic_log)
  ===============================================================
[2022/09/14 19:17:08.944327,  0] ../../lib/util/fault.c:173(smb_panic_log)
  INTERNAL ERROR: assert failed: !fsp_is_alternate_stream(fsp) in pid 11690 (4.16.5)
[2022/09/14 19:17:08.944340,  0] ../../lib/util/fault.c:177(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
[2022/09/14 19:17:08.944352,  0] ../../lib/util/fault.c:182(smb_panic_log)
  ===============================================================
[2022/09/14 19:17:08.944369,  0] ../../lib/util/fault.c:183(smb_panic_log)
  PANIC (pid 11690): assert failed: !fsp_is_alternate_stream(fsp) in 4.16.5
[2022/09/14 19:17:08.944425,  0] ../../lib/util/fault.c:245(log_stack_trace)
  BACKTRACE:
   #0 log_stack_trace + 0x41 [ip=0x7f61ba7624e1] [sp=0x7ffccc712150]
   #1 smb_panic + 0xe [ip=0x7f61ba76286e] [sp=0x7ffccc712a80]
   #2 file_find_fd + 0x124f [ip=0x7f61ba98fb5f] [sp=0x7ffccc712a90]
   #3 string_replace_allocate + 0x1077 [ip=0x7f61b55cac67] [sp=0x7ffccc712ac0]
   #4 inherit_access_posix_acl + 0x242 [ip=0x7f61baa0b232] [sp=0x7ffccc712b10]
   #5 vfs_not_implemented_init + 0x62a3 [ip=0x7f61baa6b963] [sp=0x7ffccc712b80]
   #6 create_directory + 0xada [ip=0x7f61ba9f6afa] [sp=0x7ffccc712f20]
   #7 create_file_default + 0x337 [ip=0x7f61ba9f8667] [sp=0x7ffccc713130]
   #8 string_replace_allocate + 0x9b9 [ip=0x7f61b55e81a9] [sp=0x7ffccc7132b0]
   #9 smbd_smb2_request_process_create + 0xd54 [ip=0x7f61baa302e4] [sp=0x7ffccc713410]
   #10 smbd_smb2_request_dispatch + 0x14a2 [ip=0x7f61baa27de2] [sp=0x7ffccc713570]
   #11 reply_smb20ff + 0x467 [ip=0x7f61baa29f57] [sp=0x7ffccc713610]
   #12 tevent_common_invoke_fd_handler + 0x96 [ip=0x7f61ba586986] [sp=0x7ffccc7136b0]
   #13 tevent_common_loop_timer_delay + 0xb08 [ip=0x7f61ba58a738] [sp=0x7ffccc7136e0]
   #14 tevent_common_fd_set_close_fn + 0x7ad [ip=0x7f61ba58292d] [sp=0x7ffccc713740]
   #15 _tevent_loop_once + 0x96 [ip=0x7f61ba584e96] [sp=0x7ffccc713760]
   #16 tevent_common_loop_wait + 0x1c [ip=0x7f61ba584f9c] [sp=0x7ffccc713790]
   #17 tevent_common_fd_set_close_fn + 0x81d [ip=0x7f61ba58299d] [sp=0x7ffccc7137b0]
   #18 smbd_process + 0x83c [ip=0x7f61baa13c6c] [sp=0x7ffccc7137d0]
   #19 _start + 0x1ddc [ip=0x5619ed906c9c] [sp=0x7ffccc713870]
   #20 tevent_common_invoke_fd_handler + 0x96 [ip=0x7f61ba586986] [sp=0x7ffccc713940]
   #21 tevent_common_loop_timer_delay + 0xb08 [ip=0x7f61ba58a738] [sp=0x7ffccc713970]
   #22 tevent_common_fd_set_close_fn + 0x7ad [ip=0x7f61ba58292d] [sp=0x7ffccc7139d0]
   #23 _tevent_loop_once + 0x96 [ip=0x7f61ba584e96] [sp=0x7ffccc7139f0]
   #24 tevent_common_loop_wait + 0x1c [ip=0x7f61ba584f9c] [sp=0x7ffccc713a20]
   #25 tevent_common_fd_set_close_fn + 0x81d [ip=0x7f61ba58299d] [sp=0x7ffccc713a40]
   #26 main + 0x1d07 [ip=0x5619ed904d27] [sp=0x7ffccc713a60]
   #27 __libc_init_first + 0x90 [ip=0x7f61ba3b9290] [sp=0x7ffccc713d90]
   #28 __libc_start_main + 0x8a [ip=0x7f61ba3b934a] [sp=0x7ffccc713e30]
   #29 _start + 0x25 [ip=0x5619ed904ee5] [sp=0x7ffccc713e80]
[2022/09/14 19:17:08.960388,  0] ../../source3/lib/dumpcore.c:317(dump_core)
  coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern

Expected situation
The smbd server doesn’t crash when a big file is uploaded to a share from macOS Monterey 12.6.

 
Notes
The configuration of the server didn’t change.
The only change is the upgrade to macOS Monterey 12.6.

Thanks for any help.
Comment 1 Alain Nussbaumer 2022-09-18 11:06:26 UTC
I tried a few things and I discovered that it was related to the permissions.
To solve the problem, I removed the following directive: inherit permissions = yes

It still puzzles me why when having the aforementioned directive, it crashes the Samba server.
Comment 2 Andrew Bartlett 2022-09-19 05:01:18 UTC
Thanks so much for finding what option triggers your issue, this will help those who might pick this up in the future greatly. 

I'm guessing this might be a use-after-free, if the file size matters.

If you can get Samba running under valgrind that would likely show the issue very fast, without needing the large file.  Otherwise a rebuild with --address-sanitizer would also likely work.