CVE-2022-49822: cifs: Fix connections leak when tlink setup failed
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix connections leak when tlink setup failed
If the tlink setup failed, lost to put the connections, then
the module refcnt leak since the cifsd kthread not exit.
Also leak the fscache info, and for next mount with fsc, it will
print the follow errors:
CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)
Let's check the result of tlink setup, and do some cleanup.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can leak CIFS/SMB client resources when a mount setup fails. Over time, affected systems could retain connections, module references, or cache state, causing operational instability. The sources do not provide a CVSS score or evidence of active exploitation.
Executive priority
Treat this as a targeted reliability and availability issue, not a confirmed emergency. Patch during normal kernel maintenance, but prioritize file-sharing clients or production hosts where CIFS mount failures could accumulate and affect service stability.
Technical view
The flaw is in the Linux CIFS client tlink setup failure path. Failed setup did not release connections, preventing the cifsd kthread from exiting and leaking fscache information. The kernel fix adds cleanup when tlink setup fails.
Likely exposure
Exposure is most relevant to Linux systems using CIFS/SMB client mounts, particularly with fscache. Systems not using the CIFS client are unlikely to be affected. Exact fixed package versions depend on the distribution kernel backport.
Exploitation context
CISA KEV status is false in the provided bundle. The sources do not describe active exploitation, a remote attack path, or public weaponization. Practical risk appears tied to triggering failed CIFS mount setup and resource leakage.
Researcher notes
The source evidence is limited to the CVE record and kernel stable commits. No CVSS, CWE, exploit details, or vendor-specific package matrix is provided. The core behavior is a cleanup omission after failed tlink setup in the CIFS client.
Mitigation direction
Update to a Linux kernel or distribution package containing the referenced stable fixes.
Check distribution advisories for exact fixed kernel builds and backport status.
Prioritize hosts that use CIFS/SMB mounts or fscache-backed CIFS configurations.
Remove or disable unused CIFS/fscache configurations where operationally safe.
Validation and detection
Inventory Linux hosts using CIFS/SMB client mounts.
Check running kernel versions against distribution fixed-build guidance.
Review logs for repeated CIFS mount setup failures or fscache key reuse errors.
Confirm patched kernels include the referenced CIFS cleanup change.
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.
cve · low confidence lookup
CVE-2022-49822 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 1, 2025, 14:09 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.