CVE-2022-48865

Updated on 16 Jul 2024

Severity

5.5 Medium severity

Details

CVSS score
5.5
CVSS vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Overview

About vulnerability

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] [ 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.

Details

Affected packages:
linux-hwe @ 4.15.0 (+3 more)

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] [ 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.

Fixes