CVE-2026-23299 in Linux
Summary
by MITRE • 03/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: purge error queues in socket destructors
When TX timestamping is enabled via SO_TIMESTAMPING, SKBs may be queued into sk_error_queue and will stay there until consumed. If userspace never gets to read the timestamps, or if the controller is removed unexpectedly, these SKBs will leak.
Fix by adding skb_queue_purge() calls for sk_error_queue in affected bluetooth destructors. RFCOMM does not currently use sk_error_queue.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/02/2026
This vulnerability exists within the Linux kernel's Bluetooth implementation where improper handling of socket error queues leads to memory leaks and resource exhaustion. The issue specifically affects Bluetooth socket destructors that manage the sk_error_queue data structure, which serves as a holding area for error messages and timestamping data. When applications enable TX timestamping through the SO_TIMESTAMPING socket option, the kernel places relevant SKBs (socket kernel buffers) into the sk_error_queue for later retrieval. However, the kernel fails to properly clean up these queued SKBs when sockets are destroyed, creating a persistent memory leak that can accumulate over time and eventually impact system stability. The vulnerability demonstrates a classic resource management flaw where temporary data structures are not adequately disposed of during object destruction, leading to gradual memory consumption that can degrade system performance or cause unexpected failures.
The technical flaw stems from the absence of proper cleanup operations in Bluetooth socket destructor functions. When Bluetooth sockets are closed or destroyed, the kernel should ensure all associated data structures are properly freed, including the sk_error_queue that contains pending SKBs. The current implementation lacks calls to skb_queue_purge() which would iterate through and free all SKBs in the error queue before the socket structure is deallocated. This oversight affects multiple Bluetooth protocol layers that utilize the sk_error_queue mechanism, though RFCOMM is noted as not currently using this queue. The vulnerability represents a violation of proper resource lifecycle management principles and can be classified under CWE-404, which addresses improper resource release or unbalanced resource management. The flaw is particularly concerning because it operates at the kernel level where memory leaks can have cascading effects on system stability and performance.
The operational impact of this vulnerability extends beyond simple memory consumption to potentially compromise system reliability and availability. When SKBs accumulate in the sk_error_queue without proper cleanup, they consume kernel memory that could otherwise be utilized for legitimate network operations. This memory leak becomes more pronounced in systems with high Bluetooth activity or when Bluetooth controllers are frequently removed or reconnected. Applications that rely on continuous Bluetooth connectivity may experience degraded performance as system memory becomes fragmented and scarce. In extreme cases, sustained memory leaks can lead to system instability, kernel memory allocation failures, or even complete system crashes. The vulnerability affects any system running the affected Linux kernel version where Bluetooth functionality is enabled, making it particularly relevant for mobile devices, IoT systems, and embedded platforms that depend heavily on Bluetooth connectivity.
Mitigation strategies should focus on implementing the recommended kernel patch that adds skb_queue_purge() calls to the affected Bluetooth destructors. System administrators should prioritize updating to kernel versions that contain this fix, particularly in production environments where Bluetooth connectivity is critical. Additionally, monitoring systems should be implemented to track memory usage patterns and identify potential leak conditions before they cause significant impact. For environments where immediate patching is not feasible, administrators can consider limiting Bluetooth activity or implementing application-level resource management to reduce the likelihood of hitting resource exhaustion limits. The fix aligns with ATT&CK framework techniques related to system resource exhaustion and kernel exploitation, where improper resource management can lead to privilege escalation or denial of service conditions. Organizations should also implement regular vulnerability assessments to identify similar resource management issues across their kernel components and maintain updated security baselines that include proper kernel patch management procedures.