From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Cc: fw@strlen.de, will@kernel.org, stranche@codeaurora.org,
netfilter-devel@vger.kernel.org, tglx@linutronix.de,
peterz@infradead.org, lkp@intel.com
Subject: Re: [PATCH nf v2] netfilter: x_tables: Switch synchronization to RCU
Date: Tue, 8 Dec 2020 12:57:56 +0100 [thread overview]
Message-ID: <20201208115756.GA3328@salvia> (raw)
In-Reply-To: <1606328842-22747-1-git-send-email-subashab@codeaurora.org>
On Wed, Nov 25, 2020 at 11:27:22AM -0700, Subash Abhinov Kasiviswanathan wrote:
> When running concurrent iptables rules replacement with data, the per CPU
> sequence count is checked after the assignment of the new information.
> The sequence count is used to synchronize with the packet path without the
> use of any explicit locking. If there are any packets in the packet path using
> the table information, the sequence count is incremented to an odd value and
> is incremented to an even after the packet process completion.
>
> The new table value assignment is followed by a write memory barrier so every
> CPU should see the latest value. If the packet path has started with the old
> table information, the sequence counter will be odd and the iptables
> replacement will wait till the sequence count is even prior to freeing the
> old table info.
>
> However, this assumes that the new table information assignment and the memory
> barrier is actually executed prior to the counter check in the replacement
> thread. If CPU decides to execute the assignment later as there is no user of
> the table information prior to the sequence check, the packet path in another
> CPU may use the old table information. The replacement thread would then free
> the table information under it leading to a use after free in the packet
> processing context-
>
> Unable to handle kernel NULL pointer dereference at virtual
> address 000000000000008e
> pc : ip6t_do_table+0x5d0/0x89c
> lr : ip6t_do_table+0x5b8/0x89c
> ip6t_do_table+0x5d0/0x89c
> ip6table_filter_hook+0x24/0x30
> nf_hook_slow+0x84/0x120
> ip6_input+0x74/0xe0
> ip6_rcv_finish+0x7c/0x128
> ipv6_rcv+0xac/0xe4
> __netif_receive_skb+0x84/0x17c
> process_backlog+0x15c/0x1b8
> napi_poll+0x88/0x284
> net_rx_action+0xbc/0x23c
> __do_softirq+0x20c/0x48c
>
> This could be fixed by forcing instruction order after the new table
> information assignment or by switching to RCU for the synchronization.
Applied, thanks.
prev parent reply other threads:[~2020-12-08 11:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 18:27 [PATCH nf v2] netfilter: x_tables: Switch synchronization to RCU Subash Abhinov Kasiviswanathan
2020-12-08 11:57 ` Pablo Neira Ayuso [this message]
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=20201208115756.GA3328@salvia \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=lkp@intel.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=stranche@codeaurora.org \
--cc=subashab@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).