linux-kernel - Re: [PATCH 1/2] net/netfilter/nf_conntrack

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:   Wed, 7 Jul 2021 01:06:41 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Manfred Spraul <manfred@...orfullife.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        netfilter-devel@...r.kernel.org,
        Davidlohr Bueso <dave@...olabs.net>,
        "Paul E . McKenney" <paulmck@...nel.org>, 1vier1@....de
Subject: Re: [PATCH 1/2] net/netfilter/nf_conntrack_core: Mark access for
 KCSAN

On Sun, Jun 27, 2021 at 06:19:18PM +0200, Manfred Spraul wrote:
> KCSAN detected an data race with ipc/sem.c that is intentional.
> 
> As nf_conntrack_lock() uses the same algorithm: Update
> nf_conntrack_core as well:
> 
> nf_conntrack_lock() contains
>   a1) spin_lock()
>   a2) smp_load_acquire(nf_conntrack_locks_all).
> 
> a1) actually accesses one lock from an array of locks.
> 
> nf_conntrack_locks_all() contains
>   b1) nf_conntrack_locks_all=true (normal write)
>   b2) spin_lock()
>   b3) spin_unlock()
> 
> b2 and b3 are done for every lock.
> 
> This guarantees that nf_conntrack_locks_all() prevents any
> concurrent nf_conntrack_lock() owners:
> If a thread past a1), then b2) will block until that thread releases
> the lock.
> If the threat is before a1, then b3)+a1) ensure the write b1) is
> visible, thus a2) is guaranteed to see the updated value.
> 
> But: This is only the latest time when b1) becomes visible.
> It may also happen that b1) is visible an undefined amount of time
> before the b3). And thus KCSAN will notice a data race.
> 
> In addition, the compiler might be too clever.
> 
> Solution: Use WRITE_ONCE().

Applied, thanks.