Bug 14605 - Zero length VLAs in messaging functions can lead to segfaults
Summary: Zero length VLAs in messaging functions can lead to segfaults
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.13.3
Hardware: All FreeBSD
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-01 21:00 UTC by Dimitry Andric
Modified: 2021-01-29 13:56 UTC (History)
1 user (show)

See Also:


Attachments
Patch for 4.12 and 4.13 cherry-picked from master (2.19 KB, patch)
2021-01-04 14:10 UTC, Ralph Böhme
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric 2021-01-01 21:00:58 UTC
As reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252157, on recent versions of FreeBSD 13.0-CURRENT with clang/llvm 11.0.0, the various samba ports (net/samba411, net/samba/412 and net/samba413) sometimes dump core when shares are accessed.

This turned out to be due to variable length arrays (VLAs) being used in source3/lib/messages.c, where sometimes the length would end up being zero, which is undefined behavior. For example, in messaging_recv_cb() there is a VLA 'fds64[]', being declared using incoming 'num_fds' parameter, which is sometimes zero, resulting in:

Program received signal SIGSEGV, Segmentation fault.
0x0000000801c784a7 in messaging_recv_cb (ev=0x805475060, msg=0x7fffffffdbe8 "\035#", msg_len=98, fds=0x7fffffffdbdc, num_fds=0, private_data=0x80546e300) at ../../source3/lib/messages.c:394
394             int64_t fds64[MIN(num_fds, INT8_MAX)];
(gdb) print num_fds
$6 = 0

To fix this, I propose to use MAX(1, number) to ensure the VLA is always declared with a length of at least 1. In the FreeBSD port case, this fixes the aforementioned core dumping occurrences.

I found two other places in source3/lib/messages.c using VLAs and incoming length parameters, which can also be fixed in the same way. The proposed fix is at:
https://gitlab.com/DimitryAndric/samba/-/commit/37b28febaaea58de08434eff7dcc73908b542ffd

I will also create a MR from this branch.
Comment 1 Dimitry Andric 2021-01-01 21:11:43 UTC
Due to commit message rewriting, the commit hash changed to:
https://gitlab.com/DimitryAndric/samba/-/commit/638058cdfa1efbd0c334f103b2fed42e8d86e980
Comment 2 Samba QA Contact 2021-01-04 10:51:07 UTC
This bug was referenced in samba master:

3e96c95d41e4ccd0bf43b3ee78af644e2bc32e30
Comment 3 Ralph Böhme 2021-01-04 14:10:44 UTC
Created attachment 16373 [details]
Patch for 4.12 and 4.13 cherry-picked from master
Comment 4 Karolin Seeger 2021-01-05 08:10:47 UTC
Pushed to autobuild-v4-{13,12}-test.
Comment 5 Samba QA Contact 2021-01-05 09:12:03 UTC
This bug was referenced in samba v4-12-test:

d24a1173c9a42ba1123b7efff7d89d55cd6ab211
Comment 6 Samba QA Contact 2021-01-05 12:51:04 UTC
This bug was referenced in samba v4-13-test:

6e6a16d88050ee7930f74e12615c0e046c3f9f77
Comment 7 Karolin Seeger 2021-01-06 11:16:32 UTC
Closing out bug report.

Thanks!
Comment 8 Samba QA Contact 2021-01-14 08:35:07 UTC
This bug was referenced in samba v4-12-stable (Release samba-4.12.11):

d24a1173c9a42ba1123b7efff7d89d55cd6ab211
Comment 9 Samba QA Contact 2021-01-29 13:56:18 UTC
This bug was referenced in samba v4-13-stable (Release samba-4.13.4):

6e6a16d88050ee7930f74e12615c0e046c3f9f77