CVE-2026-53274 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS
A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely.
The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held.
Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog.
[ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds.
[ 240.123489] Call Trace:
[ 240.123501] smc_shutdown+...
[ 240.123512] lock_sock_nested+...
This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/25/2026
The vulnerability exists within the Linux kernel's SMC (Socket Memory Channel) subsystem where a critical logic flaw in the __smc_setsockopt() function creates a potential for local denial of service attacks. This issue specifically affects unprivileged users who can exploit the improper handling of socket locks during configuration operations. The flaw stems from the function calling copy_from_sockptr() while maintaining an active lock on the socket structure through lock_sock(sk), creating a scenario where execution can be indefinitely suspended during memory copying operations.
The technical implementation of this vulnerability leverages userfaultfd monitoring capabilities or FUSE-backed memory systems to create memory pages that will cause the kernel to block during the copy operation. When an attacker provides such memory pages as the optval parameter in socket configuration calls, the kernel's execution becomes stalled while attempting to copy data from user space into kernel space. This blocking occurs within the critical section protected by the socket lock, preventing other threads from accessing the same socket structure and creating a deadlock condition.
The operational impact of this vulnerability extends beyond simple service disruption as it can exhaust the kernel workqueue system through asynchronous tear-down operations such as shutdown(). When the socket lock remains indefinitely held during copy operations, the kworkers responsible for handling these cleanup tasks become blocked, leading to resource exhaustion. The hung task watchdog mechanism eventually triggers when kernel threads remain blocked for extended periods, typically exceeding 120 seconds as demonstrated in the system logs showing kworker/u8:2 blocked for more than 120 seconds.
This vulnerability aligns with CWE-667 which addresses improper locking scenarios and represents a classic example of lock contention leading to denial of service conditions. The flaw also connects to ATT&CK technique T1499.004 which covers network disruption through resource exhaustion, though in this case the resource exhaustion occurs at the kernel level rather than network infrastructure. The patch implementation specifically addresses this by moving the user-space memory copying operation outside the lock_sock() critical section, thereby preventing the indefinite hold on socket locks. This remediation follows established security best practices for avoiding blocking operations within critical sections and aligns with the principle of minimizing lock duration to prevent system-wide resource exhaustion.
The vulnerability demonstrates a fundamental design flaw in how kernel subsystems handle user-space memory operations within protected contexts, particularly when dealing with memory monitoring mechanisms that can cause indefinite blocking. The fix represents a standard defensive programming approach where potentially blocking operations are separated from critical sections to maintain system responsiveness and prevent cascading failures that could affect the entire kernel operation. This type of vulnerability highlights the importance of careful lock management in kernel space and the potential for seemingly benign operations to create serious system stability issues when combined with specific memory management features.