Re: nft_rbtree_lookup: BUG: unable to handle kernel NULL pointer dereference

[Florian Westphal <fw@strlen.de>]

Anders K. Pedersen <akp@akp.dk> wrote:
> Hello,
> 
> While doing some tests with nftables, I've run into the the following
> bug, which is easily reproducable:
> 
> [ 1409.721487] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> [ 1409.730512] IP: [<ffffffff81495de9>] nft_rbtree_lookup+0xa9/0x150
> [ 1409.737525] PGD 0
> [ 1409.739841] Oops: 0000 [#1] SMP
> [ 1409.743445] Modules linked in:
> [ 1409.746966] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0 #1
> [ 1409.753660] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 2.1.6 05/19/2016
> [ 1409.762253] task: ffffffff8180b500 ti: ffffffff81800000 task.ti: ffffffff81800000
> [ 1409.770846] RIP: 0010:[<ffffffff81495de9>]  [<ffffffff81495de9>] nft_rbtree_lookup+0xa9/0x150
> [ 1409.780651] RSP: 0018:ffff88085f2039c8  EFLAGS: 00010202
> [ 1409.786745] RAX: ffff88083dc76f80 RBX: ffff88083dc76fa4 RCX: 0000000000000002
> [ 1409.794937] RDX: 0000000000000004 RSI: ffff88083dc76de0 RDI: ffff88083dc76fa4
> [ 1409.803130] RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88085f203aa0
> [ 1409.811323] R10: ffff88083dc699e2 R11: ffff88085803d000 R12: ffff88085ae2f700
> [ 1409.819517] R13: ffff88083dc76f80 R14: ffff88085f203aa0 R15: 0000000000000000
> [ 1409.827710] FS:  0000000000000000(0000) GS:ffff88085f200000(0000) knlGS:0000000000000000
> [ 1409.837006] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1409.843594] CR2: 0000000000000010 CR3: 0000000001806000 CR4: 00000000001406f0
> [ 1409.851788] Stack:
> [ 1409.854095]  ffffffff00000002 ffff8800785b0100 0000000000000000 ffff88085f203a20
> [ 1409.862641]  ffff88085ae2f700 ffff880855e16428 ffff88085f203a90 0000000000000002
> [ 1409.871184]  00000000ffffffff ffff880855e16428 ffffffff81493a4e ffff880859d699d8
> [ 1409.879736] Call Trace:
> [ 1409.882539]  <IRQ>
> [ 1409.884751]  [<ffffffff81493a4e>] ? nft_lookup_eval+0x2e/0x80
[..]

> I have narrowed the rule set in use down to:
> 
> table ip filter {
>         set bogons {
>                 type ipv4_addr
>                 flags interval
>         }
> 
>         chain prerouting {
>                 type filter hook prerouting priority -300; policy accept;
>                 iif lo accept
>                 ip daddr @bogons ip daddr != 224.0.0.0/4 log prefix "Bogon" group 0 snaplen 80 counter packets 0 bytes 0 drop
>                 ip saddr @bogons log prefix "Bogon" group 0 snaplen 80 counter packets 0 bytes 0 drop
>         }
> }
> 
> With the following shell code, the box will crash quite quickly (within
> seconds) during the "nft delete element" part:
> 
> I=1
> while : ; do
> 	echo -n "${I} add"
> 	nft add element ip filter bogons { 0.0.0.0/8 }
> 	echo -n " delete"
> 	nft delete element ip filter bogons { 0.0.0.0/8 }
> 	echo
> 	I=$[${I}+1]
> done

Perfect.  Thanks for this detailed bug report!

When the 'goto found' path is taken then 'parent' has already been set in
previous loop and might be NULL.

diff --git a/net/netfilter/nft_rbtree.c b/net/netfilter/nft_rbtree.c
--- a/net/netfilter/nft_rbtree.c
+++ b/net/netfilter/nft_rbtree.c
@@ -72,6 +72,8 @@ static bool nft_rbtree_lookup(const struct net *net, const struct nft_set *set,
 		else {
 found:
 			if (!nft_set_elem_active(&rbe->ext, genmask)) {
+				if (parent == NULL)
+					goto out;
 				parent = parent->rb_left;
 				continue;
 			}
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html