{"api_version":"1","generated_at":"2026-10-22T12:26:39+00:00","cve":"CVE-2026-98507","urls":{"html":"https://cve.report/CVE-2026-98507","api":"https://cve.report/api/cve/CVE-2026-98507.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-98507","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-98507"},"summary":{"title":"mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish\n\nOn arm64 server, we find that a task trying to grab the anon_vma lock\ntriggers hungtask.\n\nINFO: task main:2354726 blocked for more than 120 seconds.\n      Tainted: G            E     5.10.0-0021.aarch64 #1\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01\nCall trace:\n __switch_to+0x7c/0xbc\n __schedule+0x3b4/0x8a0\n schedule+0x50/0xe0\n rwsem_down_write_slowpath+0x3cc/0x6cc\n down_write+0x60/0x260\n __anon_vma_prepare+0x6c/0x210\n do_anonymous_page+0x258/0x660\n handle_pte_fault+0x188/0x214\n __handle_mm_fault+0x1b0/0x380\n handle_mm_fault+0xf4/0x284\n do_page_fault+0x19c/0x494\n do_translation_fault+0xcc/0xf8\n do_mem_abort+0x48/0xac\n el0_da+0x44/0x80\n el0_sync_handler+0x88/0xb4\n el0_sync+0x160/0x180\n\nAfter analyzing the vmcore, we found the anon_vma->root->rwsem.count is\n-1.  There is another anon_vma whose anon_vma->root->rwsem.count is 1, the\nanon_vma->root->rwsem.owner shows the lock is held, but the stack of the\ntask shows the task doesn't hold the anon_vma lock.\n\nAfter adding more debugging info, we found __anon_vma_prepare() reuses\nanon_vma and triggers the UAF of anon_vma->root due to missing memory\nbarrier, leading to locking and unlocking two different anon_vma->root,\nthus leading to an anon_vma will never be unlocked, and another anon_vma\ncouldn't be locked anymore.\n\nThis race requires two adjacent VMAs that are not merged but are\nanon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be\nchanged by mprotect()).  Two threads fault on each VMA concurrently, both\ncalling __anon_vma_prepare() with only mmap_lock held for reading.\n\n    THREAD A                             THREAD B\n__anon_vma_prepare                __anon_vma_prepare\n find_mergeable_anon_vma() -> NULL\n anon_vma = anon_vma_alloc();\n   anon_vma->root = anon_vma;\n // the two stores may be reordered\n vma->anon_vma = anon_vma;\n                                   // finds A's anon_vma\n                                   anon_vma = find_mergeable_anon_vma(vma);\n                                   anon_vma_lock_write(anon_vma);\n                                     // may still see the old root\n                                     down_write(&anon_vma->root->rwsem);\n                                   anon_vma_unlock_write(anon_vma);\n                                     // see the new root, never unlock old\n                                     up_write(&anon_vma->root->rwsem);\n\nthread A triggers page fault and calls __anon_vma_prepare() to prepare\nanon_vma for the faulting vma.  __anon_vma_prepare() allocates and\ninitializes a new anon_vma, and then publishes it to the vma with a plain\nstore.  anon_vma_prepare() only requires the mmap_lock to be held for\nreading, so two threads can fault on adjacent VMAs at the same time. \nWhile thread A publishes a new anon_vma, thread B could find the anon_vma\nvia find_mergeable_anon_vma() and then locks anon_vma->root->rwsem.\n\nThe store to anon_vma->root in anon_vma_alloc() and the store to\nvma->anon_vma can be reordered.  The anon_vma_lock_write() and spin_lock()\nonly provide acquire semantics, which do not prevent prior stores from\nbeing reordered after them.  The release semantics of the corresponding\nspin_unlock() and anon_vma_unlock_write() come too late, the store to\nvma->anon_vma is already published before they take effect.  As a result,\nthread B can observe the following order:\n\n    vma->anon_vma = anon_vma;\n    anon_vma->root = anon_vma;\n\nThe anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma\nmay reuse memory from a previously freed one.  The constructor\n(anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma()\ndoesn't clear it either, so the old root value persists until\nanon_vma_alloc() overwrites it.  If that store isn't v\n---truncated---","state":"PUBLISHED","assigner":"Linux","published_at":"2026-10-18 16:17:01","updated_at":"2026-10-21 13:21:32"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/b6ac0b3f6013c168f22cad97e79967accacb08e1","name":"https://git.kernel.org/stable/c/b6ac0b3f6013c168f22cad97e79967accacb08e1","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/4cef512a955e4008ae4436a4fc97726976df1fdf","name":"https://git.kernel.org/stable/c/4cef512a955e4008ae4436a4fc97726976df1fdf","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/465e222815c8839445d09028fa4c77e70f7f1c7d","name":"https://git.kernel.org/stable/c/465e222815c8839445d09028fa4c77e70f7f1c7d","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d348a715380bfcc6a611bdf722169d53fd01e735","name":"https://git.kernel.org/stable/c/d348a715380bfcc6a611bdf722169d53fd01e735","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a500df43cde075f6ea4b8bae495d89f2c35b3e16","name":"https://git.kernel.org/stable/c/a500df43cde075f6ea4b8bae495d89f2c35b3e16","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-98507","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98507","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1 465e222815c8839445d09028fa4c77e70f7f1c7d git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1 a500df43cde075f6ea4b8bae495d89f2c35b3e16 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1 4cef512a955e4008ae4436a4fc97726976df1fdf git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1 d348a715380bfcc6a611bdf722169d53fd01e735 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1 b6ac0b3f6013c168f22cad97e79967accacb08e1 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 2.6.36","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 2.6.36 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.160 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.112 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.55 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.9 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"98507","cve":"CVE-2026-98507","epss":"0.002000000","percentile":"0.093180000","score_date":"2026-10-21","updated_at":"2026-10-22 00:15:10"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["mm/rmap.c","mm/vma.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"465e222815c8839445d09028fa4c77e70f7f1c7d","status":"affected","version":"5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1","versionType":"git"},{"lessThan":"a500df43cde075f6ea4b8bae495d89f2c35b3e16","status":"affected","version":"5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1","versionType":"git"},{"lessThan":"4cef512a955e4008ae4436a4fc97726976df1fdf","status":"affected","version":"5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1","versionType":"git"},{"lessThan":"d348a715380bfcc6a611bdf722169d53fd01e735","status":"affected","version":"5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1","versionType":"git"},{"lessThan":"b6ac0b3f6013c168f22cad97e79967accacb08e1","status":"affected","version":"5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["mm/rmap.c","mm/vma.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"2.6.36"},{"lessThan":"2.6.36","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.160","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.112","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.55","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.9","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.160","versionStartIncluding":"2.6.36","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.112","versionStartIncluding":"2.6.36","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.55","versionStartIncluding":"2.6.36","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.9","versionStartIncluding":"2.6.36","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","versionStartIncluding":"2.6.36","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish\n\nOn arm64 server, we find that a task trying to grab the anon_vma lock\ntriggers hungtask.\n\nINFO: task main:2354726 blocked for more than 120 seconds.\n      Tainted: G            E     5.10.0-0021.aarch64 #1\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01\nCall trace:\n __switch_to+0x7c/0xbc\n __schedule+0x3b4/0x8a0\n schedule+0x50/0xe0\n rwsem_down_write_slowpath+0x3cc/0x6cc\n down_write+0x60/0x260\n __anon_vma_prepare+0x6c/0x210\n do_anonymous_page+0x258/0x660\n handle_pte_fault+0x188/0x214\n __handle_mm_fault+0x1b0/0x380\n handle_mm_fault+0xf4/0x284\n do_page_fault+0x19c/0x494\n do_translation_fault+0xcc/0xf8\n do_mem_abort+0x48/0xac\n el0_da+0x44/0x80\n el0_sync_handler+0x88/0xb4\n el0_sync+0x160/0x180\n\nAfter analyzing the vmcore, we found the anon_vma->root->rwsem.count is\n-1.  There is another anon_vma whose anon_vma->root->rwsem.count is 1, the\nanon_vma->root->rwsem.owner shows the lock is held, but the stack of the\ntask shows the task doesn't hold the anon_vma lock.\n\nAfter adding more debugging info, we found __anon_vma_prepare() reuses\nanon_vma and triggers the UAF of anon_vma->root due to missing memory\nbarrier, leading to locking and unlocking two different anon_vma->root,\nthus leading to an anon_vma will never be unlocked, and another anon_vma\ncouldn't be locked anymore.\n\nThis race requires two adjacent VMAs that are not merged but are\nanon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be\nchanged by mprotect()).  Two threads fault on each VMA concurrently, both\ncalling __anon_vma_prepare() with only mmap_lock held for reading.\n\n    THREAD A                             THREAD B\n__anon_vma_prepare                __anon_vma_prepare\n find_mergeable_anon_vma() -> NULL\n anon_vma = anon_vma_alloc();\n   anon_vma->root = anon_vma;\n // the two stores may be reordered\n vma->anon_vma = anon_vma;\n                                   // finds A's anon_vma\n                                   anon_vma = find_mergeable_anon_vma(vma);\n                                   anon_vma_lock_write(anon_vma);\n                                     // may still see the old root\n                                     down_write(&anon_vma->root->rwsem);\n                                   anon_vma_unlock_write(anon_vma);\n                                     // see the new root, never unlock old\n                                     up_write(&anon_vma->root->rwsem);\n\nthread A triggers page fault and calls __anon_vma_prepare() to prepare\nanon_vma for the faulting vma.  __anon_vma_prepare() allocates and\ninitializes a new anon_vma, and then publishes it to the vma with a plain\nstore.  anon_vma_prepare() only requires the mmap_lock to be held for\nreading, so two threads can fault on adjacent VMAs at the same time. \nWhile thread A publishes a new anon_vma, thread B could find the anon_vma\nvia find_mergeable_anon_vma() and then locks anon_vma->root->rwsem.\n\nThe store to anon_vma->root in anon_vma_alloc() and the store to\nvma->anon_vma can be reordered.  The anon_vma_lock_write() and spin_lock()\nonly provide acquire semantics, which do not prevent prior stores from\nbeing reordered after them.  The release semantics of the corresponding\nspin_unlock() and anon_vma_unlock_write() come too late, the store to\nvma->anon_vma is already published before they take effect.  As a result,\nthread B can observe the following order:\n\n    vma->anon_vma = anon_vma;\n    anon_vma->root = anon_vma;\n\nThe anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma\nmay reuse memory from a previously freed one.  The constructor\n(anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma()\ndoesn't clear it either, so the old root value persists until\nanon_vma_alloc() overwrites it.  If that store isn't v\n---truncated---"}],"providerMetadata":{"dateUpdated":"2026-10-21T12:55:17.804Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/465e222815c8839445d09028fa4c77e70f7f1c7d"},{"url":"https://git.kernel.org/stable/c/a500df43cde075f6ea4b8bae495d89f2c35b3e16"},{"url":"https://git.kernel.org/stable/c/4cef512a955e4008ae4436a4fc97726976df1fdf"},{"url":"https://git.kernel.org/stable/c/d348a715380bfcc6a611bdf722169d53fd01e735"},{"url":"https://git.kernel.org/stable/c/b6ac0b3f6013c168f22cad97e79967accacb08e1"}],"title":"mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-98507","datePublished":"2026-10-18T15:17:13.767Z","dateReserved":"2026-09-25T10:25:14.354Z","dateUpdated":"2026-10-21T12:55:17.804Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-18 16:17:01","lastModifiedDate":"2026-10-21 13:21:32","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"98507","Ordinal":"1","Title":"mm/rmap: fix missing barrier between anon_vma init and vma->anon","CVE":"CVE-2026-98507","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"98507","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish\n\nOn arm64 server, we find that a task trying to grab the anon_vma lock\ntriggers hungtask.\n\nINFO: task main:2354726 blocked for more than 120 seconds.\n      Tainted: G            E     5.10.0-0021.aarch64 #1\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01\nCall trace:\n __switch_to+0x7c/0xbc\n __schedule+0x3b4/0x8a0\n schedule+0x50/0xe0\n rwsem_down_write_slowpath+0x3cc/0x6cc\n down_write+0x60/0x260\n __anon_vma_prepare+0x6c/0x210\n do_anonymous_page+0x258/0x660\n handle_pte_fault+0x188/0x214\n __handle_mm_fault+0x1b0/0x380\n handle_mm_fault+0xf4/0x284\n do_page_fault+0x19c/0x494\n do_translation_fault+0xcc/0xf8\n do_mem_abort+0x48/0xac\n el0_da+0x44/0x80\n el0_sync_handler+0x88/0xb4\n el0_sync+0x160/0x180\n\nAfter analyzing the vmcore, we found the anon_vma->root->rwsem.count is\n-1.  There is another anon_vma whose anon_vma->root->rwsem.count is 1, the\nanon_vma->root->rwsem.owner shows the lock is held, but the stack of the\ntask shows the task doesn't hold the anon_vma lock.\n\nAfter adding more debugging info, we found __anon_vma_prepare() reuses\nanon_vma and triggers the UAF of anon_vma->root due to missing memory\nbarrier, leading to locking and unlocking two different anon_vma->root,\nthus leading to an anon_vma will never be unlocked, and another anon_vma\ncouldn't be locked anymore.\n\nThis race requires two adjacent VMAs that are not merged but are\nanon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be\nchanged by mprotect()).  Two threads fault on each VMA concurrently, both\ncalling __anon_vma_prepare() with only mmap_lock held for reading.\n\n    THREAD A                             THREAD B\n__anon_vma_prepare                __anon_vma_prepare\n find_mergeable_anon_vma() -> NULL\n anon_vma = anon_vma_alloc();\n   anon_vma->root = anon_vma;\n // the two stores may be reordered\n vma->anon_vma = anon_vma;\n                                   // finds A's anon_vma\n                                   anon_vma = find_mergeable_anon_vma(vma);\n                                   anon_vma_lock_write(anon_vma);\n                                     // may still see the old root\n                                     down_write(&anon_vma->root->rwsem);\n                                   anon_vma_unlock_write(anon_vma);\n                                     // see the new root, never unlock old\n                                     up_write(&anon_vma->root->rwsem);\n\nthread A triggers page fault and calls __anon_vma_prepare() to prepare\nanon_vma for the faulting vma.  __anon_vma_prepare() allocates and\ninitializes a new anon_vma, and then publishes it to the vma with a plain\nstore.  anon_vma_prepare() only requires the mmap_lock to be held for\nreading, so two threads can fault on adjacent VMAs at the same time. \nWhile thread A publishes a new anon_vma, thread B could find the anon_vma\nvia find_mergeable_anon_vma() and then locks anon_vma->root->rwsem.\n\nThe store to anon_vma->root in anon_vma_alloc() and the store to\nvma->anon_vma can be reordered.  The anon_vma_lock_write() and spin_lock()\nonly provide acquire semantics, which do not prevent prior stores from\nbeing reordered after them.  The release semantics of the corresponding\nspin_unlock() and anon_vma_unlock_write() come too late, the store to\nvma->anon_vma is already published before they take effect.  As a result,\nthread B can observe the following order:\n\n    vma->anon_vma = anon_vma;\n    anon_vma->root = anon_vma;\n\nThe anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma\nmay reuse memory from a previously freed one.  The constructor\n(anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma()\ndoesn't clear it either, so the old root value persists until\nanon_vma_alloc() overwrites it.  If that store isn't v\n---truncated---","Type":"Description","Title":"mm/rmap: fix missing barrier between anon_vma init and vma->anon"}]}}}