Race Condition Affecting kernel-zfcpdump-devel package, versions *
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL8-KERNELZFCPDUMPDEVEL-7506583
- published 17 Jul 2024
- disclosed 16 Jul 2024
Introduced: 16 Jul 2024
CVE-2022-48865 Open this link in a new tabHow to fix?
There is no fixed version for RHEL:8
kernel-zfcpdump-devel
.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-devel
package and not the kernel-zfcpdump-devel
package as distributed by RHEL
.
See How to fix?
for RHEL:8
relevant fixed versions and status.
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.
References
- https://access.redhat.com/security/cve/CVE-2022-48865
- https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5
- https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3
- https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94
- https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71