From: Jason Gunthorpe
> Sent: 27 May 2015 18:05
> On Wed, May 27, 2015 at 04:41:18PM +, David Laight wrote:
>
> > The code will be sleeping in kernel_accept() and later calls
> > kernel_getpeername().
> > The code is used for both TCP and SCTP and this part is common (using
> > the TCP semanti
From: Jason Gunthorpe
Date: Tue, 26 May 2015 17:30:17 -0600
> sctp_v4_map_v6 was subtly writing and reading from members
> of a union in a way the clobbered data it needed to read before
> it read it.
>
> Zeroing the v6 flowinfo overwrites the v4 sin_addr with 0, meaning
> that every place that
On Wed, May 27, 2015 at 04:41:18PM +, David Laight wrote:
> The code will be sleeping in kernel_accept() and later calls
> kernel_getpeername().
> The code is used for both TCP and SCTP and this part is common (using
> the TCP semantics).
getpeername uses a different flow, it calls into inet6
From: Jason Gunthorpe
> Sent: 27 May 2015 17:32
> On Wed, May 27, 2015 at 04:16:44PM +, David Laight wrote:
> > From: Jason Gunthorpe
> > > Sent: 27 May 2015 16:32
> > > On Wed, May 27, 2015 at 10:11:22AM +, David Laight wrote:
> > >
> > > > In any case it looks like I can escape by turning
On Wed, May 27, 2015 at 04:16:44PM +, David Laight wrote:
> From: Jason Gunthorpe
> > Sent: 27 May 2015 16:32
> > On Wed, May 27, 2015 at 10:11:22AM +, David Laight wrote:
> >
> > > In any case it looks like I can escape by turning off
> > > SCTP_I_WANT_MAPPED_V4_ADDR for kernels 3.17 thro
From: Jason Gunthorpe
> Sent: 27 May 2015 16:32
> On Wed, May 27, 2015 at 10:11:22AM +, David Laight wrote:
>
> > In any case it looks like I can escape by turning off
> > SCTP_I_WANT_MAPPED_V4_ADDR for kernels 3.17 through 4.0.
>
> Just be aware that option is unusable on kernels without 299
On Wed, May 27, 2015 at 10:11:22AM +, David Laight wrote:
> In any case it looks like I can escape by turning off
> SCTP_I_WANT_MAPPED_V4_ADDR for kernels 3.17 through 4.0.
Just be aware that option is unusable on kernels without 299ee.
I fixed everything wrong I saw, but that doesn't mean i
On Tue, May 26, 2015 at 05:30:17PM -0600, Jason Gunthorpe wrote:
> sctp_v4_map_v6 was subtly writing and reading from members
> of a union in a way the clobbered data it needed to read before
> it read it.
>
> Zeroing the v6 flowinfo overwrites the v4 sin_addr with 0, meaning
> that every place th
From: Daniel Borkmann
> Sent: 27 May 2015 10:34
...
> >> Fixes: 299ee123e198 (sctp: Fixup v4mapped behaviour to comply with Sock
> >> API)
> > ...
> >> This bugfix should be a candidate for -stable
> >
> > Anyone know off-hand which kernel releases are affected?
> > I'm going to have to note this
On 05/27/2015 11:06 AM, David Laight wrote:
From: Jason Gunthorpe
...
Fixes: 299ee123e198 (sctp: Fixup v4mapped behaviour to comply with Sock API)
...
This bugfix should be a candidate for -stable
Anyone know off-hand which kernel releases are affected?
I'm going to have to note this in the
From: Jason Gunthorpe
> Sent: 27 May 2015 00:30
> sctp_v4_map_v6 was subtly writing and reading from members
> of a union in a way the clobbered data it needed to read before
> it read it.
>
> Zeroing the v6 flowinfo overwrites the v4 sin_addr with 0, meaning
> that every place that calls sctp_v4_
On 05/27/2015 01:30 AM, Jason Gunthorpe wrote:
sctp_v4_map_v6 was subtly writing and reading from members
of a union in a way the clobbered data it needed to read before
s/the/that/
it read it.
Zeroing the v6 flowinfo overwrites the v4 sin_addr with 0, meaning
that every place that calls sct
sctp_v4_map_v6 was subtly writing and reading from members
of a union in a way the clobbered data it needed to read before
it read it.
Zeroing the v6 flowinfo overwrites the v4 sin_addr with 0, meaning
that every place that calls sctp_v4_map_v6 gets :::0.0.0.0 as the
result.
Reorder things to
13 matches
Mail list logo