Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751396AbdDBMZL (ORCPT ); Sun, 2 Apr 2017 08:25:11 -0400 Received: from nuclearcat.com ([144.76.183.226]:60976 "EHLO nuclearcat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750912AbdDBMZK (ORCPT ); Sun, 2 Apr 2017 08:25:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 02 Apr 2017 15:25:06 +0300 From: Denys Fedoryshchenko To: Eric Dumazet Cc: Florian Westphal , Linux Kernel Network Developers , Pablo Neira Ayuso , Patrick McHardy , Jozsef Kadlecsik , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-kernel@vger.kernel.org, netdev-owner@vger.kernel.org Subject: Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8 In-Reply-To: <1491135593.10124.9.camel@edumazet-glaptop3.roam.corp.google.com> References: <6c6e2f7505f969d8c2998efff24063ba@nuclearcat.com> <1491132259.10124.3.camel@edumazet-glaptop3.roam.corp.google.com> <20170402114545.GA31804@breakpoint.cc> <1491134084.10124.6.camel@edumazet-glaptop3.roam.corp.google.com> <1491135593.10124.9.camel@edumazet-glaptop3.roam.corp.google.com> Message-ID: <4442718191e17f0ff91bf1359da6d631@nuclearcat.com> User-Agent: Roundcube Webmail/1.2.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1641 Lines: 43 On 2017-04-02 15:19, Eric Dumazet wrote: > On Sun, 2017-04-02 at 04:54 -0700, Eric Dumazet wrote: >> On Sun, 2017-04-02 at 13:45 +0200, Florian Westphal wrote: >> > Eric Dumazet wrote: >> > > - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { >> > > + for (i = sizeof(struct tcphdr); i < tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { >> > > if (opt[i] == TCPOPT_MSS && opt[i+1] == TCPOLEN_MSS) { >> > > u_int16_t oldmss; >> > >> > maybe I am low on caffeeine but this looks fine, for tcp header with >> > only tcpmss this boils down to "20 <= 24 - 4" so we acccess offsets 20-23 which seems ok. >> >> I am definitely low on caffeine ;) >> >> An issue in this function is that we might add the missing MSS option, >> without checking that TCP options are already full. >> >> But this should not cause a KASAN splat, only some malformed TCP >> packet >> >> (tcph->doff would wrap) > > Something like that maybe. > > diff --git a/net/netfilter/xt_TCPMSS.c b/net/netfilter/xt_TCPMSS.c > index > 27241a767f17b4b27d24095a31e5e9a2d3e29ce4..1465aaf0e3a15d69d105d0a50b0429b11b6439d3 > 100644 > --- a/net/netfilter/xt_TCPMSS.c > +++ b/net/netfilter/xt_TCPMSS.c > @@ -151,7 +151,9 @@ tcpmss_mangle_packet(struct sk_buff *skb, > */ > if (len > tcp_hdrlen) > return 0; > - > + /* tcph->doff is 4 bits wide, do not wrap its value to 0 */ > + if (tcp_hdrlen >= 15 * 4) > + return 0; > /* > * MSS Option not found ?! add it.. > */ I will add also WARN_ON_ONCE(tcp_hdrlen >= 15 * 4) before, for curiosity, if this condition are triggered. Is it fine like that?