netdev - Re: [PATCH ipsec-next] xfrm: check that cached bundle is still valid

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]

Message-Id: <20170807.142628.1235964040083698243.davem@davemloft.net>
Date:   Mon, 07 Aug 2017 14:26:28 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     fw@...len.de
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH ipsec-next] xfrm: check that cached bundle is still
 valid

From: Florian Westphal <fw@...len.de>
Date: Sun,  6 Aug 2017 10:19:07 +0200

> Quoting Ilan Tayari:
>   1. Set up a host-to-host IPSec tunnel (or transport, doesn't matter)
>   2. Ping over IPSec, or do something to populate the pcpu cache
>   3. Join a MC group, then leave MC group
>   4. Try to ping again using same CPU as before -> traffic
>      doesn't egress the machine at all
> 
> Ilan debugged the problem down to the fact that one of the path dsts
> devices point to lo due to earlier dst_dev_put().
> In this case, dst is marked as DEAD and we cannot reuse the bundle.
> 
> The cache only asserted that the requested policy and that of the cached
> bundle match, but its not enough - also verify the path is still valid.
> 
> Fixes: ec30d78c14a813 ("xfrm: add xdst pcpu cache")
> Reported-by: Ayham Masood <ayhamm@...lanox.com>
> Tested-by: Ilan Tayari <ilant@...lanox.com>
> Signed-off-by: Florian Westphal <fw@...len.de>

Since this regression is from the flow cache removal that went directly
into my tree, I'll apply this directly to net-next as well.

Thanks Florian.