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: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.

• CWE-476

• https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5Patch
• https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3Patch
• https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94Patch
• https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71Patch
• https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5Patch
• https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3Patch
• https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94Patch
• https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71Patch

Published

Jul 16, 2024

Last Modified

Jun 17, 2026

Status

Modified

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2022-4886Ingress-nginx `path` sanitization can be bypassed with `log_…6.5
• CVE-2022-48860In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2022-48861In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2022-48862In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2022-48863In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2022-48864In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2022-48866In the Linux kernel, the following vulnerability has been re…7.1
• CVE-2022-48867In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2022-48868In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2022-48869In the Linux kernel, the following vulnerability has been re…4.7
• CVE-2022-48870In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2022-48871In the Linux kernel, the following vulnerability has been re…7.1