CVE-2026-46330

What it actually does

This is a local Linux kernel flaw in the SMC TCP ULP implementation. The vulnerable code attempts to transform an already-open TCP socket into an SMC socket by modifying kernel VFS objects such as the associated file, dentry, and inode in place. Those objects are expected to remain stable for the lifetime of an open file, so mutating them can violate kernel object-lifetime assumptions and create use-after-free conditions, memory corruption, kernel crashes, and potentially local privilege escalation. The CVSS vector indicates local access with low attack complexity and low privileges, with potential loss of confidentiality, integrity, and availability.

Why it matters to the business

An attacker who already has a local foothold on a Linux system could potentially crash the host or escalate privileges to take full control of it. For multi-user servers, shared compute platforms, container hosts, build systems, developer workstations, and internet-facing services where attackers may first gain low-privileged code execution, this increases the risk that a limited compromise becomes full host compromise. The issue is not currently in CISA KEV, is not reported as ransomware-used, and has low EPSS, but the kernel-level impact warrants timely remediation during normal emergency or high-priority patch cycles.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user on a vulnerable Linux system. They then create or use a TCP socket and exercise the vulnerable TCP ULP path for SMC, causing the kernel to attempt an unsafe in-place conversion of the socket’s backing file/VFS structures. By repeatedly triggering this transition and shaping kernel object allocation and lifetime behavior, the attacker may be able to induce a use-after-free or related memory corruption condition. The most likely visible outcome is a kernel oops, panic, or denial of service; with a reliable exploit, the same primitive could potentially be used to read or modify kernel memory and gain elevated privileges.

How to fix it

Upgrade to a Linux kernel build from the operating system or appliance vendor that removes/reverts the SMC TCP ULP support introduced by commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40. No exact fixed package versions were provided in the input, so rely on vendor advisories for the affected distribution, kernel stream, cloud image, container host image, or embedded platform. Where immediate patching is not possible, consider disabling or blacklisting the SMC kernel module/functionality if it is not required, reducing local shell/code-execution exposure, limiting access to shared systems, enforcing least privilege, and prioritizing patching for multi-tenant, developer, CI/CD, virtualization, and container-host systems. Mitigations should be validated carefully because kernel feature availability and module names vary by distribution and configuration.

How to confirm the fix worked

Confirm the running kernel version and package release are at or above the vendor-fixed level, not merely that updated packages are installed on disk. Verify that the kernel build no longer contains the reverted SMC TCP ULP feature or includes the vendor backport that removes it. On systems where SMC is not needed, confirm the SMC module is not loaded and cannot be auto-loaded if blacklisting is used. In a staging environment, a negative functional test can attempt to select the SMC TCP ULP on a TCP socket and confirm the vulnerable conversion path is unavailable or fails safely. Review kernel logs after validation for any oops, panic, KASAN, refcount, or use-after-free messages related to SMC, TCP ULP, sockets, file, dentry, or inode handling.

Typical attack path

1. Gain local code execution on a vulnerable Linux host as a low-privileged user.
2. Create TCP sockets and invoke the SMC TCP ULP path, for example through the TCP_ULP socket option where the vulnerable feature is present.
3. Trigger the unsafe socket-to-SMC conversion that mutates file, dentry, and inode state for an already-open socket.
4. Attempt to shape kernel memory reuse to turn the resulting use-after-free or corruption into a controlled crash, information leak, or privilege escalation primitive.
5. Use elevated privileges, if obtained, to disable defenses, access sensitive data, install persistence, or move laterally.

How to detect it

There are no public exploit indicators provided and exploitation would occur locally inside the kernel, so detection should focus on forensic evidence of attempted local privilege escalation and kernel instability. Review kernel logs, system journals, crash dumps, audit logs, and EDR telemetry for oops, panic, KASAN, refcount, slab, or use-after-free messages near references to SMC, TCP ULP, sockets, dentry, inode, or file object handling. Correlate crashes with local user sessions, recent process executions, compiler use, temporary exploit-like binaries, repeated socket activity, and sudden privilege changes. On systems with auditd or eBPF-based telemetry, look for unusual local programs making TCP socket option calls associated with TCP_ULP and SMC. If crash dumps are collected, inspect call traces for SMC and TCP ULP paths. Absence of these artifacts does not prove non-exploitation because a successful privilege escalation may leave minimal logs.

• BUG: KASAN: use-after-free
• BUG: unable to handle kernel NULL pointer dereference
• kernel BUG at net/smc
• Oops:
• Kernel panic - not syncing
• general protection fault
• use-after-free
• refcount_t: underflow
• slab-use-after-free
• net/smc
• TCP_ULP
• smc
• setsockopt TCP_ULP smc
• smc_ulp
• d7cd421da9da2cc7b4d25b8537f66db5c8331c40

What your security team should do

• Prioritize patching Linux systems that allow untrusted local users, host containers, run CI/CD workloads, provide SSH or developer access, or expose services where remote code execution could become local code execution.
• Track distribution-specific advisories and fixed kernel package versions because no universal fixed version was provided.
• If SMC is not operationally required, disable or blacklist the SMC kernel module/functionality as a temporary risk reduction measure until patched.
• Hunt for kernel crashes, oopses, KASAN reports, and suspicious local activity around the time of any system instability, especially on shared or externally exposed hosts.
• Ensure reboot orchestration is included in remediation, because kernel package installation alone does not protect systems still running the old kernel.
• Maintain least-privilege controls, EDR coverage, audit logging, and workload isolation to reduce the chance that local code execution can be converted into full host compromise.