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.
