{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2026-46025 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-46025 is a medium-severity vulnerability in Linux kernel, published on 27 May 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-46025 and fix it if it is affected.\n\nWhat it is: CVE-2026-46025 is a medium-severity vulnerability in Linux kernel, published on 27 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-46025 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-46025/ (Markdown: https://insights.sbomify.com/CVE-2026-46025/index.md)","id":"CVE-2026-46025","markdown":"https://insights.sbomify.com/CVE-2026-46025/index.md","name":"CVE-2026-46025","record":{"aliases":["BELL-CVE-2026-46025","DEBIAN-CVE-2026-46025","GHSA-rhpm-rxf4-q3hf","UBUNTU-CVE-2026-46025"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel DAMON subsystem can cause deadlocks or memory leaks when concurrent operations race with kdamond termination.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":4.7,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-362","name":"Concurrent Execution using Shared Resource with Improper Synchronization"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/core: fix damon_call() vs kdamond_fn() exit race\n\nPatch series \"mm/damon/core: fix damon_call()/damos_walk() vs kdmond exit\nrace\".\n\ndamon_call() and damos_walk() can leak memory and/or deadlock when they\nrace with kdamond terminations.  Fix those.\n\nThis patch (of 2);\n\nWhen kdamond_fn() main loop is finished, the function cancels all\nremaining damon_call() requests and unset the damon_ctx-\u003ekdamond so that\nAPI callers and API functions themselves can know the context is\nterminated.  damon_call() adds the caller's request to the queue first. \nAfter that, it shows if the kdamond of the damon_ctx is still running\n(damon_ctx-\u003ekdamond is set).  Only if the kdamond is running, damon_call()\nstarts waiting for the kdamond's handling of the newly added request.\n\nThe damon_call() requests registration and damon_ctx-\u003ekdamond unset are\nprotected by different mutexes, though.  Hence, damon_call() could race\nwith damon_ctx-\u003ekdamond unset, and result in deadlocks.\n\nFor example, let's suppose kdamond successfully finished the damon_call()\nrequests cancelling.  Right after that, damon_call() 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\ndamon_call() 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 damon_call() caller threads\ninfinitely waits.\n\nFix this by introducing another damon_ctx field, namely\ncall_controls_obsolete.  It is protected by the\ndamon_ctx-\u003ecall_controls_lock, which protects damon_call() requests\nregistration.  Initialize (unset) it in kdamond_fn() before letting\ndamon_start() returns and set it just before the cancelling of remaining\ndamon_call() requests is executed.  damon_call() reads the obsolete field\nunder 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\nNote that the deadlock will not happen when damon_call() is called for\nrepeat mode request.  In tis case, damon_call() returns instead of waiting\nfor the handling when the request registration succeeds and it shows the\nkdamond is running.  However, if the request also has dealloc_on_cancel,\nthe request memory would be leaked.\n\nThe issue is found by sashiko [1].","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"mm/damon/core: fix damon_call() vs kdamond_fn() exit race","id":"CVE-2026-46025","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"race_condition","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"net: qrtr: ns: Limit the maximum number of lookups","id":"CVE-2026-46026"},"packages":[],"prev":{"headline":"libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()","id":"CVE-2026-46024"},"products":["Linux"],"published":"2026-05-27","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-06-14","vendors":["Linux"]},"summary":"A race condition in the Linux kernel DAMON subsystem can cause deadlocks or memory leaks when concurrent operations race with kdamond termination.","url":"https://insights.sbomify.com/CVE-2026-46025/"}