CVE-2026-72447 in Linuxinfo

Summary

by MITRE • 08/15/2026

In the Linux kernel, the following vulnerability has been resolved:

sctp: hold socket lock when dumping endpoints in sctp_diag

SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace.

Fix this by:

- Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking

Also:

- Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and
its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused
cb->args[5] for sctp_sock_dump().

Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks.

This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 08/15/2026

The vulnerability identified in the Linux kernel's SCTP implementation stems from improper synchronization during diagnostic endpoint dumping operations, specifically within the sctp_diag functionality. This flaw represents a race condition that occurs when traversing SCTP endpoint address lists without adequate locking mechanisms, creating potential security implications for systems utilizing SCTP protocol support. The issue manifests when the diagnostic interface attempts to enumerate endpoint addresses while concurrent socket operations may modify these lists, leading to inconsistent state representation during data retrieval.

Technical exploitation of this vulnerability involves a specific race condition where nla_reserve() function counts addresses under RCU protection but subsequent memory copying operations may observe fewer entries than initially counted. This discrepancy can result in uninitialized memory being exposed to userspace applications, creating potential information disclosure risks and possible exploitation vectors for privilege escalation attacks. The flaw directly relates to improper locking practices during concurrent access scenarios, where socket operations modify endpoint lists while diagnostic routines attempt to traverse them without appropriate synchronization.

The operational impact of this vulnerability extends beyond simple information leakage to potentially enable more sophisticated attack patterns against network services utilizing SCTP protocol. Systems running affected kernel versions may expose sensitive memory contents through diagnostic interfaces, which could be leveraged by attackers to gain insights into kernel memory layout or extract confidential data from network connections. The race condition particularly affects environments where SCTP endpoints undergo frequent modifications through bindx operations or other concurrent socket management activities.

The fix implementation addresses the core synchronization issues by introducing proper reference counting mechanisms during hash traversal and reworking the endpoint iteration logic to support restart-based traversal with explicit position tracking. The solution involves moving socket locking operations outside read_lock_bh() contexts, implementing serialization for address list access during dump operations, and adding WARN_ON_ONCE() checks for inconsistent address count scenarios. Additionally, the patch ensures proper handling of LISTEN state filtering, skips endpoints being freed, and removes reliance on deprecated callback argument structures while maintaining backward compatibility.

This vulnerability aligns with common software security weaknesses categorized under CWE-362: Concurrent Execution using Shared Resource with Unprotected Synchronization, and represents a classic example of race condition exploitation in kernel space. The mitigation strategy follows established best practices for concurrent programming in kernel environments, ensuring that shared data structures are properly protected during access operations. The solution also addresses ATT&CK technique T1059.006: Command and Scripting Interpreter: Python, by preventing potential information disclosure that could aid in crafting more sophisticated attacks against system components.

The fix maintains operational efficiency through restart-based traversal mechanisms that accommodate small bucket sizes while ensuring sleeping-safe callback operations remain functional. This approach balances security requirements with performance considerations, as the multiple bucket rescanning is deemed acceptable due to the limited size of hash buckets and the necessity for safe memory access patterns during diagnostic operations. The implementation also includes proper cleanup of unused callback argument references, improving code maintainability while eliminating potential future vulnerabilities related to stale data handling.

The vulnerability was identified through coordinated disclosure efforts involving security researchers from TrendAI Zero Day Initiative, demonstrating the importance of collaborative security research in identifying and resolving kernel-level flaws that could impact large-scale network infrastructure. This resolution exemplifies proper vulnerability management practices where security researchers work directly with vendors to develop and implement appropriate fixes for critical system components, ensuring that network protocols remain secure against exploitation while maintaining their intended functionality and performance characteristics.

Responsible

Linux

Reservation

08/09/2026

Disclosure

08/15/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!