CVE-2022-48865 in Linux
Summary
by MITRE • 07/16/2024
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/29/2024
The vulnerability described in CVE-2022-48865 resides within the Linux kernel's TIPC (Transparent Inter-Process Communication) subsystem, specifically manifesting as a kernel panic during bearer enabling operations. This issue represents a classic race condition scenario where concurrent threads access shared kernel memory structures without proper synchronization, leading to a null pointer dereference that terminates system operation. The TIPC protocol is designed for high-performance communication between nodes in clustered environments, making this vulnerability particularly concerning for distributed systems relying on kernel-level network communication.
The technical flaw occurs in the tipc_mon_prep function where a monitoring structure pointer is dereferenced before the corresponding memory allocation has completed. This race condition manifests when thread 1 executes tipc_enable_bearer() and proceeds to test and set a bit lock before thread 2 can complete the allocation of monitoring data through tipc_mon_create(). The call trace reveals a complex chain of function calls starting from tipc_l2_rcv_msg() processing incoming activate messages, through tipc_rcv() and __tipc_node_link_up(), eventually reaching tipc_link_build_state_msg() and tipc_link_build_proto_msg() before culminating in the null pointer dereference within tipc_mon_prep(). This sequence demonstrates how the kernel's network processing pipeline can be compromised by improper ordering of memory allocation and access operations in concurrent contexts.
The operational impact of this vulnerability extends beyond simple system crashes, as it can cause complete system instability in environments utilizing TIPC networking protocols. When a kernel panic occurs due to this race condition, the entire system becomes unresponsive, requiring manual intervention or reboot to restore functionality. This vulnerability is particularly dangerous in high-availability systems where continuous operation is critical, as it can be triggered by normal network operations during bearer status changes, potentially leading to service disruption or denial of service conditions. The attack surface is broadened by the fact that any system employing TIPC for inter-node communication could be affected, including clustered applications, containerized environments, and embedded systems relying on kernel networking features.
The fix implemented addresses this vulnerability by reordering the sequence of operations to ensure proper memory allocation occurs before enabling the bearer for message processing. This solution aligns with established security practices for concurrent programming and memory management in kernel space, following principles similar to those outlined in CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-476 (NULL Pointer Dereference). The mitigation strategy follows ATT&CK framework concepts related to privilege escalation and system stability compromise, as it prevents an attacker from leveraging this race condition to cause system instability. By allocating monitoring data before enabling bearer operations, the fix ensures proper synchronization between concurrent threads and eliminates the window of vulnerability where null pointer dereference could occur, thereby maintaining system integrity and preventing unauthorized privilege escalation through kernel-level exploitation.