CVE-2026-46104: selinux: use sk blob accessor in socket permission helpers
In the Linux kernel, the following vulnerability has been resolved:
selinux: use sk blob accessor in socket permission helpers
SELinux socket state lives in the composite LSM socket blob.
sock_has_perm() and nlmsg_sock_has_extended_perms() currently
dereference sk->sk_security directly, which assumes the SELinux socket
blob is at offset zero.
In stacked configurations that assumption does not hold. If another LSM
allocates socket blob storage before SELinux, these helpers may read the
wrong blob and feed invalid SID and class values into AVC checks.
Use selinux_sock() instead of accessing sk->sk_security directly.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw affects SELinux permission checks for sockets when multiple Linux Security Modules are stacked. SELinux may read another module's socket security data, causing invalid security identifiers and classes to be checked. The source bundle does not describe business impact, privilege requirements, or confirmed exploitation.
Executive priority
Track as an operational kernel correctness issue until vendor severity is available. Prioritize patch planning for hardened Linux environments using SELinux and multiple LSMs, but do not treat it as actively exploited based on current evidence.
Technical view
sock_has_perm() and nlmsg_sock_has_extended_perms() directly dereference sk->sk_security, assuming SELinux socket data is at offset zero. In stacked LSM configurations, another LSM may allocate socket blob storage first. The fix replaces direct access with selinux_sock(), the proper SELinux socket blob accessor.
Likely exposure
Exposure is likely limited to Linux systems using SELinux with stacked LSM configurations where SELinux is not first in socket blob layout. The bundle lists Linux kernel versions as affected but lacks distribution-specific package mappings.
Exploitation context
No active exploitation is supported by the provided sources. KEV is false, and the references are kernel stable commits. The bundle does not provide exploitability details, attack prerequisites, or observed abuse.
Researcher notes
The key condition is incorrect direct access to sk->sk_security in SELinux socket permission helpers. The security consequence is not fully characterized in the bundle; analysis should focus on stacked LSM blob layout and whether invalid SID/class AVC checks can cause bypass or denial.
Mitigation direction
Apply a Linux kernel update containing the referenced stable fixes.
Check your distribution's security advisory for backported kernel packages.
Prioritize systems using SELinux with stacked LSM configurations.
Avoid assuming version strings alone; confirm vendor backport status.
Validation and detection
Inventory Linux kernel versions across SELinux-enabled systems.
Identify hosts using stacked Linux Security Module configurations.
Confirm kernels include one of the referenced stable commits or vendor backports.
Review SELinux AVC behavior after patching for unexpected policy regressions.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46104 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 28, 2026, 09:35 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.