{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2025-22034 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2025-22034 is a high-severity denial of service vulnerability in Linux kernel, published on 16 Apr 2025. 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-2025-22034 and fix it if it is affected.\n\nWhat it is: CVE-2025-22034 is a high-severity denial of service vulnerability in Linux kernel, published on 16 Apr 2025. 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-2025-22034 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-2025-22034/ (Markdown: https://insights.sbomify.com/CVE-2025-22034/index.md)","id":"CVE-2025-22034","markdown":"https://insights.sbomify.com/CVE-2025-22034/index.md","name":"CVE-2025-22034","record":{"aliases":["BELL-CVE-2025-22034","DEBIAN-CVE-2025-22034","GHSA-4297-r96p-57pp","UBUNTU-CVE-2025-22034"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A flaw in the Linux kernel memory management allows attackers to cause a denial of service by preventing memory migration and offlining when device-exclusive entries are used with hugetlb VMAs.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs\n\nPatch series \"mm: fixes for device-exclusive entries (hmm)\", v2.\n\nDiscussing the PageTail() call in make_device_exclusive_range() with\nWilly, I recently discovered [1] that device-exclusive handling does not\nproperly work with THP, making the hmm-tests selftests fail if THPs are\nenabled on the system.\n\nLooking into more details, I found that hugetlb is not properly fenced,\nand I realized that something that was bugging me for longer -- how\ndevice-exclusive entries interact with mapcounts -- completely breaks\nmigration/swapout/split/hwpoison handling of these folios while they have\ndevice-exclusive PTEs.\n\nThe program below can be used to allocate 1 GiB worth of pages and making\nthem device-exclusive on a kernel with CONFIG_TEST_HMM.\n\nOnce they are device-exclusive, these folios cannot get swapped out\n(proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how much\none forces memory reclaim), and when having a memory block onlined to\nZONE_MOVABLE, trying to offline it will loop forever and complain about\nfailed migration of a page that should be movable.\n\n# echo offline \u003e /sys/devices/system/memory/memory136/state\n# echo online_movable \u003e /sys/devices/system/memory/memory136/state\n# ./hmm-swap \u0026\n... wait until everything is device-exclusive\n# echo offline \u003e /sys/devices/system/memory/memory136/state\n[  285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000\n  index:0x7f20671f7 pfn:0x442b6a\n[  285.196618][T14882] memcg:ffff888179298000\n[  285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate|\n  dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff)\n[  285.201734][T14882] raw: ...\n[  285.204464][T14882] raw: ...\n[  285.207196][T14882] page dumped because: migration failure\n[  285.209072][T14882] page_owner tracks the page as allocated\n[  285.210915][T14882] page last allocated via order 0, migratetype\n  Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO),\n  id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774\n[  285.216765][T14882]  post_alloc_hook+0x197/0x1b0\n[  285.218874][T14882]  get_page_from_freelist+0x76e/0x3280\n[  285.220864][T14882]  __alloc_frozen_pages_noprof+0x38e/0x2740\n[  285.223302][T14882]  alloc_pages_mpol+0x1fc/0x540\n[  285.225130][T14882]  folio_alloc_mpol_noprof+0x36/0x340\n[  285.227222][T14882]  vma_alloc_folio_noprof+0xee/0x1a0\n[  285.229074][T14882]  __handle_mm_fault+0x2b38/0x56a0\n[  285.230822][T14882]  handle_mm_fault+0x368/0x9f0\n...\n\nThis series fixes all issues I found so far.  There is no easy way to fix\nwithout a bigger rework/cleanup.  I have a bunch of cleanups on top (some\nprevious sent, some the result of the discussion in v1) that I will send\nout separately once this landed and I get to it.\n\nI wish we could just use some special present PROT_NONE PTEs instead of\nthese (non-present, non-none) fake-swap entries; but that just results in\nthe same problem we keep having (lack of spare PTE bits), and staring at\nother similar fake-swap entries, that ship has sailed.\n\nWith this series, make_device_exclusive() doesn't actually belong into\nmm/rmap.c anymore, but I'll leave moving that for another day.\n\nI only tested this series with the hmm-tests selftests due to lack of HW,\nso I'd appreciate some testing, especially if the interaction between two\nGPUs wanting a device-exclusive entry works as expected.\n\n\u003cprogram\u003e\n#include \u003cstdio.h\u003e\n#include \u003cfcntl.h\u003e\n#include \u003cstdint.h\u003e\n#include \u003cunistd.h\u003e\n#include \u003cstdlib.h\u003e\n#include \u003cstring.h\u003e\n#include \u003csys/mman.h\u003e\n#include \u003csys/ioctl.h\u003e\n#include \u003clinux/types.h\u003e\n#include \u003clinux/ioctl.h\u003e\n\n#define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, struct hmm_dmirror_cmd)\n\nstruct hmm_dmirror_cmd {\n\t__u64 addr;\n\t__u64 ptr;\n\t__u64 npages;\n\t__u64 cpages;\n\t__u64 faults;\n};\n\nconst size_t size = 1 * 1024 * 1024 * 1024ul;\nconst size_t chunk_size = 2 * 1024 * 1024ul;\n\nint m\n---truncated---","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/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs","id":"CVE-2025-22034","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"denial_of_service","year":"2025"},"n_packages":0,"n_references":4,"next":{"headline":"tracing: Fix use-after-free in print_graph_function_flags during tracer switching","id":"CVE-2025-22035"},"packages":[],"prev":{"headline":"arm64: Don't call NULL in do_compat_alignment_fixup()","id":"CVE-2025-22033"},"products":["Linux"],"published":"2025-04-16","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":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A flaw in the Linux kernel memory management allows attackers to cause a denial of service by preventing memory migration and offlining when device-exclusive entries are used with hugetlb VMAs.","url":"https://insights.sbomify.com/CVE-2025-22034/"}