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 semantics).
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
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 in the release
From: Jason Gunthorpe jguntho...@obsidianresearch.com
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,
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 299ee.
I
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 it
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 that
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 off
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
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 through 4.0.
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
11 matches
Mail list logo
