Bug 15221 - Core dump in 4.17.2 non_widelink_open (assert failed: slash == NULL)
Summary: Core dump in 4.17.2 non_widelink_open (assert failed: slash == NULL)
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.17.2
Hardware: x64 FreeBSD
: P5 normal (vote)
Target Milestone: ---
Assignee: Jule Anger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-01 09:24 UTC by Peter Eriksson
Modified: 2022-11-14 22:27 UTC (History)
1 user (show)

See Also:


Attachments
smb.conf (3.45 KB, text/plain)
2022-11-02 13:13 UTC, Peter Eriksson
no flags Details
Patch (1.87 KB, patch)
2022-11-04 13:06 UTC, Volker Lendecke
slow: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Eriksson 2022-11-01 09:24:05 UTC
Just got a core dump from Samba 4.17.2 smbd, GDB backtrace:

Also, I when bug reporting it in bugzilla, can’t select 4.17.2 in Version (latest there seems to be 4.17.1 :-)

FreeBSD 12.3.

- Peter


Sent by thr_kill() from pid 33958 and user 0.
#0  0x00000008043a769a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x00000008043a769a in thr_kill () from /lib/libc.so.7
#1  0x00000008043a5af4 in raise () from /lib/libc.so.7
#2  0x000000080431b719 in abort () from /lib/libc.so.7
#3  0x0000000801f0af37 in dump_core () at ../../source3/lib/dumpcore.c:338
#4  0x0000000801f17f76 in smb_panic_s3 (why=<optimized out>) at ../../source3/lib/util.c:713
#5  0x0000000803d8b7f8 in smb_panic (why=why@entry=0x8017d6b8c "assert failed: slash == NULL")
    at ../../lib/util/fault.c:198
#6  0x00000008017061ba in non_widelink_open (dirfsp=dirfsp@entry=0x811dc9120, fsp=fsp@entry=0x811dcab60, 
    smb_fname=smb_fname@entry=0x80f32fa00, _how=_how@entry=0x7fffffffdf00, link_depth=link_depth@entry=0)
    at ../../source3/smbd/open.c:773
#7  0x0000000801708eca in fd_openat (dirfsp=dirfsp@entry=0x811dc9120, smb_fname=smb_fname@entry=0x80f32fa00, 
    fsp=0x811dcab60, _how=_how@entry=0x7fffffffe000) at ../../source3/smbd/open.c:952
#8  0x00000008016e2c9f in openat_pathref_fullname (conn=conn@entry=0x80eb98c60, dirfsp=dirfsp@entry=0x811dc9120, 
    basefsp=basefsp@entry=0x0, full_fname=full_fname@entry=0x7fffffffdff8, smb_fname=smb_fname@entry=0x80f32fa00, 
    how=how@entry=0x7fffffffe000) at ../../source3/smbd/files.c:481
#9  0x00000008016e342b in openat_pathref_fsp (dirfsp=dirfsp@entry=0x811dc9120, smb_fname=smb_fname@entry=0x80f32fa00)
    at ../../source3/smbd/files.c:590
#10 0x0000000801704601 in openat_pathref_fsp_case_insensitive (ucf_flags=0, smb_fname_rel=0x80f32fa00, 
    dirfsp=0x811dc9120) at ../../source3/smbd/filename.c:912
#11 filename_convert_dirfsp_nosymlink (_unparsed=<synthetic pointer>, _substitute=<synthetic pointer>, 
    _smb_fname=0x7fffffffe208, _dirfsp=0x7fffffffe200, twrp=0, ucf_flags=0, name_in=<optimized out>, conn=0x80eb98c60, 
    mem_ctx=0x80ebeb0e0) at ../../source3/smbd/filename.c:1259
#12 filename_convert_dirfsp (mem_ctx=mem_ctx@entry=0x80ebeb0e0, conn=<optimized out>, 
    name_in=0x80ebeb530 "sopas205/Downloads/teamviewerqs/profile/dosdevices/CQFO6Q~M", ucf_flags=0, twrp=0, 
    _dirfsp=_dirfsp@entry=0x7fffffffe200, _smb_fname=0x7fffffffe208) at ../../source3/smbd/filename.c:1457
#13 0x0000000801746f20 in smbd_smb2_create_send (in_context_blobs=..., 
    in_name=0x80ebead30 "sopas205\\Downloads\\teamviewerqs\\profile\\dosdevices\\CQFO6Q~M", 
    in_create_options=<optimized out>, in_create_disposition=<optimized out>, in_share_access=3, in_file_attributes=0, 
    in_desired_access=1048705, in_impersonation_level=2, in_oplock_level=<optimized out>, smb2req=0x80ebea8e0, 
    ev=<optimized out>, mem_ctx=0x80ebea8e0) at ../../source3/smbd/smb2_create.c:976
#14 smbd_smb2_request_process_create (smb2req=smb2req@entry=0x80ebea8e0) at ../../source3/smbd/smb2_create.c:270
#15 0x000000080173c7c7 in smbd_smb2_request_dispatch (req=req@entry=0x80ebea8e0) at ../../source3/smbd/smb2_server.c:3399
#16 0x000000080173d4b3 in smbd_smb2_io_handler (fde_flags=<optimized out>, xconn=0x80eb9e560)

(gdb) frame 6
#6  0x00000008017061ba in non_widelink_open (dirfsp=dirfsp@entry=0x811dc9120, fsp=fsp@entry=0x811dcab60, smb_fname=smb_fname@entry=0x80f32fa00, 
    _how=_how@entry=0x7fffffffdf00, link_depth=link_depth@entry=0) at ../../source3/smbd/open.c:773
773			SMB_ASSERT(slash == NULL);

(gdb) print *dirfsp
$1 = {next = 0x811dc9d60, prev = 0x811dcab60, fnum = 0, op = 0x0, conn = 0x80eb98c60, fh = 0x812efcb00, num_smb_operations = 0, file_id = {
    devid = 5952628266332556909, inode = 4654, extid = 0}, initial_allocation_size = 0, file_pid = 0, vuid = 0, open_time = {tv_sec = 0, tv_usec = 0}, 
  access_mask = 0, fsp_flags = {is_pathref = true, is_fsa = false, have_proc_fds = false, kernel_share_modes_taken = false, 
    update_write_time_triggered = false, update_write_time_on_close = false, write_time_forced = false, can_lock = false, can_read = false, 
    can_write = false, modified = false, is_directory = true, is_dirfsp = false, aio_write_behind = false, initial_delete_on_close = false, 
    delete_on_close = false, is_sparse = false, backup_intent = false, use_ofd_locks = false, closing = false, lock_failure_seen = false, 
    encryption_required = false, fstat_before_close = false}, update_write_time_event = 0x0, close_write_time = {tv_sec = 0, tv_nsec = -2}, 
  oplock_type = 0, leases_db_seqnum = 0, lease_type = 0, lease = 0x0, sent_oplock_break = 0, oplock_timeout = 0x0, current_lock_count = 0, 
  posix_flags = 0, fsp_name = 0x80f333e80, name_hash = 1414196691, mid = 0, vfs_extension = 0x0, fake_file_handle = 0x0, notify = 0x0, base_fsp = 0x0, 
  stream_fsp = 0x0, share_mode_flags_seqnum = 0, share_mode_flags = 0, brlock_seqnum = 0, brlock_rec = 0x0, dptr = 0x0, print_file = 0x0, 
  num_aio_requests = 0, aio_requests = 0x0, blocked_smb1_lock_reqs = 0x0, lock_failure_offset = 0}

(gdb) print *fsp
$2 = {next = 0x811dc9120, prev = 0x80eb65ae0, fnum = 0, op = 0x0, conn = 0x80eb98c60, fh = 0x812efd1e0, num_smb_operations = 0, file_id = {devid = 0, 
    inode = 0, extid = 0}, initial_allocation_size = 0, file_pid = 0, vuid = 0, open_time = {tv_sec = 1667232016, tv_usec = 588582}, access_mask = 0, 
  fsp_flags = {is_pathref = true, is_fsa = false, have_proc_fds = false, kernel_share_modes_taken = false, update_write_time_triggered = false, 
    update_write_time_on_close = false, write_time_forced = false, can_lock = false, can_read = false, can_write = false, modified = false, 
    is_directory = false, is_dirfsp = false, aio_write_behind = false, initial_delete_on_close = false, delete_on_close = false, is_sparse = false, 
    backup_intent = false, use_ofd_locks = false, closing = false, lock_failure_seen = false, encryption_required = false, fstat_before_close = false}, 
  update_write_time_event = 0x0, close_write_time = {tv_sec = 0, tv_nsec = -2}, oplock_type = 0, leases_db_seqnum = 0, lease_type = 0, lease = 0x0, 
  sent_oplock_break = 0, oplock_timeout = 0x0, current_lock_count = 0, posix_flags = 0, fsp_name = 0x811dc4780, name_hash = 2156576274, mid = 0, 
  vfs_extension = 0x0, fake_file_handle = 0x0, notify = 0x0, base_fsp = 0x0, stream_fsp = 0x0, share_mode_flags_seqnum = 0, share_mode_flags = 0, 
  brlock_seqnum = 0, brlock_rec = 0x0, dptr = 0x0, print_file = 0x0, num_aio_requests = 0, aio_requests = 0x0, blocked_smb1_lock_reqs = 0x0, 
  lock_failure_offset = 0}

(gdb) print *smb_fname
$3 = {base_name = 0x80f32fb20 "sopas205/Downloads/teamviewerqs/profile/drive_c", stream_name = 0x0, flags = 0, st = {st_ex_dev = 0, st_ex_ino = 0, 
    st_ex_mode = 0, st_ex_nlink = 0, st_ex_uid = 0, st_ex_gid = 0, st_ex_rdev = 0, st_ex_size = 0, st_ex_atime = {tv_sec = 0, tv_nsec = 0}, 
    st_ex_mtime = {tv_sec = 0, tv_nsec = 0}, st_ex_ctime = {tv_sec = 0, tv_nsec = 0}, st_ex_btime = {tv_sec = 0, tv_nsec = 0}, st_ex_blksize = 0, 
    st_ex_blocks = 0, st_ex_flags = 0, st_ex_iflags = 0}, twrp = 0, fsp = 0x0, fsp_link = 0x0}


- Peter
Comment 1 Volker Lendecke 2022-11-01 11:26:25 UTC
Can you also print *smb_fname_rel?
Comment 2 Peter Eriksson 2022-11-01 13:21:03 UTC
Sure.

(gdb) print *smb_fname_rel
$6 = {base_name = 0x80f32fb20 "sopas205/Downloads/teamviewerqs/profile/drive_c", stream_name = 0x0, flags = 0, st = {st_ex_dev = 0, st_ex_ino = 0, 
    st_ex_mode = 0, st_ex_nlink = 0, st_ex_uid = 0, st_ex_gid = 0, st_ex_rdev = 0, st_ex_size = 0, st_ex_atime = {tv_sec = 0, tv_nsec = 0}, 
    st_ex_mtime = {tv_sec = 0, tv_nsec = 0}, st_ex_ctime = {tv_sec = 0, tv_nsec = 0}, st_ex_btime = {tv_sec = 0, tv_nsec = 0}, st_ex_blksize = 0, 
    st_ex_blocks = 0, st_ex_flags = 0, st_ex_iflags = 0}, twrp = 0, fsp = 0x0, fsp_link = 0x0}


(gdb) print smb_fname_rel
$8 = (struct smb_filename *) 0x80f32fa00

(gdb) print smb_fname
$9 = (struct smb_filename *) 0x80f32fa00

Seems to point at the same struct as smb_fname.

(gdb) print link_depth
$10 = 0

(gdb) print *_how
$11 = {flags = 4, mode = 0, resolve = 0}

(gdb) print have_opath
$15 = false



The directory where this bug happened looks like this btw:

root@filur02:/export/students/sopas205/Downloads/teamviewerqs/profile # ls -lr dosdevices drive_c
drive_c:
total 35
drwxr-xr-x  3 sopas205  student-liu.se   3 Oct 12  2020 windows
drwxr-xr-x  3 sopas205  student-liu.se   3 Oct 12  2020 users
drwxr-xr-x  2 sopas205  student-liu.se  33 Oct 12  2020 TeamViewer

dosdevices:
total 2
lrwxrwxrwx  1 sopas205  student-liu.se   1 Oct 12  2020 z: -> /
lrwxrwxrwx  1 sopas205  student-liu.se  54 Oct 12  2020 c: -> /home/sopas205/Downloads/teamviewerqs/profile/drive_c/
Comment 3 Jeremy Allison 2022-11-01 17:06:32 UTC
OK, the directory dosdevices contains names "c:" and "z:", which will be represented as mangled names to the clients:

CQFO6Q~M

Looks like we're not handling the mapping from a mangled name back to the name on the filesystem in this codepath somehow.
Comment 4 Jeremy Allison 2022-11-01 17:43:26 UTC
Hmmm. I've tried on a recent 4.17 build and can't reproduce.

$ mkdir dosdev
$ cd dosdev
$ ln -s / c:

From smbclient:

get dosdev\CQFO6Q~M
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \dosdev\CQFO6Q~M
Comment 5 Jeremy Allison 2022-11-01 17:46:25 UTC
Mangled names are working fine.

$ mkdir dosdev
$ cd dosdev
$ touch testfile
$ ln -s testfile c:

From smbclient:

get dosdev\CQFO6Q~M
getting file \dosdev\CQFO6Q~M of size 0 as dosdev\CQFO6Q~M

(In the local target directory)
$ ls
'dosdev\CQFO6Q~M'
Comment 6 Peter Eriksson 2022-11-02 10:40:21 UTC
If I create this directory structure:

peter86@espresso:/home/peter86$ ls -lR samba-15221
samba-15221:
total 1
drwx------ 2 peter86 employee-liu.se 3 Nov  2 11:29 dosdevices
drwx------ 2 peter86 employee-liu.se 2 Nov  2 11:21 drive_c

samba-15221/dosdevices:
total 1
lrwxrwxrwx 1 peter86 employee-liu.se 10 Nov  2 11:28 c: -> ../drive_c

samba-15221/drive_c:
total 0
"CQ
And then try to access the CQFO6Q~M directory in a Windows 10 file browser window the I get a spat of coredumps.


Same with smbclient:

smbclient -k //filur04.it.liu.se/staff
Try "help" to get a list of possible commands.
smb: \> cd peter86
smb: \peter86\> cd samba-15221
smb: \peter86\samba-15221\> dir
  .                                   D        0  Wed Nov  2 11:21:06 2022
  ..                                  D        0  Wed Nov  2 11:23:20 2022
  drive_c                             D        0  Wed Nov  2 11:21:06 2022
  dosdevices                          D        0  Wed Nov  2 11:29:26 2022

		292968750 blocks of size 1024. 251388048 blocks available
smb: \peter86\samba-15221\> cd dosdevices\
smb: \peter86\samba-15221\dosdevices\> dir
  .                                   D        0  Wed Nov  2 11:29:26 2022
  ..                                  D        0  Wed Nov  2 11:21:06 2022
  CQFO6Q~M                            D        0  Wed Nov  2 11:21:06 2022

		292968750 blocks of size 1024. 251388048 blocks available
smb: \peter86\samba-15221\dosdevices\> cd CQFO6Q~M
smb: \peter86\samba-15221\dosdevices\CQFO6Q~M\> dir
NT_STATUS_CONNECTION_DISCONNECTED listing \peter86\samba-15221\dosdevices\CQFO6Q~M\*
smb: \peter86\samba-15221\dosdevices\CQFO6Q~M\> pwd
Current directory is \\filur04.it.liu.se\staff\peter86\samba-15221\dosdevices\CQFO6Q~M\
smb: \peter86\samba-15221\dosdevices\CQFO6Q~M\> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The connection is disconnected now



In our smb.conf we have:

  follow symlinks = true
  wide links = false

Testing some more with smbclient:

With "follow symlinks = false" the c: / CQFO6Q~M doesn't show up.

With "wide links = true" it shows up but gives "NT_STATUS_OBJECT_NAME_INVALID"
(follow symlinks setting doesn't matter in that case)
Comment 7 Peter Eriksson 2022-11-02 10:51:40 UTC
> With "wide links = true" it shows up but gives "NT_STATUS_OBJECT_NAME_INVALID"
> (follow symlinks setting doesn't matter in that case)

... but it seems to sort-of work via Windows 10 file browser with the relative path. Sort of... Clicking on the "C:" I end up on the local machine C:\ :-)
Comment 8 Volker Lendecke 2022-11-02 10:58:48 UTC
Just tried this with your dirs and symlinks on Linux, but I can't reproduce the crash. Do you have any patches on top of plain 4.17.2? Can you share your smb.conf? I'll try on FreeBSD next.
Comment 9 Volker Lendecke 2022-11-02 11:38:41 UTC
FreeBSD 12.3p5 amd64 does not crash either. Would it be possible to set up a test system and let me in via ssh as root?
Comment 10 Peter Eriksson 2022-11-02 13:13:10 UTC
Created attachment 17611 [details]
smb.conf

Our smb.conf file.
Comment 11 Peter Eriksson 2022-11-02 14:08:07 UTC
We have some local patches but nothing that should affect this part of Samba. Anyway I rebuilt Samba now without any local patches - but still the same core dumps... Gcc 11.3.0


Umm... Some more background details about our systems:

FreeBSD 12.3-RELEASE-p8
Dell PowerEdge R730xd & R740xd servers with 512-768GB RAM
ZFS filesystems
Joined to AD (Windows servers) with 171683 (unix) users, 2974 (unix) groups.

Windows, MacOS & Linux users.
SMB, NFS & SFTP access to the files.
Comment 12 Volker Lendecke 2022-11-04 13:06:44 UTC
Created attachment 17626 [details]
Patch

This fixes the problem for me. Can you try?

Thanks for giving me access to a reproducer, this made it a lot simpler.
Comment 13 Peter Eriksson 2022-11-04 13:41:06 UTC
I can confirm that the patch seems to solve this core-dumping issue. Thanks!
Comment 14 Volker Lendecke 2022-11-04 16:33:54 UTC
Jule, can you merge this for 4.17.next? This is 4.17 only.

Thanks, Volker
Comment 15 Jule Anger 2022-11-08 08:20:22 UTC
Pushed to autobuild-v4-17-test.
Reviewed-By tag with Ralph added.
Comment 16 Samba QA Contact 2022-11-08 09:24:20 UTC
This bug was referenced in samba v4-17-test:

2803e76fba0ee0eb6bb7e0b7acaca5c397249941
Comment 17 Jule Anger 2022-11-08 13:11:54 UTC
Closing out bug report.

Thanks!