netfilter: nf_tables: fix base chain stat rcu_dereference usage
authorFlorian Westphal <fw@strlen.de>
Tue, 30 Apr 2019 12:33:22 +0000 (14:33 +0200)
committerPablo Neira Ayuso <pablo@netfilter.org>
Sun, 5 May 2019 22:36:29 +0000 (00:36 +0200)
commitedbd82c5fba009f68d20b5db585be1e667c605f6
tree7b5d5f9218ae196268c61c2484e0fbaaedfcac64
parentf5e85ce8e733c2547827f6268136b70b802eabdb
netfilter: nf_tables: fix base chain stat rcu_dereference usage

Following splat gets triggered when nfnetlink monitor is running while
xtables-nft selftests are running:

net/netfilter/nf_tables_api.c:1272 suspicious rcu_dereference_check() usage!
other info that might help us debug this:

1 lock held by xtables-nft-mul/27006:
 #0: 00000000e0f85be9 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1a/0x50
Call Trace:
 nf_tables_fill_chain_info.isra.45+0x6cc/0x6e0
 nf_tables_chain_notify+0xf8/0x1a0
 nf_tables_commit+0x165c/0x1740

nf_tables_fill_chain_info() can be called both from dumps (rcu read locked)
or from the transaction path if a userspace process subscribed to nftables
notifications.

In the 'table dump' case, rcu_access_pointer() cannot be used: We do not
hold transaction mutex so the pointer can be NULLed right after the check.
Just unconditionally fetch the value, then have the helper return
immediately if its NULL.

In the notification case we don't hold the rcu read lock, but updates are
prevented due to transaction mutex. Use rcu_dereference_check() to make lockdep
aware of this.

Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
net/netfilter/nf_tables_api.c