Eric Dumazet <edumazet@xxxxxxxxxx> wrote: > On Wed, Sep 4, 2024 at 2:25 PM Jiawei Ye <jiawei.ye@xxxxxxxxxxx> wrote: > > > > In the `nf_tproxy_laddr4` function, both the `__in_dev_get_rcu()` call > > and the `in_dev_for_each_ifa_rcu()` macro are used to access > > RCU-protected data structures. Previously, these accesses were not > > enclosed within an RCU read-side critical section, which violates RCU > > usage rules and can lead to race conditions, data inconsistencies, and > > memory corruption issues. > > > > This possible bug was identified using a static analysis tool developed > > by myself, specifically designed to detect RCU-related issues. > > > > To address this, `rcu_read_lock()` and `rcu_read_unlock()` are added > > around the RCU-protected operations in the `nf_tproxy_laddr4` function by > > acquiring the RCU read lock before calling `__in_dev_get_rcu()` and > > iterating with `in_dev_for_each_ifa_rcu()`. This change prevents > > potential RCU issues and adheres to proper RCU usage patterns. > > Please share with us the complete stack trace where you think rcu is not held, > because your static tool is unknown to us. > > nf_tproxy_get_sock_v4() would have a similar issue. Right, all netfilter hooks assume rcu read lock is held. See nf_hook()/nf_hook_slow().
