<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 03:07:25 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-23346 — arm64: io: Extract user memory type in ioremap_prot()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-23346</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;arm64: io: Extract user memory type in ioremap_prot()&lt;/p&gt;
&lt;p&gt;The only caller of ioremap_prot() outside of the generic ioremap()
implementation is generic_access_phys(), which passes a &amp;#39;pgprot_t&amp;#39; value
determined from the user mapping of the target &amp;#39;pfn&amp;#39; being accessed by
the kernel. On arm64, the &amp;#39;pgprot_t&amp;#39; 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:&lt;/p&gt;
&lt;p&gt;| 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&lt;/p&gt;
&lt;p&gt;Extract only the memory type from the user &amp;#39;pgprot_t&amp;#39; in ioremap_prot()
and assert that we&amp;#39;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().&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;arm64: io: Extract user memory type in ioremap_prot()&lt;/p&gt;
&lt;p&gt;The only caller of ioremap_prot() outside of the generic ioremap()
implementation is generic_access_phys(), which passes a &amp;#39;pgprot_t&amp;#39; value
determined from the user mapping of the target &amp;#39;pfn&amp;#39; being accessed by
the kernel. On arm64, the &amp;#39;pgprot_t&amp;#39; 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:&lt;/p&gt;
&lt;p&gt;| 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&lt;/p&gt;
&lt;p&gt;Extract only the memory type from the user &amp;#39;pgprot_t&amp;#39; in ioremap_prot()
and assert that we&amp;#39;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().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-23346</guid>
    </item>
  </channel>
</rss>
