lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121107171541.GA24482@redhat.com>
Date:	Wed, 7 Nov 2012 12:15:41 -0500
From:	Dave Jones <davej@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Julius Werner <jwerner@...omium.org>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Patrick McHardy <kaber@...sh.net>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	James Morris <jmorris@...ei.org>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Sameer Nanda <snanda@...omium.org>,
	Mandeep Singh Baines <msb@...omium.org>,
	Eric Dumazet <edumazet@...omium.org>
Subject: Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper
 crashusers

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ