Volker Lendecke [Fri, 19 Dec 2025 13:27:41 +0000 (14:27 +0100)]
smbd: Make reference_smb_fname_fsp_link() static
Only referenced in files.c
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Anoop C S <anoopcs@samba.org>
Autobuild-User(master): Anoop C S <anoopcs@samba.org>
Autobuild-Date(master): Mon Aug 3 10:08:42 UTC 2026 on atb-devel-224
Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Sat Aug 1 09:11:02 UTC 2026 on atb-devel-224
Martin Schwenke [Thu, 30 Jul 2026 04:49:16 +0000 (14:49 +1000)]
ctdb-common: Align integer types
Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Anoop C S <anoopcs@samba.org>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Fri Jul 31 00:48:24 UTC 2026 on atb-devel-224
These are listed as: Memory - corruptions (OVERRUN)
While sockaddr_ll only has 8 octets for sll_addr, a sockaddr_storage
is being intentionally used here to provide additional space. So, the
overrun is a technicality and there is no corruption.
However, the code is incorrect because it does overrun sll_addr[] in
sockaddr_ll. The assignments into out-of-bounds indices also cause
the -O3 build fail.
So, use an extra variable to point to where sll_addr should start in a
sockaddr_storage and index from there.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Anoop C S <anoopcs@samba.org>
lib: Fix undefined behaviour at fork time in pthreadpool
If a pthread times out at the same time with a fork, ETIMEDOUT is
overwritten and not being taken care of. This means that we can race
with the forking thread destroying pool->condvar in the next round of
the thread's while(1) loop. pthread_cond_wait() on a condition
variable that has been destroyed is not a good idea.
Shachar Sharon [Mon, 23 Mar 2026 09:47:33 +0000 (11:47 +0200)]
smbstatus: Split brlocks logic into collect and dump phases
Split the logic of 'smbstatus --byterange' into two phases:
1) Collect locks-info into in-memory representation (linked-list) under
lock of 'locking.tdb'.
2) Print-out (text or json) locks-info _after_ releasing this lock.
This split-logic is needed to avoid deadlock with smbd; in particular,
cases where the output of 'smbstatus -B' is piped-out into another
process, the primary lock may be held for long duration due to blocked
stdout on smbstatus side, thus causing starvation on smbd side.
Pair-Programmed-With: Volker Lendecke <vl@samba.org> Signed-off-by: Shachar Sharon <ssharon@redhat.com> Reviewed-by: Anoop C S <anoopcs@samba.org> Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Thu Jul 30 12:41:51 UTC 2026 on atb-devel-224
s4:torture/smb2: split out smb2.persistent-open-reconnect-contended
This means the rule in selftest/skip actually works.
Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Wed Jul 29 08:33:12 UTC 2026 on atb-devel-224
Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Björn Jacke <bjacke@samba.org>
Autobuild-Date(master): Tue Jul 28 17:02:13 UTC 2026 on atb-devel-224
Volker Lendecke [Wed, 17 Jun 2026 06:24:47 +0000 (08:24 +0200)]
CVE-2026-58218: dns_server: Fix an error path memleak
We talloc the new key off "dns->tkeys", which is long-lived. On any
error we never free'd that again. Probably not remotely triggerable,
this is only setting up the gensec context.
Douglas Bagnall [Sun, 31 May 2026 00:48:11 +0000 (12:48 +1200)]
CVE-2026-58216: kdc:kpasswd: calculate correct size for password blob
We were making the enc_data_blob 6 bytes too big.
Its payload is an ASN.1 structure that knows its own size, so the
extra bytes are not usually read by Heimdal, but a crafted packet
could force them to be read.
Martin Schwenke [Tue, 30 Jun 2026 03:58:22 +0000 (13:58 +1000)]
CVE-2026-58224: ctdb-common: Add comments to ward off vulnerability reports
We can't deal with this in the current CTDB protocol without
disproportionate effort. So, document reality clearly in the code to
try to stop these from being reported.
Martin Schwenke [Wed, 10 Jun 2026 02:37:02 +0000 (12:37 +1000)]
CVE-2026-58224: ctdb-protocol: Avoid DoS memory allocations
The pull loop already avoids out of bounds accesses beyond the end of
the buffer. However, it does not avoid a DoS memory allocation due to
an unreasonably large array size.
Check that the number of specified array elements can be pulled from
buffer, which puts a reasonable upper bound on the subsequent memory
allocation.
Use an initialised dummy variable to avoid static analysers
complaining about uninitialised variables being passed.
Martin Schwenke [Wed, 10 Jun 2026 02:15:17 +0000 (12:15 +1000)]
CVE-2026-58224: ctdb-protocol: Avoid DoS memory allocations
The pull loop already avoids out of bounds accesses beyond the end of
the buffer. However, it does not avoid a DoS memory allocation due to
an unreasonably large array size.
Check that the number of specified array elements can be pulled from
buffer, which puts a reasonable upper bound on the subsequent memory
allocation.
Use an initialised dummy variable to avoid static analysers
complaining about uninitialised variables being passed.
Martin Schwenke [Tue, 9 Jun 2026 11:54:20 +0000 (21:54 +1000)]
CVE-2026-58224: ctdb-protocol: Always pull the specified number of bytes
The string should not contain a premature NUL terminator, which would
cause less than the specified number of bytes to be pulled. If it
does, consume the specified number of bytes anyway. The alternative
doesn't make sense.
Note that this is unlikely to be a security issue, where trailing data
in the string field causes the buffer to be overrun. That would
require an additional protocol bug. However, include this fix here
for posterity.
Martin Schwenke [Tue, 9 Jun 2026 11:48:02 +0000 (21:48 +1000)]
CVE-2026-58224: ctdb-protocol: Avoid off-by-one error for bytes pulled
As per the comment, if there is no NUL byte in the buffer then don't
count one in the number of bytes pulled.
Note that this is unlikely to be a security issue because it would
take a protocol bug elsewhere to overrun the buffer. However, include
this fix here for posterity.
Martin Schwenke [Tue, 9 Jun 2026 00:41:25 +0000 (10:41 +1000)]
CVE-2026-58224: ctdb-daemon: Avoid out of bounds data access
Instead of checking only that there is enough data for the length
field, check there is enough data for the entire header part of the
struct. After cross-checking overall lengths, ensure there is enough
data for the key/data in the data element.
Martin Schwenke [Sun, 31 May 2026 05:11:39 +0000 (15:11 +1000)]
CVE-2026-58224: ctdb-daemon: Avoid out of bounds data access
The first check is clearly needed because m->db_id is referenced. The
second check is handled by a similar update to
ctdb_control_update_record(), but repeat it in case something else
changes.
Martin Schwenke [Sat, 30 May 2026 04:25:00 +0000 (14:25 +1000)]
CVE-2026-58224: ctdb-daemon: Avoid out-of-bounds data access
Do not allow the VNN map's size to extend past the end of the buffer.
This is checked by switching to ctdb_vnn_map_pull(), which also
simplifies the code.
Martin Schwenke [Sat, 30 May 2026 04:38:02 +0000 (14:38 +1000)]
CVE-2026-58224: ctdb-protocol: Avoid DoS memory allocation
The pull loop already avoids out of bounds accesses beyond the end of
the buffer. However, it does not avoid a DoS memory allocation due to
an unreasonably large array size.
Check that the number of specified array elements can be pulled from
buffer, which puts a reasonable upper bound on the subsequent memory
allocation.
Use an initialised dummy variable to avoid static analysers
complaining about uninitialised variables being passed. Variable i
could be reused but that might be confusing, so leave any optimisation
to the compiler.
Reported-by: Martin Schwenke <mschwenke@ddn.com> Reported-by: Also Andrew Tridgell (issue 22) Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Stefan Metzmacher <metze@samba.org>
CVE-2026-6949: s4:dns_server: correctly truncate the buffer for TSIG verification
Calculating the length of the TSIG additional dns_res_rec,
via ndr_push_dns_res_rec() is fragile and may generate
a buffer larger than the original dns_name_packet buffer.
This could underflow the resulting packet_len,
to a very large value and buffer_len to a small value.
Resulting in a memcpy() of a very large size into
a very small buffer. This most likely already
gets a segmentation fault when reading after the
in->data.
This was reported by Arjun Basnet with Securin Labs.
While the code can generally handle arbitrary length addresses, known
lengths are used to set the hardware type. Therefore, tests are
artificially limited to 6 octet addresses (Ethernet) and 20 octet
addresses (IPoIB).
As per the comment in the code: reading RFC4391, section 4 and looking
at example GIDs on a system, suggests a simple method of mapping the
IPv4 broadcast address to an IPv6oIB multicast address.
Variable sall is no longer used by IPv4. It is now only used to
construct the sendto() destination address for IPv6 NA.
Replace this variable with a sockaddr_storage so it can fit larger
link-level addresses. Change the type of ip6_ll_multicast_build() and
use it to set the sockaddr_storage (as a sockaddr_ll), based on the
link-level broadcast address and RFCs.
Martin Schwenke [Fri, 5 Dec 2025 06:39:56 +0000 (17:39 +1100)]
ctdb-common: Find interface using getifaddrs(3)
This is the first step towards IPoIB ARP/NA support, which uses 20
octet hardware addresses. See the comment in the code for more
details.
This is a (relatively) minimal change. find_interface() returns a lot
of duplicate information that isn't yet used. Also, this is (still)
explicitly restricted to Ethernet. Improvements and clean up to come
in subsequent commits.
projects / thirdparty / samba.git / log
