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: <200905111554.50118.elendil@planet.nl>
Date:	Mon, 11 May 2009 15:54:48 +0200
From:	Frans Pop <elendil@...net.nl>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	Matthias Andree <matthias.andree@....de>,
	Netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH v2] tcp: fix MSG_PEEK race check

On Monday 11 May 2009, Ilpo Järvinen wrote:
> On Mon, 11 May 2009, Frans Pop wrote:
> > On Monday 11 May 2009, Ilpo Järvinen wrote:
> > > I took my time to fix the urg_hole madness too. The patch below.
> >
> > Hmm. I wonder if it wouldn't be better to keep the two issues
> > separate. The initial patch is a clear regression fix (4 people have
> > reported it against fetchmail for Debian). The URG part is IMO a
> > separate issue which I at least have never seen in practice.
> > And my Tested-by doesn't cover the additional change either.
>
> Disagreed. It's true that your testing very likely doesn't cover such a
> corner case. The URG thing is legacy which shouldn't exist anymore but
> it might still be that some people are crazy enough to use URG not
> inline (and at the same time are doing MSG_PEEK too). However, that URG
> part is not a _separate_ issue, you might not just have a test case but
> it happens due to the very same reason and was broken by the very same
> commit.

OK. I understood that there's always been a corner case with URG that 
could cause incorrect messages [1] and I thought the additional change 
was to fix that, but if this is related to the same regression then of 
course it's fine by me.

[1] http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/6009.html

> This issue has nothing to do with fetchmail or so alone (regardless of
> how many bugs have been filed against it), it's generic TCP (in kernel)
> issue, whether it's triggered is just about right test pattern which
> here happens with fetchmail but it is by no means limited to it.

I never claimed that. In fact, I was the one who also saw the issue with 
other applications (wget, IMAP)...

> I don't care too much if distro people have some local policies
> regarding fixes and that here shouldn't be a bother to them anyway
> since there's the more limited fix available in the archives too if
> they specifically want that.

Where did that come from? Not from anything I said...

> If you don't have URG holes, the v2 change yields to: -0 which equals
> to no-op. No testing is going to undo that :-). ...And that can be seen
> already from the patch context.

I'll still give the new patch a try on my next build :-)
The rest I happily leave up to you and David.

Thanks for clarifying.

Cheers,
FJP
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ