CVE-2022-50555
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-07

Last updated on: 2026-02-05

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: tipc: fix a null-ptr-deref in tipc_topsrv_accept syzbot found a crash in tipc_topsrv_accept: KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipc_rcv tipc_topsrv_accept RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 It was caused by srv->listener that might be set to null by tipc_topsrv_stop() in net .exit whereas it's still used in tipc_topsrv_accept() worker. srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop() where it's waiting until the tipc_topsrv_accept worker to be done. Note that sk_callback_lock is used to protect sk->sk_user_data instead of srv->listener, and it should check srv in tipc_topsrv_listener_data_ready() instead. This also ensures that no more tipc_topsrv_accept worker will be started after tipc_conn_close() is called in tipc_topsrv_stop() where it sets sk->sk_user_data to null.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-07
Last Modified
2026-02-05
Generated
2026-05-07
AI Q&A
2025-10-07
EPSS Evaluated
2026-05-05
NVD
CVE-2022-50555
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.1
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a null pointer dereference in the Linux kernel's TIPC (Transparent Inter-Process Communication) component, specifically in the tipc_topsrv_accept function. It occurs because the srv->listener pointer can be set to null by tipc_topsrv_stop() while tipc_topsrv_accept() is still using it, leading to a crash. The fix involves adding checks under the appropriate locks to ensure srv->listener is not null before use and adjusting the order of socket release to prevent use-after-free conditions.


How can this vulnerability impact me? :

This vulnerability can cause a kernel crash (null pointer dereference) when the affected function is called, potentially leading to denial of service by crashing the system or kernel panic. It may affect system stability and availability.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the fix for the null pointer dereference in tipc_topsrv_accept has been applied. The fix involves adding proper checks for srv->listener under srv->idr_lock in tipc_topsrv_accept and ensuring sock_release() is called after tipc_topsrv_work_stop() to avoid use-after-free conditions. Applying the official kernel patch or upgrading to a fixed kernel version is the recommended immediate step.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart