Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
returns QUEUE or STOLEN verdict") fixed incorrect usage of NF_HOOK's
return value by consuming packets in okfn via br_pass_frame_up().
However, this function re-injects packets to the Rx path with skb->dev
set to the bridge device, which breaks kernel's STP, as all STP packets
appear to originate from the bridge device itself.
Instead, if okfn was called for a packet, make bridge's rx_handler
re-inject it to the Rx path by returning RX_HANDLER_PASS. This is
consistent with previous behavior.
Cc: Florian Westphal <fw@strlen.de>
Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
Reviewed-by: Jiri Pirko <redacted>
Signed-off-by: Ido Schimmel <redacted>
---
net/bridge/br_input.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
@@ -287,8 +286,11 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)}/* Deliver packet to local host only */-NF_HOOK(NFPROTO_BRIDGE,NF_BR_LOCAL_IN,dev_net(skb->dev),-NULL,skb,skb->dev,NULL,br_handle_local_finish);+err=NF_HOOK(NFPROTO_BRIDGE,NF_BR_LOCAL_IN,dev_net(skb->dev),+NULL,skb,skb->dev,NULL,+br_handle_local_finish);+if(err==RX_HANDLER_PASS)+returnRX_HANDLER_PASS;returnRX_HANDLER_CONSUMED;}
@@ -287,8 +286,11 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)}/* Deliver packet to local host only */-NF_HOOK(NFPROTO_BRIDGE,NF_BR_LOCAL_IN,dev_net(skb->dev),-NULL,skb,skb->dev,NULL,br_handle_local_finish);+err=NF_HOOK(NFPROTO_BRIDGE,NF_BR_LOCAL_IN,dev_net(skb->dev),+NULL,skb,skb->dev,NULL,+br_handle_local_finish);+if(err==RX_HANDLER_PASS)+returnRX_HANDLER_PASS;returnRX_HANDLER_CONSUMED;
Seems '*pskb = skb' is needed prior returning RX_HANDLER_PASS - there's
a 'skb = skb_share_check()' at beginning of br_handle_frame.
(The *pskb = skb was present prior 8626c56c8279, but gone since there
was no longer an RX_HANDLER_PASS return).
One nit to consider:
The fix relies on the fact that RX_HANDLER_PASS != 0 (otherwise we end up
not knowing whether skb was STOLEN or br_handle_local_finish has
executed, which was the original problem 8626c56c8279 tried to address).
No reason to use the RX_HANDLER_xxx enumeration space as the ret code
of an 'okfn' (br_handle_local_finish in this case).
Some positive value locally defined in br_input.c (and documented in
br_handle_local_finish) would do.
Regards,
Shmulik
@@ -287,8 +286,11 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)}/* Deliver packet to local host only */-NF_HOOK(NFPROTO_BRIDGE,NF_BR_LOCAL_IN,dev_net(skb->dev),-NULL,skb,skb->dev,NULL,br_handle_local_finish);+err=NF_HOOK(NFPROTO_BRIDGE,NF_BR_LOCAL_IN,dev_net(skb->dev),+NULL,skb,skb->dev,NULL,+br_handle_local_finish);+if(err==RX_HANDLER_PASS)+returnRX_HANDLER_PASS;returnRX_HANDLER_CONSUMED;
Seems '*pskb = skb' is needed prior returning RX_HANDLER_PASS - there's
a 'skb = skb_share_check()' at beginning of br_handle_frame.
(The *pskb = skb was present prior 8626c56c8279, but gone since there
was no longer an RX_HANDLER_PASS return).
Right! Will fix that in v2.
One nit to consider:
The fix relies on the fact that RX_HANDLER_PASS != 0 (otherwise we end up
not knowing whether skb was STOLEN or br_handle_local_finish has
executed, which was the original problem 8626c56c8279 tried to address).
No reason to use the RX_HANDLER_xxx enumeration space as the ret code
of an 'okfn' (br_handle_local_finish in this case).
Some positive value locally defined in br_input.c (and documented in
br_handle_local_finish) would do.
Yes, I agree it would be clearer to state that explicitly. Will add that
in v2.
Thanks for reviewing!
Hi Florian,
Fri, Jun 03, 2016 at 12:39:45PM IDT, idosch@mellanox.com wrote:
Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
returns QUEUE or STOLEN verdict") fixed incorrect usage of NF_HOOK's
return value by consuming packets in okfn via br_pass_frame_up().
However, this function re-injects packets to the Rx path with skb->dev
set to the bridge device, which breaks kernel's STP, as all STP packets
appear to originate from the bridge device itself.
Instead, if okfn was called for a packet, make bridge's rx_handler
re-inject it to the Rx path by returning RX_HANDLER_PASS. This is
consistent with previous behavior.
Cc: Florian Westphal <fw@strlen.de>
Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
Reviewed-by: Jiri Pirko <redacted>
Signed-off-by: Ido Schimmel <redacted>
I read your commit more closely and also looked at nf_reinject() and I'm
not sure how the fix should be carried out.
After packet is processed by okfn it should return to the Rx path -
by making bridge's rx_handler return RX_HANDLER_PASS - so that it
could be picked up by the packet handlers.
However, if verdict is NF_QUEUE and packet is later re-injected via
nf_reinject() then this can't happen, as rx_handler already returned
RX_HANDLER_CONSUMED for the packet.
So, my patch is wrong because it doesn't consume the packet in okfn, but
yours consumes it in a way which breaks current packet handlers.
Any suggestions regarding a fix? I have a feeling I'm missing something
obvious.
Thanks!