Cloudanix VulnDB

CVE-2026-98923

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug on certain processors can generate confusing error messages when special memory pages are examined through system tools, but it does not let attackers steal data or take control.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Other
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

ioremap_prot() on arm64 fails to validate that supplied page protections include PTE_USER, allowing PROT_NONE and execute-only mappings to reach generic_access_phys() and trigger a spurious WARN_ON_ONCE even though the mapping is valid.

Why it matters to the business

Kernel log spam, potential monitoring alerts, and minor operational noise on arm64 Linux systems that permit /dev/mem access; no direct data loss or remote code execution but increases noise in security and stability monitoring.

How an attack unfolds

An attacker with sufficient privileges opens /dev/mem, maps a target process stack page using PROT_NONE (or execute-only), then triggers proc_pid_cmdline_read which calls access_remote_vm and ultimately generic_access_phys, causing the invalid protection to reach ioremap_prot and fire the warning.

How to fix it

Apply the upstream kernel commit that updates ioremap_prot() to reject protection values lacking PTE_USER without emitting a warning; rebuild and deploy the fixed kernel image to all arm64 systems.

How to confirm the fix worked

Confirm the patched kernel version is running, then attempt the PROT_NONE mapping + cmdline read sequence and verify that no warning is emitted and access fails cleanly with an error.

Typical attack path

  1. Obtain privileges allowing /dev/mem or equivalent physical memory access
  2. Identify a target process and locate a stack-top or execute-only page
  3. Map the page via mmap or equivalent with PROT_NONE protection
  4. Trigger cmdline or similar procfs read that walks remote VM
  5. Observe kernel warning in dmesg or logs

How to detect it

Search kernel logs and dmesg for the exact warning emitted by generic_access_phys when ioremap_prot receives a non-user protection; correlate with processes that opened /dev/mem or accessed remote VM via procfs.

  • WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys
  • generic_access_phys+0x1c8/0x228
  • proc_pid_cmdline_read+0x68/0x120

What your security team should do

  • Prioritize kernel update on all arm64 production systems within the normal patch cycle
  • Add the warning string to log monitoring rules for the next 30 days as a detection backstop
  • Review any custom /dev/mem usage or memory introspection tools for similar protection handling

The record

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.

Affected packages

Ecosystem Package Introduced Fixed