[Bridge] [patch net/stable v2] br: fix use of ->rx_handler_data in code executed on non-rx_handler path

[Jiri Pirko]

Fri, Dec 06, 2013 at 10:10:28PM CET, stephen at networkplumber.org wrote:
>On Fri, 06 Dec 2013 15:43:21 -0500 (EST)
>David Miller <davem at davemloft.net> wrote:
>
>> From: Jiri Pirko <jiri at resnulli.us>
>> Date: Thu,  5 Dec 2013 16:27:37 +0100
>> 
>> > br_stp_rcv() is reached by non-rx_handler path. That means there is no
>> > guarantee that dev is bridge port and therefore simple NULL check of
>> > ->rx_handler_data is not enough. There is need to check if dev is really
>> > bridge port and since only rcu read lock is held here, do it by checking
>> > ->rx_handler pointer.
>> > 
>> > Note that synchronize_net() in netdev_rx_handler_unregister() ensures
>> > this approach as valid.
>> > 
>> > Introduced originally by:
>> > commit f350a0a87374418635689471606454abc7beaa3a
>> >   "bridge: use rx_handler_data pointer to store net_bridge_port pointer"
>> > 
>> > Fixed but not in the best way by:
>> > commit b5ed54e94d324f17c97852296d61a143f01b227a
>> >   "bridge: fix RCU races with bridge port"
>> > 
>> > Reintroduced by:
>> > commit 716ec052d2280d511e10e90ad54a86f5b5d4dcc2
>> >   "bridge: fix NULL pointer deref of br_port_get_rcu"
>> > 
>> > Please apply to stable trees as well. Thanks.
>> > 
>> > RH bugzilla reference: https://bugzilla.redhat.com/show_bug.cgi?id=1025770
>> > 
>> > Reported-by: Laine Stump <laine at redhat.com>
>> > Debugged-by: Michael S. Tsirkin <mst at redhat.com>
>> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
>> > Signed-off-by: Jiri Pirko <jiri at resnulli.us>
>> > ---
>> > v1->v2: moved br_port_get_check_rcu definition below br_handle_frame definition
>> 
>> Applied and queued up for -stable, thanks Jiri.
>
>How come you ignored my simpler fix, that used the existing logic.
>I don't like introducing this especially into the stable; much prefer
>to go back to testing the flag as was being done before.

Although your patch is technically sane, it depends on rtnl indirectly.
My patch depends on rcu locking and synchronize_rcu which is direct.
Therefore I think it is more appropriate.

Jiri