netdev - Re: [PATCH net] net: rfs: fix crash in get_rps

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] [day] [month] [year] [list]

Date:	Sun, 26 Apr 2015 16:09:10 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org, tom@...bertland.com, ben@...adent.org.uk
Subject: Re: [PATCH net] net: rfs: fix crash in get_rps_cpus()

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Sat, 25 Apr 2015 09:35:24 -0700

> From: Eric Dumazet <edumazet@...gle.com>
> 
> Commit 567e4b79731c ("net: rfs: add hash collision detection") had one
> mistake :
> 
> RPS_NO_CPU is no longer the marker for invalid cpu in set_rps_cpu()
> and get_rps_cpu(), as @next_cpu was the result of an AND with
> rps_cpu_mask
> 
> This bug showed up on a host with 72 cpus :
> next_cpu was 0x7f, and the code was trying to access percpu data of an
> non existent cpu.
> 
> In a follow up patch, we might get rid of compares against nr_cpu_ids,
> if we init the tables with 0. This is silly to test for a very unlikely
> condition that exists only shortly after table initialization, as
> we got rid of rps_reset_sock_flow() and similar functions that were
> writing this RPS_NO_CPU magic value at flow dismantle : When table is
> old enough, it never contains this value anymore.
> 
> Fixes: 567e4b79731c ("net: rfs: add hash collision detection")
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: Tom Herbert <tom@...bertland.com>
> Cc: Ben Hutchings <ben@...adent.org.uk>

Applied and queued up for 4.0-stable, thanks Eric.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html