CVE-2026-52928

What it actually does

This Linux kernel flaw is an input-validation issue in the AF_UNIX socket implementation. The SIOCATMARK ioctl is intended to report the urgent-data mark for out-of-band data, but AF_UNIX out-of-band handling is only valid for SOCK_STREAM sockets. Before the fix, the kernel could accept SIOCATMARK on AF_UNIX SOCK_DGRAM or SOCK_SEQPACKET sockets and inspect receive-queue state for socket types that should not support that operation. The corrected behavior is to return EOPNOTSUPP for non-stream AF_UNIX sockets before examining the queue. Based on the available description, exploitation is local and requires the ability to create/use Unix-domain sockets and issue ioctls; there is no public evidence of remote exploitation, active exploitation, or ransomware use.

Why it matters to the business

The practical risk is primarily to Linux systems where untrusted local users, sandboxed workloads, containers, or multi-tenant processes can exercise kernel socket interfaces. A successful exploit, if weaponized beyond the described invalid operation, could affect host stability or kernel behavior, potentially disrupting workloads on shared Linux hosts. Current urgency is lower than for internet-facing remote-code-execution issues because EPSS is very low, no exploit maturity is reported, and it is not in the CISA Known Exploited Vulnerabilities catalog; however, kernel flaws should still be remediated through normal patch cycles because local bugs can become useful in chained attacks.

How an attack unfolds

An attacker would need local code execution on a Linux system, such as a shell, compromised application process, container workload, or other ability to run arbitrary code. The attacker creates an AF_UNIX socket using a non-stream type such as SOCK_DGRAM or SOCK_SEQPACKET, arranges socket state as needed, and invokes the SIOCATMARK ioctl against that socket. Vulnerable kernels fail to reject the unsupported operation early and proceed to inspect receive-queue state even though out-of-band data is not supported for that socket type. The fixed kernel rejects the request with EOPNOTSUPP. There is currently no reported public exploit path or named threat actor activity for this CVE, so defenders should treat attempts to exercise SIOCATMARK on AF_UNIX datagram or seqpacket sockets as suspicious primarily when observed in untrusted or post-compromise execution contexts.

How to fix it

Apply vendor-provided Linux kernel updates that include the AF_UNIX fix rejecting SIOCATMARK on non-stream sockets. Because affected product and fixed-version data was not provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel build source. Reboot systems into the patched kernel after installation; merely installing kernel packages is insufficient if the running kernel is still vulnerable. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, tightening container and workload isolation, disabling unnecessary shell access, enforcing least privilege, and monitoring for unusual ioctl activity. There is no general configuration-only mitigation that reliably removes this kernel behavior while preserving normal AF_UNIX socket functionality.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a kernel version or vendor package build that includes the AF_UNIX SIOCATMARK non-stream socket fix. Validate the running kernel after reboot using standard OS inventory commands, package manager queries, and vendor advisories, not just installed-package state. Functional validation can be performed in a controlled test environment by invoking SIOCATMARK on AF_UNIX SOCK_DGRAM and SOCK_SEQPACKET sockets and confirming the operation fails with EOPNOTSUPP or an equivalent unsupported-operation error. Exposure validation should focus on Linux hosts that allow untrusted local users, container workloads, CI jobs, shared compute, or application plugins to execute code.

Typical attack path

1. Gain local code execution on a Linux system through a compromised account, application, container, or other initial access path.
2. Create an AF_UNIX socket using SOCK_DGRAM or SOCK_SEQPACKET rather than SOCK_STREAM.
3. Optionally manipulate socket receive-queue state to reach the vulnerable code path.
4. Invoke ioctl with SIOCATMARK against the non-stream AF_UNIX socket.
5. Attempt to use the resulting incorrect kernel behavior as part of a denial-of-service, sandbox-escape, or privilege-escalation chain if additional exploit primitives are available.

How to detect it

There are no known public exploitation indicators, named threat actors, or ransomware campaigns associated with this issue. Retrospective detection should focus on local execution telemetry rather than network logs, because exploitation requires a local process invoking a kernel ioctl on Unix-domain sockets. Useful sources include Linux auditd logs for ioctl syscalls, eBPF or syscall tracing telemetry, endpoint detection process telemetry, container runtime audit logs, and crash logs such as kernel oops, panic, or warning messages around AF_UNIX, unix_ioctl, sock_ioctl, or SIOCATMARK handling. Search for ioctl command 0x8905, which corresponds to SIOCATMARK, especially when issued by unexpected processes, recently dropped binaries, container workloads, build jobs, scripting runtimes, web service child processes, or processes running from temporary directories. Because SIOCATMARK can be legitimate for stream sockets, higher-fidelity detection requires correlating the ioctl with AF_UNIX SOCK_DGRAM or SOCK_SEQPACKET socket creation and with anomalous process lineage. Also review system instability events, unexplained service restarts, kernel crash dumps, and EDR alerts occurring shortly after suspicious local code execution.

• SIOCATMARK
• 0x8905
• cmd=0x8905
• ioctl cmd=0x8905
• syscall=ioctl a1=8905
• syscall=16 a1=8905
• unix_ioctl
• sock_ioctl
• AF_UNIX SOCK_DGRAM SIOCATMARK
• AF_UNIX SOCK_SEQPACKET SIOCATMARK
• EOPNOTSUPP SIOCATMARK

What your security team should do

• Prioritize patching Linux kernels on shared, multi-user, container-hosting, CI/CD runner, and internet-exposed application servers where local compromise is more likely to be chained with kernel flaws.
• Track vendor kernel advisories and deploy the first fixed kernel available for each supported distribution or appliance image, then reboot into the patched kernel.
• Inventory systems still running older kernels after patch deployment; kernel package installation without reboot should be treated as incomplete remediation.
• For high-risk hosts, enable or review audit/eBPF/syscall telemetry capable of identifying unusual ioctl usage, especially SIOCATMARK against Unix-domain sockets from untrusted processes.
• Do not treat this as an emergency KEV-style remediation item based on current intelligence; EPSS is low, exploit maturity is none, and no ransomware use is reported, but include it in regular kernel maintenance because local kernel bugs can become valuable in exploit chains.