linux-kernel - [ 064/102] asix: fix BUG in receive path when lowering MTU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130517213251.116419900@linuxfoundation.org>
Date:	Fri, 17 May 2013 14:36:19 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	linux-kernel@...r.kernel.org
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	stable@...r.kernel.org,
	Holger Eitzenberger <holger@...zenberger.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: [ 064/102] asix: fix BUG in receive path when lowering MTU

3.9-stable review patch.  If anyone has any objections, please let me know.

------------------


From: "holger@...zenberger.org" <holger@...zenberger.org>

[ Upstream commit c5060cec6ba27ad3f0e7facfdf05d2f18e3e3010 ]

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>
Signed-off-by: David S. Miller <davem@...emloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
 drivers/net/usb/asix_common.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -100,6 +100,9 @@ int asix_rx_fixup_internal(struct usbnet
 			netdev_err(dev->net, "asix_rx_fixup() Bad RX Length %d\n",
 				   rx->size);
 			kfree_skb(rx->ax_skb);
+			rx->ax_skb = NULL;
+			rx->size = 0U;
+
 			return 0;
 		}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/