Bug 1033528 - xinetd segfaults when connecting to tcpmux service
Summary: xinetd segfaults when connecting to tcpmux service
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xinetd
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-22 10:22 UTC by Jan Synacek
Modified: 2014-01-22 03:09 UTC (History)
2 users (show)

Fixed In Version: xinetd-2.3.15-10.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1037565 (view as bug list)
Environment:
Last Closed: 2013-12-14 03:34:00 UTC


Attachments (Terms of Use)
Patch v1 - disable service (736 bytes, patch)
2013-11-22 10:24 UTC, Jan Synacek
no flags Details | Diff
Patch v2 - shift args (823 bytes, patch)
2013-11-22 10:24 UTC, Jan Synacek
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1029208 None None None Never

Internal Links: 1029208

Description Jan Synacek 2013-11-22 10:22:55 UTC
Description of problem:
xinetd segfaults when connecting to tcpmux service.


Version-Release number of selected component (if applicable):
2:xinetd-2.3.15-8.fc19.x86_64


Steps to Reproduce:
1. enable tcpmux service
2. create a sample tcpmux-activated service

service test
{
   id = tcpmux-test
   disable = no
   socket_type = stream
   wait = no
   user = root
   type = TCPMUXPLUS UNLISTED
   server = /bin/uname
   server_args = uname -s -r -v
   flags = NAMEINARGS
}

The order of server_args and flags is important.

3. run xinetd
4. telnet <host> 1
5. type 'test' and enter


Actual results:
Segfault.


Expected results:
Service is run as expected.


Additional info:

(gdb) bt
#0  0x00007f8f5cbcc9a0 in __strrchr_sse42 () from /lib64/libc.so.6
#1  0x00007f8f5dc025ae in access_control (sp=sp@entry=0x7f8f5f0f31a0, cp=cp@entry=0x7f8f5f109880, check_mask=check_mask@entry=0x0) at access.c:236
#2  0x00007f8f5dc12453 in svc_child_access_control (sp=sp@entry=0x7f8f5f0f31a0, cp=cp@entry=0x7f8f5f109880) at service.c:913
#3  0x00007f8f5dc05065 in child_process (serp=0x7f8f5f0fd300) at child.c:347
#4  0x00007f8f5dc03ff6 in tcpmux_handler (serp=0x7f8f5f109920) at builtins.c:650
#5  0x00007f8f5dc052f2 in child_process (serp=serp@entry=0x7f8f5f109920) at child.c:434
#6  0x00007f8f5dc10981 in server_start (serp=serp@entry=0x7f8f5f109920) at server.c:222
#7  0x00007f8f5dc10a98 in server_run (sp=sp@entry=0x7f8f5f0f30f0, cp=cp@entry=0x7f8f5f109880) at server.c:173
#8  0x00007f8f5dc122c1 in svc_generic_handler (sp=sp@entry=0x7f8f5f0f30f0, cp=cp@entry=0x7f8f5f109880) at service.c:684
#9  0x00007f8f5dc12309 in svc_request (sp=0x7f8f5f0f30f0) at service.c:652
#10 0x00007f8f5dc02165 in main_loop () at main.c:229
#11 main (argc=<optimized out>, argv=<optimized out>) at main.c:107

(gdb) up
#1  0x00007f8f5dc025ae in access_control (sp=sp@entry=0x7f8f5f0f31a0, cp=cp@entry=0x7f8f5f109880, check_mask=check_mask@entry=0x0) at access.c:236
236	            server = strrchr( SC_SERVER_ARGV(scp)[0], '/' );

(gdb) p *scp->sc_server_argv@3
$1 = {0x0, 0x7f8f5f107a20 "uname", 0x0}

Apparently, the server arg is there, but it's offset by 1.

This looks like the NAMEINARGS argument never worked correctly. If it's specified, the first argument of server_args in the config is supposed to be argv[0] (the name of the server).

Xinetd parses and applies its configuration line by line. If a user wants to specify NAMEINARGS as a flag, it has to be *before* specifying 'server_args'.

Just swapping 'server_args' and 'flags' lines in our example is enough...

The only reasonable fix that comes into my mind is to exit if NAMEINARGS is used *after* server_args is set. And, of course, make this fact cleanly visible in the documentation.

The 'proper' fix would be to make the config parsing aware of every other option set. This would probably have to be done in two passes and IMHO is just not worth it.

Comment 1 Jan Synacek 2013-11-22 10:24:25 UTC
Created attachment 827667 [details]
Patch v1 - disable service

Disable service if NAMEINARGS is present in flags and is specified after server_args.

Comment 2 Jan Synacek 2013-11-22 10:24:49 UTC
Created attachment 827668 [details]
Patch v2 - shift args

Shift server arguments if NAMEINARGS flag is specified after server_args.

Comment 3 Jan Synacek 2013-11-22 10:25:05 UTC
I consider patch v1 somewhat cleaner solution to the problem.

Comment 4 Fedora Update System 2013-12-03 10:23:58 UTC
xinetd-2.3.15-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xinetd-2.3.15-10.fc20

Comment 6 Fedora Update System 2013-12-03 11:40:26 UTC
xinetd-2.3.15-9.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xinetd-2.3.15-9.fc19

Comment 7 Fedora Update System 2013-12-03 18:22:50 UTC
Package xinetd-2.3.15-10.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xinetd-2.3.15-10.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-22655/xinetd-2.3.15-10.fc20
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2013-12-14 03:34:00 UTC
xinetd-2.3.15-10.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2014-01-13 09:15:05 UTC
xinetd-2.3.15-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xinetd-2.3.15-10.fc19

Comment 10 Fedora Update System 2014-01-22 03:09:12 UTC
xinetd-2.3.15-10.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


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