netdev - Re: [PATCH 1/2] encx24j600: bugfix - always move ERXTAIL to next packet in encx24j600_rx

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:   Fri, 16 Dec 2016 13:32:08 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     jeroen.de_wachter.ext@...ia.com
Cc:     jringle@...dpoint.com, akpm@...ux-foundation.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] encx24j600: bugfix - always move ERXTAIL to next
 packet in encx24j600_rx_packets

From: <jeroen.de_wachter.ext@...ia.com>
Date: Mon, 12 Dec 2016 14:29:08 +0100

> From: Jeroen De Wachter <jeroen.de_wachter.ext@...ia.com>
> 
> Before, encx24j600_rx_packets did not update encx24j600_priv's next_packet
> member when an error occurred during packet handling (either because the
> packet's RSV header indicates an error or because the encx24j600_receive_packet
> method can't allocate an sk_buff).
> 
> If the next_packet member is not updated, the ERXTAIL register will be set to
> the same value it had before, which means the bad packet remains in the
> component's memory and its RSV header will be read again when a new packet
> arrives. If the RSV header indicates a bad packet or if sk_buff allocation
> continues to fail, new packets will be stored in the component's memory until
> that memory is full, after which packets will be dropped.
> 
> The SETPKTDEC command is always executed though, so the encx24j600 hardware has
> an incorrect count of the packets in its memory.
> 
> To prevent this, the next_packet member should always be updated, allowing the
> packet to be skipped (either because it's bad, as indicated in its RSV header,
> or because allocating an sk_buff failed). In the allocation failure case, this
> does mean dropping a valid packet, but dropping the oldest packet to keep as
> much memory as possible available for new packets seems preferable to keeping
> old (but valid) packets around while dropping new ones.
> 
> Signed-off-by: Jeroen De Wachter <jeroen.de_wachter.ext@...ia.com>

Applied.