CVE-2026-72242 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()
selinux_sctp_bind_connect() dereferences sk->sk_socket to pass a struct socket * to selinux_socket_bind() and selinux_socket_connect_helper(). However, when the hook is invoked from the ASCONF softirq path (sctp_process_asconf), there is no file reference guaranteeing that sk->sk_socket is non-NULL. The setsockopt callers (bindx, connectx, set_primary, sendmsg connect) hold a file reference and are not affected.
Both selinux_socket_bind() and selinux_socket_connect_helper() immediately resolve sock->sk, never using the struct socket * for anything else. Refactor the inner logic into helpers that take a struct sock * directly so that selinux_sctp_bind_connect() never needs to touch sk->sk_socket at all.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's Security-Enhancement Module (SELinux) implementation specifically affecting the sctp_bind_connect hook functionality. The issue stems from an improper dereference pattern that creates a potential null pointer access condition when processing SCTP (Stream Control Transmission Protocol) connections through the ASCONF softirq path. The vulnerability manifests when the selinux_sctp_bind_connect() function attempts to dereference sk->sk_socket without proper validation of the socket reference, creating a race condition scenario that could lead to system instability or potential privilege escalation.
The technical flaw occurs because selinux_sctp_bind_connect() directly accesses the sk->sk_socket field to pass a struct socket * pointer to subsequent SELinux hook functions selinux_socket_bind() and selinux_socket_connect_helper(). However, when this hook executes from the ASCONF softirq context (sctp_process_asconf), there are no file references ensuring that sk->sk_socket remains non-NULL. This contrasts with regular setsockopt callers such as bindx, connectx, set_primary, sendmsg, and connect which maintain proper file references and remain unaffected by this issue.
The operational impact of this vulnerability extends beyond simple system stability concerns into potential security implications within the kernel's security framework. When the ASCONF softirq path executes, the lack of guarantee for sk->sk_socket validity could result in null pointer dereferences that may trigger kernel oops, system crashes, or potentially provide an attack vector for privilege escalation attacks. The vulnerability specifically affects scenarios involving SCTP asynchronous association updates where the kernel's security module attempts to validate socket operations without proper reference checking.
The mitigation strategy involves refactoring the SELinux implementation to eliminate the problematic socket dereference pattern entirely. The solution requires restructuring the inner logic of the affected functions to accept struct sock directly instead of struct socket , thereby removing the dependency on sk->sk_socket access that creates the vulnerability. This approach aligns with secure coding practices that emphasize avoiding unnecessary dereferences and maintaining proper reference validation before accessing kernel object fields. The fix ensures that selinux_sctp_bind_connect() never needs to touch sk->sk_socket at all, effectively eliminating the race condition while preserving the intended security functionality.
This vulnerability type maps to CWE-476 which describes NULL Pointer Dereference in security contexts, and potentially relates to ATT&CK technique T1068 for local privilege escalation through kernel vulnerabilities. The fix demonstrates proper defensive programming principles that should be applied across kernel security modules to prevent similar race conditions in asynchronous execution paths where reference guarantees may not exist. The solution represents a common pattern for addressing kernel-level concurrency issues in security frameworks where different code paths have varying reference semantics and lifecycle management requirements.