[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20130503.161245.1218501153413968440.davem@davemloft.net>
Date: Fri, 03 May 2013 16:12:45 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: holger@...zenberger.org
Cc: oliver@...kum.org, netdev@...r.kernel.org
Subject: Re: [patch 1/1] asix: fix BUG in receive path when lowering MTU
From: holger@...zenberger.org
Date: Fri, 03 May 2013 12:02:20 +0200
> There is bug in the receive path of the asix driver at the time a
> packet is received larger than MTU size and DF bit set:
>
> BUG: unable to handle kernel paging request at 0000004000000001
> IP: [<ffffffff8126f65b>] skb_release_head_state+0x2d/0xd2
> ...
> Call Trace:
> <IRQ>
> [<ffffffff8126f86d>] ? skb_release_all+0x9/0x1e
> [<ffffffff8126f8ad>] ? __kfree_skb+0x9/0x6f
> [<ffffffffa00b4200>] ? asix_rx_fixup_internal+0xff/0x1ae [asix]
> [<ffffffffa00fb3dc>] ? usbnet_bh+0x4f/0x226 [usbnet]
> ...
>
> It is easily reproducable by setting an MTU of 512 e. g. and sending
> something like
>
> ping -s 1472 -c 1 -M do $SELF
>
> from another box.
>
> And this is because the rx->ax_skb is freed on error, but rx->ax_skb
> is not reset, and the size is not reset to zero in this case.
>
> And since the skb is added again to the usbnet->done skb queue it is
> accessing already freed memory, resulting in the BUG when freeing a
> 2nd time. I therefore think the value 0x0000004000000001 show in the
> trace is more or less random data.
>
> Signed-off-by: Holger Eitzenberger <holger@...zenberger.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists