CVE-2026-23346
Description
In the Linux kernel, the following vulnerability has been resolved:
arm64: io: Extract user memory type in ioremap_prot()
The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN:
| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68
Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In the Linux kernel's arm64 ioremap_prot(), a bug causes kernel panic when accessing user-mapped memory with PAN enabled, fixed by extracting only memory type.
What the vulnerability is
CVE-2026-23346 is a bug in the Linux kernel's ioremap_prot() function on arm64 architectures. The function incorrectly passes the entire pgprot_t from a user page table entry (PTE) when creating a kernel mapping for physical memory access via generic_access_phys(). On systems with Privileged Access Never (PAN) enabled, this results in a kernel mapping with user permissions, causing a fault when the kernel attempts to read from that memory [1].
How it is exploited
The attack vector requires the ability to trigger generic_access_phys() through interfaces like /proc/pid/mem or ptrace (e.g., reading /proc/pid/environ). An attacker must have local access and the ability to read or write memory of another process. The kernel panic occurs when the kernel tries to perform a read from the mapped I/O region, as the mapping lacks kernel-read permission due to the user permission bits inherited from the user PTE [1].
Impact
A local attacker can cause a kernel panic (denial of service) by inducing the kernel to access a user-mapped physical address via generic_access_phys(). The bug manifests as an "Unable to handle kernel read from unreadable memory" error, leading to system crash. No privilege escalation is reported [1].
Mitigation
The fix, applied to multiple stable kernel branches, extracts only the memory type attributes from the user pgprot_t and asserts that the mapping originated from a user page. The patches also define a new ioremap() macro to avoid false positives. Users should update to kernels containing commits d1ad8fe7f72d, 3d64dcc0799c, or 8f098037139b [1][2][3].
AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
9cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*+ 8 more
- cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*range: >=6.0.1,<6.18.17
- cpe:2.3:o:linux:linux_kernel:6.0:-:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*
Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
3News mentions
0No linked articles in our index yet.