CVE-2022-48865

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:tipcmonprep+0x4e/0x130 [tipc] ... [ 4.520030] Call Trace: [ 4.520689] <IRQ> [ 4.521236] tipclinkbuildprotomsg+0x375/0x750 [tipc] [ 4.522654] tipclinkbuildstatemsg+0x48/0xc0 [tipc] [ 4.524034] _tipcnodelinkup+0xd7/0x290 [tipc] [ 4.525292] tipcrcv+0x5da/0x730 [tipc] [ 4.526346] ? _netifreceiveskbcore+0xb7/0xfc0 [ 4.527601] tipcl2rcvmsg+0x5e/0x90 [tipc] [ 4.528737] _netifreceiveskblistcore+0x20b/0x260 [ 4.530068] netifreceiveskblistinternal+0x1bf/0x2e0 [ 4.531450] ? devgroreceive+0x4c2/0x680 [ 4.532512] napicompletedone+0x6f/0x180 [ 4.533570] virtnetpoll+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
     --------           |              --------
                        |

tipcenablebearer() | testandsetbitlock() | tipcbearerxmitskb() | | tipcl2rcvmsg() | tipcrcv() | _tipcnodelinkup() | tipclinkbuildstatemsg() | tipclinkbuildprotomsg() | tipcmonprep() | { | ... | // null-pointer dereference | u16 gen = mon->domgen; | ... | } // Not being executed yet | tipcmoncreate() | { | ... | // 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.