From: Florian Westphal <fw@strlen.de>
To: Eric Dumazet <edumazet@google.com>
Cc: Jiawei Ye <jiawei.ye@foxmail.com>,
pablo@netfilter.org, kadlec@netfilter.org, davem@davemloft.net,
dsahern@kernel.org, kuba@kernel.org, pabeni@redhat.com,
fw@strlen.de, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] netfilter: tproxy: Add RCU protection in nf_tproxy_laddr4
Date: Wed, 4 Sep 2024 14:48:40 +0200 [thread overview]
Message-ID: <20240904124840.GA15053@breakpoint.cc> (raw)
In-Reply-To: <CANn89iLQuBYht_jMx7WwtbDP-PTnhBvNu2FWW1uGnKkcqnvT+w@mail.gmail.com>
Eric Dumazet <edumazet@google.com> wrote:
> On Wed, Sep 4, 2024 at 2:25 PM Jiawei Ye <jiawei.ye@foxmail.com> 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().
next prev parent reply other threads:[~2024-09-04 12:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 12:18 [PATCH] netfilter: tproxy: Add RCU protection in nf_tproxy_laddr4 Jiawei Ye
2024-09-04 12:32 ` Eric Dumazet
2024-09-04 12:48 ` Florian Westphal [this message]
2024-09-05 11:53 ` kernel test robot
2024-09-05 15:41 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240904124840.GA15053@breakpoint.cc \
--to=fw@strlen.de \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=jiawei.ye@foxmail.com \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.