netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Julius Werner <jwerner@chromium.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Patrick McHardy <kaber@trash.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	James Morris <jmorris@namei.org>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	"David S. Miller" <davem@davemloft.net>,
	Sameer Nanda <snanda@chromium.org>,
	Mandeep Singh Baines <msb@chromium.org>,
	Eric Dumazet <edumazet@chromium.org>
Subject: Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crashusers
Date: Wed, 7 Nov 2012 12:15:41 -0500	[thread overview]
Message-ID: <20121107171541.GA24482@redhat.com> (raw)
In-Reply-To: <1352307902.3140.4588.camel@edumazet-glaptop>

On Wed, Nov 07, 2012 at 09:05:02AM -0800, Eric Dumazet wrote:
 > On Wed, 2012-11-07 at 11:43 -0500, Dave Jones wrote:
 > 
 > > dude, look at the bug reports I just pointed you at.
 > > People _are_ aware there are bugs there.
 > > 
 > If I remember well, I helped to fix some of them.

indeed, and I commend you for it. I want to help you fix more ;)

 > >  > I understand a distro maintainer has its own choices, but for upstream
 > >  > kernel we want to have early reports.
 > > 
 > > I'm running out of ways to word this, but I'll try again.
 > > You won't get those early reports if you turn this into a BUG().
 > > 
 > >  > This bug is fatal and a security issue. BUG() is appropriate.
 > > 
 > > turning a bug into a remote DoS is also a security issue.
 > 
 > Apparently in some cases we can loop and fill the syslog, or
 > else Julius wouldnt have sent a patch.
 > 
 > So the proper fix is to emit this message only once, and to find
 > a way to alert the user security is compromised.
 > 
 > So if BUG() isnt good, just use WARN_ON_ONCE()
 > 
 > I feel that WARN_ON_ONCE() wont be clear enough to the user, especially
 > if we recover from this by closing the tcp session, exactly as if we
 > received a proper FIN.

Judging by the mangled traces we've seen, further reports after the initial
one aren't too useful anyway.  Automated detectors like abrt should be
able to pick up these traces from the logs on the next reboot.
(Which would probably be better than it trying to file them immediately over
 the network when the tcp layer is so confused)

sidenote: If the integrity of the tcp layer is in question, maybe some kind of
localised version of BUG() that just shuts down that subsystem might
be something worth persueing.

 > Really if you object a BUG() here, I cant understand you didnt shout to
 > other BUG() uses in the kernel.

When I see them, I call them. But I am just one person, and usage of that
macro is like a disease.

	Dave

  reply	other threads:[~2012-11-07 17:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07  0:15 [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crash Julius Werner
2012-11-07  1:39 ` Dave Jones
2012-11-07  1:51   ` Julius Werner
2012-11-07 15:54     ` Dave Jones
2012-11-07 16:29       ` [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crashusers Eric Dumazet
2012-11-07 16:43         ` Dave Jones
2012-11-07 17:05           ` Eric Dumazet
2012-11-07 17:15             ` Dave Jones [this message]
2012-11-07 19:32               ` Julius Werner
2012-11-07 19:33                 ` [PATCH] tcp: Avoid infinite loop on recvmsg bug Julius Werner
2012-11-07 19:40                   ` Eric Dumazet
2012-11-07 21:14                     ` Julius Werner
2012-11-07 23:33                       ` Eric Dumazet
2012-11-07 23:42                         ` Eric Dumazet
2012-11-08  2:25                           ` Julius Werner
2012-11-09  3:29                             ` Eric Dumazet
2012-12-10 19:33                               ` Julius Werner
2012-12-10 20:23                                 ` David Miller
2012-11-07  1:51   ` [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crash Eric Dumazet

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=20121107171541.GA24482@redhat.com \
    --to=davej@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@chromium.org \
    --cc=eric.dumazet@gmail.com \
    --cc=jmorris@namei.org \
    --cc=jwerner@chromium.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msb@chromium.org \
    --cc=netdev@vger.kernel.org \
    --cc=snanda@chromium.org \
    --cc=yoshfuji@linux-ipv6.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;
as well as URLs for NNTP newsgroup(s).