From a quick check it seems this should be fixed by additional bound checks in ad_unpack(). I'll take a closer look next week.

Created attachment 17008 [details]
Possible fix

Requested a CVE number from Red Hat product security.

Sorry for the delay Ralph, I'll take a look at this tomorrow.

Comment on attachment 17008 [details]
Possible fix

Just to confirm, I've examined the fix and it looks to be correct. Check is exactly where it needs to be and should protect against any EA abuse I can see IMHO.

After some more research and studying of the problematic code, I noticed that the function ad_get_entry() has a check for len == 0 and returns NULL in that case which prevents the described attack.

I wonder whether you were looking at an older Samba version that doesn't have the following commit:

3d5bf4b85f3ca120206a12b3d102aef2ead33082
vfs_fruit: replace unsafe ad_entry macro with a function 

This commit is from 2017 so it's included on all currently shipping supported Samba versions 4.13, 4.14 and 4.15.

While this doesn't prevent an attack with a len value between 1 and 31, it should prevent the described attack.

Can you please check you analysis and PoC?

Hi, I actually reproduced the bug in version 4.15.0. About the len, you can still assign the `len` to `1` and the `offset` to the `end-of-the-buffer - 1`. That also results the same OOB read/write.

Oh, I got your point. Sorry for the inaccurate description in my advisory. It's true and the `len=0` won't work. However, my PoC use `len=1` to trigger the bug and the result is still the same OOB read/write on the latest version (4.15.0) of Samba!

(In reply to Orange Tsai from comment #12)
As said in #10 I'm aware of the fact that with eg len=1 you can bypass the len=0 check in ad_get_entry() and so mount the attack.
But as the exploit description talks about len=0 and invalid reads and writes of 32 bytes in several places, I was a bit confused.

Thanks for clarifying!

Hi, I'm Art Manion from the CERT/CC, and would like to discuss public disclosure plans for this vulnerability.  We understand that Samba has a disclosure process that includes notifying some Samba vendors/users and we don't want to unnecessarily interfere.  We've talked to Western Digital and ZDI, both of whom seem willing to be flexible, and DEVCORE has asked for a 2022-02-17 deadline.

CERT/CC would like to notify a broad list of vendors privately, before public disclosure.  We don't know that all of these vendors use Samba, but we consider such a broad notification to be a beneficial trade off to catch Samba vendors we were not aware of.  Again, we'd like to do this in a way/at a time that is in coordination with Samba vendor notifications.  We advertise a 45 day embargo but that does not apply here, we'll go with what the group decides and after stable patches are ready.

Received via security@samba.org:

ZDI-CAN-16156: Samba AppleDouble Entry Heap-based Buffer Overflow Remote Co=
de Execution Vulnerability

-- CVSS -----------------------------------------

9.8: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

-- ABSTRACT -------------------------------------

Trend Micro's Zero Day Initiative has identified a vulnerability affecting =
the following products:
Samba - Samba

-- VULNERABILITY DETAILS ------------------------
* Version tested:4.15.2
* Installer file:samba-4.15.2.tar.gz
* Platform tested:ubuntu 18.04.5 amd64 desktop edition

---

### Analysis

```
samba validates AppleDouble entry one by one
ZDI-CAN-15846 didn't validate ADEID_FINDERI
and this case didn't validate ADEID_FILEDATESI
it leads to OOBR in ad_getdate and OOBW in ad_setdate
```

~~~C+++
int ad_setdate(struct adouble *ad, unsigned int dateoff, uint32_t date)
{
	bool xlate =3D (dateoff & AD_DATE_UNIX);
	char *p =3D NULL;

	p =3D ad_get_entry(ad, ADEID_FILEDATESI);
	if (p =3D=3D NULL) {
		return -1;
	}

	dateoff &=3D AD_DATE_MASK;
	if (xlate) {
		date =3D AD_DATE_FROM_UNIX(date);
	}

	if (dateoff > AD_DATE_ACCESS) {
		return -1;
	}

	memcpy(p + dateoff, &date, sizeof(date)); 		// overflow 3 bytes

	return 0;
}
~~~

OOB read report
```
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D23354=3D=3DERROR: AddressSanitizer: heap-buffer-overflow on address 0=
x615000010df1 at pc 0x7fffdd368fc0 bp 0x7fffffffc530 sp 0x7fffffffc520
READ of size 4 at 0x615000010df1 thread T0
    #0 0x7fffdd368fbf in ad_getdate ../../source3/lib/adouble.c:313
    #1 0x7fffdd37bbd4 in update_btime ../../source3/modules/vfs_fruit.c:536
    #2 0x7fffdd37bf3b in fruit_stat ../../source3/modules/vfs_fruit.c:3282
    #3 0x7ffff640df26 in smb_vfs_call_stat ../../source3/smbd/vfs.c:2187
    #4 0x7fffdd140a4c in catia_stat ../../source3/modules/vfs_catia.c:627
    #5 0x7ffff640df26 in smb_vfs_call_stat ../../source3/smbd/vfs.c:2187
    #6 0x7ffff640e173 in vfs_stat ../../source3/smbd/vfs.c:1508
    #7 0x7ffff63de49b in unix_convert ../../source3/smbd/filename.c:1184
    #8 0x7ffff63e304b in filename_convert_internal ../../source3/smbd/filen=
ame.c:1984
    #9 0x7ffff63e3beb in filename_convert ../../source3/smbd/filename.c:2072
    #10 0x7ffff648fca6 in smbd_smb2_create_send ../../source3/smbd/smb2_cre=
ate.c:968
    #11 0x7ffff648fca6 in smbd_smb2_request_process_create ../../source3/sm=
bd/smb2_create.c:268
    #12 0x7ffff6471e08 in smbd_smb2_request_dispatch ../../source3/smbd/smb=
2_server.c:3394
    #13 0x7ffff6474818 in smbd_smb2_io_handler ../../source3/smbd/smb2_serv=
er.c:5003
    #14 0x7ffff6474818 in smbd_smb2_connection_handler ../../source3/smbd/s=
mb2_server.c:5041
    #15 0x7ffff5061869 in tevent_common_invoke_fd_handler ../../lib/tevent/=
tevent_fd.c:142
    #16 0x7ffff5075f53 in epoll_event_loop ../../lib/tevent/tevent_epoll.c:=
736
    #17 0x7ffff5075f53 in epoll_event_loop_once ../../lib/tevent/tevent_epo=
ll.c:937
    #18 0x7ffff506e921 in std_event_loop_once ../../lib/tevent/tevent_stand=
ard.c:110
    #19 0x7ffff505f872 in _tevent_loop_once ../../lib/tevent/tevent.c:790
    #20 0x7ffff505ff36 in tevent_common_loop_wait ../../lib/tevent/tevent.c=
:913
    #21 0x7ffff506e836 in std_event_loop_wait ../../lib/tevent/tevent_stand=
ard.c:141
    #22 0x7ffff505ffe7 in _tevent_loop_wait ../../lib/tevent/tevent.c:932
    #23 0x7ffff64430e5 in smbd_process ../../source3/smbd/process.c:4246
    #24 0x555555571db5 in smbd_accept_connection ../../source3/smbd/server.=
c:972
    #25 0x7ffff5061869 in tevent_common_invoke_fd_handler ../../lib/tevent/=
tevent_fd.c:142
    #26 0x7ffff5075f53 in epoll_event_loop ../../lib/tevent/tevent_epoll.c:=
736
    #27 0x7ffff5075f53 in epoll_event_loop_once ../../lib/tevent/tevent_epo=
ll.c:937
    #28 0x7ffff506e921 in std_event_loop_once ../../lib/tevent/tevent_stand=
ard.c:110
    #29 0x7ffff505f872 in _tevent_loop_once ../../lib/tevent/tevent.c:790
    #30 0x7ffff505ff36 in tevent_common_loop_wait ../../lib/tevent/tevent.c=
:913
    #31 0x7ffff506e836 in std_event_loop_wait ../../lib/tevent/tevent_stand=
ard.c:141
    #32 0x7ffff505ffe7 in _tevent_loop_wait ../../lib/tevent/tevent.c:932
    #33 0x55555557534c in smbd_parent_loop ../../source3/smbd/server.c:1365
    #34 0x55555557534c in main ../../source3/smbd/server.c:2190
    #35 0x7ffff202ebf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.=
6+0x21bf6)
    #36 0x555555568739 in _start (/usr/local/samba/sbin/smbd+0x14739)

0x615000010df2 is located 0 bytes to the right of 498-byte region [0x615000=
010c00,0x615000010df2)
allocated by thread T0 here:
    #0 0x7ffff6ef6b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/li=
basan.so.4+0xdeb40)
    #1 0x7ffff571be02 in __talloc_with_prefix ../../lib/talloc/talloc.c:783
    #2 0x7ffff571be02 in __talloc ../../lib/talloc/talloc.c:825
    #3 0x7ffff571be02 in _talloc_named_const ../../lib/talloc/talloc.c:982
    #4 0x7ffff571be02 in _talloc_zero ../../lib/talloc/talloc.c:2421
    #5 0x7ffff571c2bf in _talloc_zero_array ../../lib/talloc/talloc.c:2774
    #6 0x7fffdd36670a in ad_alloc ../../source3/lib/adouble.c:2410
    #7 0x7fffdd36ecec in ad_get_internal ../../source3/lib/adouble.c:2502
    #8 0x7fffdd36fc39 in ad_get ../../source3/lib/adouble.c:2557
    #9 0x7fffdd372c72 in ad_get_meta_fsp ../../source3/modules/vfs_fruit.c:=
244
    #10 0x7fffdd37bbb0 in update_btime ../../source3/modules/vfs_fruit.c:532
    #11 0x7fffdd37bf3b in fruit_stat ../../source3/modules/vfs_fruit.c:3282
    #12 0x7ffff640df26 in smb_vfs_call_stat ../../source3/smbd/vfs.c:2187
    #13 0x7fffdd140a4c in catia_stat ../../source3/modules/vfs_catia.c:627
    #14 0x7ffff640df26 in smb_vfs_call_stat ../../source3/smbd/vfs.c:2187
    #15 0x7ffff640e173 in vfs_stat ../../source3/smbd/vfs.c:1508
    #16 0x7ffff63de49b in unix_convert ../../source3/smbd/filename.c:1184
    #17 0x7ffff63e304b in filename_convert_internal ../../source3/smbd/file=
name.c:1984
    #18 0x7ffff63e3beb in filename_convert ../../source3/smbd/filename.c:20=
72
    #19 0x7ffff648fca6 in smbd_smb2_create_send ../../source3/smbd/smb2_cre=
ate.c:968
    #20 0x7ffff648fca6 in smbd_smb2_request_process_create ../../source3/sm=
bd/smb2_create.c:268
    #21 0x7ffff6471e08 in smbd_smb2_request_dispatch ../../source3/smbd/smb=
2_server.c:3394
    #22 0x7ffff6474818 in smbd_smb2_io_handler ../../source3/smbd/smb2_serv=
er.c:5003
    #23 0x7ffff6474818 in smbd_smb2_connection_handler ../../source3/smbd/s=
mb2_server.c:5041
    #24 0x7ffff5061869 in tevent_common_invoke_fd_handler ../../lib/tevent/=
tevent_fd.c:142
    #25 0x7ffff5075f53 in epoll_event_loop ../../lib/tevent/tevent_epoll.c:=
736
    #26 0x7ffff5075f53 in epoll_event_loop_once ../../lib/tevent/tevent_epo=
ll.c:937
    #27 0x7ffff506e921 in std_event_loop_once ../../lib/tevent/tevent_stand=
ard.c:110
    #28 0x7ffff505f872 in _tevent_loop_once ../../lib/tevent/tevent.c:790
    #29 0x7ffff505ff36 in tevent_common_loop_wait ../../lib/tevent/tevent.c=
:913
    #30 0x7ffff506e836 in std_event_loop_wait ../../lib/tevent/tevent_stand=
ard.c:141
    #31 0x7ffff505ffe7 in _tevent_loop_wait ../../lib/tevent/tevent.c:932
    #32 0x7ffff64430e5 in smbd_process ../../source3/smbd/process.c:4246
    #33 0x555555571db5 in smbd_accept_connection ../../source3/smbd/server.=
c:972
    #34 0x7ffff5061869 in tevent_common_invoke_fd_handler ../../lib/tevent/=
tevent_fd.c:142
    #35 0x7ffff5075f53 in epoll_event_loop ../../lib/tevent/tevent_epoll.c:=
736
    #36 0x7ffff5075f53 in epoll_event_loop_once ../../lib/tevent/tevent_epo=
ll.c:937

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../source3/lib/adouble.c=
:313 in ad_getdate
Shadow bytes around the buggy address:
  0x0c2a7fffa160: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2a7fffa170: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a7fffa190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a7fffa1a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=3D>0x0c2a7fffa1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[02]fa
  0x0c2a7fffa1c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa1d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa1e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa1f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
=3D=3D23354=3D=3DABORTING
```

OOBW debug log
```
(gdb) s
ad_alloc (ctx=3D0x5555557cf9a0, type=3DADOUBLE_META) at ../../source3/lib/a=
double.c:2372
2372		int rc =3D 0;
(gdb) n
2373		size_t adsize =3D 0;
(gdb)
2376		switch (type) {
(gdb)
2378			adsize =3D AD_DATASZ_XATTR;
(gdb)
2379			break;
(gdb)
2403		ad =3D talloc_zero(ctx, struct adouble);
(gdb)
2404		if (ad =3D=3D NULL) {
(gdb)
2409		if (adsize) {
(gdb)
2410			ad->ad_data =3D talloc_zero_array(ad, char, adsize);
(gdb) p/x adsize
$3 =3D 0x192
(gdb) n
2411			if (ad->ad_data =3D=3D NULL) {
(gdb) p ad->ad_data
$4 =3D 0x555555794eb0 ""
(gdb) x/10xg 0x555555794eb0+0x190
0x555555795040:	0x0000000000000000	0x0000000000000321
0x555555795050:	0x0000000000000000	0x000055555576f010
0x555555795060:	0x0000000000000000	0x0000000000000001
0x555555795070:	0x0000000000000000	0x0000000000000000
0x555555795080:	0x0000000000000000	0x0000000000000000
(gdb) c
Continuing.

Breakpoint 2, ad_setdate (ad=3D0x5555557bc800, dateoff=3D1024, date=3D16409=
20271) at ../../source3/lib/adouble.c:320
320		bool xlate =3D (dateoff & AD_DATE_UNIX);
(gdb) n
321		char *p =3D NULL;
(gdb)
323		p =3D ad_get_entry(ad, ADEID_FILEDATESI);
(gdb)
324		if (p =3D=3D NULL) {
(gdb) p /x p
$5 =3D 0x555555795041
(gdb) n
328		dateoff &=3D AD_DATE_MASK;
(gdb)
329		if (xlate) {
(gdb)
330			date =3D AD_DATE_FROM_UNIX(date);
(gdb)
333		if (dateoff > AD_DATE_ACCESS) {
(gdb)
337		memcpy(p + dateoff, &date, sizeof(date));
(gdb) n
339		return 0;
(gdb) x/10xg 0x555555794eb0+0x190
0x555555795040:	0x0000004f31612920	0x0000000000000321 		// overflow 3 bytes
0x555555795050:	0x0000000000000000	0x000055555576f010
0x555555795060:	0x0000000000000000	0x0000000000000001
0x555555795070:	0x0000000000000000	0x0000000000000000
0x555555795080:	0x0000000000000000	0x0000000000000000
(gdb) bt
#0  ad_setdate (ad=3D0x5555557bc800, dateoff=3D0, date=3D1328636201) at ../=
../source3/lib/adouble.c:339
#1  0x00007fffe31c2e0f in fruit_fntimes (handle=3D0x5555557d5df0, fsp=3D0x5=
555557da810, ft=3D0x7fffffffd490) at ../../source3/modules/vfs_fruit.c:3954
#2  0x00007ffff774ca96 in smb_vfs_call_fntimes (handle=3D0x5555557d5df0, fs=
p=3D0x5555557da810, ft=3D0x7fffffffd490) at ../../source3/smbd/vfs.c:2266
#3  0x00007fffe2fa3c0c in catia_fntimes (handle=3D0x5555557d6050, fsp=3D0x5=
555557da810, ft=3D0x7fffffffd490) at ../../source3/modules/vfs_catia.c:832
#4  0x00007ffff774ca96 in smb_vfs_call_fntimes (handle=3D0x5555557d6050, fs=
p=3D0x5555557da810, ft=3D0x7fffffffd490) at ../../source3/smbd/vfs.c:2266
#5  0x00007ffff772b7ba in file_ntimes (conn=3D0x5555557a1770, fsp=3D0x55555=
57da810, ft=3D0x7fffffffd490) at ../../source3/smbd/dosmode.c:1231
#6  0x00007ffff771d349 in smb_set_file_time (conn=3D0x5555557a1770, fsp=3D0=
x5555557da810, smb_fname=3D0x5555557dc210, ft=3D0x7fffffffd490, setting_wri=
te_time=3Dtrue) at ../../source3/smbd/trans2.c:6641
#7  0x00007ffff7720290 in smb_set_file_basic_info (conn=3D0x5555557a1770, p=
data=3D0x5555557b69c0 "\200\061\322\017\364\375\327\001", total_data=3D40, =
fsp=3D0x5555557da810, smb_fname=3D0x5555557dc210) at ../../source3/smbd/tra=
ns2.c:7923
#8  0x00007ffff7723443 in smbd_do_setfilepathinfo (conn=3D0x5555557a1770, r=
eq=3D0x55555578ddd0, mem_ctx=3D0x5555557d25a0, info_level=3D1004, fsp=3D0x5=
555557da810, smb_fname=3D0x5555557dc210, ppdata=3D0x7fffffffd5f0, total_dat=
a=3D40,
    ret_data_size=3D0x7fffffffd5d4) at ../../source3/smbd/trans2.c:9220
#9  0x00007ffff77ab7b5 in smbd_smb2_setinfo_send (mem_ctx=3D0x555555790740,=
 ev=3D0x555555793fb0, smb2req=3D0x555555790740, fsp=3D0x5555557da810, in_in=
fo_type=3D1 '\001', in_file_info_class=3D4 '\004', in_input_buffer=3D...,
    in_additional_information=3D0) at ../../source3/smbd/smb2_setinfo.c:516
#10 0x00007ffff77aa611 in smbd_smb2_request_process_setinfo (req=3D0x555555=
790740) at ../../source3/smbd/smb2_setinfo.c:112
#11 0x00007ffff7783882 in smbd_smb2_request_dispatch (req=3D0x555555790740)=
 at ../../source3/smbd/smb2_server.c:3477
#12 0x00007ffff7788673 in smbd_smb2_io_handler (xconn=3D0x5555557c7c00, fde=
_flags=3D1) at ../../source3/smbd/smb2_server.c:5003
#13 0x00007ffff77887a2 in smbd_smb2_connection_handler (ev=3D0x555555793fb0=
, fde=3D0x5555557c07f0, flags=3D1, private_data=3D0x5555557c7c00) at ../../=
source3/smbd/smb2_server.c:5041
#14 0x00007ffff66dfb1c in tevent_common_invoke_fd_handler (fde=3D0x5555557c=
07f0, flags=3D1, removed=3D0x0) at ../../lib/tevent/tevent_fd.c:142
#15 0x00007ffff66ea81d in epoll_event_loop (epoll_ev=3D0x5555557a3f30, tval=
p=3D0x7fffffffda60) at ../../lib/tevent/tevent_epoll.c:736
#16 0x00007ffff66eaf00 in epoll_event_loop_once (ev=3D0x555555793fb0, locat=
ion=3D0x7ffff790c8d8 "../../source3/smbd/process.c:4246") at ../../lib/teve=
nt/tevent_epoll.c:937
#17 0x00007ffff66e7690 in std_event_loop_once (ev=3D0x555555793fb0, locatio=
n=3D0x7ffff790c8d8 "../../source3/smbd/process.c:4246") at ../../lib/tevent=
/tevent_standard.c:110
#18 0x00007ffff66de947 in _tevent_loop_once (ev=3D0x555555793fb0, location=
=3D0x7ffff790c8d8 "../../source3/smbd/process.c:4246") at ../../lib/tevent/=
tevent.c:790
#19 0x00007ffff66dec99 in tevent_common_loop_wait (ev=3D0x555555793fb0, loc=
ation=3D0x7ffff790c8d8 "../../source3/smbd/process.c:4246") at ../../lib/te=
vent/tevent.c:913
#20 0x00007ffff66e7732 in std_event_loop_wait (ev=3D0x555555793fb0, locatio=
n=3D0x7ffff790c8d8 "../../source3/smbd/process.c:4246") at ../../lib/tevent=
/tevent_standard.c:141
#21 0x00007ffff66ded3c in _tevent_loop_wait (ev=3D0x555555793fb0, location=
=3D0x7ffff790c8d8 "../../source3/smbd/process.c:4246") at ../../lib/tevent/=
tevent.c:932
#22 0x00007ffff77694ed in smbd_process (ev_ctx=3D0x555555793fb0, msg_ctx=3D=
0x55555578d910, dce_ctx=3D0x55555578df00, sock_fd=3D44, interactive=3Dtrue)=
 at ../../source3/smbd/process.c:4246
#23 0x00005555555616fe in smbd_accept_connection (ev=3D0x555555793fb0, fde=
=3D0x5555557c9e80, flags=3D1, private_data=3D0x5555557bcea0) at ../../sourc=
e3/smbd/server.c:972
#24 0x00007ffff66dfb1c in tevent_common_invoke_fd_handler (fde=3D0x5555557c=
9e80, flags=3D1, removed=3D0x0) at ../../lib/tevent/tevent_fd.c:142
#25 0x00007ffff66ea81d in epoll_event_loop (epoll_ev=3D0x5555557a2840, tval=
p=3D0x7fffffffde10) at ../../lib/tevent/tevent_epoll.c:736
#26 0x00007ffff66eaf00 in epoll_event_loop_once (ev=3D0x555555793fb0, locat=
ion=3D0x555555569ac0 "../../source3/smbd/server.c:1365") at ../../lib/teven=
t/tevent_epoll.c:937
#27 0x00007ffff66e7690 in std_event_loop_once (ev=3D0x555555793fb0, locatio=
n=3D0x555555569ac0 "../../source3/smbd/server.c:1365") at ../../lib/tevent/=
tevent_standard.c:110
#28 0x00007ffff66de947 in _tevent_loop_once (ev=3D0x555555793fb0, location=
=3D0x555555569ac0 "../../source3/smbd/server.c:1365") at ../../lib/tevent/t=
event.c:790
#29 0x00007ffff66dec99 in tevent_common_loop_wait (ev=3D0x555555793fb0, loc=
ation=3D0x555555569ac0 "../../source3/smbd/server.c:1365") at ../../lib/tev=
ent/tevent.c:913
#30 0x00007ffff66e7732 in std_event_loop_wait (ev=3D0x555555793fb0, locatio=
n=3D0x555555569ac0 "../../source3/smbd/server.c:1365") at ../../lib/tevent/=
tevent_standard.c:141
#31 0x00007ffff66ded3c in _tevent_loop_wait (ev=3D0x555555793fb0, location=
=3D0x555555569ac0 "../../source3/smbd/server.c:1365") at ../../lib/tevent/t=
event.c:932
#32 0x0000555555562661 in smbd_parent_loop (ev_ctx=3D0x555555793fb0, parent=
=3D0x5555557a6a30) at ../../source3/smbd/server.c:1365
#33 0x0000555555564b07 in main (argc=3D2, argv=3D0x7fffffffe3b8) at ../../s=
ource3/smbd/server.c:2190
(gdb)
```


-- CREDIT ---------------------------------------
This vulnerability was discovered by:
Lucas Leong (@_wmliang_) of Trend Micro Zero Day Initiative

-- FURTHER DETAILS ------------------------------

If supporting files were contained with this report they are provided withi=
n a password protected ZIP file. The password is the ZDI candidate number i=
n the form: ZDI-CAN-XXXX where XXXX is the ID number.

Please confirm receipt of this report. We expect all vendors to remediate Z=
DI vulnerabilities within 120 days of the reported date. If you are ready t=
o release a patch at any point leading up to the deadline, please coordinat=
e with us so that we may release our advisory detailing the issue. If the 1=
20-day deadline is reached and no patch has been made available we will rel=
ease a limited public advisory with our own mitigations, so that the public=
 can protect themselves in the absence of a patch. Please keep us updated r=
egarding the status of this issue and feel free to contact us at any time:

Zero Day Initiative
zdi-disclosures@trendmicro.com

The PGP key used for all ZDI vendor communications is available from:

  http://www.zerodayinitiative.com/documents/disclosures-pgp-key.asc

-- INFORMATION ABOUT THE ZDI --------------------
Established by TippingPoint and acquired by Trend Micro, the Zero Day Initi=
ative (ZDI) neither re-sells vulnerability details nor exploit code. Instea=
d, upon notifying the affected product vendor, the ZDI provides its Trend M=
icro TippingPoint customers with zero day protection through its intrusion =
prevention technology. Explicit details regarding the specifics of the vuln=
erability are not exposed to any parties until an official vendor patch is =
publicly available.

Please contact us for further details or refer to:

  http://www.zerodayinitiative.com

-- DISCLOSURE POLICY ----------------------------

Our vulnerability disclosure policy is available online at:

  http://www.zerodayinitiative.com/advisories/disclosure_policy/

Hello,

Can you please provide us an update on the status of the fix for this bug? Is it fixed? If not, when do you think it will be fixed? 

Thank you. 

Best Regards,

Diana Della Rocchetta
Product Security Incident Response Program Manager

Western Digital®
Email: diana.della.rocchetta@wdc.com
Email: PSIRT@wdc.com
Mobile: +1-408-504-3706


-----Original Message-----
From: samba-bugs@samba.org <samba-bugs@samba.org> 
Sent: Monday, December 13, 2021 5:51 AM
To: Diana Della Rocchetta <Diana.Della.Rocchetta@wdc.com>
Subject: [Bug 14914] CVE-2021-44142 [EMBARGOED][SECURITY] Out-of-Bound Read/Write on Samba vfs_fruit module

CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.


https://bugzilla.samba.org/show_bug.cgi?id=14914

Stefan Metzmacher <metze@samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |14079

--
You are receiving this mail because:
You are on the CC list for the bug.

Created attachment 17084 [details]
Patch for master

Final patchset, ready for review.

Next comes writing the CVE advisory. Once that's done, hopefully tomorrow, we can plan for a coordinated release with the other pending CVEs.

Appreciate the update Ralph!

Comment on attachment 17084 [details]
Patch for master

Ralph, before I RB+ can I get some clarification on "[PATCH 3/5] CVE-2021-44142: libadouble: add a comment to ad_unpack_xattrs()" please ?

The comment says:

+       /*
+        * NB: the buffer ad->ad_data is always of size AD_XATTR_MAX_HDR_SIZE
+        * bytes. If the ._ file was smaller then that the remaining data is
+        * zero initialized in ad_alloc(). Therefor we don't need any buffer
+        * size validation below eg before accessing the header, because in the
+        * worst case we will be reading 0 bytes.
+        */

Inside source3/lib/adouble.c we have:

#if AD_DATASZ_XATTR != 402
#error bad size for AD_DATASZ_XATTR
#endif

#define AD_XATTR_MAX_HDR_SIZE 65536

However, if I look at ad_alloc() I see:

-------------------------------------------------------
static struct adouble *ad_alloc(TALLOC_CTX *ctx,
                                adouble_type_t type)
{
        int rc = 0;
        size_t adsize = 0;
        struct adouble *ad;

        switch (type) {
        case ADOUBLE_META:
                adsize = AD_DATASZ_XATTR;
                break;
        case ADOUBLE_RSRC:
...
                adsize = AD_XATTR_MAX_HDR_SIZE;
                break;
...
        if (adsize) {
                ad->ad_data = talloc_zero_array(ad, char, adsize);
--------------------------------------------

So this looks to me that ad->ad_data can be a zero array
either of size AD_DATASZ_XATTR (402) or AD_XATTR_MAX_HDR_SIZE (65536)
which doesn't match the added comment.

Can you clarify the comment please ?

(In reply to Jeremy Allison from comment #20)

ad_unpack_xattrs() is called from ad_unpack() which is called from both ad_read_meta() and from ad_read_rsrc_adouble(). Either of these can be called from ad_read():

--------------------------------------------
static ssize_t ad_read_rsrc(vfs_handle_struct *handle,
                            struct adouble *ad,
                            const struct smb_filename *smb_fname)
{
        return ad_read_rsrc_adouble(handle, ad, smb_fname);
}

static ssize_t ad_read(vfs_handle_struct *handle,
                       struct adouble *ad,
                       const struct smb_filename *smb_fname)
{
        switch (ad->ad_type) {
        case ADOUBLE_META:
                return ad_read_meta(handle, ad, smb_fname);
        case ADOUBLE_RSRC:
                return ad_read_rsrc(handle, ad, smb_fname);

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

So it looks to me that ad_unpack_xattrs() can be called with ad->ad_data of size AD_DATASZ_XATTR (402) or AD_XATTR_MAX_HDR_SIZE (65536), which doesn't match the new comment.

Just trying to understand the fix, sorry :-(.

The rest of the patch looks great ! I really like the well thought out, tested and comprehensive checks in ad_entry_check_size().

Not sure this is typical of a patch review, but could DEVCORE/ZDI/the researchers test a patched samba and report back?  CERT/CC may be able to do this also.  No disparagement of Samba's patch development and review process, just an additional check.

Would also like to confirm that what DEVCORE reported and what Lucas Leong/ZDI reported are in fact the same vulnerability/ies (an OOB read and and OOB write, and just CVE-2021-44142).

(In reply to Art Manion from comment #23)

Anyone on the bug report have full access to the sausage-making process. Please feel free to test the patches, just make sure knowledge of them doesn't leak until  official release time. That's been a problem in the past, which is why we usually lock down the bug reports to Team members only.

(In reply to Jeremy Allison from comment #24)

ACK any findings from us will only come back to this ticket.

From WD's standpoint, we'd like to request for Orange Tsai to run a mitigation test on the reported vulnerability and confirm that it has indeed fixed the issue.

Please provide the results as soon as possible.

Hi, I just checked the patch. It looks good to me!

(In reply to Jeremy Allison from comment #21)
Good catch, thanks! Indeed, ad_unpack_xattrs() is supposed to be only called for parsing ._ AppleDouble sidecar files, but an attacked could forge an AppleDouble xattr so the current checks are not sufficient.

I've updated the patchset, replacing the problematic commit with

  libadouble: harden ad_unpack_xattrs()

Created attachment 17087 [details]
Patch for master

Created attachment 17088 [details]
CVE-2021-44142 Advisory

First shot for an advisory text. Jeremy, can you please take a look?

Comment on attachment 17088 [details]
CVE-2021-44142 Advisory

Is it really limited to "network-adjacent?"  Any SMB share reachable via TCP is a vector?  I'd suggest "remote" (also in the subject, "remove code execution."  People do put their linux/netatalk NAS on the internet.  Adjust CVSS vector also, if this is not limited to adjacent.

DEVCORE might prefer the all-caps style.

(In reply to Art Manion from comment #31)
Thanks for your feedback! Wrt to network-adjacent or not, well, I took this from another report on the issue we received from WD PSIRT. As SMB is typically blocked by ISPs, I guess AV:A is closer to the truth then AV:N, but I'm really by no means an expert in CVSS scoring.

(In reply to Ralph Böhme from comment #32)

I appreciate that it may be common and expected to run Samba on NAS and other "internal" systems but I'm pretty confident the CVSS spec treats this as "remote." " Adjacent" requires technical restrictions to e.g., ethernet/radio range/logical/physical proximity:

https://www.first.org/cvss/v3.1/specification-document#2-1-1-Attack-Vector-AV

CVSS also uses a "worst reasonable case" philosophy in general.

(In reply to Art Manion from comment #31)

Yes, please use "Orange Tsai from DEVCORE" (all capitals on the company name) as the credits instead!

Thanks :)

Created attachment 17089 [details]
CVE-2021-44142 Advisory v2

Updated advisory with CVSS AV:N and DEVCORE.

Comment on attachment 17089 [details]
CVE-2021-44142 Advisory v2

In summary:

"allows network-adjacent attackers" -> "allows remote attackers"

"Authentication is not required to exploit this vulnerablity" - is that true ? Don't you need a valid auth in order to write the "evil" EA ?

s/All versions of Samba priors to/All versions of Samba prior to/g

The rest looks great !

(In reply to Jeremy Allison from comment #36)
Thanks for taking a look! Wrt to authentication: I guess it depends on whether we still consider guest authentication a possible authentication mechanism.

(In reply to Ralph Böhme from comment #37)

Hmmm. But does guest have the ability to write the evil EA ? Usually in these situations if it requires write access to anything, I say "auth is required", as that's the minimal "sane" setup. Just my 2cents :-).

Created attachment 17090 [details]
CVE-2021-44142 Advisory v3

Updated CVE with fixes from Jeremy and chaning from "no authentication" to "authentication as unprivileged user".

Comment on attachment 17087 [details]
Patch for master

Sorry Ralph, I have one more question before I RB+.

Inside ad_unpack_xattrs() we have (after the patch is applied):

----------------------------------------------
 803 static bool ad_unpack_xattrs(struct adouble *ad)
 804 {
 805         struct ad_xattr_header *h = &ad->adx_header;
 806         size_t bufsize = talloc_get_size(ad->ad_data);
 807         const char *p = ad->ad_data;
 808         uint32_t hoff;
 809         uint32_t i;
 810 
 811         if (ad->ad_type != ADOUBLE_RSRC) {
 812                 return false;
 813         }
 814 
 815         if (ad_getentrylen(ad, ADEID_FINDERI) <= ADEDLEN_FINDERI) {
 816                 return true;
 817         }
----------------------------------------------

The code in 815-187 is unchanged from before the patch. What does this:

 815         if (ad_getentrylen(ad, ADEID_FINDERI) <= ADEDLEN_FINDERI) {
 816                 return true;
 817         }

do ? I don't understand why it's returning "true" if the entrylen for ADEID_FINDERI is less than or equal to ADEDLEN_FINDERI (32 bytes).

ad_unpack_xattrs() is called from ad_unpack(). ad_unpack() is called in two places.

Once here - in ad_read_rsrc_adouble()

---------------------------------------
2386         /* Now parse entries */
2387         ok = ad_unpack(ad,
2388                        ADEID_NUM_DOT_UND,
2389                        ad->ad_fsp->fsp_name->st.st_ex_size);
2390         if (!ok) {
2391                 DBG_ERR("invalid AppleDouble resource %s\n",
2392                         smb_fname->base_name);
2393                 errno = EINVAL;
2394                 return -1;
2395         }
2396 
2397         if ((ad_getentryoff(ad, ADEID_FINDERI) != ADEDOFF_FINDERI_DOT_UND)
2398             || (ad_getentrylen(ad, ADEID_FINDERI) < ADEDLEN_FINDERI)
2399             || (ad_getentryoff(ad, ADEID_RFORK) < ADEDOFF_RFORK_DOT_UND))
2400         {
2401                 DBG_ERR("invalid AppleDouble resource %s\n",
2402                         smb_fname->base_name);
2403                 errno = EINVAL;
2404                 return -1;
2405         }
---------------------------------------

Note here in line 2398 we check: ad_getentrylen(ad, ADEID_FINDERI) < ADEDLEN_FINDERI) and reject if so. Then why does ad_unpack_xattrs() explicitly allow (ad_getentrylen(ad, ADEID_FINDERI) <= ADEDLEN_FINDERI) ?

Second caller is in ad_read_meta():

---------------------------------------
2179         ok = ad_unpack(ad, ADEID_NUM_XATTR, AD_DATASZ_XATTR);
2180         if (!ok) {
2181                 DEBUG(2, ("invalid AppleDouble metadata xattr\n"));
2182                 errno = EINVAL;
2183                 rc = -1;
2184                 goto exit;
2185         }
2186 
2187         if (!ad_getentryoff(ad, ADEID_FINDERI)
2188             || !ad_getentryoff(ad, ADEID_COMMENT)
2189             || !ad_getentryoff(ad, ADEID_FILEDATESI)
2190             || !ad_getentryoff(ad, ADEID_AFPFILEI)
2191             || !ad_getentryoff(ad, ADEID_PRIVDEV)
2192             || !ad_getentryoff(ad, ADEID_PRIVINO)
2193             || !ad_getentryoff(ad, ADEID_PRIVSYN)
2194             || !ad_getentryoff(ad, ADEID_PRIVID)) {
2195                 DEBUG(2, ("invalid AppleDouble metadata xattr\n"));
2196                 errno = EINVAL;
2197                 rc = -1;
2198                 goto exit;
2199         }
---------------------------------------

Here we check (line 2187): if (!ad_getentryoff(ad, ADEID_FINDERI), but we don't check ad_getentrylen(ad, ADEID_FINDERI).

I guess I just don't understand these checks, or why they're different in these cases.

Sorry if I'm being really dumb, but I'd like to understand first.

Comment on attachment 17090 [details]
CVE-2021-44142 Advisory v3

Sorry:

== Versions:    All versions of Samba priors to 4.13.17

needs to be:

== Versions:    All versions of Samba prior to 4.13.17

(that's why the s///g had the "g" in the regexp in the previous comment :-).

Comment on attachment 17090 [details]
CVE-2021-44142 Advisory v3

Also I'd change:

"Authentication as unprivileged user that has write access to a file's
EAs is required to exploit this vulnerablity."

to:

"Access as a user that has write access to a file's
extended attributes is required to exploit this vulnerability. Note that this could be a guest or unauthenticated user if such users are allowed write access to file extended attributes."

Created attachment 17091 [details]
CVE-2021-44142 Advisory v4

Updated advisory with revised section on authentication and "priors" typo fixed.

(In reply to Jeremy Allison from comment #40)
The ad_getentrylen(ad, ADEID_FINDERI) check in in ad_unpack_xattrs() is just checking whether FinderInfo is actually containing additional xattrs which is implied by a lenght > 32. It's not a marshalling/security check. So if ad_getentrylen(ad, ADEID_FINDERI) is 32 or smaller we just do nothing and return success.

The sanity checks for a conforming AppleDouble data blob are now all done in ad_entry_check_size() for all AppleDouble entries, so callers can be more relaxed and just check for presence of the AppleDouble entries they expect. Iow the ad_getentrylen() check in ad_getentrylen() could in theory be removed.

Makes sense? :)

Comment on attachment 17091 [details]
CVE-2021-44142 Advisory v4

Looks great Ralph, thanks !

Comment on attachment 17087 [details]
Patch for master

Ok Ralph, thanks for the explanation. That actually makes sense :-). I think I'm good with this now. RB+.

Created attachment 17092 [details]
Patch for 4.15 cherry-picked from master

Created attachment 17093 [details]
Patch for 4.14 backported from master

Just a minor conflict in the tests driver tests.py caused by context differences.

Created attachment 17094 [details]
Patch for 4.13 backported from master

Additional conflict caused by context changes in trans2.c by changed includes.

Planned release date is set for January 31st. Does that work for everyone? Bug will be opened to vendors this Friday.

No concerns with release schedule.  @slow have you or anyone written up the CVE-2021-44142 JSON file?  Want us to do it?

CERT/CC would like to pre-notify a set of vendors, I'll propose we do this on Jan 24, and that we inform recipients that:

* an important Samba vulnerability in vfs_fruit is being handled
* expected public disclosure is Jan 31
* those who use Samba and want further details should... contact Samba?  If so, how?
* CERT/CC will publish a vulnerability note on Jan 31 once the Samba release and documentation are published

We could distribute patches, but that seems more complicated than directing interested parties to contact Samba.  I also expect many of our vendors will just wait for the official Samba release, but some might want to test earlier.

I suspect that the Samba and CERT/CC vendor sets overlap some, we can use the CVE ID to avoid confusion.

We think our pre-notification is an effective way to reduce risk, but we want to work with and respect the Samba disclosure policy and process.

Hi Art

Western Digital will not be ready for a Jan 31 disclosure. Our engineers are in Asia and will be celebrating Chinese New Year. They plan to incorporate the fix beginning 2/18. I suspect it will take a few days from there. Can we delay the disclosure till the end of Feb?

(In reply to diana.della.rocchetta from comment #53)

Hard to say who's in charge of that decision, I'll suggest it's mostly up to Samba, here is their process:

https://wiki.samba.org/index.php/Samba_Security_Process

So far:

  Samba: Jan 31
     WD: ~Feb 28
DEVCORE: Feb 17
    ZDI: April?

CERT/CC doesn't have a set date.  DEVCORE, WD, and ZDI have researcher stakes, WD is also a downstream vendor, and Samba owns their process.  I'll ask a typical set of questions, is Samba willing to delay, and can WD act more quickly?  Delaying fixes is bad, publishing before downstream vendors are ready is bad, we're looking for a less/least bad option.

(In reply to Art Manion from comment #54)
Sorry, but this can't be delayed further. Our process it to release as as soon as possible once patches are ready and tested, giving vendors a 10 day ahead of time notification.
Given the severity of this issue it's crucially important to get this out of the door as soon as possible without delays.

Opening bug to vendors.

Samba vendors, set release date for this is January 31st.

(In reply to Art Manion from comment #51)
> @slow have you or anyone written up the CVE-2021-44142 JSON file?
> Want us to do it?

We only provide the plain text version, if you need a JSON version please do that on yourself.

(In reply to Art Manion from comment #52)
> CERT/CC would like to pre-notify a set of vendors, I'll propose
> we do this on Jan 24, and that we inform recipients that:

To avoid uncontrolled spreading of sensitive information we try to control and restrict the list of parties that get notified by requiring them to be a registered Samba vendor. Vendors can be onboarded by sending a mail to security@samba.org.

Having said that, I guess it's ok for CERT to be an exception to this rule.

> * an important Samba vulnerability in vfs_fruit is being handled0
> * expected public disclosure is Jan 31
> * those who use Samba and want further details should... contact Samba?
> If so, how?

Mail security@samba.org

> We could distribute patches, but that seems more complicated
> than directing interested parties to contact Samba.  

Please don't distribute patches. Have them contact security@samba.org so we can onboard them, add them to the Samba vendors list so they get access to this bug and the patches.

Thanks!

(In reply to Ralph Böhme from comment #59)

ACK, we'll notify our vendor list Monday Jan 24 and direct interested parties to security@samba.org.

Samba vendors, release date for this is going to be January 31st.

Created attachment 17115 [details]
backport for 4.11.14

Backport for 4.11.14

Aside from location of the patches (adouble.[ch] doesn't exist in this version) backported patches should be more or less the same as functionality as patches for 4.13

Created attachment 17116 [details]
backport for 4.6.16

Patches here are again more or less (aside from adouble.[ch]) functionally equivelant to patches for 4.13.

However, one difference here is the hardening check in (see [PATCH 4/6] SQUASH: vfs_fruit: CVE-2021-44142 tweak buffer size check)

ad_alloc is different in this samba version and while the initial value of bufsize is AD_DATASZ_DOT_UND (for the case where there are no embedded xattrs) bufsize is incremented in ad_read_rsrc_adouble before ad_unpack so in this version it seems bufsize can be between ADEDOFF_FINDERI_DO and AD_XATTR_MAX_HDR_SIZE.

*BUT* to be honest I'm not sure if this check is still necessary (or even correct now) I think ad_entry_check_size (and it's usage should be sufficient)

Created attachment 17117 [details]
backport for 4.4.2

Patches here are different again, this version of vfs_fruit doesn't support embedded xattrs and seems to strip them out, however it still looks like a manipulated len between 0-31 could cause an OOB so I included the ad_entry_check_size patches (and a supporting pre-requisite patch). Because embedded xattrs are not processed (and if present truncated, e.g. entry len for ADEID_FINDERI is fixed to ADEDLEN_FINDERI in ad_convert after ad_upack) To handle that I had to modify the ad_entry_check_size method, please see ( [PATCH 5/5] squash: Adjust previous patch to cater for non handling
 of emedded xattrs )

Created attachment 17119 [details]
CVE-2021-44142 Advisory v5

Bumped 4.15 version number after release last week and added section on affected configurations.

Comment on attachment 17119 [details]
CVE-2021-44142 Advisory v5

"then the default values"

should be:

"than the default values".

Sorry.

Created attachment 17128 [details]
CVE-2021-44142 Advisory v6

s/then/than/
s/different setting/different settings/

There will be a delay in releasing the patch due to the Chinese New Year. Western Digital would like to propose to move the disclosure date to Feb 14, 2022. We will be ready to release on Feb 7, 2022.

Also, please let us know where we can download the patch from ASAP.

There will be a delay in releasing the patch due to the Chinese New Year. Western Digital would like to propose to move the disclosure date to Feb 14, 2022. We will be ready to release on Feb 7, 2022.

Also, please let us know where we can download the patch from ASAP.

There will be a delay in releasing the patch due to the Chinese New Year. Western Digital would like to propose to move the disclosure date to Feb 14, 2022. We will be ready to release on Feb 7, 2022.

Also, please let us know where we can download the patch from ASAP.

There will be a delay in releasing the patch due to the Chinese New Year. Western Digital would like to propose to move the disclosure date to Feb 14, 2022. We will be ready to release on Feb 7, 2022.

Also, please let us know where we can download the patch from ASAP.

(In reply to Muskaan Kalra from comment #71)

@Muskaan patches are attached at the top of this ticket.

Comment on attachment 17128 [details]
CVE-2021-44142 Advisory v6

While I question the value of digging in to the CVSS vector, I'll suggest S:U and base score 8.8 (scope is not changed, any code execution happen with the privileges of the Samba process running the OS).

(In reply to Art Manion from comment #73)

Art, code running with the privileges of the Samba process can merely call an internal function to become root (the function is called become_root() :-). We run as realid 0, eid authenticated user. So I think the original score is appropriate.

(In reply to Muskaan Kalra from comment #71)
Please see comment #55.

This bug was referenced in samba v4-13-stable (Release samba-4.13.17):

57d9afe5d71da5360501f43f1c69208bca3b0769
9eba87ce4b47488f1422248b8d4ad9b37ae26899
b3b76222cfba5d162843b14b55570a02573c8ce8
ffa40d4acb5f2d57443670be31dca05caacb1cfd
edf661e40b3c17681563613bf58b2e757a6ebc12

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.

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

eee61be9b5867b63b73b0b1fea03f44a4e1235b7
22b4091924977f6437b59627f33a8e6f02b41011
b4c0b4620f12055207adb0519c8d91c3021f354a
4533a7b4319cd95815d2dcd5fe5075539fb850e5
0e2b3fb982d1f53d111e10d9197ed2ec2e13712c

This bug was referenced in samba v4-14-stable (Release samba-4.14.12):

8b7d5751eee3c18ebbf9069e9b06a7c5e08a469e
4672487f3db3a88070ffcb2cc8fec4b7d3b24186
5da11db4cd9058bbec13a3096e7597727798a627
3dab3dd8d57d9d727d6d15577435bfe22993f525
092e9baee3b83dfddf732c9cded316d400744a7a

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

57d9afe5d71da5360501f43f1c69208bca3b0769
9eba87ce4b47488f1422248b8d4ad9b37ae26899
b3b76222cfba5d162843b14b55570a02573c8ce8
ffa40d4acb5f2d57443670be31dca05caacb1cfd
edf661e40b3c17681563613bf58b2e757a6ebc12

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

eee61be9b5867b63b73b0b1fea03f44a4e1235b7
22b4091924977f6437b59627f33a8e6f02b41011
b4c0b4620f12055207adb0519c8d91c3021f354a
4533a7b4319cd95815d2dcd5fe5075539fb850e5
0e2b3fb982d1f53d111e10d9197ed2ec2e13712c

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

8b7d5751eee3c18ebbf9069e9b06a7c5e08a469e
4672487f3db3a88070ffcb2cc8fec4b7d3b24186
5da11db4cd9058bbec13a3096e7597727798a627
3dab3dd8d57d9d727d6d15577435bfe22993f525
092e9baee3b83dfddf732c9cded316d400744a7a

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

9d7dd721b81292c197f0c1556e38c006604b6727
36f847861bcea8cfca80121055685d7ddf6d73f2
39eb60d97a4e2ae2765b5bc964e5606534ef664a
03c6ba0054b79143519fcf3079715139c0632a6f
ef8229843604bd2dcd17403a786ea70586e3d632

This bug was referenced in samba master:

a9211cfe6e4bceb1f1e61c0ddfda25f3232aa411
96083abc0c32aca397cfdf4341d179bfc5663d35
c61a06503ede85658e9f0b3ac1f9c2a30ccf2fe7
eb087934025c5e1f29a584ea5594ac4838018cdf
751d7696646975f34c1d053a90c49756e7a87c68

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

9d7dd721b81292c197f0c1556e38c006604b6727
36f847861bcea8cfca80121055685d7ddf6d73f2
39eb60d97a4e2ae2765b5bc964e5606534ef664a
03c6ba0054b79143519fcf3079715139c0632a6f
ef8229843604bd2dcd17403a786ea70586e3d632

Pushed to all branches.
Closing out bug report.

Thanks!