Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751482AbdDBLva (ORCPT ); Sun, 2 Apr 2017 07:51:30 -0400 Received: from nuclearcat.com ([144.76.183.226]:59268 "EHLO nuclearcat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdDBLv3 (ORCPT ); Sun, 2 Apr 2017 07:51:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 02 Apr 2017 14:51:25 +0300 From: Denys Fedoryshchenko To: Florian Westphal Cc: Eric Dumazet , Linux Kernel Network Developers , Pablo Neira Ayuso , Patrick McHardy , Jozsef Kadlecsik , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-kernel@vger.kernel.org Subject: Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8 In-Reply-To: <20170402114545.GA31804@breakpoint.cc> References: <6c6e2f7505f969d8c2998efff24063ba@nuclearcat.com> <1491132259.10124.3.camel@edumazet-glaptop3.roam.corp.google.com> <20170402114545.GA31804@breakpoint.cc> Message-ID: 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: 1303 Lines: 32 On 2017-04-02 14:45, 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. It seems some non-standard(or corrupted) packets are passing, because even on ~1G server it might cause corruption once per several days, KASAN seems need less time to trigger. I am not aware how things working, but: [25181.875696] Memory state around the buggy address: [25181.875919] ffff8802975fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [25181.876275] ffff880297600000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [25181.876628] >ffff880297600080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [25181.876984] ^ [25181.877203] ffff880297600100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [25181.877569] ffff880297600180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Why all data here is zero? I guess it should be some packet data?