From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:37872 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751271AbdBWR7j (ORCPT ); Thu, 23 Feb 2017 12:59:39 -0500 Date: Thu, 23 Feb 2017 18:57:45 +0100 From: Greg KH To: Thomas Deutschmann Cc: "stable@vger.kernel.org" , andreyknvl@google.com, edumazet@google.com, davem@davemloft.net Subject: Re: Please cherry-pick 5edabca9d4cf (CVE-2017-6074) for all stable kernels Message-ID: <20170223175745.GA13067@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Thu, Feb 23, 2017 at 06:35:04PM +0100, Thomas Deutschmann wrote: > Hi, > > haven't seen commit > > > From 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 Mon Sep 17 00:00:00 2001 > > From: Andrey Konovalov > > Date: Thu, 16 Feb 2017 17:22:46 +0100 > > Subject: dccp: fix freeing skb too early for IPV6_RECVPKTINFO > > > > In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet > > is forcibly freed via __kfree_skb in dccp_rcv_state_process if > > dccp_v6_conn_request successfully returns. > > > > However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb > > is saved to ireq->pktopts and the ref count for skb is incremented in > > dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed > > in dccp_rcv_state_process. > > > > Fix by calling consume_skb instead of doing goto discard and therefore > > calling __kfree_skb. > > > > Similar fixes for TCP: > > > > fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed. > > 0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now > > simply consumed > > > > Signed-off-by: Andrey Konovalov > > Acked-by: Eric Dumazet > > Signed-off-by: David S. Miller > > in recent LTS kernel releases (3.2.85, 3.16.40, 4.4.51, 4.9.12...) nor > found any information that this patch is queued. That's because it was released after those kernels were under review :) Also, networking patches for stable trees come from the networking maintainer, you can always check: http://patchwork.ozlabs.org/bundle/davem/stable/?submitter=&state=*&q=&archive= to see what has been marked to be sent for stable kernels. Hope this helps, greg k-h