Answer in brief
CVE-2024-56640 records a Critical severity (CVSS 9.8) vulnerability in net/smc: fix LGR and link use-after-free issue. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 9.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3b2dec2603d5b06ad3af71c1164ca0b92df3d2a8 <f502a88fdd415647a1f2dc45fac71b9c522a052b || >=3b2dec2603d5b06ad3af71c1164ca0b92df3d2a8 <0cf598548a6c36d90681d53c6b77d52363f2f295 || >=3b2dec2603d5b06ad3af71c1164ca0b92df3d2a8 <673d606683ac70bc074ca6676b938bff18635226 || >=3b2dec2603d5b06ad3af71c1164ca0b92df3d2a8 <6f0ae06a234a78ae137064f2c89135ac078a00eb || >=3b2dec2603d5b06ad3af71c1164ca0b92df3d2a8 <2c7f14ed9c19ec0f149479d1c2842ec1f9bf76d7 | f502a88fdd415647a1f2dc45fac71b9c522a052b, 0cf598548a6c36d90681d53c6b77d52363f2f295, 673d606683ac70bc074ca6676b938bff18635226, 6f0ae06a234a78ae137064f2c89135ac078a00eb, 2c7f14ed9c19ec0f149479d1c2842ec1f9bf76d7 |
| Linux/Linuxgeneric | 4.18 | Not reported |
Published upstream
Dec 27, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix LGR and link use-after-free issue We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 It is caused by repeated release of LGR/link refcnt. One suspect is that smc_conn_free() is called repeatedly because some smc_conn_free() from server listening path are not protected by sock lock. e.g. Calls under socklock | smc_listen_work ------------------------------------------------------- lock_sock(sk) | smc_conn_abort smc_conn_free | \- smc_conn_free \- smcr_link_put | \- smcr_link_put (duplicated) release_sock(sk) So here add sock lock protection in smc_listen_work() path, making it exclusive with other connection operations.
Quoted source text, attributed separately from HOL analysis.