netdev - RE: [PATCH net 1/2] xfrm6: Fix IPv6 payload_len in xfrm6_transport

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: <AM4PR0501MB22743B34120802DA21BCE59BC4DA0@AM4PR0501MB2274.eurprd05.prod.outlook.com>
Date:   Wed, 21 Jun 2017 11:24:05 +0000
From:   Yossi Kuperman <yossiku@...lanox.com>
To:     Steffen Klassert <steffen.klassert@...unet.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Yevgeny Kliteynik <kliteyn@...lanox.com>,
        Boris Pismenny <borisp@...lanox.com>,
        Ilan Tayari <ilant@...lanox.com>
Subject: RE: [PATCH net 1/2] xfrm6: Fix IPv6 payload_len in
 xfrm6_transport_finish



> -----Original Message-----
> From: Steffen Klassert [mailto:steffen.klassert@...unet.com]
> Sent: Wednesday, June 21, 2017 8:37 AM
> To: Yossi Kuperman <yossiku@...lanox.com>
> Cc: netdev@...r.kernel.org; Herbert Xu <herbert@...dor.apana.org.au>;
> Yevgeny Kliteynik <kliteyn@...lanox.com>; Boris Pismenny
> <borisp@...lanox.com>; Ilan Tayari <ilant@...lanox.com>
> Subject: Re: [PATCH net 1/2] xfrm6: Fix IPv6 payload_len in
> xfrm6_transport_finish
> 
> On Mon, Jun 19, 2017 at 11:33:20AM +0300, yossiku@...lanox.com wrote:
> > From: Yossi Kuperman <yossiku@...lanox.com>
> >
> > IPv6 payload length indicates the size of the payload, including any
> > extension headers. In xfrm6_transport_finish,
> > ipv6_hdr(skb)->payload_len is set to the payload size only, regardless
> > of the presence of any extension headers.
> >
> > After ESP GRO transport mode decapsulation, ipv6_rcv trims the packet
> > according to the wrong payload_len, thus corrupting the packet.
> >
> > Set payload_len to account for extension headers as well.
> >
> > Fixes: 716062fd4c2f ("[IPSEC]: Merge most of the input path")
> > Signed-off-by: Yossi Kuperman <yossiku@...lanox.com>
> > ---
> >  net/ipv6/xfrm6_input.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c index
> > 08a807b..3ef5d91 100644
> > --- a/net/ipv6/xfrm6_input.c
> > +++ b/net/ipv6/xfrm6_input.c
> > @@ -43,8 +43,8 @@ int xfrm6_transport_finish(struct sk_buff *skb, int
> async)
> >  		return 1;
> >  #endif
> >
> > -	ipv6_hdr(skb)->payload_len = htons(skb->len);
> >  	__skb_push(skb, skb->data - skb_network_header(skb));
> > +	ipv6_hdr(skb)->payload_len = htons(skb->len - sizeof(struct
> > +ipv6hdr));
> 
> You mentioned that the bug happens with ESP GRO. Does this bug also
> happen in the standard codepath? If not, you might better move the above
> line into the 'if' section below.
> 

Yes, it happens only with ESP GRO.
Normally, ipv6_rcv happens first which trims the packet correctly and then comes xfrm6_transport_finish.
Now, with ESP GRO introduced, xfrm6_transport_finish, which comes first, modifies the packet's payload_len,
and followed by a call to ipv6_rcv which trims it wrongly.

If I understand you right, you suggest to move the new line under the "if" section and restore the removed line?

> >
> >  	if (xo && (xo->flags & XFRM_GRO)) {
> >  		skb_mac_header_rebuild(skb);
> > --
> > 2.8.1