GHSA-5MCX-8CMV-FVGX
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33In 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].
{
"affected": [],
"aliases": [
"CVE-2026-46008"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:18Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/core: fix damos_walk() vs kdamond_fn() exit race\n\nWhen kdamond_fn() main loop is finished, the function cancels remaining\ndamos_walk() request and unset the damon_ctx-\u003ekdamond so that API callers\nand API functions themselves can show the context is terminated. \ndamos_walk() adds the caller\u0027s request to the queue first. After that, it\nshows if the kdamond of the damon_ctx is still running (damon_ctx-\u003ekdamond\nis set). Only if the kdamond is running, damos_walk() starts waiting for\nthe kdamond\u0027s handling of the newly added request.\n\nThe damos_walk() requests registration and damon_ctx-\u003ekdamond unset are\nprotected by different mutexes, though. Hence, damos_walk() could race\nwith damon_ctx-\u003ekdamond unset, and result in deadlocks.\n\nFor example, let\u0027s suppose kdamond successfully finished the damow_walk()\nrequest cancelling. Right after that, damos_walk() is called for the\ncontext. It registers the new request, and shows the context is still\nrunning, because damon_ctx-\u003ekdamond unset is not yet done. Hence the\ndamos_walk() caller starts waiting for the handling of the request. \nHowever, the kdamond is already on the termination steps, so it never\nhandles the new request. As a result, the damos_walk() caller thread\ninfinitely waits.\n\nFix this by introducing another damon_ctx field, namely\nwalk_control_obsolete. It is protected by the\ndamon_ctx-\u003ewalk_control_lock, which protects damos_walk() request\nregistration. Initialize (unset) it in kdamond_fn() before letting\ndamon_start() returns and set it just before the cancelling of the\nremaining damos_walk() request is executed. damos_walk() reads the\nobsolete field under the lock and avoids adding a new request.\n\nAfter this change, only requests that are guaranteed to be handled or\ncancelled are registered. Hence the after-registration DAMON context\ntermination check is no longer needed. Remove it together.\n\nThe issue is found by sashiko [1].",
"id": "GHSA-5mcx-8cmv-fvgx",
"modified": "2026-05-27T15:33:20Z",
"published": "2026-05-27T15:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46008"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ba956a239ba6e3fae8555d3660e22e675be63b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33c3f6c2b48cd84b441dba1ee3e62290e53930f4"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.