#905647 tftpd-hpa: Logic flaw in macro expansion in remap for \x causes malfunction and memory corruption

Package:
tftpd-hpa
Source:
tftp-hpa
Description:
HPA's tftp server
Submitter:
Tomas Forsman
Date:
2026-09-28 14:17:02 UTC
Severity:
normal
Tags:
#905647#5
Date:
2018-08-07 14:51:13 UTC
From:
To:
Dear Maintainer,

   * What led up to the situation?

I wanted to use the remap function with macro \x (hex ip)

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Start with --map-file /somefile
In '/somefile', I have a rule:
r       /fai/efi/grub.cfg       /fai/efi/grub.cfg.d/\x

   * What was the outcome of this action?

Complaints from glibc about memory corruption, segfaults. Valgrind gave
54 errors. No working file.

   * What outcome did you expect instead?

Macro expansion and working file.


In tftpd/tftpd.c the function rewrite_macros is first called with
argument 'output' = NULL, asking for "how long will the string be".
A logic flaw makes the function return l=0 for macro 'x'. 0 bytes (+1
for string-ending NULL) is allocated, and then the actual macro
expansion is performed and stored there (8 bytes for ipv4, 32 for ipv6),
overwriting other memory.

Patch moves the 'if (output)' to only include the string copying, not
length calculation.

Same flaw exists in upstreams version 5.2 and Ubuntu version
5.2+20150808-1ubuntu3.

#905647#12
Date:
2026-09-27 13:11:16 UTC
From:
To:
Hello hpa,

did you happen to see this issue? It was forwarded on to
https://bugzilla.syslinux.org/show_bug.cgi?id=76

I can't reproduce it with 7.2 (on arm64), maybe it was solved,
possibly by 04d7b0db0672ef5c7c36886e00f136672881a9ef?

Thanks,
Chris
[..]

#905647#17
Date:
2026-09-28 00:04:19 UTC
From:
To:
Hi,

This was fixed quite a while ago. I can't remember if it was intentional or an accidental side effect of another change.

#905647#22
Date:
2026-09-28 14:14:28 UTC
From:
To:
Closing this per info from upstream.