Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752462AbcKZUet (ORCPT ); Sat, 26 Nov 2016 15:34:49 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:36814 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751123AbcKZUek (ORCPT ); Sat, 26 Nov 2016 15:34:40 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Eric Dumazet Date: Sat, 26 Nov 2016 12:34:38 -0800 Message-ID: Subject: Re: net: GPF in eth_header To: Andrey Konovalov Cc: syzkaller , Dmitry Vyukov , David Miller , Tom Herbert , Alexander Duyck , Hannes Frederic Sowa , Jiri Benc , Sabrina Dubroca , netdev , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1131 Lines: 31 2016-11-26 12:05 GMT-08:00 Eric Dumazet : >> Hi Eric, >> >> The crash happens when the kernel tries to access shadow for nonmapped memory. >> >> The issue here is an integer overflow which happens in neigh_resolve_output(). >> skb_network_offset(skb) can return negative number, but __skb_pull() >> accepts unsigned int as len. >> As a result, the least significat bit in higher 32 bits of skb->data >> gets set and we get an out-of-bounds with offset of 4 GB. >> >> I've attached a short reproducer, but you either need KASAN or to add >> a BUG_ON to see the crash. >> In this reproducer skb_network_offset() becomes negative after merging >> two ipv6 fragments. >> >> I actually see multiple places where skb_network_offset() is used as >> an argument to skb_pull(). >> So I guess every place can potentially be buggy. > > Well, I think the intent is to accept a negative number. > > This definitely was assumed by commit e1f165032c8bade authors ! > > I guess they were using a 32bit kernel for their tests. Correct fix would be to use skb_push(skb, -skb_network_offset(skb)); As done in other locations...