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]
Message-Id: <20161216.133208.2134512725082545132.davem@davemloft.net>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ