public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zaitsev <peter@mysql.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Wolfpaw - Dale Corse <admin@wolfpaw.net>, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.27 SECURITY BUG - TCP Local (probable Remote) Denial of Service
Date: Sat, 11 Sep 2004 23:27:05 -0700	[thread overview]
Message-ID: <1094970424.29211.489.camel@sphere.site> (raw)
In-Reply-To: <20040911204710.4aa7abed.davem@davemloft.net>

On Sat, 2004-09-11 at 20:47, David S. Miller wrote:

> If the application doesn't close it's file descriptors there is
> absolutely nothing the kernel can do about it.
> 
> It's a resource leak, plain and simple.
> 
> > That being said - below is a the proper description, and the code
> > used to exploit it. Hope it helps. This version is not the one
> > which invokes the CLOSE_WAIT state, but rather the TIME_WAIT one,
> > I am not able to publish the source code for the CLOSE_WAIT bug.
> 
> There is nothing wrong with creating tons of TIME_WAIT sockets,
> they simply time out after 60 seconds (unless hit by a RESET
> packet or similar).  This is how TCP works.
> 

Hm,

As this question arose may I ask where this timeout is configured ?

There is tcp_fin_timeout  configuration but I found nothing
corresponding to TIME_WAIT.

Here is how it bothers me.  On the Web sites using Apache/PHP and MySQL 
on different hosts I often see  "Sleep" connections hanging for many
minutes on MySQL hosts.    Tracking remote host and port shows this
connection is not assigned to any process on other end any more but
rather being in TIME_WAIT state. 

I do not care about TIME_WAIT  connection on client site itself, what
concerns me is, until connection is not fully closed server side does
not seems to be informed connection is dead and so  server resources are
not deallocated.    

Any ideas ? 



-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com




  reply	other threads:[~2004-09-12  6:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <022601c49866$9e8aa8f0$0300a8c0@s>
2004-09-12  2:45 ` Linux 2.4.27 SECURITY BUG - TCP Local (probable Remote) Denial of Service Wolfpaw - Dale Corse
2004-09-12  3:47   ` David S. Miller
2004-09-12  6:27     ` Peter Zaitsev [this message]
2004-09-12  6:56       ` Willy Tarreau
2004-09-12  7:11         ` Peter Zaitsev
2004-09-13 17:46   ` Ron DuFresne
     [not found] <026001c4989c$e2bddbb0$0300a8c0@s>
2004-09-12  9:24 ` Wolfpaw - Dale Corse
2004-09-12 10:36   ` Willy Tarreau
     [not found] <025e01c4989c$ba5f62b0$0300a8c0@s>
2004-09-12  9:10 ` Wolfpaw - Dale Corse
2004-09-11 21:41 Wolfpaw - Dale Corse
2004-09-12  1:12 ` David S. Miller
2004-09-14  9:00 ` Ivan Groenewald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1094970424.29211.489.camel@sphere.site \
    --to=peter@mysql.com \
    --cc=admin@wolfpaw.net \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox