arm64: io: Reject non-user protection in ioremap_prot()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.6.158, 6.12.112, 6.18.55, 6.20, 7.2.9
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Linux kernel's arm64 I/O remapping code (ioremap_prot()) is affected, so systems running affected kernels are impacted. A local user who maps a PROT_NONE or execute-only page through /dev/mem can trigger a spurious kernel warning when another process's command line is read, and the fix makes such accesses fail cleanly instead.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- Record last updated
- First seen by cve.now
Affected versions
- Linux Linux
From 64858b76ec67c5fc40fef8ec1841fecb78c1ebde · fixed in fddc90d4af4550af410f52d11bbf6b5f36443838; From eeecafce5afffb4da703666ebefbd4d6e2a5abf6 · fixed in 0b04af3d88bb7fc69b2d92457890608860e42365; From 3d64dcc0799c2d6921ba027716b7be721eb19fa8 · fixed in b17aa4955e3a694c663ebe99626e4c76ca4f7cfb; From 8f098037139b294050053123ab2bc0f819d08932 · fixed in 9b583795feb51f8d50203228d001760d1344ef01; From 8f098037139b294050053123ab2bc0f819d08932 · fixed in bb756b11ad63832ebee58caf9e8f9381eaecff9f; From 6.6.143 · fixed in 6.6.158; From 6.12.93 · fixed in 6.12.112; From 6.18.17 · fixed in 6.18.55; From 6.19.7 · fixed in 6.20
- Linux Linux
7.0
- KernelLinux
fixed in 6.6.158; From 6.7.0 · fixed in 6.12.112; From 6.13.0 · fixed in 6.18.55; From 6.19.0 · fixed in 7.2.9