{"id":"CVE-2026-98923","kind":"vulnerability","aliases":["CVE-2026-98923"],"related":[],"title":"Linux arm64: spurious kernel warning when reading PROT_NONE mappings via /dev/mem","description":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: io: Reject non-user protection in ioremap_prot()\n\nMapping a stack-top page via /dev/mem with PROT_NONE and then\nreading that process's /proc/<pid>/cmdline triggers a spurious WARN\nin ioremap_prot() through generic_access_phys():\n\n  WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys\n  Call trace:\n    generic_access_phys+0x1c8/0x228 (P)\n    __access_remote_vm+0x2b4/0x398\n    access_remote_vm+0x14/0x30\n    get_mm_cmdline+0xf8/0x2a0\n    proc_pid_cmdline_read+0x68/0x120\n\ngeneric_access_phys() passes the protection derived from the user PTE\nto ioremap_prot(). On arm64, a PROT_NONE mapping is represented by a\npresent-invalid PTE, so pte_present() still returns true and the\nprotection reaches ioremap_prot().\n\nA PROT_NONE mapping does not have PTE_USER, causing the existing\nWARN_ON_ONCE() in ioremap_prot() to fire even though this is a valid\nuser mapping. Execute-only mappings have the same issue and must not\nbe readable through this path either.\n\nioremap_prot() should therefore reject protection values without\nPTE_USER without warning. This makes the access fail cleanly for\nPROT_NONE and execute-only mappings while retaining the existing\nuser-protection contract.","summary":"On arm64 Linux, mapping a page through /dev/mem with PROT_NONE and reading that process's /proc/<pid>/cmdline triggers a spurious kernel WARN in ioremap_prot(). The fix makes ioremap_prot() reject non-user protection values cleanly, so PROT_NONE and execute-only mappings can no longer be read through this path.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["arm64","kernel","linux","runtime"],"not_affected_if":["no-dev-mem-access","non-arm64"],"how_to_check":null,"fix":null,"status":"open","published_at":"2026-10-23T13:17:12+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","triaged_at":"2026-10-25T04:58:17+00:00","updated_at":"2026-10-25T04:58:17+00:00","category":"runtime","confidence":0.5,"triage":{"at":"2026-10-25T04:58:17Z","model":"claude-haiku-5-5","output":{"fix":"unknown","reach":"local","title":"Linux arm64: spurious kernel warning when reading PROT_NONE mappings via /dev/mem","impact":"low","summary":"On arm64 Linux, mapping a page through /dev/mem with PROT_NONE and reading that process's /proc/<pid>/cmdline triggers a spurious kernel WARN in ioremap_prot(). The fix makes ioremap_prot() reject non-user protection values cleanly, so PROT_NONE and execute-only mappings can no longer be read through this path.","category":"runtime","nicknames":[],"who_cares":["linux","arm64","kernel"],"confidence":0.5,"needs_auth":"unknown","worst_case":"unknown","analyst_note":"Sources give only the NVD record and the kernel commit text; confirm affected kernel versions, fixed stable releases, and whether reading PROT_NONE memory via /dev/mem leaks data or only triggers a warning.","how_to_check":"unknown","needs_analyst":true,"not_affected_if":["non-arm64","no-dev-mem-access"],"who_is_affected":"Systems running arm64 Linux kernels with /dev/mem access; the sources do not name affected kernel versions or whether default configurations expose /dev/mem.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"unknown"},"cost_usd":0.000613,"input_tokens":3731,"output_tokens":479,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'+0':139C,145C,150C,155C,161C '-2026':14A,17A '-98923':15A,18A '/arch/arm64/include/asm/io.h':128C '/cmdline':40B,115C '/dev/mem':12A,30B,104C '/proc':39B,114C '275':129C 'access':125C,132C,137C,142C,147C,164C,263C 'arm64':2A,19B,24B,87C,178C 'call':134C 'caus':212C 'clean':60B,265C 'cmdline':154C,159C 'contract':281C 'cve':13A,16A 'deriv':169C 'either':247C 'even':223C 'execut':66B,232C,271C 'execute-on':65B,231C,270C 'exist':214C,277C 'fail':264C 'fire':222C 'fix':50B 'follow':82C 'generic':124C,131C,136C,163C 'get':152C 'invalid':189C 'io':88C 'ioremap':47B,52B,95C,121C,175C,201C,219C,248C 'issu':238C 'kernel':4A,20B,44B,80C 'linux':1A,21B,25B,79C 'longer':71B 'make':51B,261C 'map':10A,26B,68B,97C,182C,206C,230C,234C,273C 'mm':153C 'must':240C 'non':56B,91C 'non-us':55B,90C 'none':9A,33B,63B,107C,181C,205C,268C 'p':141C 'page':28B,102C 'pass':166C 'path':76B,246C 'phys':126C,133C,138C,165C 'pid':158C 'present':188C,193C 'present-invalid':187C 'proc':157C 'process':37B,112C 'prot':8A,32B,48B,53B,62B,96C,106C,122C,176C,180C,202C,204C,220C,249C,267C 'protect':58B,93C,168C,199C,253C,280C 'pte':173C,190C,192C,210C,256C 'reach':200C 'read':7A,35B,73B,110C,160C 'readabl':243C 'reject':54B,89C,252C 'remot':143C,148C 'repres':184C 'resolv':86C 'retain':275C 'return':195C 'runtim':22B 'spurious':3A,43B,118C 'stack':100C 'stack-top':99C 'still':194C 'therefor':251C 'though':224C 'top':101C 'trace':135C 'trigger':41B,116C 'true':196C 'user':57B,92C,172C,211C,229C,257C,279C 'user-protect':278C 'valid':228C 'valu':59B,254C 'via':11A,103C 'vm':144C,149C 'vulner':83C 'warn':5A,45B,119C,127C,215C,259C 'without':255C,258C 'x14/0x30':151C 'x1c8/0x228':140C 'x2b4/0x398':146C 'x68/0x120':162C 'xf8/0x2a0':156C","nicknames":[],"mitigations":[],"who_affected":"Systems running arm64 Linux kernels with /dev/mem access; the sources do not name affected kernel versions or whether default configurations expose /dev/mem.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T13:17:12+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98923","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98923","severity":null,"published_at":"2026-10-23T13:17:12+00:00","modified_at":"2026-10-23T13:17:12+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","fetched_at":"2026-10-23T22:29:03+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"}