From: Florian Westphal <fw@strlen.de>
To: Quan Tian <tianquan23@gmail.com>
Cc: netfilter-devel@vger.kernel.org, pablo@netfilter.org,
kadlec@netfilter.org, fw@strlen.de
Subject: Re: [PATCH nf-next] netfilter: nf_tables: support updating userdata for nft_table
Date: Sun, 10 Mar 2024 14:51:03 +0100 [thread overview]
Message-ID: <20240310135103.GB28153@breakpoint.cc> (raw)
In-Reply-To: <20240310130810.54904-1-tianquan23@gmail.com>
Quan Tian <tianquan23@gmail.com> wrote:
> - if (!(trans->ctx.table->flags & __NFT_TABLE_F_UPDATE)) {
> - nft_trans_destroy(trans);
> - break;
> + if (trans->ctx.table->flags & __NFT_TABLE_F_UPDATE) {
> + if (trans->ctx.table->flags & NFT_TABLE_F_DORMANT)
> + nf_tables_table_disable(net, trans->ctx.table);
> + trans->ctx.table->flags &= ~__NFT_TABLE_F_UPDATE;
> }
> - if (trans->ctx.table->flags & NFT_TABLE_F_DORMANT)
> - nf_tables_table_disable(net, trans->ctx.table);
> -
> - trans->ctx.table->flags &= ~__NFT_TABLE_F_UPDATE;
> + kfree(trans->ctx.table->udata);
This kfree() needs to happen in nft_commit_release().
Otherwise netlink dumps (which run without a lock) results in
use-after-free.
Second issue is that ->udata and ->udlen would have to be
updated atomically so that async dump doesn't observe old/new
pointer with a larger udlen.
I suggest a preparation patch that replaces
u16 udlen;
u8 *udata;
in struct nft_table with
struct nlattr *udata;
so its enough to swap() ctx.table->udata with nft_trans_table_udata(),
then kfree() the old udata from nft_commit_release().
At _release time we can be sure no other cpu is referencing the old
udata.
prev parent reply other threads:[~2024-03-10 13:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-10 13:08 [PATCH nf-next] netfilter: nf_tables: support updating userdata for nft_table Quan Tian
2024-03-10 13:51 ` Florian Westphal [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=20240310135103.GB28153@breakpoint.cc \
--to=fw@strlen.de \
--cc=kadlec@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=tianquan23@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).