[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62dad5ad-cafb-7569-b010-cb355f7affc7@bitwise.fi>
Date: Wed, 15 Feb 2017 10:28:57 +0200
From: Anssi Hannula <anssi.hannula@...wise.fi>
To: David Miller <davem@...emloft.net>
Cc: michal.simek@...inx.com, soren.brinkmann@...inx.com,
netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] net: xilinx_emaclite: fix receive buffer overflow
On 14.2.2017 22:12, David Miller wrote:
> From: Anssi Hannula <anssi.hannula@...wise.fi>
> Date: Tue, 14 Feb 2017 19:11:44 +0200
>
>> xilinx_emaclite looks at the received data to try to determine the
>> Ethernet packet length but does not properly clamp it if
>> proto_type == ETH_P_IP or 1500 < proto_type <= 1518, causing a buffer
>> overflow and a panic via skb_panic() as the length exceeds the allocated
>> skb size.
>>
>> Fix those cases.
>>
>> Also add an additional unconditional check with WARN_ON() at the end.
>>
>> Signed-off-by: Anssi Hannula <anssi.hannula@...wise.fi>
>> Fixes: bb81b2ddfa19 ("net: add Xilinx emac lite device driver")
> Why does this driver do all of this crazy stuff parsing the packet
> headers?
>
> It should be able to just read the length provided by the device
> at XEL_RPLR_OFFSET and just use that.
Looks like XEL_RPLR_OFFSET == XEL_HEADER_OFFSET + XEL_RXBUFF_OFFSET and
that is where the driver reads the on-wire Type/Length field.
Looking through the product guide [1] I don't see the actual receive
packet length provided anywhere, so I guess that is why the crazy stuff
is done.
[1]
https://www.xilinx.com/support/documentation/ip_documentation/axi_ethernetlite/v3_0/pg135-axi-ethernetlite.pdf
--
Anssi Hannula / Bitwise Oy
+358503803997
Powered by blists - more mailing lists