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.

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

Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Stefan Metzmacher <metze@samba.org>

diff --git a/ctdb/common/ctdb_io.c b/ctdb/common/ctdb_io.c
index 9ac9b84a7fb2dd5930874f0ceb0892509db08fd7..346a7456f471554c16a7db60b3eb37aacd75bdc1 100644 (file)
--- a/ctdb/common/ctdb_io.c
+++ b/ctdb/common/ctdb_io.c
@@ -115,7 +115,25 @@ static void queue_process(struct ctdb_queue *queue)
                return;
        }
 
-       /* Extract complete packet */
+       /*
+        * Extract complete packet
+        *
+        * Yes, this allows an out-of-memory denial of service (DoS)
+        * attack if a number of packets are received with
+        * unreasonable packet sizes, noting that the maximum packet
+        * size is ~4GB.  The CTDB protocol was not designed with a
+        * maximum packet size in mind, so CTDB may send very large
+        * valid packets.  This means that imposing an arbitrary limit
+        * on incoming packets is not reasonable.  Arguments that
+        * header fields, such as magic and/or version, should be
+        * validated before allocating a packet buffer are spurious
+        * from a security perspective because an attacker attempting
+        * DoS can send packets with valid headers.  The private
+        * network and ctdbd socket should be secured against
+        * untrusted access, so reports that this possible DoS vector
+        * represents a security issue will be ignored.  See the
+        * "Private addresses" section in ctdb(7) for more details.
+        */
        data = talloc_memdup(queue->data_pool,
                             queue->buffer.data + queue->buffer.offset,
                             pkt_size);

diff --git a/ctdb/common/pkt_read.c b/ctdb/common/pkt_read.c
index 212ace54bbd824450a7fd9f05ee78dc150ae758d..8877f6aa368fea414fea063a9d3f647d6118d020 100644 (file)
--- a/ctdb/common/pkt_read.c
+++ b/ctdb/common/pkt_read.c
@@ -146,6 +146,25 @@ void pkt_read_handler(struct tevent_context *ev, struct tevent_fd *fde,
                return;
        }
 
+       /*
+        * Allocate buffer for entire packet
+        *
+        * Yes, this allows an out-of-memory denial of service (DoS)
+        * attack if a number of packets are received with
+        * unreasonable packet sizes, noting that the maximum packet
+        * size is ~4GB.  The CTDB protocol was not designed with a
+        * maximum packet size in mind, so CTDB may send very large
+        * valid packets.  This means that imposing an arbitrary limit
+        * on incoming packets is not reasonable.  Arguments that
+        * header fields, such as magic and/or version, should be
+        * validated before allocating a packet buffer are spurious
+        * from a security perspective because an attacker attempting
+        * DoS can send packets with valid headers.  The private
+        * network and ctdbd socket should be secured against
+        * untrusted access, so reports that this possible DoS vector
+        * represents a security issue will be ignored.  See the
+        * "Private addresses" section in ctdb(7) for more details.
+        */
        if (state->use_fixed) {
                /* switch to dynamic buffer */
                tmp = talloc_array(state, uint8_t, state->total + more);