Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 May 2001 23:03:54 -0700
From:      "Brian O'Shea" <boshea@ricochet.net>
To:        Matthew Emmerton <matt@gsicomp.on.ca>
Cc:        John Indra <john@office.naver.co.id>, freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject:   Re: My network is dead because of this program :(
Message-ID:  <20010515230354.A62767@shaolin.hq.netapp.com>
In-Reply-To: <00b401c0ddb2$23b2c710$1200a8c0@gsicomp.on.ca>; from matt@gsicomp.on.ca on Tue, May 15, 2001 at 10:44:32PM -0400
References:  <20010516092035.A79109@office.naver.co.id> <00b401c0ddb2$23b2c710$1200a8c0@gsicomp.on.ca>

next in thread | previous in thread | raw e-mail | index | archive | help

--3uo+9/B/ebqu+fSQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, May 15, 2001 at 10:44:32PM -0400, Matthew Emmerton wrote:
[...]
> > After going to single user mode, cause I can't kill the offending
> > program once it is running in multiuser mode (even kill -9 won't
> > work ...

Probably because the program is forking and you can't kill it's children
fast enough.

> > Can anyone help me trace what the program does? And how can I
> > prevent the program to DoS my network interface? Even when the
> > program is started by unprivileged user, it works, it DoS my network
> > interface. Is this a bug?
[...]

Unfortunately it looks like the program forks, does it's thing, and then
each child forks too.  There is a call to sleep probably to introduce a
delay so that things don't go completely crazy right away, but processes
build up exponentially with each child process forking, so eventually
resources get exhausted.  Take a look at the attachment for more
details.

-brian

-- 
Brian O'Shea
<boshea@ricochet.net>

--3uo+9/B/ebqu+fSQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="x.disasm"

It looks like the program basically does this, in pseudo-code:

main()
{
    int      pid;

    while (1) {
        pid = fork();

        if (pid == 0) {     /* child process */
            socketpair();   /* get two AF_LOCAL sockets */

            setsockopt();   /* set receive buffer size on one socket */
            setsockopt();   /* set send buffer size on other socket */

            fcntl();        /* set non-blocking I/O on both sockets */
            fcntl();

            write();        /* write some data from one socket to the other */
            write();
        }

        /* else we're in the parent, or fork() failed */

        sleep();            /* sleep a while */
    }

    return;
}



(gdb) disassemble main
Dump of assembler code for function main:
0x804865c <main>:	push   %ebp
0x804865d <main+1>:	mov    %esp,%ebp
0x804865f <main+3>:	sub    $0x32018,%esp
0x8048665 <main+9>:	nop    


We're probably in an infinite loop here.

0x8048666 <main+10>:	movl   $0x0,0xfffffff4(%ebp)
0x804866d <main+17>:	lea    0x0(%esi),%esi
0x8048670 <main+20>:	cmpl   $0x12,0xfffffff4(%ebp)
0x8048674 <main+24>:	jle    0x8048678 <main+28>
0x8048676 <main+26>:	jmp    0x8048690 <main+52>


The first thing we do in the loop is call fork().

0x8048678 <main+28>:	call   0x80484c0 <fork>


Then we check its return value.

0x804867d <main+33>:	mov    %eax,%eax
0x804867f <main+35>:	test   %eax,%eax
0x8048681 <main+37>:	je     0x8048688 <main+44>
0x8048683 <main+39>:	jmp    0x8048690 <main+52>
0x8048685 <main+41>:	lea    0x0(%esi),%esi


It looks like the parent calls fork in a loop.  The child processes that
it creates continue.

0x8048688 <main+44>:	incl   0xfffffff4(%ebp)
0x804868b <main+47>:	jmp    0x8048670 <main+20>
0x804868d <main+49>:	lea    0x0(%esi),%esi
0x8048690 <main+52>:	add    $0xfffffff4,%esp


Sleep for 5 seconds ...

0x8048693 <main+55>:	push   $0x5
0x8048695 <main+57>:	call   0x8048490 <sleep>
0x804869a <main+62>:	add    $0x10,%esp



0x804869d <main+65>:	lea    0x0(%esi),%esi
0x80486a0 <main+68>:	jmp    0x80486a8 <main+76>
0x80486a2 <main+70>:	jmp    0x80487ac <main+336>
0x80486a7 <main+75>:	nop    


Child calls socketpair with the following arguments:

    int socketpair(int domain, int type, int protocol, int *sv)
    int      domain   = 0x1     (AF_LOCAL)
    int      type     = 0x1     (SOCK_STREAM)
    int      protocol = 0x0     (typically 0 for AF_LOCAL)
    int     *sv       = address of an array of two file descriptors


Push arguments to socketpair onto stack and call socketpair again:

0x80486a8 <main+76>:	lea    0xfffffff8(%ebp),%eax
0x80486ab <main+79>:	push   %eax
0x80486ac <main+80>:	push   $0x0
0x80486ae <main+82>:	push   $0x1
0x80486b0 <main+84>:	push   $0x1
0x80486b2 <main+86>:	call   0x80484e0 <socketpair>
0x80486b7 <main+91>:	add    $0x10,%esp
0x80486ba <main+94>:	mov    %eax,%eax

Note: It's strange that the address family is AF_LOCAL.  I wouldn't think
this would cause the problems that you are seeing with the xl0 device,
unless AF_LOCAL sockets consume some of the same resources that this driver
also consumes, and thus starves it of those resources.  I don't know enough
about FreeBSD to tell.


Looks like we're checking the return value of socketpair.
The value 0xffffffff is -1, which is what socketpair returns if it fails.

0x80486bc <main+96>:	cmp    $0xffffffff,%eax

0x80486bf <main+99>:	jne    0x80486c8 <main+108>
0x80486c1 <main+101>:	jmp    0x80487ac <main+336>

If it fails, jumps ahead to a call to pause (below at main+336)


0x80486c6 <main+106>:	mov    %esi,%esi
0x80486c8 <main+108>:	movl   $0x32000,0xfffffff4(%ebp)
0x80486cf <main+115>:	add    $0xfffffff4,%esp


Push arguments to setsockopt onto stack and call setsockopt:

0x80486d2 <main+118>:	push   $0x4
0x80486d4 <main+120>:	lea    0xfffffff4(%ebp),%eax
0x80486d7 <main+123>:	push   %eax
0x80486d8 <main+124>:	push   $0x1002
0x80486dd <main+129>:	push   $0xffff
0x80486e2 <main+134>:	mov    0xfffffff8(%ebp),%eax
0x80486e5 <main+137>:	push   %eax
0x80486e6 <main+138>:	call   0x80484b0 <setsockopt>

    int setsockopt(
        int          s,         /* socket descriptor */
        int          level,     /* 0xffff (SOL_SOCKET) */
        int          optname,   /* 0x1002 (SO_RCVBUF) */
        void        *optval,    /* pointer to a buffer containing optval */
        socklen_t   *optlen     /* pointer to buffer length */
    )


Pop arguments to first setsockopt call off stack.

0x80486eb <main+143>:	add    $0x20,%esp
0x80486ee <main+146>:	add    $0xfffffff4,%esp


Same thing, this time with optname 0x1001 (SO_SNDBUF).

0x80486f1 <main+149>:	push   $0x4
0x80486f3 <main+151>:	lea    0xfffffff4(%ebp),%eax
0x80486f6 <main+154>:	push   %eax
0x80486f7 <main+155>:	push   $0x1001
0x80486fc <main+160>:	push   $0xffff
0x8048701 <main+165>:	mov    0xfffffff8(%ebp),%eax
0x8048704 <main+168>:	push   %eax
0x8048705 <main+169>:	call   0x80484b0 <setsockopt>


0x804870a <main+174>:	add    $0x20,%esp
0x804870d <main+177>:	add    $0xfffffff4,%esp

Pop arguments to second setsockopt call off stack.


Probably the same call to setsockopt follows, except for the other socket
in the socketpair.

0x8048710 <main+180>:	push   $0x4
0x8048712 <main+182>:	lea    0xfffffff4(%ebp),%eax
0x8048715 <main+185>:	push   %eax
0x8048716 <main+186>:	push   $0x1002
0x804871b <main+191>:	push   $0xffff
0x8048720 <main+196>:	mov    0xfffffffc(%ebp),%eax
0x8048723 <main+199>:	push   %eax
0x8048724 <main+200>:	call   0x80484b0 <setsockopt>
0x8048729 <main+205>:	add    $0x20,%esp
0x804872c <main+208>:	add    $0xfffffff4,%esp
0x804872f <main+211>:	push   $0x4
0x8048731 <main+213>:	lea    0xfffffff4(%ebp),%eax
0x8048734 <main+216>:	push   %eax
0x8048735 <main+217>:	push   $0x1001
0x804873a <main+222>:	push   $0xffff
0x804873f <main+227>:	mov    0xfffffffc(%ebp),%eax
0x8048742 <main+230>:	push   %eax
0x8048743 <main+231>:	call   0x80484b0 <setsockopt>



0x8048748 <main+236>:	add    $0x20,%esp
0x804874b <main+239>:	add    $0xfffffffc,%esp
0x804874e <main+242>:	push   $0x4
0x8048750 <main+244>:	push   $0x4
0x8048752 <main+246>:	mov    0xfffffff8(%ebp),%eax
0x8048755 <main+249>:	push   %eax
0x8048756 <main+250>:	call   0x8048500 <fcntl>

     fcntl(
        int      fd,        /* socket descriptor */
        int      cmd,       /* 0x4 (O_NONBLOCK) */
        ...
    )

Puts the socket into non-blocking I/O mode.

0x804875b <main+255>:	add    $0x10,%esp
0x804875e <main+258>:	add    $0xfffffffc,%esp

Pop pop...


Same thing for other socket.

0x8048761 <main+261>:	push   $0x4
0x8048763 <main+263>:	push   $0x4
0x8048765 <main+265>:	mov    0xfffffffc(%ebp),%eax
0x8048768 <main+268>:	push   %eax
0x8048769 <main+269>:	call   0x8048500 <fcntl>

     fcntl(
        int      fd,        
        int      cmd,       
        ...
    )


0x804876e <main+274>:	add    $0x10,%esp
0x8048771 <main+277>:	add    $0xfffffffc,%esp



Push arguments to write onto stack.

0x8048774 <main+280>:	push   $0x32000
0x8048779 <main+285>:	lea    0xfffcdff4(%ebp),%eax
0x804877f <main+291>:	push   %eax
0x8048780 <main+292>:	mov    0xfffffff8(%ebp),%eax
0x8048783 <main+295>:	push   %eax
0x8048784 <main+296>:	call   0x80484a0 <write>

0x8048789 <main+301>:	add    $0x10,%esp
0x804878c <main+304>:	add    $0xfffffffc,%esp

    write(
        int         d,          /* socket descriptor */
        const void *buf,        /* buffer to write */
        size_t      nbytes      /* number of bytes to write (204800) */
    )


Call write again.

0x804878f <main+307>:	push   $0x32000
0x8048794 <main+312>:	lea    0xfffcdff4(%ebp),%eax
0x804879a <main+318>:	push   %eax
0x804879b <main+319>:	mov    0xfffffffc(%ebp),%eax
0x804879e <main+322>:	push   %eax
0x804879f <main+323>:	call   0x80484a0 <write>

0x80487a4 <main+328>:	add    $0x10,%esp



0x80487a7 <main+331>:	jmp    0x80486a0 <main+68>
0x80487ac <main+336>:	call   0x8048480 <pause>
0x80487b1 <main+341>:	xor    %eax,%eax
0x80487b3 <main+343>:	jmp    0x80487b8 <main+348>
0x80487b5 <main+345>:	lea    0x0(%esi),%esi
0x80487b8 <main+348>:	leave  
0x80487b9 <main+349>:	ret    
0x80487ba <main+350>:	nop    
0x80487bb <main+351>:	nop    
End of assembler dump.
(gdb) quit

--3uo+9/B/ebqu+fSQ--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010515230354.A62767>