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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 3 Dec 2018 10:22:56 +0530
From:   Harini Katakam <harinik@...inx.com>
To:     anssi.hannula@...wise.fi
Cc:     Nicolas Ferre <nicolas.ferre@...rochip.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 2/3] net: macb: fix dropped RX frames due to a race

Hi Anssi,
On Fri, Nov 30, 2018 at 11:53 PM Anssi Hannula <anssi.hannula@...wise.fi> wrote:
>
> Bit RX_USED set to 0 in the address field allows the controller to write
> data to the receive buffer descriptor.
>
> The driver does not ensure the ctrl field is ready (cleared) when the
> controller sees the RX_USED=0 written by the driver. The ctrl field might
> only be cleared after the controller has already updated it according to
> a newly received frame, causing the frame to be discarded in gem_rx() due
> to unexpected ctrl field contents.
>
> A message is logged when the above scenario occurs:
>
>   macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor
>
> Fix the issue by ensuring that when the controller sees RX_USED=0 the
> ctrl field is already cleared.
>
> This issue was observed on a ZynqMP based system.
>

Thanks for the patch.
Could you please describe the test in which this behavior was observed?
Were you able to confirm that this was because of the ctrl field being
cleared late? This error can also be observed under stress when RX UBR
is observed.
I understand it makes sense to clear ctrl field before setting RX used bit.
But I'm trying to understand if a dmb is necessary in the receive data path.

Regards,
Harini

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ