CVE-2023-54195
Unknown Unknown - Not Provided
Null Pointer Dereference in Linux rxrpc Call Timeout Handling

Publication date: 2025-12-30

Last updated on: 2025-12-30

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix timeout of a call that hasn't yet been granted a channel afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may get stalled in the background waiting for a connection to become available); it then calls rxrpc_kernel_set_max_life() to set the timeouts - but that starts the call timer so the call timer might then expire before we get a connection assigned - leading to the following oops if the call stalled: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701 RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157 ... Call Trace: <TASK> rxrpc_send_ACK+0x50/0x13b rxrpc_input_call_event+0x16a/0x67d rxrpc_io_thread+0x1b6/0x45f ? _raw_spin_unlock_irqrestore+0x1f/0x35 ? rxrpc_input_packet+0x519/0x519 kthread+0xe7/0xef ? kthread_complete_and_exit+0x1b/0x1b ret_from_fork+0x22/0x30 Fix this by noting the timeouts in struct rxrpc_call when the call is created. The timer will be started when the first packet is transmitted. It shouldn't be possible to trigger this directly from userspace through AF_RXRPC as sendmsg() will return EBUSY if the call is in the waiting-for-conn state if it dropped out of the wait due to a signal.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-30
Last Modified
2025-12-30
Generated
2026-05-07
AI Q&A
2025-12-30
EPSS Evaluated
2026-05-05
NVD
CVE-2023-54195
EUVD
EUVD-2023-60446
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.3.0-rc7
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's rxrpc subsystem involves a timing issue where a call's timeout timer starts before a communication channel is assigned. Specifically, the call timer may expire before a connection is established, leading to a kernel NULL pointer dereference (a crash). The issue occurs because the timeout is set too early, and the fix delays starting the timer until the first packet is transmitted, preventing the crash.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to crash due to a NULL pointer dereference when an rxrpc call times out prematurely. This could lead to system instability or denial of service conditions on affected systems.


What immediate steps should I take to mitigate this vulnerability?

Apply the patch or update to a Linux kernel version that includes the fix for this vulnerability, which ensures the call timer starts only when the first packet is transmitted, preventing the kernel NULL pointer dereference. Avoid triggering the vulnerable state from userspace as sendmsg() will return EBUSY if the call is waiting for a connection and interrupted by a signal.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring the Linux kernel logs for the specific NULL pointer dereference oops related to rxrpc calls. Look for kernel messages containing 'BUG: kernel NULL pointer dereference' and call traces involving rxrpc_alloc_txbuf, rxrpc_send_ACK, and rxrpc_input_call_event. You can use the following command to check the kernel log for such messages: sudo dmesg | grep -i 'rxrpc' | grep -i 'NULL pointer dereference' Additionally, monitoring for kernel crashes or oops messages related to rxrpc in system logs (e.g., /var/log/kern.log or journalctl) can help detect this issue.


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