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] [day] [month] [year] [list]
Message-ID: <AM5PR0401MB2561E88A34915612B2BCFD4C96E40@AM5PR0401MB2561.eurprd04.prod.outlook.com>
Date:   Tue, 30 Jan 2018 16:31:13 +0000
From:   Claudiu Manoil <claudiu.manoil@....com>
To:     "aspencer@...cex.com" <aspencer@...cex.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>
Subject: RE: [PATCH net] gianfar: prevent integer wrapping in the rx handler

>-----Original Message-----
>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
>On Behalf Of David Miller
>Sent: Monday, January 29, 2018 9:18 PM
>To: aspencer@...cex.com
>Cc: netdev@...r.kernel.org; claudiu.manoil@...escale.com
>Subject: Re: [PATCH net] gianfar: prevent integer wrapping in the rx handler
>
>From: Andy Spencer <aspencer@...cex.com>
>Date: Thu, 25 Jan 2018 19:37:50 -0800
>
>> When the frame check sequence (FCS) is split across the last two frames
>> of a fragmented packet, part of the FCS gets counted twice, once when
>> subtracting the FCS, and again when subtracting the previously received
>> data.
>>
>> For example, if 1602 bytes are received, and the first fragment contains
>> the first 1600 bytes (including the first two bytes of the FCS), and the
>> second fragment contains the last two bytes of the FCS:
>>
>>   'skb->len == 1600' from the first fragment
>>
>>   size  = lstatus & BD_LENGTH_MASK; # 1602
>>   size -= ETH_FCS_LEN;              # 1598
>>   size -= skb->len;                 # -2
>>
>> Since the size is unsigned, it wraps around and causes a BUG later in
>> the packet handling, as shown below:
>>
>>   kernel BUG at ./include/linux/skbuff.h:2068!
>>   Oops: Exception in kernel mode, sig: 5 [#1]
>>   ...
>>   NIP [c021ec60] skb_pull+0x24/0x44
>>   LR [c01e2fbc] gfar_clean_rx_ring+0x498/0x690
>>   Call Trace:
>>   [df7edeb0] [c01e2c1c] gfar_clean_rx_ring+0xf8/0x690 (unreliable)
>>   [df7edf20] [c01e33a8] gfar_poll_rx_sq+0x3c/0x9c
>>   [df7edf40] [c023352c] net_rx_action+0x21c/0x274
>>   [df7edf90] [c0329000] __do_softirq+0xd8/0x240
>>   [df7edff0] [c000c108] call_do_irq+0x24/0x3c
>>   [c0597e90] [c00041dc] do_IRQ+0x64/0xc4
>>   [c0597eb0] [c000d920] ret_from_except+0x0/0x18
>>   --- interrupt: 501 at arch_cpu_idle+0x24/0x5c
>>
>> Change the size to a signed integer and then trim off any part of the
>> FCS that was received prior to the last fragment.
>>
>> Fixes: 6c389fc931bc ("gianfar: fix size of scatter-gathered frames")
>> Signed-off-by: Andy Spencer <aspencer@...cex.com>
>
>Applied.

Good catch, thanks.
The fix is not pretty, but I don't see another way around this since this hardware
is not able to remove the FCS from the Rx frame.

Thanks,
Claudiu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ