1485943 – memory corruption in tftpd (patch attached!)

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 - memory corruption in tftpd (patch attached!)

Summary: memory corruption in tftpd (patch attached!)

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	tftp
Sub Component:
Version:	7.4
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Jan Synacek
QA Contact:	Release Test Team
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1465901 2066858 2066862
TreeView+	depends on / blocked

Reported:	2017-08-28 13:49 UTC by anshockm
Modified:	2022-03-22 16:03 UTC (History)
CC List:	3 users (show)
Fixed In Version:	tftp-5.2-15.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	2066858 2066862 (view as bug list)
Environment:
Last Closed:	2018-04-10 08:35:30 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
rewrite_macro patch (1.21 KB, patch) 2017-08-28 13:49 UTC, anshockm	no flags	Details \| Diff
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHEA-2018:0660	0	None	None	None	2018-04-10 08:35:58 UTC

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

Note You need to log in before you can comment on or make changes to this bug.