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]
Date:   Mon, 9 Jan 2017 07:58:02 +0000
From:   Hayes Wang <hayeswang@...ltek.com>
To:     Ansis Atteka <aatteka@...ira.com>
CC:     David Miller <davem@...emloft.net>,
        "mlord@...ox.com" <mlord@...ox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        nic_swsd <nic_swsd@...ltek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Ansis Atteka <aatteka@....org>
Subject: RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Ansis Atteka [mailto:aatteka@...ira.com]
> Sent: Tuesday, January 03, 2017 8:41 AM
[...]
> Hayes, in your iperf reproduction environment did you
> 1) connect sender and receiver directly with an Ethernet cable?
> 2) use iperf's TCP mode instead of UDP mode, because I believe that
> with UDP mode packets are more likely to be sparsely distributed?
> Also, this bug is way easier to reproduce when IP fragmentation kicks
> in because IP fragments are typically sent out very close to each
> other.
> 3) were you plugging your USB Ethernet dongle in USB 3.0 port or
> whatever Mark was using? It seems that each USB mode has different
> coalesce parameters and yours might have work "out of box"?

Yes. I connect them directly and use iperf's TCP mode. However,
I test the RTL8152 which only support USB 2.0. Therefore, I don't
think it occurs with different coalesce parameters.

> While I would not call this a proper fix, because it simply reduces
> coalescing timeouts by order of 10X and most likely does not eliminate
> security aspects of the bug, it at least made my system functionally
> stable and I don't see either of those two bugs in my setup anymore:

Do you try commit a59e6d815226 ("r8152: correct the rx early size"),
or you have used it?

Best Regards,
Hayes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ