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 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.