| Name | CVE-2022-48865 | 
| Description | 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. | 
| Source | CVE (at NVD; CERT, ENISA, LWN, oss-sec, fulldisc, Debian ELTS, Red Hat, Ubuntu, Gentoo, SUSE bugzilla/CVE, GitHub advisories/code/issues, web search, more) | 
The table below lists information on source packages.
The information below is based on the following data on fixed versions.