CVE-2022-50676 in Linux
Summary
by MITRE • 12/09/2025
In the Linux kernel, the following vulnerability has been resolved:
net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()
syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], for
commit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in rds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a section protected by lock_sock() without realizing that rds_send_xmit() might call lock_sock().
We don't need to protect cancel_delayed_work_sync() using lock_sock(), for even if rds_{send,recv}_worker() re-queued this work while __flush_work()
from cancel_delayed_work_sync() was waiting for this work to complete, retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UP
bit.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/29/2026
The vulnerability CVE-2022-50676 represents a critical locking issue within the Linux kernel's Reliable Datagram Sockets (RDS) implementation, specifically affecting the TCP transport layer. This flaw manifests as a potential deadlock condition that occurs during the execution of the rds_tcp_reset_callbacks() function, which is part of the RDS networking subsystem designed to provide high-performance communication between nodes. The issue stems from improper handling of kernel locking mechanisms during work cancellation operations, creating a scenario where the system can become unresponsive due to circular lock dependencies.
The technical root cause of this vulnerability lies in the improper synchronization between the socket lock and work queue operations within the RDS TCP implementation. When the commit ac3615e7f3cffe2a introduced code duplication reduction by adding cancel_delayed_work_sync() into a section protected by lock_sock(), it inadvertently created a deadlock scenario. The problem occurs because rds_send_xmit() function may also call lock_sock() while the cancel_delayed_work_sync() operation is in progress, resulting in a circular dependency where each function waits for the other to release locks. This lockdep warning indicates a violation of proper locking hierarchy that can lead to system hangs and denial of service conditions, as documented in the kernel's locking subsystem.
The operational impact of this vulnerability extends beyond simple system instability to potentially compromise network service availability and system responsiveness. When the deadlock occurs, network operations that depend on the RDS TCP transport layer can become blocked indefinitely, affecting applications that rely on reliable datagram communication between systems. The vulnerability is particularly concerning because it operates at the kernel level, meaning that exploitation can lead to complete system unresponsiveness without requiring privileged access. The reported behavior shows that even if work re-queueing occurs during the cancellation process, the system remains vulnerable due to the improper lock ordering, as the RDS_CONN_UP bit check prevents re-execution of worker functions but does not resolve the underlying locking conflict.
Mitigation strategies for this vulnerability require careful attention to kernel version management and patch application, as the fix involves modifying the locking behavior in the RDS subsystem to eliminate the circular dependency. System administrators should prioritize updating to kernel versions that contain the patched implementation, which removes the unnecessary lock_sock() protection around cancel_delayed_work_sync() calls. The solution aligns with best practices for kernel lock management and follows the principles outlined in CWE-667, which addresses improper locking conditions in software systems. Additionally, monitoring for lockdep warnings and implementing proper system resource management can help identify potential lock contention issues before they escalate into system-wide failures. Organizations should also consider implementing network segmentation and redundancy measures to minimize the impact of such kernel-level vulnerabilities on mission-critical network services, as recommended by ATT&CK framework's approach to kernel-mode exploitation techniques.