[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB408FE@AcuExch.aculab.com>
Date: Wed, 27 May 2015 09:06:54 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Jason Gunthorpe' <jgunthorpe@...idianresearch.com>,
Neil Horman <nhorman@...driver.com>,
Daniel Borkmann <dborkman@...hat.com>
CC: "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
Vlad Yasevich <vyasevich@...il.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH] sctp: Fix mangled IPv4 addresses on a IPv6 listening
socket
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_map_v6 gets ::ffff:0.0.0.0 as the
> result.
>
> Reorder things to guarantee correct behaviour no matter what the
> union layout is.
>
> This impacts user space clients that open an IPv6 SCTP socket and
> receive IPv4 connections. Prior to 299ee user space would see a
> sockaddr with AF_INET and a correct address, after 299ee the sockaddr
> is AF_INET6, but the address is wrong.
>
> 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 notes for one of our products.
David
--
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