CVE-2026-85234: Tftp: tftp-hpa: denial of service due to out-of-bounds read/write in remap engine

AIONLYREPORT package: tftp-5.2-50.el10 ------ Summary: Out-of-bounds read/write in genmatchstring() when RULEINVERSE clears pmatch to -1 and RULEABORT formats custom error: when an inverse remap rule also aborts with a non-empty custom error message, the remap engine passes match offsets of -1 into genmatchstring(), causing out-of-bounds pointer arithmetic and memcpy operations that can crash the daemon in affected deployments. Requirements to exploit: The attacker needs network reachability to an in.tftpd deployment that was built with remap support, started with m/-map-file, and configured with an inverse (~) + abort (a) rule that has a non-empty custom error pattern. The attacker then only needs to send an unauthenticated RRQ/WRQ for a filename that does not match the rule regex. Component affected: tftp-hpa (in.tftpd remap engine in tftpd/remap.c, genmatchstring() / rewritestring()) Version affected: tftp-5.2-50.el10 (confirmed in the provided source snapshot); introduction commit provenance could not be determined in this checkout, and other versions with the same remap logic are likely affected. The same vulnerable logic is also present in tftpd/remap.c.zero. Patch available: Proposed fix included in this report (see "Proposed Fix"); upstream release status unknown. Version fixed (if any already): unknown Upstream coordination: Not yet notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 7.5 (HIGH) AV:N - Triggerable over the network via unauthenticated RRQ/WRQ requests. AC:L - Once an affected remap deployment exists, exploitation only requires a non-matching filename request; no race or advanced conditions are needed. PR:N - No authentication is required. UI:N - No user interaction is required. S:U - The vulnerable and impacted component is the TFTP service itself. C:N - No direct confidentiality impact is demonstrated. I:N - No reliable integrity impact is demonstrated. A:H - The demonstrated outcome is a daemon crash / remote denial of service. Impact: Moderate. This is a real remote, unauthenticated memory-safety flaw, but the demonstrated impact is denial of service rather than proven code execution or data exposure. The issue only affects deployments with remap support enabled, m/-map-file in use, and a specific inverse+abort rule with a non-empty custom message, which makes it less broadly exploitable than a default-path network service flaw. Embargo: no Reason: The issue is configuration-dependent and mitigation is straightforward: disable filename remapping, remove inverse+abort custom-message rules, or build without remap support until a fix is available. Based on the current evidence, this does not appear to require embargoed handling. Acknowledgement: Aisle Research Steps to reproduce: 1. Build in.tftpd with remap support enabled, or verify at runtime that in.tftpd -V reports with remap. 2. Create a remap file containing: text a~ ^allowed/ Access denied for \0 3. Start the server with filename remapping enabled, for example: bash in.tftpd -L -m <remap-file> -s <tftp-root> 4. Send an RRQ or WRQ for a filename that does not match ^allowed/, such as badfile. 5. In the inverse path, rewritestring() clears pmatch[] to -1; the abort path then calls genmatchstring() twice to format the custom error. 6. Observe a crash or sanitizer error in genmatchstring() at the memcpy / pointer arithmetic operations. Mitigation: Do not enable filename remapping with m/-map-file unless it is required.

If remapping is required, avoid inverse (~) + abort (a) rules that use a non-empty custom error message.

Where feasible, build without remap support (--without-remap) until a fix is available.

Vulnerability Details

When rewritestring() takes an inverse match, it deliberately clears all pmatch[] entries to -1: c if (ruleptr->ruleflags & RULEINVERSE) { int i; for (i = 0; i < 10; i++) pmatch[i].rmso = pmatch[i].rmeo = -1; } If that same rule also has RULEABORT and a non-empty pattern, genmatchstring() is still called twice with this invalid state: c if (ruleptr->ruleflags & RULEABORT) { if (ruleptr->pattern[0]) { len = genmatchstring(NULL, ruleptr->pattern, current, pmatch, macrosub); newstr = tfmalloc(len + 1); genmatchstring(newstr, ruleptr->pattern, current, pmatch, macrosub); errmsg = newstr; } return NULL; } genmatchstring() assumes pmatch[0] contains valid offsets and uses it in length calculations, pointer arithmetic, and memcpy: c endbytes = strlen(input) - pmatch[0].rmeo; len = pmatch[0].rmso + endbytes; memcpy(string, input, pmatch[0].rmso); memcpy(string, input + pmatch[0].rmeo, endbytes); With pmatch[0].rmso = pmatch[0].rmeo = -1, the second genmatchstring() call converts -1 to a huge sizet and also forms input - 1, producing a reachable out-of-bounds read/write. The parser permits + a and only rejects + r, and remote filename requests are passed through this remap path when m/-map-file is in use.

Proposed Fix

diff diff --git a/tftpd/remap.c b/tftpd/remap.c @@ static int genmatchstring(char string, const char pattern, const char input, const regmatcht pmatch, matchpatterncallback macrosub) { int (xform) (int) = xformnull; int len = 0; int n, mlen, sublen; int endbytes; + sizet inlen, endbytes; + regofft so, eo; @@

endbytes = strlen(input) - pmatch[0].rmeo;

len = pmatch[0].rmso + endbytes; + inlen = strlen(input); + so = pmatch[0].rmso; + eo = pmatch[0].rmeo; + if (so < 0 || eo < 0 || eo < so || (sizet)so > inlen || (sizet)eo > inlen) { + so = 0; + eo = 0; + } + endbytes = inlen - (sizet)eo; + len = (int)so + (int)endbytes; if (string) {

memcpy(string, input, pmatch[0].rmso);

string += pmatch[0].rmso; + memcpy(string, input, (sizet)so); + string += so; @@ if (string) {

memcpy(string, input + pmatch[0].rmeo, endbytes); + memcpy(string, input + eo, endbytes); string[endbytes] = '\0'; }

The same fix should also be applied to tftpd/remap.c.zero if that file is maintained in sync. ------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat