CVE-2026-98923 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
arm64: io: Reject non-user protection in ioremap_prot()
Mapping a stack-top page via /dev/mem with PROT_NONE and then reading that process's /proc/<pid>/cmdline triggers a spurious WARN in ioremap_prot() through generic_access_phys():
WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys Call trace: generic_access_phys+0x1c8/0x228 (P) __access_remote_vm+0x2b4/0x398 access_remote_vm+0x14/0x30 get_mm_cmdline+0xf8/0x2a0 proc_pid_cmdline_read+0x68/0x120
generic_access_phys() passes the protection derived from the user PTE to ioremap_prot(). On arm64, a PROT_NONE mapping is represented by a present-invalid PTE, so pte_present() still returns true and the protection reaches ioremap_prot().
A PROT_NONE mapping does not have PTE_USER, causing the existing WARN_ON_ONCE() in ioremap_prot() to fire even though this is a valid user mapping. Execute-only mappings have the same issue and must not be readable through this path either.
ioremap_prot() should therefore reject protection values without PTE_USER without warning. This makes the access fail cleanly for PROT_NONE and execute-only mappings while retaining the existing user-protection contract.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel contains a vulnerability in the arm64 architecture implementation of memory mapping functions, specifically within ioremap_prot(), which is triggered by improper handling of non-user protection flags during physical address access via /dev/mem. The issue arises when an attacker or misconfigured application maps the stack-top page using PROT_NONE and subsequently attempts to read that process's command line information through /proc/<pid>/cmdline. This sequence triggers a spurious warning in ioremap_prot() because generic_access_phys() passes protection attributes derived from user Page Table Entries (PTEs) directly into the mapping function without sufficient validation of whether those mappings are intended for user-space access.
On arm64 architectures, PROT_NONE mappings are represented by present-invalid PTE entries where pte_present() still returns true despite the lack of actual readable or writable permissions. Consequently, when generic_access_phys retrieves these protection values and forwards them to ioremap_prot(), the function encounters a situation where it receives valid-looking but semantically incorrect protection flags that do not include PTE_USER. The existing WARN_ON_ONCE macro in ioremap_prot() is designed to catch cases where non-user mappings are incorrectly passed through, yet this check fires erroneously for legitimate user-space operations involving PROT_NONE or execute-only mappings because the presence bit remains set even though user access bits are cleared.
This false positive warning indicates a deeper logical flaw in how kernel memory management subsystems validate protection attributes during physical address accesses initiated from user space via /dev/mem interfaces. While the immediate symptom is merely an annoying console warning, it represents a deviation from expected security behavior where legitimate operations trigger error conditions that could potentially be exploited for denial-of-service through log flooding or information disclosure if additional logging mechanisms are enabled. Furthermore, execute-only mappings suffer from identical issues since they also lack PTE_USER bits while remaining present in page tables, meaning any attempt to read such mapped regions will similarly trigger the erroneous warning condition without actually providing unauthorized access capabilities beyond what was already permitted by the initial mapping configuration.
From a vulnerability classification perspective, this issue aligns with CWE-20 Improper Input Validation as the kernel fails to properly validate whether incoming protection flags correspond to actual user-space authorized mappings before processing them through critical memory management routines. In terms of MITRE ATT&CK framework relevance, while not directly exploitable for privilege escalation or code execution in its current state, it relates to TA0005 Defense Evasion techniques where attackers might attempt to trigger kernel warnings to obscure malicious activities within system logs or cause resource exhaustion through repeated triggering events. The vulnerability primarily affects systems utilizing arm64 architecture with /dev/mem access capabilities enabled and processes that manipulate stack mappings using restrictive protection flags followed by standard process information retrieval operations.
The resolution involves modifying ioremap_prot() to explicitly reject protection values lacking PTE_USER without generating warnings, thereby allowing PROT_NONE and execute-only mappings to fail cleanly rather than triggering spurious error conditions. This approach maintains the existing user-protection contract while eliminating false positives that could interfere with system monitoring tools or indicate incorrect security posture assessments during vulnerability scanning operations. By ensuring only properly flagged user-space protected regions proceed through physical access paths, the kernel enforces stricter separation between privileged and unprivileged memory accesses without compromising legitimate operational functionality for applications requiring precise control over page protection attributes.
System administrators should ensure their kernels are updated to include this fix which prevents unnecessary warning generation during normal process management operations involving restricted memory mappings. Security teams monitoring arm64-based systems should verify that /dev/mem access controls remain appropriately configured according to organizational security policies since unrestricted physical memory access remains a significant attack vector regardless of whether specific kernel warnings occur correctly or incorrectly. The patch effectively closes the logical gap in protection flag validation while preserving intended security boundaries between user and kernel space operations on affected architectures.