CVE-2026-74719: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix qentry overwrite for CONFIRMLINK and ADDLINKCONT in smcllceventhandler()
The SMCLLCCONFIRMLINK / SMCLLCADDLINKCONT branch in smcllceventhandler() 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 CONFIRMLINK or ADDLINKCONT request while a flow is active and flow->qentry is already set, smcllcflowqentryset() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message.
The sibling SMCLLCDELETELINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRMLINK/ADDLINKCONT 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 (smcllcrxresponse()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Linux kernel: Ensure the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in net/smc (smc_llc_event_handler()) uses the same guard as SMC_LLC_DELETE_LINK so that when flow->qentry is already occupied, the handler drops the spurious duplicate CONFIRM_LINK or ADD_LINK_CONT request without overwriting the existing allocation and without leaking the previously allocated qentry.
Event History
Frequently Asked Questions
What must an attacker or faulty peer do to trigger the leak?
The peer must send a duplicate CONFIRM_LINK or ADD_LINK_CONT request while the corresponding LLC flow is active and already has a pending qentry. Each such spurious request can cause one kmalloc-96 object to be leaked.
Is the response-processing path also vulnerable to duplicate messages?
No. The smc_llc_rx_response() direction already checks whether flow->qentry is occupied and drops duplicate responses, so the issue is limited to the affected request-handling branch.
What behavior does the fix introduce for duplicate requests?
When a qentry is already pending, duplicate CONFIRM_LINK or ADD_LINK_CONT requests are not installed into the flow. They fall through and the newly received qentry is freed at the handler's out path.