From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752068AbcKZUFU (ORCPT ); Sat, 26 Nov 2016 15:05:20 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:35846 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbcKZUFK (ORCPT ); Sat, 26 Nov 2016 15:05:10 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Eric Dumazet Date: Sat, 26 Nov 2016 12:05:08 -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 > 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.