tipc: fix kernel panic when enabling bearer

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix kernel panic when enabling bearer

When enabling a bearer on a node, a kernel panic is observed:

[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]

...

[ 4.520030] Call Trace:

[ 4.520689] <IRQ>

[ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc]

[ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc]

[ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc]

[ 4.525292] tipc_rcv+0x5da/0x730 [tipc]

[ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0

[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc]

[ 4.528737] __netif_receive_skb_list_core+0x20b/0x260

[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0

[ 4.531450] ? dev_gro_receive+0x4c2/0x680

[ 4.532512] napi_complete_done+0x6f/0x180

[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]

...

The node in question is receiving activate messages in another

thread after changing bearer status to allow message sending/

receiving in current thread:

thread 1 | thread 2

-------- | --------

|

tipc_enable_bearer() |

test_and_set_bit_lock() |

tipc_bearer_xmit_skb() |

| tipc_l2_rcv_msg()

| tipc_rcv()

| __tipc_node_link_up()

| tipc_link_build_state_msg()

| tipc_link_build_proto_msg()

| tipc_mon_prep()

| {

| ...

| // null-pointer dereference

| u16 gen = mon->dom_gen;

| ...

| }

// Not being executed yet |

tipc_mon_create() |

{ |

... |

// allocate |

mon = kzalloc(); |

... |

} |

Monitoring pointer in thread 2 is dereferenced before monitoring data

is allocated in thread 1. This causes kernel panic.

This commit fixes it by allocating the monitoring data before enabling

the bearer to receive messages.