[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <KL1P15301MB02800FAB6F40F03FD4349E0ABF720@KL1P15301MB0280.APCP153.PROD.OUTLOOK.COM>
Date: Mon, 27 Jul 2020 18:38:39 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: Greg KH <greg@...ah.com>
CC: Al Viro <viro@...iv.linux.org.uk>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
'Eric Dumazet' <edumazet@...gle.com>,
'Willy Tarreau' <w@....eu>,
Joseph Salisbury <Joseph.Salisbury@...rosoft.com>,
Michael Kelley <mikelley@...rosoft.com>
Subject: RE: UDP data corruption in v4.4
> From: Greg KH <greg@...ah.com>
> Sent: Friday, July 24, 2020 10:59 PM
> > [...]
> > Eric Dumazet made an alternative that performs the csum validation earlier:
> >
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -1589,8 +1589,7 @@ int udp_queue_rcv_skb(struct sock *sk, struct
> > sk_buff *skb)
> > }
> > }
> >
> > - if (rcu_access_pointer(sk->sk_filter) &&
> > - udp_lib_checksum_complete(skb))
> > + if (udp_lib_checksum_complete(skb))
> > goto csum_error;
> >
> > if (sk_rcvqueues_full(sk, sk->sk_rcvbuf)) {
> >
> > I personally like Eric's fix and IMHO we'd better have it in v4.4 rather than
> > trying to backport 327868212381.
>
> Does Eric's fix work with your testing?
Yes, it worked in my testing overnight.
> If so, great, can you turn it
> into something I can apply to the 4.4.y stable tree and send it to
> stable@...r.kernel.org?
>
> greg k-h
Will do shortly.
Thanks,
Dexuan
Powered by blists - more mailing lists