In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix connection leak
There's a potential leak issue under following execution sequence :
smc_release smc_connect_work
if (sk->sk_state == SMC_INIT)
send_clc_confirim
tcp_abort();
...
sk.sk_state = SMC_ACTIVE
smc_close_active
switch(sk->sk_state) {
...
case SMC_ACTIVE:
smc_close_final()
// then wait peer closed
Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are
still in the tcp send buffer, in which case our connection token cannot
be delivered to the server side, which means that we cannot get a
passive close message at all. Therefore, it is impossible for the to be
disconnected at all.
This patch tries a very simple way to avoid this issue, once the state
has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the
smc connection, considering that the state is SMC_INIT before
tcp_abort(), abandoning the complete disconnection process should not
cause too much problem.
In fact, this problem may exist as long as the CLC CONFIRM message is
not received by the server. Whether a timer should be added after
smc_close_final() needs to be discussed in the future. But even so, this
patch provides a faster release for connection in above case, it should
also be valuable.
Security readout for executives and security teams
Plain-English summary
CVE-2022-48909 is a Linux kernel networking bug in the SMC subsystem that can leave connections stuck instead of closing. The business risk is mainly availability and resource exhaustion, not confirmed data theft or code execution. Public sources do not provide CVSS, CWE, or active exploitation evidence.
Executive priority
Treat as a normal kernel maintenance priority unless SMC is heavily used in critical environments. No public evidence indicates emergency exploitation, but availability-sensitive Linux systems should receive vendor-supported kernel updates promptly.
Technical view
The issue is a race in net/smc between smc_release and smc_connect_work. If tcp_abort discards an unsent CLC CONFIRM while state later becomes SMC_ACTIVE, the peer may never receive the token needed for passive close, leaving the SMC connection unreleased. Kernel stable commits change handling to actively abort in this case.
Likely exposure
Exposure is limited to Linux systems using the kernel SMC networking code. The provided affected-version data is incomplete and should be validated against vendor kernel packages and the listed stable commits. Systems not using affected Linux kernels or SMC paths are less likely to be exposed.
Exploitation context
There is no KEV listing and no cited source claims active exploitation. The described condition depends on a specific connection-state race and lost CLC CONFIRM message. Practical impact appears to be lingering connections and potential resource leakage rather than direct compromise.
Researcher notes
The record lacks CVSS and precise exploitability analysis. The main evidence is the kernel fix narrative and stable commit references. Affected-version metadata in the bundle appears limited, so distribution backport status is essential for accurate exposure decisions.
Mitigation direction
Apply Linux kernel updates that include the referenced stable fixes.
Check distribution vendor advisories for backported fixes and affected package versions.
If patch status is unclear, ask the vendor to confirm CVE-2022-48909 coverage.
Prioritize systems where SMC networking is enabled or business-critical.
Validation and detection
Identify running kernel versions across Linux assets.
Compare vendor package changelogs with CVE-2022-48909 or the listed commit hashes.
Review whether the SMC kernel networking feature is present and used.
Confirm updated systems include the net/smc connection leak fix.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
description · low confidence lookup
Credential and access behavior lookup
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.