FSCTL_READ_FILE_USN_DATA on "SmartScreen" alternate data stream

[Jeremy Allison]

On Wed, Nov 09, 2022 at 12:58:07PM -0500, Andrew Walker via samba-technical wrote:
>Hey all,
>
>I just saw an smbd crash where we asserted here:
>```
>static NTSTATUS vfswrap_fsctl(struct vfs_handle_struct *handle,
>                              struct files_struct *fsp,
>                              TALLOC_CTX *ctx,
>                              uint32_t function,
>                              uint16_t req_flags, /* Needed for UNICODE ...
>*/
>                              const uint8_t *_in_data,
>                              uint32_t in_len,
>                              uint8_t **_out_data,
>                              uint32_t max_out_len,
>                              uint32_t *out_len)
>{
>        const char *in_data = (const char *)_in_data;
>        char **out_data = (char **)_out_data;
>        NTSTATUS status;
>
>        SMB_ASSERT(!fsp_is_alternate_stream(fsp));
>```
>
>Due to what appears to be a client sending FSCTL_READ_FILE_USN_DATA ioctl
>to a SmartScreen alternate data stream.
>
>```
>#6  0x00000008016d13be in vfswrap_fsctl (handle=0x816c73280,
>fsp=0x816c3d260, ctx=0x810398670, function=590059, req_flags=49217,
>_in_data=0x0, in_len=0, _out_data=0x7fffffffdfa0, max_out_len=320,
>    out_len=0x7fffffffe070)
>
>(gdb) p *fsp.fsp_name
>$3 = {base_name = 0x816c3e5c0 "System/Drivers/Peripherals/SoundBlaster
>X3/Drivers version 3.4.98.00/USBCMDMasterInstaller_3.4.98.00.exe",
>stream_name = 0x816c3e690 ":SmartScreen", flags = 0, st = {
>    st_ex_dev = 17440526963365876026, st_ex_ino = 13799128922567319488,
>st_ex_gen = 27211941, st_ex_file_id = 33830, st_ex_mode = 33272,
>st_ex_nlink = 1, st_ex_uid = 1000, st_ex_gid = 0,
>    st_ex_rdev = 18446744073709551615, st_ex_size = 7, st_ex_atime =
>{tv_sec = 1667955800, tv_nsec = 250523235}, st_ex_mtime = {tv_sec =
>1667955806, tv_nsec = 707597100}, st_ex_ctime = {
>      tv_sec = 1667955806, tv_nsec = 707691237}, st_ex_btime = {tv_sec =
>1667955801, tv_nsec = 825131076}, st_ex_itime = {tv_sec = 1667955801,
>tv_nsec = 825131076}, st_ex_blksize = 131072,
>    st_ex_blocks = 1, st_ex_flags = 2048, st_ex_iflags = 6}, twrp = 0, fsp
>= 0x816c3d260, fsp_link = 0x810237480}
>```
>
>Of course, it's a soundblaster driver file :))) has anyone else seen this
>behavior before from client? Perhaps we need to add fsctl hook to
>streams_xattr since this I think asserting here is probably a bit excessive
>(maybe pass along base fsp in this case)?

Can you give the entire call stack. Might be easier to
just change the upper level code to pass on metadata_fsp(fsp)
instead.

I don't think there's a case where an FSCTL/IOCTL is done
on an alternate stream fsp.