CVE-2024-53179
- Source
- https://cve.org/CVERecord?id=CVE-2024-53179
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-53179.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-53179
- Downstream
- Related
- Published
- 2024-12-27T13:49:22.982Z
- Modified
- 2026-03-11T07:46:26.672004Z
- Severity
-
- 7.8 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
- Summary
- smb: client: fix use-after-free of signing key
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free of signing key
Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race:
task A task B cifsmount() dfsmountshare() getsession() cifsmountgetsession() cifssendrecv() cifsgetsmbses() compoundsendrecv() cifssetupsession() smb2setuprequest() kfreesensitive() smb2calcsignature() cryptoshash_setkey() UAF
Fix this by ensuring that we have a valid @ses->authkey.response by checking whether @ses->sesstatus is SESGOOD or SESEXITING with @ses->seslock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2reconnectserver()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->authkey.response), so it's safe to access signing key when @ses->sesstatus == SESEXITING.
- Database specific
{ "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53179.json", "cna_assigner": "Linux" }- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/0e2b654a3848bf9da3b0d54c1ccf3f1b8c635591
- https://git.kernel.org/stable/c/343d7fe6df9e247671440a932b6a73af4fa86d95
- https://git.kernel.org/stable/c/39619c65ab4bbb3e78c818f537687653e112764d
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53179.json
- https://nvd.nist.gov/vuln/detail/CVE-2024-53179