Tridge writes: An unauthenticated DNS client can churn unique TKEY GSSAPI names; Samba allocates GENSEC state and stores each key in a 128-entry FIFO before GSS success, leaving failed entries resident and evicting legitimate update keys. - source4/dns_server/dns_server.c:144-191 parses DNS bytes and dispatches QUERY processing. - source4/dns_server/dns_server.h:39 and 46-50 define a 128-entry TKEY FIFO store. - source4/dns_server/dns_query.c:657-748 creates GENSEC state and stores the key in store->tkeys[next_idx] before returning. - source4/dns_server/dns_query.c:872-909 creates missing keys, calls accept_gss_ticket(), and leaves failed/MORE_PROCESSING_REQUIRED keys in place. - source4/dns_server/dns_update.c:801-810 requires authenticated state and later dns_find_tkey() success. Remaining uncertainty: No DNS service proof was attempted. Runtime impact depends on DNS exposure, request-rate controls outside this code, and the cost of GENSEC contexts on the deployment. #### Dataflow Attacker role: Unauthenticated remote DNS client able to send TKEY GSSAPI negotiation queries to Samba internal DNS. Entrypoint: dns_process_send() parses DNS packets and dispatches DNS_OPCODE_QUERY to dns_server_process_query_send(), which reaches handle_tkey() for TKEY queries. Trust boundary: Unauthenticated DNS request bytes cause GENSEC state allocation and insertion into the DNS server TKEY FIFO before authentication completes. Controls and counterevidence: - create_tkey() accepts only gss-tsig or gss.microsoft.com algorithms. - The TKEY store is globally capped at TKEY_BUFFER_SIZE 128 entries by FIFO replacement. - No per-client quota, expiry, or failure cleanup is visible in create_tkey()/handle_tkey(). - Runtime impact depends on DNS exposure and external rate controls. Exploit steps: 1. Send repeated TKEY GSSAPI queries with unique key names and invalid or incomplete GSS tokens. 2. handle_tkey() does not find an existing key and calls create_tkey(). 3. create_tkey() allocates dns_server_tkey, starts GENSEC/SPNEGO, frees the next FIFO slot, stores the new key, and advances next_idx before accept_gss_ticket(). Attacker outcome: An unauthenticated DNS client can churn unique TKEY GSSAPI names; Samba allocates GENSEC state and stores each key in a 128-entry FIFO before GSS success, leaving failed entries resident and evicting legitimate update keys. Counterevidence: Only GSS TKEY algorithms reach allocation, the global FIFO caps retained entries, and runtime impact depends on DNS exposure, rate controls, and GENSEC allocation cost. Remediation summary: Delay FIFO insertion until authentication succeeds or needs continuation, remove failed negotiations, and add per-client quotas/expiry for in-flight TKEY state. #### Remediation Delay FIFO insertion until authentication succeeds or needs continuation, remove failed negotiations, and add per-client quotas/expiry for in-flight TKEY state. 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. | Severity | medium | | Confidence | high | | Confidence rationale | Static source tracing identifies the attacker input, broken control, and sink in repository code. Remaining uncertainty: No DNS service proof was attempted. |
> An unauthenticated DNS client can churn unique TKEY GSSAPI names I was under the impression that only authenticated clients could register TKEY names. (This affects the severity of bug 16083).
Created attachment 19016 [details] Patch
I guess this is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L 5.3 anonymous DoS, setting the availability impact to "low" instead of "high". Although we could argue for a non-security release, we perhaps should release it at the same time as bug 16083.
Created attachment 19075 [details] advisory v1
master patch applies to 4.22, 4.23, 4.24. It needs a bit of work for 4.18 and before.
Also reported by Tristan Mandani: DNS Pre-Auth TKEY Session Flooding and Latent OOB Access ======================================================== CVSS 3.1: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) CWE: CWE-770 (Allocation of Resources Without Limits or Throttling) Auth: None (pre-auth) Version: Samba 4.24.3 and prior, master (2026-06-25) File: source4/dns_server/dns_query.c, lines 740-744, and dns_crypto.c, line 80 Root Cause: The Samba internal DNS server stores GSSAPI TKEY session keys in a fixed-size ring buffer of 128 entries (TKEY_BUFFER_SIZE). There is no rate limiting and no authentication requirement for TKEY creation. An unauthenticated attacker can send 128 TKEY requests to flush all legitimate GSS-TSIG session keys. Each request also allocates a full GENSEC/KRB5 context for resource exhaustion. #define TKEY_BUFFER_SIZE 128 // dns_query.c:740-744 - no auth, no rate limit tkey_store->entries[tkey_store->next_idx] = new_tkey; tkey_store->next_idx = (tkey_store->next_idx + 1) % TKEY_BUFFER_SIZE; Additionally, dns_find_tkey() iterates using the hardcoded constant TKEY_BUFFER_SIZE instead of store->size, creating a latent OOB read if the store size were ever changed at runtime. Data Flow: Unauthenticated attacker sends 128 GSSAPI TKEY creation requests -> each overwrites a ring buffer slot, no auth check -> all legitimate GSS-TSIG session keys are flushed -> authenticated DNS updates fail for all clients -> each GENSEC/KRB5 context allocation also exhausts memory Impact: Pre-auth denial of service: any network attacker can break authenticated DNS for the entire AD domain by flushing the TKEY store. Sustained flooding exhausts memory via GENSEC/KRB5 context allocations. Lab verified: code trace confirmed pre-auth path and ring buffer eviction.
Tristan suggests "AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H" (7.5) while we have settled on ".../A:L" (5.3) because availability recovers once the attack stops (for new TKEY registrations). But whatever. He also emphasises the memory leak that I think we fix but which wasn't in the original report.
Created attachment 19096 [details] advisory v2 (adding Tristan credit)
adding vendors here. scheduled release 2026-07-28 10:00 UTC.
This bug was referenced in samba v4-23-stable (Release samba-4.23.10): 51a7e0731ff4be22b47f3d885909d0fe11ae83fb 9f9981bf09150884d617fd4e19ea7dc5da785f92
This bug was referenced in samba v4-24-stable (Release samba-4.24.5): 3d933500625e97b94831ff3378fdf83359e9b49f 5d09d812f2dd86ac94ca4185bd72dc03f82ef251
This bug was referenced in samba v4-22-stable (Release samba-4.22.11): 77657a84ba3e29f6cdd490df80496862de5c8368 6e89df6cfd804b042ebcd693a025b522c997995b
This bug was referenced in samba v4-22-test: 77657a84ba3e29f6cdd490df80496862de5c8368 6e89df6cfd804b042ebcd693a025b522c997995b
This bug was referenced in samba v4-24-test: 17f202d039c2ae584d8175e5e9d9b29fb8d5ec9d 0d9ca2c5fcb799d0c8252bcad6c66e78cd4facc3
This bug was referenced in samba v4-23-test: 3f26fb6935774386df6e4d36fe93cda8cd7fb988 c83f5f8aff89f2ce1ab10dcbabc539c7551d9bce
This bug was referenced in samba v4-24-test: 3d933500625e97b94831ff3378fdf83359e9b49f 5d09d812f2dd86ac94ca4185bd72dc03f82ef251
This bug was referenced in samba v4-23-test: 51a7e0731ff4be22b47f3d885909d0fe11ae83fb 9f9981bf09150884d617fd4e19ea7dc5da785f92
This bug was referenced in samba master: 45cd1e5c9e92232e8d49a4b9429f0b184eb01299 9221601c43318414c5725a0845d888335e5b8197
This bug was referenced in samba v4-23-stable (Release samba-4.23.11): 3f26fb6935774386df6e4d36fe93cda8cd7fb988 c83f5f8aff89f2ce1ab10dcbabc539c7551d9bce
This bug was referenced in samba v4-24-stable (Release samba-4.24.6): 17f202d039c2ae584d8175e5e9d9b29fb8d5ec9d 0d9ca2c5fcb799d0c8252bcad6c66e78cd4facc3