CVE-2026-98507

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-98507", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-09-25T10:25:14.354Z", "datePublished": "2026-10-18T15:17:13.767Z", "dateUpdated": "2026-10-30T12:38:20.652Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-10-30T12:38:20.652Z"}, "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---"}], "metrics": [{"cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH"}, "scenarios": [{"lang": "en", "value": "AV:L - A local memory fault reaches patched __anon_vma_prepare() via do_mem_abort() \u2192 do_page_fault() \u2192 handle_mm_fault() \u2192 __handle_mm_fault() \u2192 handle_pte_fault() \u2192 do_anonymous_page() \u2192 __vmf_anon_prepare(); no network data enters this path.\nAC:L - The attacker can use mprotect() to create adjacent unmerged VMAs differing in VMA_ACCESS_FLAGS, groom stale non-self roots through fork/exit, and concurrently fault both VMAs. They control both sides of the reusable_anon_vma() race and can retry the weak-memory window.\nPR:L - mmap(), mprotect(), fork()/clone(), and faults on the caller's own mappings require no capability; neither __vmf_anon_prepare() nor __anon_vma_prepare() performs a credential check. An ordinary unprivileged local process can reach the flaw.\nUI:N - The attacking process creates the VMA layout, grooms the anon_vma cache, and drives both concurrent faults itself; no action by another user is required.\nS:U - The stale root dereference and rwsem corruption occur in the host kernel's anon_vma memory-management state reached from the attacker's process; no VM, IOMMU, or other security-authority boundary is crossed.\nC:H - reusable_anon_vma() can return a newly allocated SLAB_TYPESAFE_BY_RCU object while its root still names a freed prior anon_vma, after which anon_vma_lock_write() dereferences the stale root->rwsem. Same-cache grooming therefore provides a use-after-free read over recycled kernel object state.\nI:H - down_write() writes count and owner state through the freed or reallocated old root, while anon_vma_unlock_write() rereads the initialized root and up_write() corrupts that different semaphore, as demonstrated by counts 1 and -1. These are cross-object UAF writes into a groomable kernel slab.\nA:H - The mismatched down_write()/up_write() leaves the old anon_vma root permanently locked and underflows the new root's rwsem count, producing the reported uninterruptible hung task in __anon_vma_prepare(); repeated poisoned roots can block further faults and rmap operations."}]}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["mm/rmap.c", "mm/vma.c"], "versions": [{"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "badedec499f6320742368c73fa77cd63dcf8ca55", "status": "affected", "versionType": "git"}, {"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "aef0f69b515af1c8a4147f68a46b6b81854f46f7", "status": "affected", "versionType": "git"}, {"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "7d103fc7b836084af585d9d3471334624354cf26", "status": "affected", "versionType": "git"}, {"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "465e222815c8839445d09028fa4c77e70f7f1c7d", "status": "affected", "versionType": "git"}, {"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "a500df43cde075f6ea4b8bae495d89f2c35b3e16", "status": "affected", "versionType": "git"}, {"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "4cef512a955e4008ae4436a4fc97726976df1fdf", "status": "affected", "versionType": "git"}, {"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "d348a715380bfcc6a611bdf722169d53fd01e735", "status": "affected", "versionType": "git"}, {"version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "lessThan": "b6ac0b3f6013c168f22cad97e79967accacb08e1", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["mm/rmap.c", "mm/vma.c"], "versions": [{"version": "2.6.36", "status": "affected"}, {"version": "0", "lessThan": "2.6.36", "status": "unaffected", "versionType": "semver"}, {"version": "5.10.273", "lessThanOrEqual": "5.10.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.15.224", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.191", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.160", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12.112", "lessThanOrEqual": "6.12.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.18.55", "lessThanOrEqual": "6.18.*", "status": "unaffected", "versionType": "semver"}, {"version": "7.2.9", "lessThanOrEqual": "7.2.*", "status": "unaffected", "versionType": "semver"}, {"version": "7.3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "5.10.273"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "5.15.224"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "6.1.191"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "6.6.160"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "6.12.112"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "6.18.55"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "7.2.9"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "7.3"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/badedec499f6320742368c73fa77cd63dcf8ca55"}, {"url": "https://git.kernel.org/stable/c/aef0f69b515af1c8a4147f68a46b6b81854f46f7"}, {"url": "https://git.kernel.org/stable/c/7d103fc7b836084af585d9d3471334624354cf26"}, {"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"}}}}

{}

{"affected": [{"affectedData": [{"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": "badedec499f6320742368c73fa77cd63dcf8ca55", "status": "affected", "version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "versionType": "git"}, {"lessThan": "aef0f69b515af1c8a4147f68a46b6b81854f46f7", "status": "affected", "version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "versionType": "git"}, {"lessThan": "7d103fc7b836084af585d9d3471334624354cf26", "status": "affected", "version": "5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1", "versionType": "git"}, {"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": "5.10.*", "status": "unaffected", "version": "5.10.273", "versionType": "semver"}, {"lessThanOrEqual": "5.15.*", "status": "unaffected", "version": "5.15.224", "versionType": "semver"}, {"lessThanOrEqual": "6.1.*", "status": "unaffected", "version": "6.1.191", "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"}]}], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "cveTags": [], "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---"}], "id": "CVE-2026-98507", "lastModified": "2026-10-30T13:21:15.317", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.9, "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "type": "Secondary"}]}, "published": "2026-10-18T16:17:01.817", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/465e222815c8839445d09028fa4c77e70f7f1c7d"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/4cef512a955e4008ae4436a4fc97726976df1fdf"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/7d103fc7b836084af585d9d3471334624354cf26"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/a500df43cde075f6ea4b8bae495d89f2c35b3e16"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/aef0f69b515af1c8a4147f68a46b6b81854f46f7"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/b6ac0b3f6013c168f22cad97e79967accacb08e1"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/badedec499f6320742368c73fa77cd63dcf8ca55"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/d348a715380bfcc6a611bdf722169d53fd01e735"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Received"}

{"bugzilla": {"description": "kernel: mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish", "id": "2554843", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2554843"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.7", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-366", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nmm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish\nOn arm64 server, we find that a task trying to grab the anon_vma lock\ntriggers hungtask.\nINFO: task main:2354726 blocked for more than 120 seconds.\nTainted: 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\nschedule+0x50/0xe0\nrwsem_down_write_slowpath+0x3cc/0x6cc\ndown_write+0x60/0x260\n__anon_vma_prepare+0x6c/0x210\ndo_anonymous_page+0x258/0x660\nhandle_pte_fault+0x188/0x214\n__handle_mm_fault+0x1b0/0x380\nhandle_mm_fault+0xf4/0x284\ndo_page_fault+0x19c/0x494\ndo_translation_fault+0xcc/0xf8\ndo_mem_abort+0x48/0xac\nel0_da+0x44/0x80\nel0_sync_handler+0x88/0xb4\nel0_sync+0x160/0x180\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.\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.\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.\nTHREAD A THREAD B\n__anon_vma_prepare __anon_vma_prepare\nfind_mergeable_anon_vma() -> NULL\nanon_vma = anon_vma_alloc();\nanon_vma->root = anon_vma;\n// the two stores may be reordered\nvma->anon_vma = anon_vma;\n// finds A's anon_vma\nanon_vma = find_mergeable_anon_vma(vma);\nanon_vma_lock_write(anon_vma);\n// may still see the old root\ndown_write(&anon_vma->root->rwsem);\nanon_vma_unlock_write(anon_vma);\n// see the new root, never unlock old\nup_write(&anon_vma->root->rwsem);\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.\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:\nvma->anon_vma = anon_vma;\nanon_vma->root = anon_vma;\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---", "A flaw was found in the Linux kernel's memory management subsystem. Due to a missing synchronization barrier when preparing anonymous virtual memory areas, concurrent memory operations can be reordered. A local attacker can exploit this race condition by running concurrent threads on adjacent memory regions, causing lock mismatches or improper memory reuse. This flaw primarily results in a kernel hang or deadlock, causing a Denial of Service (DoS)."], "name": "CVE-2026-98507", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/a:redhat:openshift:4", "fix_state": "Fix deferred", "package_name": "openshift/ose-rhel-coreos-8", "product_name": "Red Hat OpenShift Container Platform 4"}, {"cpe": "cpe:/a:redhat:openshift:4", "fix_state": "Fix deferred", "package_name": "openshift/ose-rhel-coreos-9", "product_name": "Red Hat OpenShift Container Platform 4"}], "public_date": "2026-10-18T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-98507\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-98507\nhttps://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98507.mbox"], "threat_severity": "Moderate"}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1,a500df43cde075f6ea4b8bae495d89f2c35b3e16)"}}, {"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1,4cef512a955e4008ae4436a4fc97726976df1fdf)"}}, {"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1,d348a715380bfcc6a611bdf722169d53fd01e735)"}}, {"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[5c341ee1dfc8fe69d66b1c8b19e463c6d7201ae1,b6ac0b3f6013c168f22cad97e79967accacb08e1)"}}], "enrichment": {"confidence": 99.0, "confidence_source": "inferred", "scores": [{"score": 99.0, "source": "inferred"}, {"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}, {"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "2.6.36"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "[0,2.6.36)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "[6.12.112,6.13.0)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "[6.18.55,6.19.0)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "[7.2.9,7.3.0)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "[7.3-rc5,*]"}}], "enrichment": {"confidence": 99.0, "confidence_source": "inferred", "scores": [{"score": 99.0, "source": "inferred"}, {"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}], "created": "2026-10-18T17:00:09.232714+00:00", "updated": "2026-10-24T16:15:17.879053+00:00", "vendors": ["linux", "linux$PRODUCT$linux_kernel"]}