inetd fd leak?

[Denys Vlasenko]

On Wednesday 02 September 2009 20:44, Cathey, Jim wrote:
> We're seeing signs of fd's leaking in BB inetd, when it's
> used in the following way.  The inetd we're using is the 1.13.2
> version.  (I was hooked up with svn, but don't have [and have
> never used] git.)

Please try 1.15.0

> The target system is a 300 MHz MIPS-32 (Broadcom 
> Raven), running 2.6.26.6 Linux, with PREEMPT.  Gcc 4.2.3  The
> inetd portion of the config is normal, all options are enabled.
> (Sorry that I can't include it in this message, the VM through
> which my source is accessed has just crashed, hard enough to require
> rebooting my PC to get back, and I don't want to lose this
> message.  I'll follow up with it if it seems important.  Gotta
> love Windows PC's!)
> 
> The target has this for /etc/inetd.conf:
> 
>   # To re-read this file after changes, just do a 'killall -HUP inetd'
> 
>   telnet  stream  tcp     nowait.12    root    /usr/sbin/telnetd
> telnetd -i
> 
> Just the one service, which is commented-out (#) when telnet is
> feature-disabled on the target.  Note the 12/second rate limit option.
> This is an important DoS prevention measure for the target.
> 
> On the development system the following script exists:
> 
>    #!/bin/sh
>    # Bury the target in telnets
> 
>    for i in 1 2 3 4 5 6 7 8 9 10; do
>        for j  in 1 2 3 4 5 6 7 8 9 10; do
> 	   telnet 172.16.172.2 >/dev/null 2>&1 &
>        done
>    done
>    wait
> 
> which is invoked for this test with:
> 
>    while :; do ./bury; done
> 
> On the target via the console, the following runs
> (spread out in time, and trimmed to remove extraneous
> information) show what is happening:
> 
> # #Before tests starts:
> # procdump /proc/`pidof inetd`/fd
> /proc/934/fd/0 -> /dev/null
> /proc/934/fd/1 -> /dev/null
> /proc/934/fd/2 -> /dev/null
> /proc/934/fd/5 -> socket:[1455]
> # #Test starts now...
> # procdump /proc/`pidof inetd`/fd
> /proc/934/fd/0 -> /dev/null
> /proc/934/fd/1 -> /dev/null
> /proc/934/fd/2 -> /dev/null
> /proc/934/fd/5 -> socket:[1455]
> /proc/934/fd/6 -> socket:[1511]
> # procdump /proc/`pidof inetd`/fd
> /proc/934/fd/0 -> /dev/null
> /proc/934/fd/1 -> /dev/null
> /proc/934/fd/2 -> /dev/null
> /proc/934/fd/5 -> socket:[1455]
> /proc/934/fd/6 -> socket:[1511]
> /proc/934/fd/7 -> socket:[1597]
> # procdump /proc/`pidof inetd`/fd
> /proc/934/fd/0 -> /dev/null
> /proc/934/fd/1 -> /dev/null
> /proc/934/fd/2 -> /dev/null
> /proc/934/fd/5 -> socket:[1455]
> /proc/934/fd/6 -> socket:[1511]
> /proc/934/fd/7 -> socket:[1597]
> /proc/934/fd/8 -> socket:[1692]
> # procdump /proc/`pidof inetd`/fd
> /proc/934/fd/0 -> /dev/null
> /proc/934/fd/1 -> /dev/null
> /proc/934/fd/2 -> /dev/null
> /proc/934/fd/5 -> socket:[1455]
> /proc/934/fd/6 -> socket:[1511]
> /proc/934/fd/7 -> socket:[1597]
> /proc/934/fd/8 -> socket:[1692]
> /proc/934/fd/9 -> socket:[1738]
> # procdump /proc/`pidof inetd`/fd
> /proc/934/fd/0 -> /dev/null
> /proc/934/fd/1 -> /dev/null
> /proc/934/fd/2 -> /dev/null
> /proc/934/fd/5 -> socket:[1455]
> /proc/934/fd/6 -> socket:[1511]
> /proc/934/fd/7 -> socket:[1597]
> /proc/934/fd/8 -> socket:[1692]
> /proc/934/fd/9 -> socket:[1738]
> /proc/934/fd/10 -> socket:[1768]
> # procdump /proc/`pidof inetd`/fd
> /proc/934/fd/0 -> /dev/null
> /proc/934/fd/1 -> /dev/null
> /proc/934/fd/2 -> /dev/null
> /proc/934/fd/5 -> socket:[1455]
> /proc/934/fd/6 -> socket:[1511]
> /proc/934/fd/7 -> socket:[1597]
> /proc/934/fd/8 -> socket:[1692]
> /proc/934/fd/9 -> socket:[1738]
> /proc/934/fd/10 -> socket:[1768]
> /proc/934/fd/11 -> socket:[1796]
> # ...

Just "ls -l /proc/`pidof inetd`/fd" works for me.

I tried to reproduce it but it seems to work.

However, you can be onto something since I see
occasional segfaults in strace.
--
vda