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] [day] [month] [year] [list]
Date:   Fri, 10 Jan 2020 11:37:13 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     dsahern@...nel.org
Cc:     jakub.kicinski@...ronome.com, netdev@...r.kernel.org,
        haegar@...net.de, dsahern@...il.com
Subject: Re: [PATCH net] ipv4: Detect rollover in specific fib table dump

From: David Ahern <dsahern@...nel.org>
Date: Fri, 10 Jan 2020 09:03:58 -0800

> From: David Ahern <dsahern@...il.com>
> 
> Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has
> been added to a table. The looping is caused by the key rolling over from
> FFFFFFFF to 0. When dumping a specific table only, we need a means to detect
> when the table dump is done. The key and count saved to cb args are both 0
> only at the start of the table dump. If key is 0 and count > 0, then we are
> in the rollover case. Detect and return to avoid looping.
> 
> This only affects dumps of a specific table; for dumps of all tables
> (the case prior to the change in the Fixes tag) inet_dump_fib moved
> the entry counter to the next table and reset the cb args used by
> fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back
> to 0 did not cause looping with the dumps.
> 
> Fixes: effe67926624 ("net: Enable kernel side filtering of route dumps")
> Reported-by: Sven-Haegar Koch <haegar@...net.de>
> Signed-off-by: David Ahern <dsahern@...il.com>

Applied, and queued up for -stable, thanks.

Powered by blists - more mailing lists