HIGH Introduced in 5.8
smc Qentry Leak
CVE-2026-74719
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
01Description
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.
02KernelScan AI Analysis
Risk summary
A malicious SMC peer can send duplicate CONFIRM_LINK or ADD_LINK_CONT LLC messages to leak kernel memory (one kmalloc-96 object per message) on the receiving host. Repeated exploitation can exhaust kernel memory and cause system-wide denial of service. Any system with SMC enabled and a network-reachable TCP service that negotiates SMC is at risk.
Vulnerability analysis
When the SMC link-control handler receives certain link-setup messages while a local flow is already active, it stores the incoming message into a pending slot without checking whether a previous message already occupies that slot. A malicious or buggy peer can send a second such message, causing the handler to overwrite the existing reference and leak the previously allocated kernel memory object. Each spurious message leaks one small kernel allocation, and an attacker can repeat this indefinitely to drive the system toward memory exhaustion. The fix adds a guard that refuses to overwrite an already-occupied slot, so duplicate messages are discarded and freed instead of silently leaking. The vulnerability is reachable by any network peer that can establish an SMC connection to the target, which requires the target kernel to have SMC support enabled and RDMA-capable hardware configured.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 5.8 | 5.10.265 | e384f3cba6ea |
| 5.15 | 5.8 | 5.15.216 | a1e980d7a9e7 |
| 6.1 | 5.8 | 6.1.183 | e0eb87677c76 |
| 6.12 | 5.8 | 6.12.104 | c23c40922862 |
| 6.18 | 5.8 | 6.18.45 | 10cb31b2b74c |
| 6.6 | 5.8 | 6.6.152 | 06734dfeaeba |
| 7.1 | 5.8 | 7.1.9 | bfc336a9fbbf |
| mainline | 5.8 | 7.2 | 976245094925 |
| cip/5.10 | 5.8 | 5.10.268-cip77 | e384f3cba6ea |
| cip/5.10-rt | 5.8 | 5.10.268-cip77-rt34 | e384f3cba6ea |
| cip/6.1 | 5.8 | 6.1.187-cip60 | e0eb87677c76 |
| cip/6.1-rt | 5.8 | 6.1.189-cip61-rt32 | e0eb87677c76 |
| cip/6.12 | 5.8 | 6.12.104-cip30 | c23c40922862 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.104-cip30 |
| cip/6.1 | Fixed in 6.1.187-cip60 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.268-cip77 |
| cip/5.10-rt | Fixed in 5.10.268-cip77-rt34 |