bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict
authorFlorian Westphal <fw@strlen.de>
Sat, 12 Mar 2016 10:14:42 +0000 (11:14 +0100)
committerDavid S. Miller <davem@davemloft.net>
Mon, 14 Mar 2016 19:46:41 +0000 (15:46 -0400)
commit8626c56c8279b88b91b8df55345cdf89542d5e90
treef9a237a3a6fa51ab1a68d1f91584ad1eaf1071f7
parent180a2c542ce904e256ba0d8732517d7f42b3f3fa
bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict

Zefir Kurtisi reported kernel panic with an openwrt specific patch.
However, it turns out that mainline has a similar bug waiting to happen.

Once NF_HOOK() returns the skb is in undefined state and must not be
used.   Moreover, the okfn must consume the skb to support async
processing (NF_QUEUE).

Current okfn in this spot doesn't consume it and caller assumes that
NF_HOOK return value tells us if skb was freed or not, but thats wrong.

It "works" because no in-tree user registers a NFPROTO_BRIDGE hook at
LOCAL_IN that returns STOLEN or NF_QUEUE verdicts.

Once we add NF_QUEUE support for nftables bridge this will break --
NF_QUEUE holds the skb for async processing, caller will erronoulsy
return RX_HANDLER_PASS and on reinject netfilter will access free'd skb.

Fix this by pushing skb up the stack in the okfn instead.

NB: It also seems dubious to use LOCAL_IN while bypassing PRE_ROUTING
completely in this case but this is how its been forever so it seems
preferable to not change this.

Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Tested-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/bridge/br_input.c