Bug 1012277

Summary: xinetd corrupts input when reading service name
Product: Red Hat Enterprise Linux 5 Reporter: thomas.swan
Component: xinetdAssignee: Jan Synacek <jsynacek>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: unspecified    
Version: 5.11   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-08 11:23:05 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:
Attachments:
Description Flags
fix for svc_name read none

Description thomas.swan 2013-09-26 07:42:06 UTC 
Created attachment 803258 [details]
fix for svc_name read

Description of problem:
xinetd can corrupt input and miss service names by reading to much if the input buffer fills too quickly.

Version-Release number of selected component (if applicable):
xinetd-2.3.15 and earlier releases

How reproducible:
always

Steps to Reproduce:
1. Enable tcpmux-server
2. Create a simple service

   service date
   {
      id = tcpmux-date
      disable = no
      user = nobody
      group = nobody
      socket_type = stream
      type = TCPMUXPLUS UNLISTED
      flags = NAMEINARGS
      server = /bin/uname
      server_args = uname
      wait = no
   }
3. Restart/reload xinetd
4. Send a larger than expected stream
   printf 'date\r\nsomething new\r\n' |
   nc localhost 1

Actual results:
1. If running a new xinetd, you would receive
   -Service name not found


Expected results:
1. If running a newer xinetd, you would have received
   +Go
   Linux
   {output from date}

Additional info:

This is a result of the read command before inspecting the service name.

There is an open pull requet to implement the rfc1078 help command and to address the service name issue upstream.

Fix for svc_name read is attached as a patch
Comment 1 Jan Synacek 2013-11-08 11:23:05 UTC 
Red Hat Enterprise Linux 5 has entered Production 2 phase. For more details see https://access.redhat.com/support/policy/updates/errata/. As this bug is not qualified as critical, it is closed as WONTFIX.