CVE-2026-23346

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: io: Extract user memory type in ioremap_prot()<br /> <br /> The only caller of ioremap_prot() outside of the generic ioremap()<br /> implementation is generic_access_phys(), which passes a &amp;#39;pgprot_t&amp;#39; value<br /> determined from the user mapping of the target &amp;#39;pfn&amp;#39; being accessed by<br /> the kernel. On arm64, the &amp;#39;pgprot_t&amp;#39; contains all of the non-address<br /> bits from the pte, including the permission controls, and so we end up<br /> returning a new user mapping from ioremap_prot() which faults when<br /> accessed from the kernel on systems with PAN:<br /> <br /> | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000<br /> | ...<br /> | Call trace:<br /> | __memcpy_fromio+0x80/0xf8<br /> | generic_access_phys+0x20c/0x2b8<br /> | __access_remote_vm+0x46c/0x5b8<br /> | access_remote_vm+0x18/0x30<br /> | environ_read+0x238/0x3e8<br /> | vfs_read+0xe4/0x2b0<br /> | ksys_read+0xcc/0x178<br /> | __arm64_sys_read+0x4c/0x68<br /> <br /> Extract only the memory type from the user &amp;#39;pgprot_t&amp;#39; in ioremap_prot()<br /> and assert that we&amp;#39;re being passed a user mapping, to protect us against<br /> any changes in future that may require additional handling. To avoid<br /> falsely flagging users of ioremap(), provide our own ioremap() macro<br /> which simply wraps __ioremap_prot().