They say

CVSS 3.1: 6.5 (AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H)

meaning anyone on the subnet can crash a ctdb node and maybe get a glimpse of some of its memory.

The ctdb nodes trust each other. Everybody who can mask under an IP address listed in the nodes file has so many ways to corrupt things that I would consider this not too bad.

Created attachment 18999 [details]
Initial draft patch

Here is an initial draft patch for those who are interested.  Not for formal review yet.  Just sanity checking.

Elsewhere, I had mentioned using newer pull functions.  This causes a lot of churn, so: no.

(In reply to Volker Lendecke from comment #2)

Yes.

Also, this isn't a case of creating a new TCP connection and sending an invalid packet.  The TCP connections between nodes are long-lived, so the node spoofing a known node IP would have to have a fake ctdbd that connects at startup (before the node being spoofed) or later (by disrupting an existing connection so it can replace that connection).  This definitely raises the barrier.

Tomorrow, I will check whether a new connection attempt from an already connected node will cause the existing connection to be terminated.  I don't think so, but I haven't looked at this code in detail for quite a while.

Thanks for the fast patch, Martin.

On the trust model: I understand CTDB nodes trust each other by design, and the practical barrier is higher than "send one packet" because of the long-lived TCP connection model. That is a fair point about attack complexity.

However, the source code explicitly documents the absence of authentication at tcp_connect.c:300 ("currently makes no attempt to check if the connection is really from a ctdb node"), and the only gate is IP matching via ctdb_ip_to_node(). On a cluster interconnect, ARP spoofing is a standard lateral movement technique that defeats IP-based access control. The comment in the source itself suggests this was known to be a gap.

I think the scoring depends on what threat model Samba uses for CTDB. If the cluster network is assumed to be physically isolated and trusted (like iSCSI), then the impact is indeed lower. If it is a shared network segment (common in smaller deployments where cluster and client traffic share the same VLAN), the attack is more practical.

Either way, the bounds checks in the patch are clearly correct -- the handlers should not trust embedded length fields to be consistent with the allocation. Happy to test the draft patch against the lab reproducer if useful.

(In reply to TristanInSec from comment #6)
> I think the scoring depends on what threat model Samba uses for CTDB. If the
> cluster network is assumed to be physically isolated and trusted (like
> iSCSI), then the impact is indeed lower. If it is a shared network segment
> (common in smaller deployments where cluster and client traffic share the
> same VLAN), the attack is more practical.

If you can successfully connect to a ctdb node and pass the IP checks, you're in. You can trivially create havoc to the cluster with a few simple packets, all databases including ones containing secret data are there for your disposal. We might have to document this better, but there is no quick way to turn our telnet-level of security into something ssh-like.

(In reply to TristanInSec from comment #6)

> Either way, the bounds checks in the patch are clearly correct -- the handlers
> should not trust embedded length fields to be consistent with the allocation.
> Happy to test the draft patch against the lab reproducer if useful.

Thanks for reporting the issue and for taking a look at the patch.

If you're happy to test, then please do so...

For the seriousness...

This is somewhat mitigated by ctdb(7) saying:

> It is strongly recommended that the private addresses are configured
> on a private network that is separate from client  networks. This is
> because the CTDB protocol is both unauthenticated and unencrypted. If
> clients share the private network then steps need to be taken to stop
> injection of packets to relevant ports on the private addresses. It
> is also likely that CTDB protocol traffic between nodes could leak
> sensitive information if it can be intercepted.   

That minimises the possibility of "cluster-adjacent with IP
spoofing"... but not everyone listens to reasonable advice.

We can discuss this back and forth some more to decide how to proceed.

My current view is that if we do a security release for something, I have no
problem with us including this in the process.

(In reply to Martin Schwenke from comment #4)

> Tomorrow, I will check whether a new connection attempt from an already 
> connected node will cause the existing connection to be terminated.  I don't 
> think so, but I haven't looked at this code in detail for quite a while.

Where tomorrow means some time over the weekend...

Thanks Martin. I'll pull the patch and test against the reproducer -- will report back with results.

On proceeding: the ctdb(7) warning itself acknowledges that shared-network deployments exist ("if clients share the private network then steps need to be taken"). A documented mitigation that users may or may not follow doesn't eliminate the vulnerability -- it's a compensating control. I'd support handling this as a security fix with CVE assignment. The patch is clearly correct regardless of the threat model debate.

(In reply to Martin Schwenke from comment #8)

Hi Martin,

Just tested the patch against a 2-node Docker cluster with ASan-enabled ctdbd built from Samba 4.24.2.

Sent crafted CTDB_REQ_CALL with keylen=256 in a 64-byte packet (only 8 bytes of data area). Unpatched: packet processed without validation. Patched: cleanly rejected with "ctdb_request_call: Invalid packet" logged, daemon stays alive. The bounds checks work as expected.

On proceeding: the ctdb(7) warning itself acknowledges that shared-network deployments exist ("if clients share the private network then steps need to be taken"). A documented mitigation that users may or may not follow doesn't eliminate the vulnerability -- it's a compensating control. I'd support handling this as a security fix with CVE assignment. The patch is clearly correct regardless of the threat model debate.

(In reply to Martin Schwenke from comment #9)

> [...] I will check whether a new connection attempt from an already connected 
> node will cause the existing connection to be terminated.  I don't think so, 
> but I haven't looked at this code in detail for quite a while.

ctdb/tcp/tcp_connect.c:ctdb_listen_event() handles incoming connections.  It 
does this quite early on:

	if (tnode->in_queue != NULL) {
		DBG_ERR("Incoming queue active, rejecting connection from %s\n",
			node->name);
		goto failed;
	}

That is, if there is already a connection from the node then a new connection
attempt is rejected.

This reduces the attack surface and means that an attacking node needs to be 
active before the node being spoofed starts and connects.  If a node is taken
offline for maintenance then this is certainly a possibility.

Tristan, how does your reproducer work?

> Sent crafted CTDB_REQ_CALL with keylen=256 in a 64-byte packet (only 8 bytes 
> of data area).

Does it open a new connection, connect pretending to be another CTDB node (which
isn't already connected) and then send the crafted CTDB_REQ_CALL?  Or does it do
something more nefarious?  :-)

Thanks...

Created attachment 19004 [details]
Work in progress patch v2

More turtles at the next level down: controls have their own sub-protocol and this sometimes happens there as well.  Trying to find and fix those too.  I think I'm more than 1/2 way through.

This seems like a reasonable place for an off-site backup of work-in-progress.  ;-)

(In reply to Martin Schwenke from comment #13)

Hi Martin,

On the reproducer: yes, straightforward -- 2-node Docker cluster, attacker registered in the nodes file as node 1, PoC opens a new TCP connection from that IP, sends one crafted packet, disconnects. No ARP spoofing or hijacking. Works because node 1's ctdbd isn't running, so `tnode->in_queue` is NULL and the connection is accepted.

On the v2 patch: reviewed all 6 commits. 1/6 and the new sub-protocol hardening (2/6, 4/6, 5/6, 6/6) all look correct. Nice catches on the VNN map allocation DoS and the db_attach string termination.

One issue in patch 3/6 (ctdb_recover.c setvnnmap): the recovery mode guard lost its `return -1`. The if-block closes early with the new `}` and the original `return -1;` gets absorbed into the `if (ret != 0)` block for ctdb_vnn_map_pull(). Result: setvnnmap logs but falls through and sets the VNN map even outside recovery mode.

Also two typos in 3/6: "Memory allocatione error" (extra 'e') and `break;;` (double semicolon).

Will re-test once 3/6 is fixed.

Created attachment 19007 [details]
Patch for master branch v3

I have now been through all of the controls and I think I've caught all of the issues.

1 additional commit, some reviewed by tags and fixes in commit 3 (thanks Tristan - I completely lost that hunk in the patch, noticed, but only put back most of it; typos fixed too).

(In reply to Martin Schwenke from comment #15)

Hi Martin,

Tested v3 patch against Samba 4.24.2 with ASan-enabled ctdbd in a Docker cluster.

Sent all 4 crafted packet types (CTDB_REQ_CALL, REQ_DMASTER, REQ_MESSAGE, REQ_CONTROL) with oversized keylen/datalen fields in 64-byte packets. All were silently rejected — no ASan crash, no OOB read, daemon stays alive.   

v3 patch works correctly. The additional hardening (VNN map DoS, db_attach NUL check, marshall_buffer count checks, trans3_commit) all look good.

Created attachment 19015 [details]
Patch for master branch v4

Similar additional issues were reported by Tridge, so including fixes for them
in this ticket.  They are no worse than the issues reported by Tristan.

I have fixed the reported issues plus similar unreported issues in
ctdb/protocol/protocol_types.c.  All the places that use talloc_array() have
now been fixed or commented on.

Tridge's report also included a couple of cases where the solution would be to
limit the maximum size of packets.  However, given the incremental development
of the current CTDB protocol, it is difficult to determine a maximum packet
size that won't break anything.  So, I won't fix these.  Instead, I have:

* secured the eventd socket, to avoid any doubts there; and
* strengthened the statements in the documentation about the private network.

Hopefully this is sufficient.  Viva CTDB redesign!

Tristan, I have currently dropped the Reviewed-by: tag for you in:

  Subject: [PATCH 02/14] ctdb-protocol: Avoid DoS memory allocation

After becoming aware of more of these, I reworked the commit message and
moved the new check to immediately before the talloc_array() call - it was
previously before the if-statement just above where it is now.

(In reply to Martin Schwenke from comment #17)

LGTM

For the patch, if you decide to add me (up to you)
or in other, can you please rather use:
Tristan Madani <tristan@talencesecurity.com>

Thanks.

Best,
Tristan

(In reply to TristanInSec from comment #18)

Hi Tristan,

LGTM

> For the patch, if you decide to add me (up to you)
> or in other, can you please rather use:
> Tristan Madani <tristan@talencesecurity.com>

Happy to mark you as a reviewer all commits, with that email address.

Is that what you were suggesting, or only the 2nd commit where I had dropped
you because I had changed the commit?

Thanks...

Here are the 5 issues reported by Andrew Tridgell.  They overlap with the issues 
reported by Tristan and all affect the CTDB private network protocol.  So, 
including them here.

Summaries first:

| 11 | medium | high | [CTDB TCP packet framing reallocates to peer-controlled packet lengths before validating size and header fields](#11-ctdb-tcp-packet-framing-reallocates-to-peer-controlled-packet-lengths-before-validating-size-and-header-fields) | Uncontrolled resource consumption |
| 13 | medium | high | [CTDB TRAVERSE_DATA legacy handler accepts undersized record buffers before dereferencing reqid/keylen/datalen fields](#13-ctdb-traverse-data-legacy-handler-accepts-undersized-record-buffers-before-dereferencing-reqid-keylen-datalen-fields) | CTDB parser out-of-bounds read |
| 16 | medium | high | [CTDB event string decoder can advance beyond a declared field length when a string lacks NUL termination](#16-ctdb-event-string-decoder-can-advance-beyond-a-declared-field-length-when-a-string-lacks-nul-termination) | Length-delimited string parser desynchronization |
| 22 | medium | high | [CTDB control reply map/count fields allocate arrays before remaining-length validation](#22-ctdb-control-reply-map-count-fields-allocate-arrays-before-remaining-length-validation) | resource exhaustion from count-controlled allocation |
| 34 | medium | high | [CTDB eventd and framed socket readers allocate from peer-controlled packet lengths before protocol validation](#34-ctdb-eventd-and-framed-socket-readers-allocate-from-peer-controlled-packet-lengths-before-protocol-validation) | Unbounded packet-length allocation |


### [11] CTDB TCP packet framing reallocates to peer-controlled packet lengths before validating size and header fields

| Field | Value |
|---|---|
| Severity | medium |
| Confidence | high |
| Confidence rationale | Static source tracing identifies the attacker input, broken control, and sink in repository code. Remaining uncertainty: Runtime proof would require CTDB networking or a cluster/local daemon setup. |
| Category | Uncontrolled resource consumption |
| CWE | CWE-400 |
| Affected lines | ctdb/tcp/tcp_connect.c:298-379; ctdb/common/ctdb_io.c:97-157; ctdb/common/ctdb_io.c:163-260; ctdb/common/ctdb_io.c:458-503; ctdb/tcp/tcp_io.c:38-82; ctdb/server/ctdb_client.c:313-315; ctdb/server/ctdb_daemon.c:1168-1170 |

#### Summary

A CTDB peer that passes node-address gating can advertise an oversized frame length that drives receive-buffer realloc and packet duplication before CTDB magic, version, alignment, or minimum-header checks run.

Candidate `CAN-R06-034-ctdb-tcp-packet-length-alloc` survived validation as a reportable `Uncontrolled resource consumption` issue.

#### Validation

Method: static source tracing across the validation and attack-path artifacts, with deployment and runtime limits retained as proof gaps rather than assumed away.

- ctdb/tcp/tcp_connect.c:298-379 accepts a peer, maps by source IP with ctdb_ip_to_node(), then creates tnode->in_queue using ctdb_queue_setup().
- ctdb/common/ctdb_io.c:163-260 reads the leading uint32 pkt_size and talloc_realloc_size()s queue->buffer.data to pkt_size if larger than the current buffer.
- ctdb/common/ctdb_io.c:97-157 waits for pkt_size bytes and duplicates pkt_size bytes with talloc_memdup().
- ctdb/common/ctdb_io.c:458-503 initializes only the starting queue buffer and pool; it does not cap later growth.
- ctdb/tcp/tcp_io.c:38-82 checks CTDB header fields only after a complete packet is delivered by the queue.
- ctdb/server/ctdb_client.c:313-315 and ctdb/server/ctdb_daemon.c:1168-1170 show local client/daemon paths use the same queue reader.

Remaining uncertainty: Runtime proof would require CTDB networking or a cluster/local daemon setup. Attacker must be a configured node, spoof/reach a configured node IP, compromise a node, or exercise a local queue consumer.

Receipts: `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R06-034-ctdb-tcp-packet-length-alloc/candidate_ledger.jsonl`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R06-034-ctdb-tcp-packet-length-alloc/validation_report.md`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R06-034-ctdb-tcp-packet-length-alloc/attack_path_analysis_report.md`.

#### Dataflow

- Attacker role: Configured CTDB node peer, attacker able to spoof/reach a configured node address, compromised node, or local CTDB queue client.
- Entrypoint: ctdb_listen_event() accepts CTDB TCP sockets from known node IPs and attaches them to ctdb_queue_setup().
- Trust boundary: Peer-controlled CTDB frame bytes cross into daemon/client receive queue allocation before CTDB header validation.

#### Reachability

The path is reachable under the attacker role and entry point documented above.

Attacker outcome: A CTDB peer that passes node-address gating can advertise an oversized frame length that drives receive-buffer realloc and packet duplication before CTDB magic, version, alignment, or minimum-header checks run.

#### Severity

Final severity is **medium**. This has a concrete sink and plausible attacker path, but role, configuration, optional feature, or runtime preconditions bound practical exploitability.

Additional runtime proof against a live Samba service or a default deployment configuration would raise confidence; evidence that the feature is unreachable, trusted-only, or fully mitigated in supported builds would lower severity.

#### Remediation

Enforce a protocol maximum packet size in ctdb_queue_setup()/queue_io_read() before reallocating or copying frame data. Add regression coverage that exercises the attacker-controlled input at the listed entry point and asserts the validation, authorization, containment, or size check occurs before the dangerous sink.



### [13] CTDB TRAVERSE_DATA legacy handler accepts undersized record buffers before dereferencing reqid/keylen/datalen fields

| Field | Value |
|---|---|
| Severity | medium |
| Confidence | high |
| Confidence rationale | Static source tracing identifies the attacker input, broken control, and sink in repository code. Remaining uncertainty: No CTDB cluster/socket runtime proof was run; validation is static because a live CTDB setup is outside the allowed proof scope. |
| Category | CTDB parser out-of-bounds read |
| CWE | CWE-125 |
| Affected lines | ctdb/server/ctdb_control.c:427-443; ctdb/server/ctdb_control.c:933-947; ctdb/server/ctdb_traverse.c:561-584; ctdb/include/ctdb_protocol.h:157-163; ctdb/protocol/protocol_types.c:1520-1577 |

#### Summary

A malicious CTDB peer or local control client can send a legacy TRAVERSE_DATA control with only the length word present; the old dispatch path accepts it and then dereferences reqid/keylen/datalen outside the buffer.

Candidate `CAN-R03-021-ctdb-traverse-short-record` survived validation as a reportable `CTDB parser out-of-bounds read` issue.

#### Validation

Method: static source tracing across the validation and attack-path artifacts, with deployment and runtime limits retained as proof gaps rather than assumed away.

- ctdb/server/ctdb_control.c:441-442 dispatches CTDB_CONTROL_TRAVERSE_DATA without CHECK_CONTROL_DATA_SIZE().
- ctdb/server/ctdb_control.c:941-947 passes c->data and c->datalen directly to the dispatcher.
- ctdb/server/ctdb_traverse.c:563-570 checks only data.dsize >= sizeof(uint32_t) and equality with d->length.
- ctdb/server/ctdb_traverse.c:574-584 reads reqid, keylen, datalen, and derived pointers after that short check.
- ctdb/include/ctdb_protocol.h:157-163 defines those fixed fields after length.
- ctdb/protocol/protocol_types.c:1520-1577 is a negative control with proper incremental bounds checks.

Remaining uncertainty: No CTDB cluster/socket runtime proof was run; validation is static because a live CTDB setup is outside the allowed proof scope.

Receipts: `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R03-021-ctdb-traverse-short-record/candidate_ledger.jsonl`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R03-021-ctdb-traverse-short-record/validation_report.md`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R03-021-ctdb-traverse-short-record/attack_path_analysis_report.md`.

#### Dataflow

**Attacker role:** Malicious or compromised CTDB node, or local user/process able to send CTDB control packets to ctdbd.

**Entrypoint:** ctdb_request_control() converts old control payload data into TDB_DATA and dispatches CTDB_CONTROL_TRAVERSE_DATA.

**Trust boundary:** Peer/local CTDB control bytes cross into ctdbd legacy record parsing.

**Controls and counterevidence:**
- The attacker is a CTDB peer or local control client, not a generic unauthenticated network user.
- The newer ctdb_rec_data_pull_data() decoder has field-by-field bounds checks.
- Runtime impact was not proven on a live CTDB cluster.

**Exploit steps:**
- Send a legacy CTDB_CONTROL_TRAVERSE_DATA packet whose payload is four bytes and whose length field is 4.
- The old control path builds TDB_DATA from the raw payload and reaches ctdb_control_traverse_data().
- The handler accepts the size because it only requires a length word and equality with d->length.
- The handler reads d->reqid and later fields outside the supplied buffer, likely crashing or destabilizing ctdbd.

- Additional evidence is available in the per-candidate attack-path report.

#### Reachability

The path is reachable under the attacker role and entry point documented above, with these limits considered:
- The attacker is a CTDB peer or local control client, not a generic unauthenticated network user.
- The newer ctdb_rec_data_pull_data() decoder has field-by-field bounds checks.
- Runtime impact was not proven on a live CTDB cluster.

Attacker outcome: A malicious CTDB peer or local control client can send a legacy TRAVERSE_DATA control with only the length word present; the old dispatch path accepts it and then dereferences reqid/keylen/datalen outside the buffer.

#### Severity

Final severity is **medium**. This has a concrete sink and plausible attacker path, but role, configuration, optional feature, or runtime preconditions bound practical exploitability.

**Impact calibration:** ctdbd denial of service through out-of-bounds reads; inconsistent larger lengths could also confuse traverse callback state.

**Likelihood calibration:** Medium: requires CTDB deployment and access as a peer or local control client, but the parser flaw is direct and high confidence.

**Severity rationale:** Final severity is **medium** because the repository evidence shows a real trust-boundary crossing and reachable sink, while the listed controls and deployment preconditions bound exploitability and blast radius.

Counterevidence and deployment limits considered: The attacker is a CTDB peer or local control client, not a generic unauthenticated network user.; The newer ctdb_rec_data_pull_data() decoder has field-by-field bounds checks.; Runtime impact was not proven on a live CTDB cluster..

Additional runtime proof against a live Samba service or a default deployment configuration would raise confidence; evidence that the feature is unreachable, trusted-only, or fully mitigated in supported builds would lower severity.

#### Remediation

Reject records smaller than the fixed old header, verify keylen and datalen fit within length before field use, or route legacy data through the checked protocol decoder. Add regression coverage that exercises the attacker-controlled input at the listed entry point and asserts the validation, authorization, containment, or size check occurs before the dangerous sink.


### [16] CTDB event string decoder can advance beyond a declared field length when a string lacks NUL termination

| Field | Value |
|---|---|
| Severity | medium |
| Confidence | high |
| Confidence rationale | Static source tracing identifies the attacker input, broken control, and sink in repository code. Remaining uncertainty: No CTDB daemon or crafted packet was executed. |
| Category | Length-delimited string parser desynchronization |
| CWE | CWE-125 |
| Affected lines | ctdb/protocol/protocol_basic.c:226-233; ctdb/protocol/protocol_basic.c:247-269; ctdb/protocol/protocol_basic.c:293-318; ctdb/protocol/protocol_basic.c:108-115; ctdb/event/event_protocol.c:380-451; ctdb/event/event_protocol.c:549-602; ctdb/event/event_protocol.c:1027-1053; ctdb/event/event_daemon.c:131-153; ctdb/event/event_request.c:116-140; ctdb/common/sock_io.c:223-245; ctdb/common/sock_daemon.c:141-151 |

#### Summary

A local eventd client can send an unterminated declared-length string; ctdb_string_pull() reports strlen()+1 bytes consumed, so subsequent RUN/SCRIPT scalar fields are parsed at an attacker-shifted offset or beyond the packet.

Candidate `CAN-R10-059-ctdb-event-string-consumption` survived validation as a reportable `Length-delimited string parser desynchronization` issue.

#### Validation

Method: static source tracing across the validation and attack-path artifacts, with deployment and runtime limits retained as proof gaps rather than assumed away.

- ctdb/protocol/protocol_basic.c:226-269 duplicates buflen bytes and reports ctdb_string_len(), implemented as strlen()+1.
- ctdb/protocol/protocol_basic.c:293-318 checks declared string length fits, but advances offset by the helper-reported npull.
- ctdb/protocol/protocol_basic.c:108-115 pulls uint32 fields with memcpy() after trusting the caller-computed buflen.
- ctdb/event/event_protocol.c:380-451 parses RUN strings before timeout and flags.
- ctdb/event/event_protocol.c:549-602 parses SCRIPT strings before an action enum.
- ctdb/event/event_protocol.c:1027-1053 performs offset > buflen only after nested request parsing returns.
- ctdb/event/event_daemon.c:131-153 passes framed socket bytes into event_pkt_send().

Remaining uncertainty: No CTDB daemon or crafted packet was executed. Socket permissions and daemon deployment affect local reachability, but the parser arithmetic is directly visible.

Receipts: `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R10-059-ctdb-event-string-consumption/candidate_ledger.jsonl`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R10-059-ctdb-event-string-consumption/validation_report.md`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R10-059-ctdb-event-string-consumption/attack_path_analysis_report.md`.

#### Dataflow

- Attacker role: Local CTDB event daemon client able to connect to the eventd framed socket.
- Entry point: event_client_send() passes framed client bytes to event_pkt_send(), which invokes ctdb_event_request_pull().
- Trust boundary: Local socket packet bytes cross into CTDB event request parsing before invalid packets are rejected.
- Exploit steps:
  1. Connect to eventd and send a framed event request containing RUN or SCRIPT request data.
  2. Set a stringn field length that fits within the remaining buffer but omit a terminating NUL inside that declared field.
  3. ctdb_stringn_pull() verifies only that the declared u32 length fits, then calls ctdb_string_pull() over that many bytes.
  4. ctdb_string_pull() uses talloc_strndup() and reports consumed length as strlen(copy) + 1, which can exceed the declared field length.
  5. RUN/SCRIPT parsers advance offset by that overlarge value and then pull uint32/enum fields from the wrong location or beyond the provided packet before the top-level offset check.
- Impact: Local parser desynchronization, wrong-field interpretation, out-of-bounds read failure, or denial of service in the CTDB event daemon.
- Likelihood: Medium when the eventd socket is reachable: the malformed packet shape is simple and the parser arithmetic is direct, but socket permissions/deployment bound the attacker population.

#### Reachability

The path is reachable under the attacker role and entry point documented above.

Attacker outcome: A local eventd client can send an unterminated declared-length string; ctdb_string_pull() reports strlen()+1 bytes consumed, so subsequent RUN/SCRIPT scalar fields are parsed at an attacker-shifted offset or beyond the packet.

#### Severity

Final severity is **medium**. This has a concrete sink and plausible attacker path, but role, configuration, optional feature, or runtime preconditions bound practical exploitability.

The bug is locally reachable in CTDB deployments and can break parser memory-safety assumptions or availability, but it is not a remote unauthenticated path, so medium severity is appropriate. Policy decision: report; final severity: medium.

Additional runtime proof against a live Samba service or a default deployment configuration would raise confidence; evidence that the feature is unreachable, trusted-only, or fully mitigated in supported builds would lower severity.

#### Remediation

Make ctdb_string_pull()/ctdb_stringn_pull() consume exactly the declared field length, require NUL termination if the wire format requires it, and check offset bounds before each nested scalar pull. Add regression coverage that exercises the attacker-controlled input at the listed entry point and asserts the validation, authorization, containment, or size check occurs before the dangerous sink.


### [22] CTDB control reply map/count fields allocate arrays before remaining-length validation

| Field | Value |
|---|---|
| Severity | medium |
| Confidence | high |
| Confidence rationale | Static source tracing identifies the attacker input, broken control, and sink in repository code. Remaining uncertainty: No CTDB cluster/runtime proof was attempted. |
| Category | resource exhaustion from count-controlled allocation |
| CWE | CWE-770 |
| Affected lines | ctdb/common/ctdb_io.c:97-152; ctdb/common/ctdb_io.c:201-212; ctdb/protocol/protocol_control.c:1592-1714; ctdb/protocol/protocol_control.c:1975-2022; ctdb/protocol/protocol_types.c:836-879; ctdb/protocol/protocol_types.c:922-966; ctdb/protocol/protocol_types.c:1081-1118; ctdb/protocol/protocol_types.c:3898-3936; ctdb/protocol/protocol_client.c:177-188; ctdb/protocol/protocol_client.c:270-281; ctdb/protocol/protocol_client.c:1243-1254; ctdb/protocol/protocol_client.c:1700-1712 |

#### Summary

A malicious CTDB reply source can place large map/list counts in dsize-bounded replies; typed parsers allocate arrays from those counts before proving the blob contains the requested elements, enabling memory-exhaustion DoS.

Candidate `CAN-R07-048-ctdb-control-reply-count-allocation` survived validation as a reportable `resource exhaustion from count-controlled allocation` issue.

#### Validation

Method: static source tracing across the validation and attack-path artifacts, with deployment and runtime limits retained as proof gaps rather than assumed away.

- ctdb/common/ctdb_io.c:97-152 extracts complete CTDB packets and delivers them to callbacks; lines 201-212 resize input buffers from packet length.
- ctdb/protocol/protocol_control.c:1975-2022 checks dsize and dispatches the bounded blob.
- ctdb/protocol/protocol_control.c:1603-1614 and 1677-1713 dispatch affected opcodes to map/list pull helpers.
- ctdb/protocol/protocol_types.c:849-872 allocates stats from val->num before element proof.
- ctdb/protocol/protocol_types.c:942-960, 1094-1112, and 3911-3929 allocate VNN, DBID, and node arrays from untrusted counts before proving elements.

Remaining uncertainty: No CTDB cluster/runtime proof was attempted. Trust-boundary severity depends on CTDB deployment, peer authentication, and which clients accept replies from attacker-controlled endpoints.

Receipts: `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R07-048-ctdb-control-reply-count-allocation/candidate_ledger.jsonl`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R07-048-ctdb-control-reply-count-allocation/validation_report.md`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R07-048-ctdb-control-reply-count-allocation/attack_path_analysis_report.md`.

#### Dataflow

Attacker role: Malicious CTDB daemon, peer, or local/control-reply endpoint able to send or influence CTDB control replies consumed by clients or daemons.

Entrypoint: CTDB queue processing delivers complete packets to ctdb_reply_control_pull(), which dispatches opcode-specific reply data to typed pull helpers.

Trust boundary: CTDB control reply bytes cross from peer/daemon/local endpoint into memory allocations in the parser before embedded count fields are proven against remaining length.

Controls and counterevidence:
- ctdb_reply_control_pull() bounds the outer control-data blob by dsize before typed dispatch.
- Element pull loops eventually fail if the bounded blob lacks enough bytes.
- CTDB deployment, peer trust, and socket permissions affect reachability.
- The typed helpers do not pre-check count <= remaining / minimum_element_size before talloc_array().

Exploit steps:
1. Reach a CTDB client/daemon parser path as a malicious peer, daemon, or local control-reply source.
2. Send a successful control reply with a small dsize but a huge embedded count for GETVNNMAP, GET_DBMAP, GET_NODEMAP, GET_NODES_FILE, or GET_STAT_HISTORY.
3. ctdb_reply_control_pull() accepts the dsize-bounded blob and dispatches by opcode.

- Additional evidence is available in the per-candidate attack-path report.

#### Reachability

The path is reachable under the attacker role and entry point documented above.

Attacker outcome: A malicious CTDB reply source can place large map/list counts in dsize-bounded replies; typed parsers allocate arrays from those counts before proving the blob contains the requested elements, enabling memory-exhaustion DoS.

#### Severity

Final severity is **medium**. This has a concrete sink and plausible attacker path, but role, configuration, optional feature, or runtime preconditions bound practical exploitability.

The validation disposition was reportable with severity suggestion medium. The final decision is report with severity medium because the source-supported attack path crosses a meaningful boundary, while the listed controls constrain likelihood and blast radius.

Counterevidence: The outer dsize is checked, later element pulls fail on short blobs, and reachability depends on CTDB deployment, peer authentication, and local socket permissions.

Remediation summary: Before allocation, validate each count against remaining bytes and a sane maximum for the specific control reply type; reject negative or impossible counts first.

Additional runtime proof against a live Samba service or a default deployment configuration would raise confidence; evidence that the feature is unreachable, trusted-only, or fully mitigated in supported builds would lower severity.

#### Remediation

Before allocation, validate each count against remaining bytes and a sane maximum for the specific control reply type; reject negative or impossible counts first. Add regression coverage that exercises the attacker-controlled input at the listed entry point and asserts the validation, authorization, containment, or size check occurs before the dangerous sink.


### [34] CTDB eventd and framed socket readers allocate from peer-controlled packet lengths before protocol validation

| Field | Value |
|---|---|
| Severity | medium |
| Confidence | high |
| Confidence rationale | Static source tracing identifies the attacker input, broken control, and sink in repository code. Remaining uncertainty: No CTDB runtime was started. |
| Category | Unbounded packet-length allocation |
| CWE | CWE-770 |
| Affected lines | ctdb/event/event_daemon.c:289-350; ctdb/common/sock_daemon.c:204-252; ctdb/common/sock_daemon.c:390-399; ctdb/common/comm.c:111-165; ctdb/common/comm.c:175-185; ctdb/common/pkt_read.c:126-168; ctdb/event/event_request.c:131-153; ctdb/event/event_protocol.c:1026-1046; ctdb/common/sock_daemon.c:90-113; ctdb/common/comm.c:163-185; ctdb/common/pkt_read.c:126-168; ctdb/event/event_daemon.c:340-350 |

#### Summary

A local CTDB socket client can advertise a huge frame length; the generic comm/pkt_read layer allocates that length before event protocol parsing, enabling pre-validation memory exhaustion.

Candidate `CAN-R09-053-ctdb-eventd-packet-length-alloc` survived validation as a reportable `Unbounded packet-length allocation` issue.

#### Validation

Method: static source tracing across the validation and attack-path artifacts, with deployment and runtime limits retained as proof gaps rather than assumed away.

- ctdb/event/event_daemon.c:289-350 creates the eventd socket and registers sock_daemon_add_unix() callbacks.
- ctdb/common/sock_daemon.c:204-252 binds and listens on the Unix socket without explicit chmod/chown in socket_setup().
- ctdb/common/comm.c:163-185 starts a four-byte read and returns packet_len - buflen from the peer-controlled first uint32_t.
- ctdb/common/pkt_read.c:126-168 allocates or reallocates to state->total + more before protocol parsing.
- ctdb/event/event_request.c:116-153 calls ctdb_event_request_pull() only after the generic frame has been delivered.

Remaining uncertainty: No CTDB runtime was started. The local attacker boundary depends on installed CTDB runtime directory mode, socket mode, and deployment packaging.

Receipts: `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R09-053-ctdb-eventd-packet-length-alloc/candidate_ledger.jsonl`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R09-053-ctdb-eventd-packet-length-alloc/validation_report.md`, `/tmp/codex-security-scans/combined/51cdf8f538d_20260605T210514Z/artifacts/05_findings/CAN-R09-053-ctdb-eventd-packet-length-alloc/attack_path_analysis_report.md`.

#### Dataflow

- Attacker role: Local user or local process able to connect to the CTDB eventd Unix socket, depending on runtime directory and socket permissions.
- Entry point: eventd creates path_socket("eventd") and registers it with sock_daemon_add_unix(), which feeds accepted clients into the generic comm/pkt_read framed reader.
- Trust boundary: Local socket bytes cross from an untrusted CTDB client into a long-running CTDB event daemon before event protocol validation.
- Exploit steps:
  1. Connect to the eventd Unix socket or another sock_daemon socket using the same generic framing path.
  2. Send a first four-byte packet length with a very large uint32_t value.
  3. comm_read_more() interprets that field as packet_len and returns packet_len - buflen.
  4. pkt_read_handler() allocates or reallocates the packet buffer to state->total + more before ctdb_event_request_pull() sees the data.
  5. Repeat or choose a sufficiently large frame to force allocation failure, memory pressure, or event daemon instability.
- Impact: Local availability impact against CTDB event handling and possibly clustered service management through memory exhaustion or daemon destabilization.
- Likelihood: Low to medium: the parser behavior is direct, but exploitability depends on CTDB being deployed and the socket/runtime directory allowing the attacker to connect.

#### Reachability

The path is reachable under the attacker role and entry point documented above.

Attacker outcome: A local CTDB socket client can advertise a huge frame length; the generic comm/pkt_read layer allocates that length before event protocol parsing, enabling pre-validation memory exhaustion.

#### Severity

Final severity is **medium**. This has a concrete sink and plausible attacker path, but role, configuration, optional feature, or runtime preconditions bound practical exploitability.

The impact is daemon availability and the attacker is local/deployment-dependent, making medium severity appropriate. Policy decision: report; final severity: medium.

Additional runtime proof against a live Samba service or a default deployment configuration would raise confidence; evidence that the feature is unreachable, trusted-only, or fully mitigated in supported builds would lower severity.

#### Remediation

Enforce a maximum frame size in comm_read_more()/pkt_read or per sock_daemon consumer before dynamic allocation, and apply explicit socket permission hardening consistently. Add regression coverage that exercises the attacker-controlled input at the listed entry point and asserts the validation, authorization, containment, or size check occurs before the dangerous sink.

Created attachment 19024 [details]
Draft advisory v1

(In reply to Martin Schwenke from comment #19)

> Is that what you were suggesting, or only the 2nd commit where I had dropped
> you because I had changed the commit?

BTW Tristan, I'm just taking care to avoid claiming that you have reviewed 
potentially bogus commits. ;-)

(In reply to Martin Schwenke from comment #22)

Hi Martin,

Reviewed-by on all commits is fine with me. I tested v3 end-to-end and reviewed the v4 diff on top, so I'm comfortable with the full set.

For the credit line:
Reviewed-by: Tristan Madani <tristan@talencesecurity.com>

Advisory draft looks good to me.

Thanks,
Tristan

Created attachment 19025 [details]
Patch for master branch v5

Changes in v5 are:

* Mark all commits Reviewed-by: Tristan Madani <tristan@talencesecurity.com>
* Annotate Reported-by: Andrew Tridgell tags with the issue number from
  his list

(In reply to Martin Schwenke from comment #24)

Thanks Martin

Created attachment 19056 [details]
Draft advisory v2

Added CVE# and guesses at release versions to advisory.

Created attachment 19057 [details]
Patch for master branch v6

Adding an additional commit that adds a comment in 2 places where packet
buffers are allocated, trying to avoid vulnerability reports.

TL;DR: The private network should be secure, so the remaining OOM DoS
attack vectors are not considered to be security vulnerabilities.

No need to repeat CI testing, since these are only comment additions?

Created attachment 19078 [details]
advisory v3 (update versions, CVE id)

Comment on attachment 19057 [details]
Patch for master branch v6

Patch 02:

+	if (val->size * ctdb_uint32_len(&dummy) > buflen - offset) {

should cast val->size to uint64_t in order to avoid an overflow on
32bit systems.

Patch 11 and 12 has similar checks....

The reset look good.

(In reply to Stefan Metzmacher from comment #29)

To avoid confusion I first added review+, while I wanted review-
and think the array length checks should be fixed for 32bit systems

Created attachment 19079 [details]
Patch for master branch v7

As before, but with those casting changes.

If I post v8 with just additional:

  Reviewed-by: Stefan Metzmacher <metze@samba.org>

Should I just mark it as already reviewed here?  Or is that bad shortcut.  :-)

Comment on attachment 19079 [details]
Patch for master branch v7

Thanks, I think posting a patch with review tags is not needed

Created attachment 19081 [details]
backport for 4.22, 4.23, 4.24

"patch for master branch v7" doesn't apply automatically to 4.2[2-4] but it is only a minor thing in the man page that resolves with `git am -3`. In any case, here is the resultant patch.

It also applies cleanly to 4.20, 4.17, and 4.10. Not 4.9.

(In reply to Douglas Bagnall from comment #33)
Thanks for that.  I guess I previously added an extra paragraph...

Do you think we need a patch for 4.9?  If so, I can do that...

(In reply to Martin Schwenke from comment #34)
> Do you think we need a patch for 4.9?

No! I only mention it because I know some people are interested in doing ancient backports.

adding vendors here.

scheduled release 2026-07-28 10:00 UTC.

Probably just a typo, but the CVSS vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H results in a 7.1 score, not 6.5.

(In reply to Andrea Mattiazzo from comment #37)

Yes, when I recalculate I also get 7.1.

If I drop C:N then I get 6.5.  However, C:L looks correct.

Unless someone complains before then, I'd update the advisory tomorrow.

Created attachment 19121 [details]
advisory with fixed score value

This bug was referenced in samba v4-24-stable (Release samba-4.24.5):

82688e9427d796d1246b34f187e4c9dd26a57269
3bec447359c569426b44ede3275d884d353b639a
5ed865769b84e8c133e957ef420b80d354b7e022
8a451568d04ed2f8758142498057a914bf41372f
67427ee4c2c5e40cb76a22d41f33dc929fce1a4e
00cb172350054bb9dd5d21bed961156db82c779e
03386441713a653a9de38245479f05ae2616a248
0dc078350f054a83bf4da889685c3dd0d9951774
05b51a72a8cfae65aedb828dc11a1ca3069ae997
ff99b84b6594a1dc1f68dfd54bd30e5f1d229e5f
b243090d096f58721dfd1db2b39b8463bb248486
f004832f15e4352518086c88929aa98906134e7d
504da6f1f73103f5bc299b2d77b1cd0aea968b4d
90724dab81367d364bcbcf40665218d585234baf
f235767036f4d9557e2f6c33cff9c8ee4dff81ee

This bug was referenced in samba v4-23-stable (Release samba-4.23.10):

8c9797460b930ea9a4ad06c1cc51101e747df4b4
94e1cec5e0b2520298b4713fe6cc976edf490197
b41a631fd65927ff22ae8d7c0855e5759bc0301d
de7ab1fda54da247ba0ebc52f53c2f30a7330390
9c0606704b509277a72dbeba634a39059a0700d9
293fe0c9e9036665359c0771a07dbb2da93c7beb
d686b1578310322b06efc1ea0e1c9cf3db6e94fb
a1256fcdf3a8ade25c5393b01ca31df938efb018
843557f3bd66c8be5523a6096bd35bde1471714b
467e96bffad260bb3b422a5380e3aee776b3f97d
1e3c4a6bf23dbe492abbd6f3f2e4dc22aaf57a61
c056fcb0868865254b151a2d93e53edfbb6dd77e
d6950d42cb9a18889f2ccc72bb5145aa2eed926d
7f0530691f9c4ff58ac0d3b34f2450e2a48064e7
85b6714b2ac3ac6eec0be42b048592adadef9555

This bug was referenced in samba v4-22-stable (Release samba-4.22.11):

7ee38693b9a2fd52934c5cb274ae4faedc4d2cca
d5d0f66ba72a6b61eadbb0586147e4f5649819d1
caa813485d3ecbb4254d0da6f18c6544674cca9b
9b35dc8f4e02165c7060cdc59ac0e40cf8850950
0b14e3300fa3af24e8862b733b1c37297d2497da
6f176a51feb56f14a40d6f46f5d333247c25c19e
b492c00183709c7c06a616ea6a237e04323d2700
710fbe1e3405df08de3cfa833451c4da56f00e29
0e6ab55628a238f6a2c439f6346e46a07b69502c
11b53ae3d423bf02c269daa7aab439e2ad0b4e1e
420f65a87d7182071f28ec771db28a81adf65451
36df6fb5df648c98c3b8e0754b20c76aaf86cb32
086e37b02d879faeee8ff9841d1cb30597326b83
de250fbfdde6923b1cc1fc51eeb25352ca15fc0a
c7f6ff916652d2dc159e4c9fed8bec3799c9cc9a

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

7ee38693b9a2fd52934c5cb274ae4faedc4d2cca
d5d0f66ba72a6b61eadbb0586147e4f5649819d1
caa813485d3ecbb4254d0da6f18c6544674cca9b
9b35dc8f4e02165c7060cdc59ac0e40cf8850950
0b14e3300fa3af24e8862b733b1c37297d2497da
6f176a51feb56f14a40d6f46f5d333247c25c19e
b492c00183709c7c06a616ea6a237e04323d2700
710fbe1e3405df08de3cfa833451c4da56f00e29
0e6ab55628a238f6a2c439f6346e46a07b69502c
11b53ae3d423bf02c269daa7aab439e2ad0b4e1e
420f65a87d7182071f28ec771db28a81adf65451
36df6fb5df648c98c3b8e0754b20c76aaf86cb32
086e37b02d879faeee8ff9841d1cb30597326b83
de250fbfdde6923b1cc1fc51eeb25352ca15fc0a
c7f6ff916652d2dc159e4c9fed8bec3799c9cc9a

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

006aa7f1f0f44a2d52d06a11b9e0f50d072e0936
0954199e9bee58d44c7a35468a7f378fe7c7c2b9
efeb84e1378583e170f3b6d95a27e7d389f040c2
559cedfd8bb16485589bfb6dc6eb49d476ce6045
82c81cfe1301590c5b43efc826640ceb96356756
d3b3de06c20fb6cabb798f01f7470caa79d0e116
9771ccedd7c24c0cc01e69f713112eddbcaa407f
8b5fc74bf1e19e18647da355a8985fb0f0cdab3a
edc0d81e7f1a26fac05771d7cdf082ae60912959
db9f000a4a3a7ac5b6d7083e9fa13dfaa025999e
e9b205b929ac5d1eed4302ee2c96795f3fef81db
1b45e5849623a0b3e6ebaa0a522971f3d9f296bf
d658c91bc95dffc7409a482e1bde8573d7ccbd22
49051f57566dd61f8c902c7a0f2bdf9e70674077
8c2c895f14ade62848a5b81883d786402f0183e8

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

f5c0d4b0132ea9a77bed91e95f4faab98c9ef519
a58fe99a14ecaace55828722229fd541418674db
d53d85813b986bf6351b2571d3c91fc7c793e1ff
50e961126a041371928c75029b98f8719400b5c3
277b66afa58f48b639c3c66fa6f6516921e75a6a
367d3298cf5c6d38be176a8b0a7d1e80a5fd457d
c6faa697bb880275aab7f65bec53f90c3b02b12d
ee014139b54c6c32854559de5fac99b21147e06e
5694cd2ac006ddb78ce21e8fc4bb53d4353beb26
aa36dba46eaeadb4ce767d8d887626e0cf8ac796
a65782f3f5290fcbeb8ee7649256dcc086f4fb9a
eeb740e32f600d9cf97fea79c350559613b6ed7f
59fd658c60016f5fd04d12132ada079aeccb0099
b8a3cb40d5383cb5ef2b426a8e1f39964951e793
017a3f335598842b410a6a94ed072f19a5d98767

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

82688e9427d796d1246b34f187e4c9dd26a57269
3bec447359c569426b44ede3275d884d353b639a
5ed865769b84e8c133e957ef420b80d354b7e022
8a451568d04ed2f8758142498057a914bf41372f
67427ee4c2c5e40cb76a22d41f33dc929fce1a4e
00cb172350054bb9dd5d21bed961156db82c779e
03386441713a653a9de38245479f05ae2616a248
0dc078350f054a83bf4da889685c3dd0d9951774
05b51a72a8cfae65aedb828dc11a1ca3069ae997
ff99b84b6594a1dc1f68dfd54bd30e5f1d229e5f
b243090d096f58721dfd1db2b39b8463bb248486
f004832f15e4352518086c88929aa98906134e7d
504da6f1f73103f5bc299b2d77b1cd0aea968b4d
90724dab81367d364bcbcf40665218d585234baf
f235767036f4d9557e2f6c33cff9c8ee4dff81ee

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

8c9797460b930ea9a4ad06c1cc51101e747df4b4
94e1cec5e0b2520298b4713fe6cc976edf490197
b41a631fd65927ff22ae8d7c0855e5759bc0301d
de7ab1fda54da247ba0ebc52f53c2f30a7330390
9c0606704b509277a72dbeba634a39059a0700d9
293fe0c9e9036665359c0771a07dbb2da93c7beb
d686b1578310322b06efc1ea0e1c9cf3db6e94fb
a1256fcdf3a8ade25c5393b01ca31df938efb018
843557f3bd66c8be5523a6096bd35bde1471714b
467e96bffad260bb3b422a5380e3aee776b3f97d
1e3c4a6bf23dbe492abbd6f3f2e4dc22aaf57a61
c056fcb0868865254b151a2d93e53edfbb6dd77e
d6950d42cb9a18889f2ccc72bb5145aa2eed926d
7f0530691f9c4ff58ac0d3b34f2450e2a48064e7
85b6714b2ac3ac6eec0be42b048592adadef9555

This bug was referenced in samba master:

80db91e1bfad43e2b875c20b0fbb30443efa8ce2
6115bcd51ff8a56c2c44b57edd472fcf12c3eff7
4e586b28b3b5afecf1fdb3612c51e71d872f1ca4
6039a5f0da29ecc78e0ae5e2524a49380aba6220
6129d0ee64f396ba52ea1a26f442f609e4df2fde
729ca6039a929c31652ba4bd7c59c1969e5a8c09
0c3001b7dc1e29d42dad135fac734c9a71bfa896
79dbf2a66e8b5fd931bbb50bd4a1569b464c9078
aa7d65bc979f879e00871750efe57702ae7e1b2f
9e6e767501b7e3434d965511c0e22b986091e015
c9db4cc5f7514632ba14d4c09527d256729d89aa
6d1fa89aa1d97563771dd4381f1cb4838ba0adf1
1e7e8055c2837b74848162eca33f014d18effb66
ab12f8739101ae416539ec6c10f29f218e1ee27a
33667fa30d3e12f9f835b5670770ab702cf9e2c4

This bug was referenced in samba v4-23-stable (Release samba-4.23.11):

f5c0d4b0132ea9a77bed91e95f4faab98c9ef519
a58fe99a14ecaace55828722229fd541418674db
d53d85813b986bf6351b2571d3c91fc7c793e1ff
50e961126a041371928c75029b98f8719400b5c3
277b66afa58f48b639c3c66fa6f6516921e75a6a
367d3298cf5c6d38be176a8b0a7d1e80a5fd457d
c6faa697bb880275aab7f65bec53f90c3b02b12d
ee014139b54c6c32854559de5fac99b21147e06e
5694cd2ac006ddb78ce21e8fc4bb53d4353beb26
aa36dba46eaeadb4ce767d8d887626e0cf8ac796
a65782f3f5290fcbeb8ee7649256dcc086f4fb9a
eeb740e32f600d9cf97fea79c350559613b6ed7f
59fd658c60016f5fd04d12132ada079aeccb0099
b8a3cb40d5383cb5ef2b426a8e1f39964951e793
017a3f335598842b410a6a94ed072f19a5d98767

This bug was referenced in samba v4-24-stable (Release samba-4.24.6):

006aa7f1f0f44a2d52d06a11b9e0f50d072e0936
0954199e9bee58d44c7a35468a7f378fe7c7c2b9
efeb84e1378583e170f3b6d95a27e7d389f040c2
559cedfd8bb16485589bfb6dc6eb49d476ce6045
82c81cfe1301590c5b43efc826640ceb96356756
d3b3de06c20fb6cabb798f01f7470caa79d0e116
9771ccedd7c24c0cc01e69f713112eddbcaa407f
8b5fc74bf1e19e18647da355a8985fb0f0cdab3a
edc0d81e7f1a26fac05771d7cdf082ae60912959
db9f000a4a3a7ac5b6d7083e9fa13dfaa025999e
e9b205b929ac5d1eed4302ee2c96795f3fef81db
1b45e5849623a0b3e6ebaa0a522971f3d9f296bf
d658c91bc95dffc7409a482e1bde8573d7ccbd22
49051f57566dd61f8c902c7a0f2bdf9e70674077
8c2c895f14ade62848a5b81883d786402f0183e8