GHSA-5mcx-8cmv-fvgx · Severity: unknown — In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix...
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix damos_walk() vs kdamond_fn() exit race When kdamond_fn() main loop is finished, the function cancels remaining damos_walk() request and unset the damon_ctx->kdamond so that API callers and API functions themselves can show the context is terminated. damos_walk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damos_walk() starts waiting for the kdamond's handling of the newly added request. The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damos_walk() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damos_walk() caller thread infinitely waits. Fix this by introducing another damon_ctx field, namely walk_control_obsolete. It is protected by the damon_ctx->walk_control_lock, which protects damos_walk() request registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of the remaining damos_walk() request is executed. damos_walk() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. The issue is found by sashiko [1].
Conclusion & alert: CVE-2026-46008 is rated Low Risk (5.3/100): low exploitation likelihood (EPSS 0.02%). Mandatory action: Low composite risk—no urgent action required; patch on your normal maintenance cycle and revisit priority if CVSS or EPSS increases.
Risk is dynamic; we continuously reassess and refresh what is shown on this page as upstream context changes.
EPSS lead: Daily EPSS estimates relative likelihood of exploitation; percentile ranks this CVE among scored vulnerabilities (higher = more severe relative rank).
| # | Date | Old EPSS score | New EPSS score | Delta (New - Old) |
|---|---|---|---|---|
| 1 | 2026-05-28 | — | 0.02% | — |
Full EPSS history (1 record total)
CVSS metrics for this CVE.
No CVSS data in dataset for this CVE.
GHSA-5mcx-8cmv-fvgx · Severity: unknown — In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix...
| vendor | priority | summary | link |
|---|---|---|---|
debian
|
unimportant | CVE-2026-46008 unimportant priority: Debian including 1 source packages (linux), 5 status rows across 5 suites (bookworm, bullseye, forky, sid, trixie): resolved 5. | https://security-tracker.debian.org/tracker/CVE-2026-46008 |
redhat
|
— | — | https://access.redhat.com/security/cve/CVE-2026-46008 |
suse
|
— | — | https://www.suse.com/security/cve/CVE-2026-46008/ |
ubuntu
|
medium | CVE-2026-46008 medium priority: Ubuntu including 158 source packages (linux, linux-allwinner-5.19, …), 1422 status rows across 9 suites (bionic, focal, jammy, noble, questing, resolute, trusty, upstream, xenial): DNE 1024, ignored 169, not-affected 112, released 84, needed 27, pending 6. | https://ubuntu.com/security/CVE-2026-46008 |
| Vendor | Product | Version | Raw CPE |
|---|---|---|---|
| No affected products in dataset. | |||