Willy Tarreau wrote:
> On Sun, Aug 20, 2006 at 02:05:20AM +0200, Michael Buesch wrote:
>> On Sunday 20 August 2006 01:48, Willy Tarreau wrote:
>>> On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote:
[snipped]
> diff --git a/net/socket.c b/net/socket.c
> index ac45b13..910ef88 100644
> -
> We're not assuming they're broken. When some code is maintained by many people
> and when conventions differ between similar functions (eg: setsockopt does
> the check at top level and getsockopt in the leaves),
thats not something you want to fix in 2.4 though ;)
it may be worth considering f
Hi David,
On Sun, Aug 20, 2006 at 12:44:27PM -0700, David Miller wrote:
> From: Willy Tarreau <[EMAIL PROTECTED]>
> Date: Sun, 20 Aug 2006 02:43:07 +0200
>
> > On Sun, Aug 20, 2006 at 02:05:20AM +0200, Michael Buesch wrote:
> > > Not to me. It heavily violates codingstyle and screws brains
> >
On Sun, Aug 20, 2006 at 08:38:34PM +0200, Andi Kleen wrote:
> On Sunday 20 August 2006 18:16, Solar Designer wrote:
> > On Sun, Aug 20, 2006 at 10:34:43AM +0200, Andi Kleen wrote:
> > > In general I don't think it makes sense to submit stuff for 2.4
> > > that isn't in 2.6.
> >
> > In general I a
From: Willy Tarreau <[EMAIL PROTECTED]>
Date: Sun, 20 Aug 2006 12:15:28 +0200
> Others will consider it totally useless because it does not cover
> all cases, but I think it is against the general principle of
> precaution we try to apply in security.
Reading in a value from userspace twice for q
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Sun, 20 Aug 2006 18:30:51 +0200
> this reasoning goes out the window with kernel preemption of course ;)
Yes and even though this thing is for 2.4.x, it just shows
that this is a hack and we shouldn't eat two userspace
accesses for a hack.
Instead
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sun, 20 Aug 2006 10:34:43 +0200
> Doing a check that is inherently racy everywhere doesn't seem like a
> security improvement to me. If there is really a length checking bug
> somewhere it needs to be fixed in a race-free way. If not then there
> is no ne
From: Willy Tarreau <[EMAIL PROTECTED]>
Date: Sun, 20 Aug 2006 02:43:07 +0200
> On Sun, Aug 20, 2006 at 02:05:20AM +0200, Michael Buesch wrote:
> > Not to me. It heavily violates codingstyle and screws brains
> ^^^
> little exageration detected here.
>
> > with the non-indente
On Sunday 20 August 2006 18:16, Solar Designer wrote:
> On Sun, Aug 20, 2006 at 10:34:43AM +0200, Andi Kleen wrote:
> > In general I don't think it makes sense to submit stuff for 2.4
> > that isn't in 2.6.
>
> In general I agree, however right now I had the choice between
> submitting these chan
Ar Sul, 2006-08-20 am 03:05 +0400, ysgrifennodd Solar Designer:
> The patch makes getsockopt(2) sanity-check the value pointed to by
> the optlen argument early on. This is a security hardening measure
> intended to prevent exploitation of certain potential vulnerabilities in
> socket type specifi
> We're on UP. sys_getsockopt() does get_user() (due to the patch) and
> makes sure that the passed *optlen is sane. Even if this get_user()
> sleeps, the value it returns in "len" is what's currently in memory at
> the time of the get_user() return (correct?) Then an underlying
> *getsockopt()
On Sun, Aug 20, 2006 at 10:34:43AM +0200, Andi Kleen wrote:
> In general I don't think it makes sense to submit stuff for 2.4
> that isn't in 2.6.
In general I agree, however right now I had the choice between
submitting these changes for 2.4 first and not submitting them at all
(at least for som
Hello.
In article <[EMAIL PROTECTED]> (at Sun, 20 Aug 2006 12:15:28 +0200), Willy
Tarreau <[EMAIL PROTECTED]> says:
> But I don't want to induce such large changes in this kernel. The goal of
> this test is a preventive measure to catch easily exploitable errors that
> might have remained undete
On Sun, Aug 20, 2006 at 10:34:43AM +0200, Andi Kleen wrote:
> On Sunday 20 August 2006 01:05, Solar Designer wrote:
> > I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> > into 2.4.34-pre.
> >
> > (2.6 kernels could benefit from the same change, too, but at the moment
> > I
On Sunday 20 August 2006 01:05, Solar Designer wrote:
> I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> into 2.4.34-pre.
>
> (2.6 kernels could benefit from the same change, too, but at the moment
> I am dealing with proper submission of generic changes like this that
> ar
On Sun, Aug 20, 2006 at 02:05:20AM +0200, Michael Buesch wrote:
> On Sunday 20 August 2006 01:48, Willy Tarreau wrote:
> > On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote:
> > > Willy,
> > >
> > > I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> > > into 2.4.
On Sunday 20 August 2006 01:48, Willy Tarreau wrote:
> On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote:
> > Willy,
> >
> > I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> > into 2.4.34-pre.
> >
> > (2.6 kernels could benefit from the same change, too, but a
On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote:
> Willy,
>
> I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> into 2.4.34-pre.
>
> (2.6 kernels could benefit from the same change, too, but at the moment
> I am dealing with proper submission of generic chang
Willy,
I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
into 2.4.34-pre.
(2.6 kernels could benefit from the same change, too, but at the moment
I am dealing with proper submission of generic changes like this that
are a part of 2.4.33-ow1.)
The patch makes getsockopt(2) sa
19 matches
Mail list logo