Skip to main content

Linux Kernel EUVDEUVD-2026-49592

| CVE-2026-64541 CRITICAL
2026-07-27 Linux GHSA-wjv3-3r54-x298
Critical
Disputed · 9.8 Vendor: Linux
Share

Severity by source

Sources disagree (Medium–Critical)
Vendor (Linux) PRIMARY
9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
5.3 MEDIUM

Race condition gives AC:H; requires an active SMC-R connection so PR:L; demonstrated impact is a kernel crash (A:H) with C/I unproven, hence C:N/I:N.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
7.0 HIGH
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Red Hat
5.5 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 30, 2026 - 06:48 vuln.today
CVSS changed
Jul 30, 2026 - 06:37 NVD
9.8 (CRITICAL)
Patch available
Jul 27, 2026 - 21:17 EUVD
CVE Published
Jul 27, 2026 - 20:10 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 27, 2026 - 20:10 cve.org
CRITICAL 9.8

DescriptionCVE.org

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

net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket

smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release.

The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory:

WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set

Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free.

Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.

AnalysisAI

Use-after-free in the Linux kernel's SMC-R (Shared Memory Communications over RDMA) subsystem allows a race between the CDC receive tasklet and socket close to operate on freed memory, enabling a kernel crash and potential memory corruption on hosts using SMC-R. The flaw lives in smc_cdc_rx_handler(), which looks up a connection under conns_lock, releases the lock, and then dereferences the socket via sock_hold() in smc_cdc_msg_recv() without holding a reference across the window. It affects only systems that have SMC-R enabled and active; there is no public exploit identified at time of analysis and EPSS is low (0.18%, 7th percentile).

Technical ContextAI

SMC (Shared Memory Communications) is a Linux TCP-transparent protocol family; the SMC-R variant carries traffic over RoCE/InfiniBand RDMA links, grouping peer connections into link groups. Connection Data Control (CDC) messages synchronize send/receive cursors between peers. The root cause is a classic CWE-416 use-after-free / reference-counting race: the only reference pinning the smc_sock while a connection is discoverable is taken in smc_lgr_register_conn() and dropped in __smc_lgr_unregister_conn(), both under conns_lock. Because smc_cdc_rx_handler() drops conns_lock before dereferencing conn and calling sock_hold(&smc->sk), a concurrent close()→smc_release()→smc_conn_free()→smc_lgr_unregister_conn() can drop the last reference and free the socket, so the later sock_hold() saturates a refcount on freed memory (refcount_warn_saturate, kernel/lib/refcount.c:25). The referenced CPE is the generic cpe:2.3:a:linux:linux, and the fix takes the socket reference while still holding conns_lock. SMC-D is not affected because its rx tasklet is stopped via tasklet_kill() before unregister.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5, or mainline 7.2-rc3 or later - which moves the sock_hold() to occur while conns_lock is still held so the registration reference can no longer be the last one. Apply the corresponding stable commit from git.kernel.org/stable/c/ (e.g. 8de4f665d0febfb92803dece377791a563fc7041) if maintaining a custom tree. If patching cannot be done immediately, the most effective compensating control is to disable SMC-R where it is not required: avoid loading/using the SMC protocol (do not configure SMC-R link groups over RDMA), which fully removes the vulnerable code path at the cost of losing SMC-R acceleration; restricting or isolating the RDMA fabric so only trusted peers share a link group also reduces exposure. Since SMC-D is unaffected, workloads needing SMC acceleration on the same host can rely on SMC-D instead. Refer to the kernel.org stable commits and https://nvd.nist.gov/vuln/detail/CVE-2026-64541 for tracking.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-49592 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy