Answer in brief
CVE-2026-23346 records a Medium severity (CVSS 5.5) vulnerability in arm64: io: Extract user memory type in ioremap_prot(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 5.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=893dea9ccd08dab924839354aba21d4ed7a9abc0 <64858b76ec67c5fc40fef8ec1841fecb78c1ebde || >=893dea9ccd08dab924839354aba21d4ed7a9abc0 <eeecafce5afffb4da703666ebefbd4d6e2a5abf6 || >=893dea9ccd08dab924839354aba21d4ed7a9abc0 <3d64dcc0799c2d6921ba027716b7be721eb19fa8 || >=893dea9ccd08dab924839354aba21d4ed7a9abc0 <d1ad8fe7f72d73e1617bac79f2ec7a3bedf47e2a || >=893dea9ccd08dab924839354aba21d4ed7a9abc0 <8f098037139b294050053123ab2bc0f819d08932 | 64858b76ec67c5fc40fef8ec1841fecb78c1ebde, eeecafce5afffb4da703666ebefbd4d6e2a5abf6, 3d64dcc0799c2d6921ba027716b7be721eb19fa8, d1ad8fe7f72d73e1617bac79f2ec7a3bedf47e2a, 8f098037139b294050053123ab2bc0f819d08932 |
| Linux/Linuxgeneric | 6.0 | Not reported |
Published upstream
Mar 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jun 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 19, 2026
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().
Quoted source text, attributed separately from HOL analysis.