Thanks for the report! Marking as private until we've verified this and have decided how to act upon it.

OK, I've reproduced and have a prototype fix for this.

As this is in SMB1-only which is disabled by default I'm not sure this is CVE-worthy. It would be much easier to fix this in the open IMHO.

Ralph, what do you think ?

What's the behaviour when SMB1 UNIX extensions are not enabled with SMB1? Or with SMB2 directly? Do we return a consistent error for both cases there?

We do not. With SMB2-only doing an smbclient "get" we get:

NT_STATUS_ACCESS_DENIED for out of share
NT_STATUS_OBJECT_PATH_NOT_FOUND for dangling symlink.

But there's no way to tell under SMB2 that the file is a symlink, so I'd argue in that case there's no information leak.

Created attachment 17002 [details]
git-am fix for master.

Here's the prototype fix, under ci here:

https://gitlab.com/samba-team/devel/samba/-/pipelines/412064180

Hidden under an innocuous "jra-prepare-info-levels-for-smb2posix" tag until we decide if this is a CVE or not :-).

It prevents all SMB1+POSIX info levels if POSIX wasn't negotiated, and ensures we return NT_STATUS_OBJECT_NAME_NOT_FOUND from check_reduced_name(), as it doesn't matter *why* we can't get to a path, whether the symlink points outside the share or doesn't exist - we now return NT_STATUS_OBJECT_NAME_NOT_FOUND in both cases.

Comment on attachment 17002 [details]
git-am fix for master.

Hmmm. Still needs some work to make sure in some cases a dangling symlink is returned as NT_STATUS_OBJECT_NAME_NOT_FOUND. New fix + tests incoming.

Created attachment 17003 [details]
git-am fix for master.

Here's the full fix for master. Includes test POSIX-SYMLINK-ERRORCODE.

    Creates 3 symlinks:
    
    1). Within share pointing to non-existing target.
    2). Outside share but to existing target.
    3). Outside share but to non-existing target.
    
    It then tries to SMB1+POSIX stat these objects,
    all should succeed.
    
    It then tries to open via 3 methods:
    
    1). SMB1+POSIX cli_posix_open()
    2). SMB1 Windows cli_ntcreate()
    3). SMB2 Windows cli_ntcreate()
    
    Ensure we always get NT_STATUS_OBJECT_NAME_NOT_FOUND
    for all return codes.

I have this in ci as:

https://gitlab.com/samba-team/devel/samba/-/pipelines/412173629

Under the innocuous name of "jra-prepare-info-levels-for-smb2posix".

I'm inclined not to get a CVE for this as it's an information leak in a non-default configuration (SMB1 is off by default).

Comments ?

(In reply to Jeremy Allison from comment #7)

Just to clarify - the test creates 3 symlinks within the share (where /tmp is *outside* the share) that point to:

1). "nonexist_errorcode_symlink" -> "nonexist_errorcode_target".
2). "tmp_symlink" -> "/tmp"
3). "tmp_noexist_symlink" -> /tmp/XXX<num><num>.

and ensures that all 3 can successfully be "stat"ed by SMB1+POSIX, but opening by SMB1+POSIX, SMB1 without POSIX and SMB2 all return NT_STATUS_OBJECT_NAME_NOT_FOUND.

Hmm, the first part of the patch where I tighten up POSIX info level to be allowed only when POSIX has been negotiated break a few tests. I'm deciding if I need to fix the tests and keep that tightening or remove the first part of the patch..

I need to fix the tests. If we keep the ability to allow cli_posix_stat() on a connection that hasn't negotiated SMB1+POSIX, then we expose info as to whether the symlink exists or not via the error code (as without negotiated SMB1+POSIX pathnames Windows always tries to follow the symlink).

I have an updated patchset that fixes the tests and keeps the restriction on only allowing SMB1+POSIX info levels on SMB1+POSIX negotiated connections, I'll tidy up and post tomorrow.

Getting there (slowly). Main problem is there are some source4/ torture tests that use SMB1+POSIX info levels without negotiating POSIX first. I'm having to fix these first.

Created attachment 17007 [details]
git-am fix for master.

OK, this one fully passes ci ! Yay !!!!

https://gitlab.com/samba-team/devel/samba/-/pipelines/412886590

Most of the pain was finding all the places where we used SMB1+POSIX calls without first negotiating SMB1+POSIX and fixing them in the tests.

I checked with Steve French, and locally, and the Linux cifsfs client *always* negotiates SMB1+POSIX when configured to do so when connecting to a Samba share that offers it, so there's no chance that Linux clients send SMB1+POSIX calls without correctly setting it up first (phew).

This patchset I think eliminates all possibilities of information leak about smylink targets outside the share. We now always return NT_STATUS_OBJECT_NAME_NOT_FOUND for all symlinks outside the share when there is an attempt to open them via SMB1, SMB1+POSIX or SMB2+, whether they point to existing targets or not.

Listing them via SMB1+POSIX still works and returns their unix2 info as a symlink, and their contents can be queried, but there's no way a client can determine if their target is valid if it points outside of the share definition (of course if they point within the share definition then the path can be looked up by the client, by following it on the client side, as expected).

Stefan, can you confirm this fixes the problem please (test on current git master) ?

In order to run your test with smbclient you'll now need to explicitly request posix using the command "posix" before issuing the POSIX-specific "stat" calls.

Created attachment 17009 [details]
git-am fix for master

One more change, fixes smbclient to prompt users to use the "posix" command to set SMB1+POSIX before using the posix commands.

Hmmm. I think we will need a CVE for this, as knowledge of files external to the share can allow a user to guess the OS and version running Samba.

I will request one from Red Hat.

Created attachment 17010 [details]
git-am fix for master

Sorry, slight tidyup of the change to smbclient (only send the "you need POSIX" message after the parameter parsing passes for a command).

Requested a CVE number from Red Hat product security.

Comment on attachment 17010 [details]
git-am fix for master

Passes ci here:

https://gitlab.com/samba-team/devel/samba/-/pipelines/413256492

I'll create back-ports for 4.15.next, 4.14.next and see if I can make it fit 4.13.next.

Created attachment 17011 [details]
git-am fix for master.

Sorry, last tweak to incorrect error message for cmd_sylink in smbclient. I'll stop messing with it now until Monday :-).

Created attachment 17012 [details]
git-am fix for master.

Sorry, I missed the warning inside the "lock" and "unlock" smbclient commands. Hopefully this is the last change I need.

(In reply to Jeremy Allison from comment #13)
Jeremy, thanks for working on this issue! However, unfortunately your patch-set doesn't fix it, or I made something wrong.

The part "# test with an old smbclient" is the one to look at.


# build with the patch-set on top of the git master
berry@pennern ~/git/samba $ uname -a
Linux pennern 5.14.16-301.fc35.x86_64 #1 SMP Wed Nov 3 13:55:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
berry@pennern ~/git/samba $ git remote add gitlab-devel https://gitlab.com/samba-team/devel/samba.git
berry@pennern ~/git/samba $ git fetch gitlab-devel
berry@pennern ~/git/samba $ git reset --hard 46d287002c3d766f9c24cc21a6185865cf2c6501
HEAD is now at 46d287002c3 s3: smbd: For SMB1+POSIX clients trying to open a symlink, always return NT_STATUS_OBJECT_NAME_NOT_FOUND.
berry@pennern ~/git/samba $ ./buildtools/bin/waf configure --prefix=/var/tmp/samba-berry/ --enable-debug --fatal-errors --without-ad-dc |& tee -a configure.out
berry@pennern ~/git/samba $ WAF_MAKE=1 ./buildtools/bin/waf -v -j5 build |& tee -a build.out
berry@pennern ~/git/samba $ WAF_MAKE=1 ./buildtools/bin/waf -v -j1 install |& tee -a install.out

# testing
[root@pennern ~]# /var/tmp/samba-berry/sbin/smbd --version
Version 4.16.0pre1-GIT-46d287002c3
[root@pennern ~]# /var/tmp/samba-berry/sbin/smbd --debug-stdout -F --configfile=/var/tmp/samba-berry/etc/smb.conf -i -d666
berry@pennern ~/git/samba $ /var/tmp/samba-berry/bin/smbclient --version
Version 4.16.0pre1-GIT-46d287002c3
berry@pennern ~/git/samba $ /var/tmp/samba-berry/bin/smbclient -U e2e%e2e //localhost/e2e -m NT1
smb: \> dir
  .                                   D        0  Thu Nov 18 11:30:29 2021
  ..                                  D        0  Thu Jul 22 01:47:06 2021
  motd                                A       23  Thu Nov 18 11:27:06 2021

                999320 blocks of size 1024. 904236 blocks available
smb: /> stat l2motd
Command "posix" must be issued before the "stat" command can be used.
smb: /> stat l2etcnotthere
Command "posix" must be issued before the "stat" command can be used.
smb: \> posix
Server supports CIFS extensions 1.0
Server supports CIFS capabilities locks acls pathnames posix_path_operations large_read posix_encrypt
smb: /> dir
  .                                            0  Thu Nov 18 11:30:29 2021
  ..                                  D        0  Thu Jul 22 01:47:06 2021
  l2motd                              N        9  Thu Nov 18 11:29:43 2021
  motd                                        23  Thu Nov 18 11:27:06 2021
  l2etcnotthere                       N       13  Thu Nov 18 11:30:29 2021

                999320 blocks of size 1024. 904236 blocks available
smb: /> stat motd
File: /motd
Size: 23                Blocks: 8       regular file
Inode: 40       Links: 1
Access: (0766/-rwxrw-rw-)       Uid: 32695      Gid: 32695
Access: 2021-11-18 11:30:02 +0100
Modify: 2021-11-18 11:27:06 +0100
Change: 2021-11-18 11:27:06 +0100
smb: /> stat l2motd
File: /l2motd
Size: 9                 Blocks: 0       symbolic link
Inode: 659      Links: 1
Access: (0777/lrwxrwxrwx)       Uid: 0  Gid: 0
Access: 2021-11-21 11:30:12 +0100
Modify: 2021-11-18 11:29:43 +0100
Change: 2021-11-18 11:29:43 +0100
smb: /> stat l2etcnotthere
File: /l2etcnotthere
Size: 13                Blocks: 0       symbolic link
Inode: 741      Links: 1
Access: (0777/lrwxrwxrwx)       Uid: 0  Gid: 0
Access: 2021-11-21 12:30:02 +0100
Modify: 2021-11-18 11:30:29 +0100
Change: 2021-11-18 11:30:29 +0100
smb: /> readlink l2motd
/l2motd -> /etc/motd
smb: /> readlink l2etcnotthere
/l2etcnotthere -> /etc/notthere

# test with an old smbclient
[root@pennern ~]# /var/tmp/samba-berry/sbin/smbd --debug-stdout -F --configfile=/var/tmp/samba-berry/etc/smb.conf -i -d666
berry@pennern ~/git/samba $ smbclient --version
Version 4.15.1
berry@pennern ~/git/samba $ smbclient -U e2e%e2e //localhost/e2e -m NT1
smb: \> dir
  .                                   D        0  Thu Nov 18 11:30:29 2021
  ..                                  D        0  Thu Jul 22 01:47:06 2021
  motd                                A       23  Thu Nov 18 11:27:06 2021

                999320 blocks of size 1024. 904236 blocks available
smb: \> stat l2motd
NT_STATUS_ACCESS_DENIED stat file \l2motd
smb: \> stat l2etcnotthere
File: \l2etcnotthere
Size: 13                Blocks: 0       symbolic link
Inode: 741      Links: 1
Access: (0777/lrwxrwxrwx)       Uid: 0  Gid: 0
Access: 2021-11-21 12:30:02 +0100
Modify: 2021-11-18 11:30:29 +0100
Change: 2021-11-18 11:30:29 +0100
smb: \> posix
Server supports CIFS extensions 1.0
Server supports CIFS capabilities locks acls pathnames posix_path_operations large_read posix_encrypt
smb: /> dir
  .                                            0  Thu Nov 18 11:30:29 2021
  ..                                  D        0  Thu Jul 22 01:47:06 2021
  l2motd                              N        9  Thu Nov 18 11:29:43 2021
  motd                                        23  Thu Nov 18 11:27:06 2021
  l2etcnotthere                       N       13  Thu Nov 18 11:30:29 2021

                999320 blocks of size 1024. 904236 blocks available
smb: /> stat motd
File: /motd
Size: 23                Blocks: 8       regular file
Inode: 40       Links: 1
Access: (0766/-rwxrw-rw-)       Uid: 32695      Gid: 32695
Access: 2021-11-18 11:30:02 +0100
Modify: 2021-11-18 11:27:06 +0100
Change: 2021-11-18 11:27:06 +0100
smb: /> stat l2motd
File: /l2motd
Size: 9                 Blocks: 0       symbolic link
Inode: 659      Links: 1
Access: (0777/lrwxrwxrwx)       Uid: 0  Gid: 0
Access: 2021-11-21 11:30:12 +0100
Modify: 2021-11-18 11:29:43 +0100
Change: 2021-11-18 11:29:43 +0100
smb: /> stat etcnotthere
NT_STATUS_OBJECT_NAME_NOT_FOUND stat file /etcnotthere
smb: /> stat l2etcnotthere
File: /l2etcnotthere
Size: 13                Blocks: 0       symbolic link
Inode: 741      Links: 1
Access: (0777/lrwxrwxrwx)       Uid: 0  Gid: 0
Access: 2021-11-21 12:30:02 +0100
Modify: 2021-11-18 11:30:29 +0100
Change: 2021-11-18 11:30:29 +0100
smb: /> readlink l2motd
/l2motd -> /etc/motd
smb: /> readlink l2etcnotthere
/l2etcnotthere -> /etc/notthere

# test with the kernel cifs module, seems to work well
[root@pennern ~]# /var/tmp/samba-berry/sbin/smbd --debug-stdout -F --configfile=/var/tmp/samba-berry/etc/smb.conf -i -d666
[root@pennern ~]# umount /mnt/cifs; PASSWD=e2e mount -t cifs //localhost/e2e /mnt/cifs --verbose -o username=e2e,port=445,vers=1.0
[root@pennern samba-berry]# ls -alF /mnt/cifs
total 9
drwxrwxrwx   2 root root    0 Nov 18 11:30 ./
drwxr-xr-x. 14 root root 4096 Jul 22 01:47 ../
lrwxrwxrwx   1 root root   13 Nov 18 11:30 l2etcnotthere -> /etc/notthere
lrwxrwxrwx   1 root root    9 Nov 18 11:29 l2motd -> /etc/motd
-rwxrw-rw-   1 e2e  e2e    23 Nov 18 11:27 motd*

# build without the patch-set
berry@pennern ~/git/samba $ git reset --hard remotes/gitlab-devel/master
HEAD is now at 1926335839a third_party/update: forget pep8
berry@pennern ~/git/samba $ ./buildtools/bin/waf configure --prefix=/var/tmp/samba-berry/ --enable-debug --fatal-errors --without-ad-dc |& tee -a configure.out
berry@pennern ~/git/samba $ WAF_MAKE=1 ./buildtools/bin/waf -v -j5 build |& tee -a build.out
berry@pennern ~/git/samba $ WAF_MAKE=1 ./buildtools/bin/waf -v -j1 install |& tee -a install.out

# test without the patch-set
[root@pennern ~]# /var/tmp/samba-berry/sbin/smbd --version
Version 4.16.0pre1-GIT-1926335839a
[root@pennern ~]# /var/tmp/samba-berry/sbin/smbd --debug-stdout -F --configfile=/var/tmp/samba-berry/etc/smb.conf -i -d666
berry@pennern ~/git/samba $ /var/tmp/samba-berry/bin/smbclient --version
Version 4.16.0pre1-GIT-1926335839a
berry@pennern ~/git/samba $ /var/tmp/samba-berry/bin/smbclient -U e2e%e2e //localhost/e2e -m NT1
smb: \> dir
  .                                   D        0  Thu Nov 18 11:30:29 2021
  ..                                  D        0  Thu Jul 22 01:47:06 2021
  motd                                A       23  Thu Nov 18 11:27:06 2021

                999320 blocks of size 1024. 904236 blocks available
smb: \> stat l2motd
NT_STATUS_ACCESS_DENIED stat file \l2motd
smb: \> stat l2etcnotthere
File: \l2etcnotthere
Size: 13                Blocks: 0       symbolic link
Inode: 741      Links: 1
Access: (0777/lrwxrwxrwx)       Uid: 0  Gid: 0
Access: 2021-11-21 12:30:02 +0100
Modify: 2021-11-18 11:30:29 +0100
Change: 2021-11-18 11:30:29 +0100

# test with the kernel cifs module, seems to work well
[root@pennern ~]# /var/tmp/samba-berry/sbin/smbd --debug-stdout -F --configfile=/var/tmp/samba-berry/etc/smb.conf -i -d666
[root@pennern ~]# umount /mnt/cifs; PASSWD=e2e mount -t cifs //localhost/e2e /mnt/cifs --verbose -o username=e2e,port=445,vers=1.0
[root@pennern samba-berry]# ls -alF /mnt/cifs
otal 9
drwxrwxrwx+  2 root root    0 Nov 18 11:30 ./
drwxr-xr-x. 14 root root 4096 Jul 22 01:47 ../
lrwxrwxrwx   1 root root   13 Nov 18 11:30 l2etcnotthere -> /etc/notthere
lrwxrwxrwx   1 root root    9 Nov 18 11:29 l2motd -> /etc/motd
-rwxrw-rw-+  1 e2e  e2e    23 Nov 18 11:27 motd*

Stefan, can you check that you are building your smbd with the patch here:

https://bugzilla.samba.org/attachment.cgi?id=17012

(that is the patch from comment number #20).

I can't reproduce your NT_STATUS_ACCESS_DENIED error with that fix running with an smbd with that patch applied.

Here are the contents of my "btest" share directory, with everything set to match your setup from comment number 21:

$ ls -l /tmp/btest
total 0
lrwxrwxrwx 1 jeremy jeremy 13 Nov 22 09:13 l2etcnotthere -> /etc/notthere
lrwxrwxrwx 1 jeremy jeremy  9 Nov 22 09:12 l2motd -> /etc/motd
-rw-rw-r-- 1 jeremy jeremy  0 Nov 22 09:14 motd

My smb.conf in its entirety:

---------------------------------------
[global]
        server min protocol = NT1
        client min protocol = NT1
        unix extensions = yes

[btest]
        path = /tmp/btest
        read only = no
---------------------------------------

# /usr/local/samba/sbin/smbd --debug-stdout -F --configfile=/home/jeremy/tmp/smb.conf -i

Trying with 2 versions. Test #1 - the system smbclient (version 4.13.14-Ubuntu):

------------------------------------------------------------------------------
$ /usr/bin/smbclient --version
Version 4.13.14-Ubuntu

$ /usr/bin/smbclient //127.0.0.1/btest -Ujeremy%pass -mNT1
Try "help" to get a list of possible commands.
smb: \> dir
  .                                   D        0  Mon Nov 22 09:14:50 2021
  ..                                  D        0  Mon Nov 22 09:25:03 2021
  motd                                N        0  Mon Nov 22 09:14:50 2021

		4841942976 blocks of size 1024. 3035160692 blocks available
smb: \> stat l2motd
NT_STATUS_INVALID_LEVEL stat file \l2motd
smb: \> posix
Server supports CIFS extensions 1.0
Server supports CIFS capabilities locks acls pathnames posix_path_operations large_read posix_encrypt
smb: /> dir
  .                                            0  Mon Nov 22 09:14:50 2021
  ..                                  D        0  Mon Nov 22 09:31:43 2021
  l2motd                              N        9  Mon Nov 22 09:12:55 2021
  motd                                         0  Mon Nov 22 09:14:50 2021
  l2etcnotthere                       N       13  Mon Nov 22 09:13:08 2021

		4841942976 blocks of size 1024. 3034844224 blocks available
smb: /> stat l2motd
File: /l2motd
Size: 9           	Blocks: 0	symbolic link
Inode: 113967214	Links: 1
Access: (0777/lrwxrwxrwx)	Uid: 1000	Gid: 1000
Access: 2021-11-22 09:13:10 -0800
Modify: 2021-11-22 09:12:55 -0800
Change: 2021-11-22 09:12:55 -0800
------------------------------------------------------------------------------

Test #2 - newly built 4.15.1 smbclient
------------------------------------------------------------------------------
$ bin/smbclient --version
Version 4.15.1

lpcfg_do_global_parameter: WARNING: The "domain logons" option is deprecated
Try "help" to get a list of possible commands.
smb: \> dir
  .                                   D        0  Mon Nov 22 09:14:50 2021
  ..                                  D        0  Mon Nov 22 09:35:03 2021
  motd                                N        0  Mon Nov 22 09:14:50 2021

		4841942976 blocks of size 1024. 3034699080 blocks available
smb: \> stat l2motd
NT_STATUS_INVALID_LEVEL stat file \l2motd
smb: \> posix
Server supports CIFS extensions 1.0
Server supports CIFS capabilities locks acls pathnames posix_path_operations large_read posix_encrypt
smb: /> dir
  .                                            0  Mon Nov 22 09:14:50 2021
  ..                                  D        0  Mon Nov 22 09:35:03 2021
  l2motd                              N        9  Mon Nov 22 09:12:55 2021
  motd                                         0  Mon Nov 22 09:14:50 2021
  l2etcnotthere                       N       13  Mon Nov 22 09:13:08 2021

		4841942976 blocks of size 1024. 3034698564 blocks available
smb: /> stat l2motd
File: /l2motd
Size: 9           	Blocks: 0	symbolic link
Inode: 113967214	Links: 1
Access: (0777/lrwxrwxrwx)	Uid: 1000	Gid: 1000
Access: 2021-11-22 09:13:10 -0800
Modify: 2021-11-22 09:12:55 -0800
Change: 2021-11-22 09:12:55 -0800

------------------------------------------------------------------------------

Note both old smbclient versions (4.13.14-Ubuntu and 4.15.1) get NT_STATUS_INVALID_LEVEL against the patched smbd when trying to do a posix "stat" call without first switching the server into SMB1+POSIX mode.

This is the key difference which makes me think you're building with an older patchset is you're not seeing the NT_STATUS_INVALID_LEVEL error when doing the smbclient "stat" call. You see NT_STATUS_ACCESS_DENIED.

The latest patchset refuses to allow posix calls until "posix" has been selected. The reason is posix calls deal with symlinks differently on open (as you discovered).

The relevant code change inside source3/smbd/trans2.c should look like this:

        if (INFO_LEVEL_IS_UNIX(info_level)) {
                if (!lp_unix_extensions()) {
                        return NT_STATUS_INVALID_LEVEL;
                }
                if (!req->posix_pathnames) {
                        return NT_STATUS_INVALID_LEVEL;
                }
        }

The old code has:

                if (!lp_unix_extensions()) {
                        return NT_STATUS_INVALID_LEVEL;
                }

the new change is the addition of the clause:

                if (!req->posix_pathnames) {
                        return NT_STATUS_INVALID_LEVEL;
                }
which should prevent any SMB1+POSIX calls without setting "posix" mode first.

Can you re-test with this patch:

https://bugzilla.samba.org/attachment.cgi?id=17012

and confirm please ? Thanks ! Jeremy.

OK, I can see one case where I missed the NT_STATUS_ACCESS_DENIED -> NT_STATUS_OBJECT_NAME_NOT_FOUND.

That is in the function check_reduced_name_with_privilege(), but I can't see how you might be getting into that function.

Anyway, I've fixed it there too and will upload a new patch version.

Created attachment 17014 [details]
git-am fix for master.

Change from previous version - fixed error code returns in check_reduced_name_with_privilege() as well as check_reduced_name().

OK Stefan, can you please test with:

https://bugzilla.samba.org/attachment.cgi?id=17014

I also fixed the NT_STATUS_ACCESS_DENIED -> NT_STATUS_OBJECT_NAME_NOT_FOUND error return in check_reduced_name_with_privilege().

If you can still reproduce the NT_STATUS_ACCESS_DENIED for 'stat l2motd' in an old smbclient I'll need access to the debug level 10 logs to see where this might be coming from. Thanks ! Jeremy.

Stefan, one more thing. Can you not use the gitlab repo to get the patch. Please download and use the patchsets uploaded to this bug report and apply them on top of Samba git master. I don't yet trust gitlab to give you the right thing :-).

So recap, please build by doing:

Download the latest patchset uploaded to this bug (as of this comment, that patchset is:

https://bugzilla.samba.org/attachment.cgi?id=17014

Should end up as ~/Downloads/bug-14911-master

$ git clone git://git.samba.org/samba.git samba-master
$ cd samba-master
$ git am ~/Downloads/bug-14911-master

Then build and test. That way I can guarantee you're using the fix I am too.

Thanks!

Jeremy.

Jeremy, I must apologise. According to my logs, a reboot of the VM was the point in time when I messed up my setup and afterwards I was testing the wrong smbd. Sorry for that confusion! The new smbd is returning NT_STATUS_INVALID_LEVEL, the issue is gone. Thank you for fixing the issue!

Oh thank goodness, that's a relief :-). I'll stop testing the patches on gitlab-ci know we know we're going to issue a security release. I'll upload a new patchset containing the bugid and CVE number to this bug report, and start writing the CVE text.

I'll start looking at back-ports for 4.15.next, 4.14.next and 4.13.next. Might not be possible to back-port to 4.14.next or 4.13.next though as some of this may depend on the open code changes that went solely into 4.15.0.

If the changes won't back-port safely I'll add mitigations of keeping SMB1 and POSIX turned off for the previous releases.

Thanks for your help ! Jeremy.

https://bugzilla.samba.org/attachment.cgi?id=17014

Still passes ci:

https://gitlab.com/samba-team/devel/samba/-/pipelines/414078105

I'll write up the CVE text and see if I can get Ralph to review the code.

Stefan, how would you like to be credited in the CVE advisory ?

(In reply to Jeremy Allison from comment #30)
About the question, how to be credited:
Stefan Behrens <sbehrens@giantdisaster.de>

Nothing else. This is a personal email address that I use for work on open source things. I'm paid for the work, the company is using open source and is actively contributing to open source projects, but I think it's OK like this. Thanks.

Created attachment 17015 [details]
Provisional CVE text.

This one is ready for review. Once you've OK'ed the code changes I can prepare back ports.

Created attachment 17016 [details]
git-am fix for master.

Now contains CVE number and bugid. No other changes (only commit message changes).

Created attachment 17017 [details]
git-am fix for 4.15.next.

Back-port to 4.15 was just cherry-picking, no reason not to do it already :-).

Jim and Andreas, wanted to give you a heads-up on this one. Is there a timeframe for the fix that works for you both ?

Comment on attachment 17017 [details]
git-am fix for 4.15.next.

Please remove the cherry-picked tags. They are misleading as they point at local commits.

Created attachment 17018 [details]
git-am fix for 4.15.next.

New version for 4.15.next without the cherry-pick tags.

Created attachment 17019 [details]
git-am fix for 4.14.next.

Back port.

Created attachment 17020 [details]
git-am fix for 4.13.next.

Back-port from 4.14.next patch. Look at the last few changes a little more closely as they (by necessity) had to be a little different from the 4.14 fix. Not too much though.

Comment on attachment 17019 [details]
git-am fix for 4.14.next.

4.14.x and 4.13.x patches don't work to hide the errors correctly. I'm investigating.

Created attachment 17021 [details]
git-am fix for 4.14.next.

This version passes the error checks correctly and behaves the same as the master and 4.15 versions. Needed a slight tweak in the last patch to bring back some logic that went into 4.15.

The logic in 4.13 is different enough it might not be possible to fix it here. Currently in 4.13, doing a simple 'dir' command in smbclient is enough to show the difference between symlinks that point to a valid target and ones that do not. I may have to fix the dir replies first.

Let me know if a 4.13 fix is needed, as that will take more work.

The reason 4.13 doesn't work, is that it doesn't have open_pathref_fsp() which is used in 4.14 and above to open a handle on all directory entries when listing them.

It is that function that allows the directory listing code to determine if an symlink object is within or without the share definition, thus allowing it not to be shown for a Windows SMB1/2/3 directory listing, but always shown for a SMB1+POSIX directory listing.

Created attachment 17022 [details]
git-am fix for 4.13.next.

I think I finally have a working back-port for 4.13.next. W00t! Took a while.

I needed more testing infrastructure to make sure I hadn't broken anything, luckily Ralph had already written these tests for 4.14.next so they were easy to back port.

Then I needed to find a way, without having openat_pathref_fsp(), to restrict the items seen in a directory enumeration only to symlinks pointing within the share and MSDFS links for Windows SMB1/2/3, and to allow all symlinks for SMB1+POSIX.

The results of that can be seen in patches:

[PATCH 08/25] CVE-2021-44141: s3: smbd: dir.c: Fix directory listing to use vfs_stat() calls.
[PATCH 09/25] CVE-2021-44141: s3: smbd: findfirst. Fix POSIX-LS-WILDCARD test.

They're subtle, but they pass all the tests I have given them, and they make 4.13 behave identically in listing directories via SMB1/2/3 or SMB1+POSIX to 4.14 and above.

And with this posted, I can finally ignore this bug (at least until next week) and have a pleasant family Thanksgiving :-).

I spoke too soon. I had another idea for a thought experiment, and found that doing:

smbclient //localhost/share -Uuser%pass -c "ls [TARGETFILE]"

even with my patches for master, 4.15.next, 4.14.next and 4.13.next will give different errors depending on whether [TARGETFILE] symlinks to an existing file or not.

I get (in master+patch, 4.15+patch, 4.14+patch and 4.13_patch):

NT_STATUS_OBJECT_NAME_NOT_FOUND for an existing [TARGETFILE] (pointing outside the share to an existing "/etc/shadow").

NT_STATUS_NO_SUCH_FILE for a non-existing [TARGETFILE] (pointing to outside the share to a non-existing "/etc/nowhere").

NT_STATUS_OBJECT_PATH_NOT_FOUND for a non-existing [TARGETFILE] (pointing within the share to a non-existing target "non-existing-localfile").

It's the client sending the specific wildcard name inside call_trans2findfirst() instead of "*" that causes the different processing. I'll examine further tomorrow, but I'll need to add an updated test and a further fix to nail this completely I think.

OK, I think I have a solution that's not too disruptive to the patches (a couple of additional patches on top, including test). I'll code this up and try and upload today. If not it'll have to be next Monday (Nov 29th) due to USA Thanksgiving Holiday.

More tests, more tests. I have something working now. Will probably not get to this until Monday though.

Behavior against Windows 10 -share containing nothing but an empty directory "emptydir".

smb: \> get notthere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \notthere
smb: \> get notthere\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \notthere\foo
smb: \> get notthere\*\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \notthere\*\foo
smb: \> get *\foo
NT_STATUS_OBJECT_NAME_INVALID opening remote file \*\foo
smb: \> get emptydir\foo
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \emptydir\foo
smb: \> get emptydir\*
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\*
smb: \> get *
NT_STATUS_OBJECT_NAME_INVALID opening remote file \*
smb: \> get emptydir\notthere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \emptydir\notthere
smb: \> get emptydir\*\notthere
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\*\notthere
smb: \> get emptydir\notthere\bar
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \emptydir\notthere\bar

Behavior with SMB2 against current master with a share set up in the same way:

smb: \> get notthere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \notthere
smb: \> get notthere\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \notthere\foo
smb: \> get notthere\*\foo
NT_STATUS_OBJECT_NAME_INVALID opening remote file \notthere\*\foo
smb: \> get *\foo
NT_STATUS_OBJECT_NAME_INVALID opening remote file \*\foo
smb: \> get emptydir\foo
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \emptydir\foo
smb: \> get emptydir\*
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\*
smb: \> get *
NT_STATUS_OBJECT_NAME_INVALID opening remote file \*
smb: \> get emptydir\notthere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \emptydir\notthere
smb: \> get emptydir\*\notthere
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\*\notthere
smb: \> get emptydir\notthere\bar
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \emptydir\notthere\bar

The only difference is with: "get notthere\*\foo" which returns NT_STATUS_OBJECT_NAME_INVALID against smbd and NT_STATUS_OBJECT_PATH_NOT_FOUND against Windows.

Now we need to make sure that doing the same calls against (1) symlinks pointing nowhere (2) symlinks pointing outside the share, but to existing objects (both files and directories) behave as though we were asking for a path component of "notthere".

Test this for these two cases at the root of the share and inside the "emptydir" directory.

One more test (3). Symlinks pointing outside the share, but to a non-existent object (e.g. -> /etc/foobar).

Test over SMB2 against current master:

Trying to get via a symlink that points nowhere (but within the share).

link-nowhere -> noooo
emptydir/link-nowhere -> noooo

smb: \> get link-nowhere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \link-nowhere
smb: \> get link-nowhere\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \link-nowhere\foo
smb: \> get link-nowhere\*
NT_STATUS_OBJECT_NAME_INVALID opening remote file \link-nowhere\*
smb: \> get link-nowhere\*\foo
NT_STATUS_OBJECT_NAME_INVALID opening remote file \link-nowhere\*\foo
smb: \> 
smb: \> get emptydir\link-nowhere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \emptydir\link-nowhere
smb: \> get emptydir\link-nowhere\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \emptydir\link-nowhere\foo
smb: \> get emptydir\link-nowhere\*
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\link-nowhere\*
smb: \> get emptydir\link-nowhere\*\foo
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\link-nowhere\*\foo

ERROR-CODES-TO-MATCH !

I need to make sure that the error codes returned when trying to transit the symlinks that point outside the share, whether to existing files, directories, or non-existent objects are the same as for the previous case of using "notthere", "emptydir\nottthere" or the non-existent symlink pointing within the share of "link-nowhere" and "emptydir\link-nowhere".

To recap, the "correct" error codes for notthere, emptydir\nottthere (and link-nowhere, emptydir\link-nowhere as these are currently the same) are:

Root of share:

smb: \> get notthere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \notthere
smb: \> get notthere\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \notthere\foo
smb: \> get notthere\*
NT_STATUS_OBJECT_NAME_INVALID opening remote file \notthere\*
smb: \> get notthere\*\foo
NT_STATUS_OBJECT_NAME_INVALID opening remote file \notthere\*\foo

Subdirectory in share:

smb: \> get emptydir\notthere
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \emptydir\notthere
smb: \> get emptydir\notthere\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \emptydir\notthere\foo
smb: \> get emptydir\notthere\*
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\notthere\*
smb: \> get emptydir\notthere\*\foo
NT_STATUS_OBJECT_NAME_INVALID opening remote file \emptydir\notthere\*\foo

(the error codes are identical if "notthere" is replaced with "link-nowhere" in all 8 tests).

Current (BAD) errors for link-etc -> /etc

smb: \> get link-etc
NT_STATUS_ACCESS_DENIED opening remote file \link-etc
smb: \> get link-etc\foo
NT_STATUS_ACCESS_DENIED opening remote file \link-etc\foo
smb: \> get emptydir\link-etc
NT_STATUS_ACCESS_DENIED opening remote file \emptydir\link-etc
smb: \> get emptydir\link-etc\foo
NT_STATUS_ACCESS_DENIED opening remote file \emptydir\link-etc\foo

(all of the '*' tests for link-etc correctly return NT_STATUS_OBJECT_NAME_INVALID).

Current (GOOD) errors for link-etc-foobar -> /etc/foobar (a non existent object in /etc).

smb: \> get link-etc-foobar
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \link-etc-foobar
smb: \> get link-etc-foobar\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \link-etc-foobar\foo

smb: \> get emptydir\link-etc-foobar
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \emptydir\link-etc-foobar
smb: \> get emptydir\link-etc-foobar\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \emptydir\link-etc-foobar\foo

(all of the '*' tests for link-etc-foobar correctly return NT_STATUS_OBJECT_NAME_INVALID).

Current (BAD) errors for link-etc-passwd -> /etc/passwd (an existing file in /etc).

smb: \> get link-etc-passwd
NT_STATUS_ACCESS_DENIED opening remote file \link-etc-passwd
smb: \> get link-etc-passwd\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \link-etc-passwd\foo

smb: \> get emptydir\link-etc-passwd
NT_STATUS_ACCESS_DENIED opening remote file \emptydir\link-etc-passwd
smb: \> get emptydir\link-etc-passwd\foo
NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \emptydir\link-etc-passwd\foo

(all of the '*' tests for link-etc-passwd correctly return NT_STATUS_OBJECT_NAME_INVALID).

Working on comprehensive smbclient-based testsuite (that's easier to script and expand as needed). I think I have a working patchset for master, but the test suite will make sure.

Please note the patches in:

https://bugzilla.samba.org/attachment.cgi?id=17016
https://bugzilla.samba.org/attachment.cgi?id=17018
https://bugzilla.samba.org/attachment.cgi?id=17021
https://bugzilla.samba.org/attachment.cgi?id=17022

are *NOT* sufficient to fix this bug. I'm still working on a complete fix. Sorry if people missunderstood.

Patchset:

https://gitlab.com/samba-team/samba/-/merge_requests/2276

is a prerequisite for the fixes for this bug. Just wanted to keep everyone up to date on my current plans.

The code that passes ci here:

https://gitlab.com/samba-team/devel/samba/-/pipelines/422481784

shows where I'm going with this. Once this is in, we have only filename_convert() to consider for error code returns as all opens for all SMB1, SMB1+POSIX or SMB2+ paths go through this.

Created attachment 17052 [details]
git-am fix for master.

This is the complete fix for master. I still need to find a private area to run it through ci.

The new tests are:

source3/script/tests/test_symlink_traversal_smb2.sh
source3/script/tests/test_symlink_traversal_smb1.sh
source3/script/tests/test_symlink_traversal_smb1_posix.sh

and they are as comprehensive as I could make them.

FYI, patches #1 - #78 are the preparatory work that can go upstream once it's reviewed.

The actual fix for this bug is only in patches #79 - 81.

Jeremy Allison wrote:

> FYI, patches #1 - #78 are the preparatory work that can go upstream once it's
> reviewed.
>
> The actual fix for this bug is only in patches #79 - 81.

Oh sorry, that's not quite correct.

Patches #1 - #74 are the preparatory work. This can be upstreamed first.

Patches #75 - #78 are the new torture tests and one existing test change for this bug.

Patches #79 - #81 are the actual bugfix.

Patches #1 - #74 are the preparatory work.

Passes ci at:

https://gitlab.com/samba-team/devel/samba/-/pipelines/424727199

Full patchset is under ci in the Catalyst cloud security gitlab.

Comment on attachment 17052 [details]
git-am fix for master.

Missed a test changing return code, found in catalyst ci run.

samba3.smbtorture_s3.plain.POSIX, old code expects NT_STATUS_OBJECT_PATH_NOT_FOUND when doing an open of posix:symlink. Now we should expect NT_STATUS_OBJECT_NAME_NOT_FOUND instead as it's a terminal path component.

I'll fix and re-run the ci, and re-upload once it's passing.

Created attachment 17053 [details]
git-am fix for master.

This version passes all tests in a private autobuild (autobuild-private-security.sh) on the Samba autobuild host.

As before:

#1 - #74 - prep work.
#75 - #79 - tests and test fixes for the new error returns.
#80 - #82 - Actual bug fixes for this bug.

Sigh. One more thought experiment shows I need one more test and fix, so as not to leak destination information existence across a SMB1+POSIX rename with a symlink destination target. One more test and fix incoming.

Running the new patchset through a private security autobuild. Also ran shellcheck on the new tests and made them clean.

Created attachment 17056 [details]
git-am fix for master.

Passes autobuild cleanly. I think this is finished for master and is ready for review.

State of patchset:

#1 - #74 - prep work (should be pushed before CVE announced).

#75 - #85 - CVE fixes including extra tests.

Passes ci here:

https://gitlab.catalyst.net.nz/samba/samba.org-security-patches/-/pipelines/325689

Comment on attachment 17056 [details]
git-am fix for master.

Note that patches #1 - #38 have already gone into master. I'll re-upload a master patchset with these parts removed to keep tracking progress.

Created attachment 17057 [details]
git-am fix for master.

Down to 54 patches. Once https://gitlab.com/samba-team/samba/-/merge_requests/2293 goes in it will shrink more.

Wildcard removal from filename_convert() MR:

https://gitlab.com/samba-team/samba/-/merge_requests/2293

Posix info level MR:

https://gitlab.com/samba-team/samba/-/merge_requests/2295

pre-requisites for this bug.

Created attachment 17058 [details]
git-am fix for 4.15.next.

This is the complete patchset back-ported for 4.15.

Passes a private security autobuild.

Jim and Andreas, can you let me know if you think this is a priority to back port prior to 4.15.next ?

The patchset for 4.15 is 92-patches long, and it will get harder to fix the further back we go.

As it's an information leak rather than a out-of-share access I'm hoping we can keep this 4.15 only. It can be mitigated by not sharing via SMB1 or POSIX and not allowing concurrent sharing via NFS.

Thoughts ?

From Andreas @ Red Hat.

------------------------------------
We only plan to fix this with RHEL 8.6 which will have Samba 4.15. We do not
plan to address this in older versions as the other SMB1 unix extension
related bug can't be fixed in older version anyway. So to be secure you need
to disable this or have a server with a single share and selinux protection.
The issues are only moderate.


I guess the same applies to SUSE.


Hope that helps ...


        Andreas
------------------------------------

Created attachment 17059 [details]
git-am fix for master.

Minimal (10 patches only) fix for master now the pre-requisites have gone in. Thanks a *LOT* Ralph for pushing the re-requisites.

Created attachment 17060 [details]
Updated CVE text .

Updated CVE text explaining this will be fixed in 4.15.4 only.

Do we have a release date for this one ?

Release date set for January 31st. Shall we open to vendors now ?

(In reply to Jeremy Allison from comment #80)
10 days before the release, so on Friday.

Opening up to vendors. Release date is January 31st.

Hello list,

I would like to make a suggestion:
would it be possible to postpone the release date a week later until Feb/7?
Jan/31 is Chinese(Lunar) New Year's Eve, people might have limited access 
to email and a bit hard to apply patches during Spring Festival,
please consider this request. Thanks!

Created attachment 17129 [details]
git-am fix for master and 4.16

Identical to the git-am master fix. Just wanted to make sure we cover the new 4.16.rc release as well.

(In reply to Jones Syue from comment #83)
ohh okay now i see :)
https://bugzilla.samba.org/show_bug.cgi?id=14914#c55

Comment on attachment 17060 [details]
Updated CVE text .

Jeremy, can you bump the version numbers to the actual release which is 4.15.5 afair?

The 4.15 patch does not apply on samba-4.15.4

$ git am -3 CVE-2021-44141-v415.patch
...
Applying: CVE-2021-44141: s3: torture: Add samba3.blackbox.test_symlink_traversal.SMB2.
error: sha1 information is lacking or useless (source3/selftest/tests.py).
error: could not build fake ancestor
Patch failed at 0083 CVE-2021-44141: s3: torture: Add samba3.blackbox.test_symlink_traversal.SMB2

Created attachment 17135 [details]
CVE-2021-44141-v415.patch

This one applies.

Created attachment 17136 [details]
CVE text updated with 4.15.5

Updated with 4.15.4 -> 4.15.5.

This bug was referenced in samba v4-15-stable (Release samba-4.15.5):

550ece56400dc7391296943cf93ce0a4e54f9843
cf661f306afaf66feeea11bb2d9e7f7e3c988914
a0fd6cd62f3d773371fa5f460306a562e524e6eb
6f9580493e250a00d100a3f96253d00bd4294b55
745d08fe10a824ef1fe1fcf57fadfd6c8b6ae216
ee3a5f2ee00cbd78446cff2e815f6cf3600e17a8
2cfbfd3e0a6fd012944cad4e0fe7fe2a8688b7cc
db095ee5f039dc079200f1791c62c168ec57f2aa
57fbf7564c7a0bea68ec80f774deb2fba22f3afb
74fe15a05ad913112c4a76431b9e280e17ab2ee4
919b3c8d3fb9c5248a79ff01e096353cab3fd9f0
04304b9f92cb6b17fa368ed039f84f3a75cf9016
18ac36f7aed4e46f2c029d67c0e97ce4c32e9bbe
ff64b0f32d0f0b41926badff7aab53c32759bc94
8349c57f76fcd53810620fc79d6b892ed2141ae6
cf109e26b7ae918833cb4610dbcba8dc9f7c5bc0
c249f1d09d60fb637a118c0ade7714cc3fcb1866
6c40cda03e7011fe6ad7df2170a11bcfcce38e40
b39ba559c078b371a3b212a4c26e589fae811417
05d2d29964ef5ef0e519b9621002138423d99bf9
80d8a557dda29441f4091ec76bed86d23fd3f223
d57802650f48391ef906283963c86e31466702c4
79ae11f3cb464ffe381c62451ad38125f1872156
e4c3d31854fa1969d946bd6a7cfcf25db5d21d7b
945c9264243c811346d28ce0aeb740bdbe1083dc
410126c7fb939c3bebee318376602e5084a93e12
7b0eba7ff03aa79400c4dbac224122209c8e8995
07b47529426d4623270c2541b840bf71cfca9d59
9d0c2fd42fc77de7a9748ef2ecd7d284b5105e37
c7678425514417b524800e65098bc8608849c457
992864a49f099052c452eb5e1da733f39294d94a
848b891d978d928dc3199f7f1e146bfc0b7ab988
ece00d51a7b28ec96c0a173ca40feb61aaf5dbe3
cafca2b7a0eca282d24d8f3571bc14ef725f30e4
be70e606c61cd2da8f27718f5a227728494793e3
cf2de328ea36011d9f4594bac84fce0b8db0889e
fc80b553dc6c6a17fa496e1347174ffb802c3ffb
8c1a9ccb546e7677dc05e98bd6aa77681e0d7510
9907c8af089a6263349566f002747d84edf926d3
9fb1d11b2edafe0b2e8fb8cfbe34e1da046b3d97
a88596028eac6facd644afa7eb5bf9ed34915c30
fad0039acabd43eaf6853af60e5d245a2691a664
26ecf18b426eb3f2db9d60f02ece2af5e6fa057e
838985e439df0c1b741516ff141da02ecbf5656f
43a9866c46b9a82af34693e5c17c0c627169cb76
68ee550a0dd41e31fd6ffdd1aeda8adb3595a8cf
0163d21c31ad978182adba73bae8f0ee48c69e53
1c1c7ed99466ace89eb61d4783903b8b8a718e27
46ec23c244bc001a5bb1105a2d1e23ebfdd78ca4
733e66aa31da219f7bc54cd380451d380d6ca3a1
3f60b452049e4c10cec414a7da8709f2ceb3f929
51c024a1b029c0ca66594336d5474b8cc64c4452
f8ecb37606ef65a53fbf45c7a4305454de1e53af
3490db2a38981b10ad165d9815ff026ad1b8513d
5c55cd93e5bd1481e88edd4fa0c76f4679bdfcc6
e6d9ef3b1e8e19c1b02a3320a619464b1c319a51
0f1436ed031b702ab5853b6a21e476a1c47b243c
12b44645fb92de451cf82de12b46a43fdc1c2cc1
fc8e6669edb9e20fbc3a4f06dccccbb7ec676f70
d91d4a17443ab833bd210c10ac68b3992cb97370
6f2c67d9993925e45245c7c3f1aa947d72cd2573
b73be0c7a7c86943416cb83de387341ebfb169fd
5e42ab3f6a09ec469ef882dca24f1372711646a0
b0fc0efbac5b1c4144769ec5a2855f4276b9c7a2
d52dd78e9d8cecbc9e913c0b91f345cafe755dbd
3471f03816f8133f501288c8e468c36cdad8ae65
36f480c7c8ea88238a040415f677ad0a57fec60c
104499b56ded1960c0fa7f2dfd49eea4d0f76172
e94d2bcbdc6d4899be71b74a2daf39e65474558c
f77e56e2d1baff6f0ff78e10d6bbba49d106edd9
f8698b1f797ddf2c6e418e683e6c68392ad3ef9e
10242faa0785ca277d584274c151467e78e787bf
738c7080e78553b9f6eeef778522a1df9a88f977
4fc4bd4f20cdfcf1df63f76f2f9940808b286c72
c032a254bb5b703f510c42880ea5416982df9577
bfcf165b29b30dd1f8037ab0f9a9e03731d2642f
08c40af638154fa009e6b6f526a357b10ba7e3ba
a7b6aa7d1f20dfb565605d662404d3988c83e5c8
300abd383ea7fc0b1b8c59d5a8c90201f216dcd6
a180e5726d598192e99ac4a26a2a3752bf7ac7c7
c7aa173d2a44b3cf254b3739c7aedc2d5c8c0d58
3e0d40f5481f2343fa93e204f2c432e1a2335c98
9e90f31639a71ba4c8099c9da4ad25102a36873b
e3f84b2b9f8eda2e5e3192452b698bfce4b7516c
700f80d551d85b3141c2cd0abd7be5efb6948a51
f03c42ea77f4ec6a4a66583bfd1d195bd2ac6731
dbeef6bc732f05da5b35274cb0782a914e7392d7
b97f4a6519f64cbcea2b6baa33d853faf4bc24cb
66774e97e200d686be9c54739dc67ff0ed56af6f
9371ace08e603c745be14d6131b7a7713b36e782
d46ffccc0780b9ef6b5a49e3e17b665345bd4362
e7d0d40e684702d7fcbb781e0f6c072be86a1386

Removing vendor CC (so that any public comments don't need to be broadcast so widely) and opening these bugs to the public.  
If you wish to continue to be informed about any changes here please CC individually.

the toplevel www.samba.org page seems to links the 44142 cve from the 44141 cve link

This bug was referenced in samba v4-15-test:

550ece56400dc7391296943cf93ce0a4e54f9843
cf661f306afaf66feeea11bb2d9e7f7e3c988914
a0fd6cd62f3d773371fa5f460306a562e524e6eb
6f9580493e250a00d100a3f96253d00bd4294b55
745d08fe10a824ef1fe1fcf57fadfd6c8b6ae216
ee3a5f2ee00cbd78446cff2e815f6cf3600e17a8
2cfbfd3e0a6fd012944cad4e0fe7fe2a8688b7cc
db095ee5f039dc079200f1791c62c168ec57f2aa
57fbf7564c7a0bea68ec80f774deb2fba22f3afb
74fe15a05ad913112c4a76431b9e280e17ab2ee4
919b3c8d3fb9c5248a79ff01e096353cab3fd9f0
04304b9f92cb6b17fa368ed039f84f3a75cf9016
18ac36f7aed4e46f2c029d67c0e97ce4c32e9bbe
ff64b0f32d0f0b41926badff7aab53c32759bc94
8349c57f76fcd53810620fc79d6b892ed2141ae6
cf109e26b7ae918833cb4610dbcba8dc9f7c5bc0
c249f1d09d60fb637a118c0ade7714cc3fcb1866
6c40cda03e7011fe6ad7df2170a11bcfcce38e40
b39ba559c078b371a3b212a4c26e589fae811417
05d2d29964ef5ef0e519b9621002138423d99bf9
80d8a557dda29441f4091ec76bed86d23fd3f223
d57802650f48391ef906283963c86e31466702c4
79ae11f3cb464ffe381c62451ad38125f1872156
e4c3d31854fa1969d946bd6a7cfcf25db5d21d7b
945c9264243c811346d28ce0aeb740bdbe1083dc
410126c7fb939c3bebee318376602e5084a93e12
7b0eba7ff03aa79400c4dbac224122209c8e8995
07b47529426d4623270c2541b840bf71cfca9d59
9d0c2fd42fc77de7a9748ef2ecd7d284b5105e37
c7678425514417b524800e65098bc8608849c457
992864a49f099052c452eb5e1da733f39294d94a
848b891d978d928dc3199f7f1e146bfc0b7ab988
ece00d51a7b28ec96c0a173ca40feb61aaf5dbe3
cafca2b7a0eca282d24d8f3571bc14ef725f30e4
be70e606c61cd2da8f27718f5a227728494793e3
cf2de328ea36011d9f4594bac84fce0b8db0889e
fc80b553dc6c6a17fa496e1347174ffb802c3ffb
8c1a9ccb546e7677dc05e98bd6aa77681e0d7510
9907c8af089a6263349566f002747d84edf926d3
9fb1d11b2edafe0b2e8fb8cfbe34e1da046b3d97
a88596028eac6facd644afa7eb5bf9ed34915c30
fad0039acabd43eaf6853af60e5d245a2691a664
26ecf18b426eb3f2db9d60f02ece2af5e6fa057e
838985e439df0c1b741516ff141da02ecbf5656f
43a9866c46b9a82af34693e5c17c0c627169cb76
68ee550a0dd41e31fd6ffdd1aeda8adb3595a8cf
0163d21c31ad978182adba73bae8f0ee48c69e53
1c1c7ed99466ace89eb61d4783903b8b8a718e27
46ec23c244bc001a5bb1105a2d1e23ebfdd78ca4
733e66aa31da219f7bc54cd380451d380d6ca3a1
3f60b452049e4c10cec414a7da8709f2ceb3f929
51c024a1b029c0ca66594336d5474b8cc64c4452
f8ecb37606ef65a53fbf45c7a4305454de1e53af
3490db2a38981b10ad165d9815ff026ad1b8513d
5c55cd93e5bd1481e88edd4fa0c76f4679bdfcc6
e6d9ef3b1e8e19c1b02a3320a619464b1c319a51
0f1436ed031b702ab5853b6a21e476a1c47b243c
12b44645fb92de451cf82de12b46a43fdc1c2cc1
fc8e6669edb9e20fbc3a4f06dccccbb7ec676f70
d91d4a17443ab833bd210c10ac68b3992cb97370
6f2c67d9993925e45245c7c3f1aa947d72cd2573
b73be0c7a7c86943416cb83de387341ebfb169fd
5e42ab3f6a09ec469ef882dca24f1372711646a0
b0fc0efbac5b1c4144769ec5a2855f4276b9c7a2
d52dd78e9d8cecbc9e913c0b91f345cafe755dbd
3471f03816f8133f501288c8e468c36cdad8ae65
36f480c7c8ea88238a040415f677ad0a57fec60c
104499b56ded1960c0fa7f2dfd49eea4d0f76172
e94d2bcbdc6d4899be71b74a2daf39e65474558c
f77e56e2d1baff6f0ff78e10d6bbba49d106edd9
f8698b1f797ddf2c6e418e683e6c68392ad3ef9e
10242faa0785ca277d584274c151467e78e787bf
738c7080e78553b9f6eeef778522a1df9a88f977
4fc4bd4f20cdfcf1df63f76f2f9940808b286c72
c032a254bb5b703f510c42880ea5416982df9577
bfcf165b29b30dd1f8037ab0f9a9e03731d2642f
08c40af638154fa009e6b6f526a357b10ba7e3ba
a7b6aa7d1f20dfb565605d662404d3988c83e5c8
300abd383ea7fc0b1b8c59d5a8c90201f216dcd6
a180e5726d598192e99ac4a26a2a3752bf7ac7c7
c7aa173d2a44b3cf254b3739c7aedc2d5c8c0d58
3e0d40f5481f2343fa93e204f2c432e1a2335c98
9e90f31639a71ba4c8099c9da4ad25102a36873b
e3f84b2b9f8eda2e5e3192452b698bfce4b7516c
700f80d551d85b3141c2cd0abd7be5efb6948a51
f03c42ea77f4ec6a4a66583bfd1d195bd2ac6731
dbeef6bc732f05da5b35274cb0782a914e7392d7
b97f4a6519f64cbcea2b6baa33d853faf4bc24cb
66774e97e200d686be9c54739dc67ff0ed56af6f
9371ace08e603c745be14d6131b7a7713b36e782
d46ffccc0780b9ef6b5a49e3e17b665345bd4362
e7d0d40e684702d7fcbb781e0f6c072be86a1386

(In reply to Marcus Meissner from comment #92)
Thank you for the tip! It is fixed now.

This bug was referenced in samba v4-16-test:

1dcd818303bdd5a1ea59faae114d290b51fc7999
e6ccaced533d28f4685319b94dcf935dc7a5b150
ea20599ff17315f9ee197634dabdfbb0e41b740c
c6d70dad3a28978e853e330ca4fcd96f435c83ac
b8da8b722051030465e86aaf08305cb18cea02a3
4106af6d620e4b4b66c015333d8e1dac9b4e9fd1
f4202a0bccd5d52aa5448748cdd2d67a68738fc0
86157b3c7bfda64060ed4fbe23711aaa571be092
239e915b8f721bab820ffba6ff355d828a34ffe9
b88d24e33b2f4a2a540698520d76f1b8a2fe3e4d

This bug was referenced in samba master:

1f7e870ddad935a04e0659b7f0c2f4caff3a0e9b
3bc85d615e6415c7469d79730fdfb11a36d62932
4e75e24baab2773bbd1966ed38330118fbf51b26
3e9f6d704d3f3c51180cb2c5ee327e2a31106b52
f5b28d8aa334f43fcc85fa70f897a2764287589f
458c7555a94f8d1e6e132b2568e900fddba3b2f9
43455edd29af00a0a4186f83557eec7481434170
be13892020013377994634a2367c3aff53245f44
a44435c6e763e042e6c4cdbb70fc0479f1662c66
e4e5539e402fd2116b4eb4f4f2d687da509491d6

This bug was referenced in samba v4-16-stable (Release samba-4.16.0rc2):

1dcd818303bdd5a1ea59faae114d290b51fc7999
e6ccaced533d28f4685319b94dcf935dc7a5b150
ea20599ff17315f9ee197634dabdfbb0e41b740c
c6d70dad3a28978e853e330ca4fcd96f435c83ac
b8da8b722051030465e86aaf08305cb18cea02a3
4106af6d620e4b4b66c015333d8e1dac9b4e9fd1
f4202a0bccd5d52aa5448748cdd2d67a68738fc0
86157b3c7bfda64060ed4fbe23711aaa571be092
239e915b8f721bab820ffba6ff355d828a34ffe9
b88d24e33b2f4a2a540698520d76f1b8a2fe3e4d

Pushed to all branches.
Closing out bug report.

Thanks!