{"id":"CVE-2026-98507","kind":"vulnerability","aliases":["CVE-2026-98507"],"related":[],"title":"Linux kernel: missing memory barrier lets anon_vma lock hang tasks","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---","summary":"A race in the Linux kernel's anonymous memory setup (mm/rmap) can let two threads publish an anon_vma in the wrong order, so one thread locks a stale root and never unlocks it. The result is hung tasks waiting on the lock, a denial of service rather than code execution as described in the sources.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["arm64","linux-kernel","package","self-hosted"],"not_affected_if":["patched-kernel"],"how_to_check":"- Run `uname -r` and compare against the fixed kernel builds listed in the NVD entry for CVE-2026-98507\n- unknown","fix":"- Update the Linux kernel to a release that includes the upstream mm/rmap barrier fix (version unknown from the sources)","status":"open","published_at":"2026-10-18T16:17:01+00:00","first_seen_at":"2026-10-23T21:57:15+00:00","triaged_at":"2026-10-25T05:25:27+00:00","updated_at":"2026-10-25T05:25:27+00:00","category":"package","confidence":0.6,"triage":{"at":"2026-10-25T05:25:27Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a release that includes the upstream mm/rmap barrier fix (version unknown from the sources)","reach":"local","title":"Linux kernel: missing memory barrier lets anon_vma lock hang tasks","impact":"medium","summary":"A race in the Linux kernel's anonymous memory setup (mm/rmap) can let two threads publish an anon_vma in the wrong order, so one thread locks a stale root and never unlocks it. The result is hung tasks waiting on the lock, a denial of service rather than code execution as described in the sources.","category":"package","nicknames":[],"who_cares":["linux-kernel","arm64","self-hosted"],"confidence":0.6,"needs_auth":"unknown","worst_case":"Tasks hang on a lock, causing denial of service on the host","analyst_note":"Sources give no severity, affected version range or fixed version; check the NVD entry and the upstream kernel commit for the fixed release numbers.","how_to_check":"- Run `uname -r` and compare against the fixed kernel builds listed in the NVD entry for CVE-2026-98507\n- unknown","needs_analyst":true,"not_affected_if":["patched-kernel"],"who_is_affected":"Systems running affected Linux kernel builds, with the arm64 server case described in the report being the one with observed hangs. Workloads that do heavy concurrent page faults on adjacent VMAs that differ in access flags are the ones that can hit the race. Teams on patched or managed kernels can skip it once their vendor kernel includes the fix.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"unknown"},"cost_usd":0.000775,"input_tokens":4882,"output_tokens":574,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'+0':161C,164C,167C,173C,177C,182C,187C,192C,197C,202C,207C,212C,217C,221C,226C,230C '-0021':136C '-1':244C '-2026':13A,16A '-98507':14A,17A '/proc/sys/kernel/hung_task_timeout_secs':141C '0':140C,150C '0x00000a01':156C '1':138C,256C '120':130C '2350673':154C '2354726':125C,152C '5.10.0':135C 'aarch64':137C 'abort':216C 'access':359C 'acquir':592C 'add':284C 'adjac':342C,529C 'alloc':405C,492C,571C,666C,706C 'alreadi':628C 'analyz':233C 'anon':7A,43B,97C,102C,117C,179C,239C,248C,251C,258C,280C,290C,294C,301C,316C,323C,331C,350C,376C,390C,393C,398C,401C,403C,406C,409C,418C,420C,425C,427C,431C,434C,438C,448C,452C,456C,467C,478C,483C,489C,497C,510C,541C,548C,553C,558C,565C,569C,577C,583C,614C,625C,645C,647C,649C,652C,655C,667C,679C,685C,690C,704C 'anonym':33B,185C 'anoth':247C,330C 'anymor':337C 'arm64':18B,106C 'b':389C,544C,638C 'barrier':5A,95C,308C 'block':126C 'call':157C,375C,477C 'chang':364C 'clear':694C 'code':75B 'come':618C 'compat':353C 'concurr':373C 'constructor':678C 'correspond':610C 'could':545C 'couldn':333C 'ctor':681C 'cve':12A,15A 'd':148C 'da':220C 'debug':286C 'denial':70B 'describ':78B 'differ':315C,356C 'disabl':142C 'doesn':276C,692C 'due':304C 'e':134C 'e.g':354C 'echo':139C 'effect':633C 'either':696C 'el0':219C,223C,228C 'execut':76B 'fault':191C,196C,201C,206C,211C,369C,475C,487C,527C 'find':109C,396C,422C,429C,546C,551C 'fix':93C 'flag':155C,360C 'follow':87C,642C 'found':237C,289C 'freed':675C 'g':133C 'grab':115C 'handl':189C,194C,199C 'handler':225C 'hang':10A 'held':266C,383C,520C 'hold':278C 'host':25B 'hung':63B 'hungtask':121C 'info':122C,287C 'init':99C 'initi':494C 'isn':712C 'kernel':2A,21B,31B,85C 'late':620C 'lead':309C,320C 'let':6A,38B 'linux':1A,20B,30B,84C 'linux-kernel':19B 'lock':9A,52B,68B,119C,264C,282C,311C,336C,382C,436C,517C,557C,585C,589C 'main':124C,146C 'may':414C,440C,669C 'mem':215C 'memori':4A,34B,307C,671C 'merg':347C 'mergeabl':397C,430C,552C 'messag':144C 'miss':3A,94C,306C 'mm':195C,200C 'mm/rmap':36B,92C 'mmap':381C,516C 'mprotect':366C 'never':57B,326C,462C 'new':460C,496C,540C 'newli':665C 'null':400C 'observ':640C 'old':444C,464C,699C 'one':50B,676C 'order':48B,643C 'overwrit':707C 'packag':22B 'page':186C,205C,474C 'persist':702C 'pid':151C 'plain':508C 'ppid':153C 'prepar':181C,292C,378C,392C,395C,480C,482C,491C,512C 'prevent':597C 'previous':674C 'prior':598C 'provid':591C 'pte':190C 'publish':41B,104C,501C,538C,629C 'put':689C 'race':27B,339C 'rather':73B 'rcu':662C 'read':385C,522C 'releas':606C 'reorder':416C,581C,602C 'requir':340C,514C 'reset':684C 'resolv':91C 'result':61B,636C 'reus':293C,670C 'root':55B,241C,253C,260C,303C,318C,408C,445C,450C,461C,469C,560C,567C,651C,687C,700C 'rwsem':169C,451C,470C,561C 'rwsem.count':242C,254C 'rwsem.owner':261C 'schedul':163C,166C 'second':131C 'see':442C,458C 'self':24B 'self-host':23B 'semant':593C,607C 'server':107C 'servic':72B 'setup':35B 'show':262C,273C 'slab':657C,659C 'slowpath':172C 'sourc':81B 'spin':588C,611C 'stack':149C,269C 'stale':54B 'state':147C 'still':441C 'store':413C,509C,563C,574C,599C,622C,711C 'switch':159C 'sync':224C,229C 'taint':132C 'take':632C 'task':11A,64B,112C,123C,145C,272C,275C 'thread':40B,51B,368C,386C,388C,471C,525C,536C,543C,637C 'thus':319C 'time':534C 'trace':158C 'translat':210C 'tri':113C 'trigger':120C,297C,473C 'truncat':715C 'two':39B,314C,341C,367C,412C,524C 'typesaf':660C 'uaf':299C 'unlock':58B,313C,328C,454C,463C,612C,616C 'v':714C 'valu':701C 'via':550C 'vma':8A,44B,98C,101C,103C,118C,180C,240C,249C,252C,259C,281C,291C,295C,302C,317C,324C,332C,352C,358C,372C,377C,391C,394C,399C,402C,404C,407C,410C,417C,419C,421C,426C,428C,432C,433C,435C,439C,449C,453C,457C,468C,479C,484C,488C,490C,498C,505C,511C,542C,549C,554C,559C,566C,570C,576C,578C,584C,615C,624C,626C,644C,646C,648C,650C,653C,656C,668C,680C,686C,691C,705C 'vma-compat':351C 'vmas':343C,530C 'vmcore':235C 'vulner':88C 'wait':65B 'whose':250C 'write':171C,176C,437C,447C,455C,466C,586C,617C 'wrong':47B 'x160/0x180':231C 'x188/0x214':193C 'x19c/0x494':208C 'x1b0/0x380':198C 'x258/0x660':188C 'x3b4/0x8a0':165C 'x3cc/0x6cc':174C 'x44/0x80':222C 'x48/0xac':218C 'x50/0xe0':168C 'x60/0x260':178C 'x6c/0x210':183C 'x7c/0xbc':162C 'x88/0xb4':227C 'xcc/0xf8':213C 'xf4/0x284':203C","nicknames":[],"mitigations":[],"who_affected":"Systems running affected Linux kernel builds, with the arm64 server case described in the report being the one with observed hangs. Workloads that do heavy concurrent page faults on adjacent VMAs that differ in access flags are the ones that can hit the race. Teams on patched or managed kernels can skip it once their vendor kernel includes the fix.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-18T16:17:01+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98507","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98507","severity":null,"published_at":"2026-10-18T16:17:01+00:00","modified_at":"2026-10-21T13:21:32+00:00","first_seen_at":"2026-10-23T21:57:15+00:00","fetched_at":"2026-10-23T22:28:56+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}