Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1485943

Summary: memory corruption in tftpd (patch attached!)
Product: Red Hat Enterprise Linux 7 Reporter: anshockm
Component: tftpAssignee: Jan Synacek <jsynacek>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: anshockm, jstodola, pholica
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tftp-5.2-15.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2066858 2066862 (view as bug list) Environment:
Last Closed: 2018-04-10 08:35:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1465901, 2066858, 2066862    
Attachments:
Description Flags
rewrite_macro patch none

Description anshockm 2017-08-28 13:49:28 UTC
Created attachment 1319083 [details]
rewrite_macro patch

Description of problem:
in.tftpd failed with the following error message when serving a file with remapping using the \x macro:
in.tftpd[97852]: *** Error in `/usr/sbin/in.tftpd': malloc(): memory corruption: 0x00007f213934acb0 ***

Version-Release number of selected component (if applicable):
tftp-server-5.2-13.el7.x86_64

How reproducible:
Using filename remapping with macro \x

Additional info:
The attached patch resolves the memory corruption.

The reason for the corruption is a bug in rewrite_macros:
rewrite_macros (which is called from genmatchstring) is supposed to return the length of the string it will produce, even when not producing a string because it is called with output == NULL. In case of \x macro this was not true.

So genmatchstring(NULL, ...) returns a too small length and after mallocing too less bytes for newstr, genmatchstring(newstr, ...) will write behind the malloced space: corruption!

The attached patch fixes the bug.

Ansgar Hockmann-Stolle

Comment 2 Jan Synacek 2017-08-29 10:50:05 UTC
Nice catch, thank you!

Comment 3 Jan Stodola 2017-08-30 12:50:43 UTC
Could you please share your remap file and instructions to reproduce the problem?

I'm not seeing any problem with \x in my simple remap file and tftp-server-5.2-13.el7.x86_64 installed:

[root@localhost ~]# cat /var/lib/tftpboot/remap
r hostname \0-\x
[root@localhost ~]# ls /var/lib/tftpboot/
hostname-C0A87A1B  remap
[root@localhost ~]#

Command to execute in.tftpd:
# in.tftpd -L -vvv -s /var/lib/tftpboot -m /var/lib/tftpboot/remap

Messages in syslog:
Aug 30 14:42:42 localhost in.tftpd[12021]: remap: input: hostname
Aug 30 14:42:42 localhost in.tftpd[12021]: remap: rule 0: rewrite: hostname-C0A87A1B
Aug 30 14:42:42 localhost in.tftpd[12021]: remap: done
Aug 30 14:42:42 localhost in.tftpd[12021]: RRQ from 192.168.122.27 filename hostname remapped to hostname-C0A87A1B
Aug 30 14:42:42 localhost in.tftpd[12021]: Client 192.168.122.27 finished hostname

And the file "hostname" ("hostname-C0A87A1B" on server side) is transferred correctly.

Thank you.

Comment 4 anshockm 2017-08-30 13:46:01 UTC
I tried it again on a fresh (updated) RHEL 7.4 system. Here are my logs:

### server

[root@vm381 ~]# cat /etc/tftpd.map
r --IP-- \x
r /EFI/xenserver/ /boot/\x/EFI/xenserver/
[root@vm381 ~]# echo hallo >/var/lib/tftpboot/::1
[root@vm381 ~]# echo hallo >/var/lib/tftpboot/a
[root@vm381 ~]# ls -l /var/lib/tftpboot/
insgesamt 8
-rw-r--r--. 1 root root 6 30. Aug 15:28 ::1
-rw-r--r--. 1 root root 6 30. Aug 15:28 a
[root@vm381 ~]# journalctl -f &
[1] 20005
[root@vm381 ~]# in.tftpd -L -vvv -s /var/lib/tftpboot -m /etc/tftpd.map
Aug 30 15:30:06 vm381.rz.uni-osnabrueck.de in.tftpd[20780]: remap: input: a
Aug 30 15:30:06 vm381.rz.uni-osnabrueck.de in.tftpd[20780]: remap: done
Aug 30 15:30:06 vm381.rz.uni-osnabrueck.de in.tftpd[20780]: RRQ from ::1 filename a
Aug 30 15:30:06 vm381.rz.uni-osnabrueck.de in.tftpd[20780]: Client ::1 finished a
Aug 30 15:30:19 vm381.rz.uni-osnabrueck.de in.tftpd[20781]: remap: input: --IP--
Aug 30 15:30:19 vm381.rz.uni-osnabrueck.de kernel: traps: in.tftpd[20781] general protection ip:7f1a754545bd sp:7ffde95fad30 error:0 in libc-2.17.so[7f1a753d9000+1b8000]
Aug 30 15:30:24 vm381.rz.uni-osnabrueck.de in.tftpd[20782]: remap: input: --IP--
Aug 30 15:30:24 vm381.rz.uni-osnabrueck.de kernel: traps: in.tftpd[20782] general protection ip:7f1a754545bd sp:7ffde95fad30 error:0 in libc-2.17.so[7f1a753d9000+1b8000]


### client
[root@vm381 ~]# tftp localhost
tftp> get a
tftp> get --IP--
^C
tftp>


Maybe the bug occurs only when there is a second \x in the remap file?

Comment 5 Jan Stodola 2017-08-30 14:16:22 UTC
Thanks, it helped.
Actually, the configuration from comment 3 is correct, the problem is with IPv6, IPv4 works fine:

IPv4 ("File not found" is expected, since the file really doesn't exist):
[root@localhost ~]# tftp 127.0.0.1 -c get hostname
Error code 1: File not found
[root@localhost ~]#

IPv6:
[root@localhost ~]# tftp ::1 -c get hostname
Transfer timed out.
[root@localhost ~]#

And the server reports:
Aug 30 16:11:32 localhost in.tftpd[12220]: remap: input: hostname
Aug 30 16:11:32 localhost kernel: traps: in.tftpd[12220] general protection ip:7f87ee5d952d sp:7ffd783e0120 error:0 in libc-2.17.so[7f87ee55e000+1b8000]

Comment 6 Jan Synacek 2017-08-31 06:37:29 UTC
Reproducer:

$ ls /var/tmp/tftp
7F000001  world

$ cat /var/tmp/tftp/7F000001 
localhost ftw!

$ cat /var/tmp/tftp.map 
r   hello   \x

# in.tftpd -L -m /var/tmp/tftp.map -s /var/tmp/tftp

In another terminal:

$ tftp 127.0.0.1 -c get hello
$ cat hello 
localhost ftw!

In my case, I had to verify the corruption with valgrind, because it didn't immediately show with the trap or any dump.

Comment 7 anshockm 2017-08-31 07:02:25 UTC
It's not quite right to say that IPv4 works, as the source code suggests. It is only more likely to occur with IPv6 because IPv6 addresses are longer.
Here a test from a remote machine with IPv4 (when I did that with "--IP--" instead of "/boot/--IP--/mboot.c32", there was no error message but a timeout instead)

### server:

[root@vm381 ~]# in.tftpd -L -vvv -s /var/lib/tftpboot -m /etc/tftpd.map
*** Error in `in.tftpd': malloc(): memory corruption: 0x000055c6e7052dd0 ***
Aug 31 08:35:35 vm381.rz.uni-osnabrueck.de in.tftpd[30367]: remap: input: /boot/--IP--/mboot.c32

### client:

anshockm@grau:~> tftp -4 vm381 -c get /boot/--IP--/mboot.c32
^Canshockm@grau:~> 

By the way, I tested it with and without an existing file in /var/lib/tftpboot/...

Comment 13 errata-xmlrpc 2018-04-10 08:35:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0660