<?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>Sun, 04 Oct 2026 00:34:25 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-50675 — arm64: mte: Avoid setting PG_mte_tagged if no tags cleared or restored</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-50675</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: mte: Avoid setting PG_mte_tagged if no tags cleared or restored&lt;/p&gt;
&lt;p&gt;Prior to commit 69e3b846d8a7 (&amp;#34;arm64: mte: Sync tags for pages where PTE
is untagged&amp;#34;), mte_sync_tags() was only called for pte_tagged() entries
(those mapped with PROT_MTE). Therefore mte_sync_tags() could safely use
test_and_set_bit(PG_mte_tagged, &amp;amp;page-&amp;gt;flags) without inadvertently
setting PG_mte_tagged on an untagged page.&lt;/p&gt;
&lt;p&gt;The above commit was required as guests may enable MTE without any
control at the stage 2 mapping, nor a PROT_MTE mapping in the VMM.
However, the side-effect was that any page with a PTE that looked like
swap (or migration) was getting PG_mte_tagged set automatically. A
subsequent page copy (e.g. migration) copied the tags to the destination
page even if the tags were owned by KASAN.&lt;/p&gt;
&lt;p&gt;This issue was masked by the page_kasan_tag_reset() call introduced in
commit e5b8d9218951 (&amp;#34;arm64: mte: reset the page tag in page-&amp;gt;flags&amp;#34;).
When this commit was reverted (20794545c146), KASAN started reporting
access faults because the overriding tags in a page did not match the
original page-&amp;gt;flags (with CONFIG_KASAN_HW_TAGS=y):&lt;/p&gt;
&lt;p&gt;BUG: KASAN: invalid-access in copy_page+0x10/0xd0 arch/arm64/lib/copy_page.S:26
  Read at addr f5ff000017f2e000 by task syz-executor.1/2218
  Pointer tag: [f5], memory tag: [f2]&lt;/p&gt;
&lt;p&gt;Move the PG_mte_tagged bit setting from mte_sync_tags() to the actual
place where tags are cleared (mte_sync_page_tags()) o…&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: mte: Avoid setting PG_mte_tagged if no tags cleared or restored&lt;/p&gt;
&lt;p&gt;Prior to commit 69e3b846d8a7 (&amp;#34;arm64: mte: Sync tags for pages where PTE
is untagged&amp;#34;), mte_sync_tags() was only called for pte_tagged() entries
(those mapped with PROT_MTE). Therefore mte_sync_tags() could safely use
test_and_set_bit(PG_mte_tagged, &amp;amp;page-&amp;gt;flags) without inadvertently
setting PG_mte_tagged on an untagged page.&lt;/p&gt;
&lt;p&gt;The above commit was required as guests may enable MTE without any
control at the stage 2 mapping, nor a PROT_MTE mapping in the VMM.
However, the side-effect was that any page with a PTE that looked like
swap (or migration) was getting PG_mte_tagged set automatically. A
subsequent page copy (e.g. migration) copied the tags to the destination
page even if the tags were owned by KASAN.&lt;/p&gt;
&lt;p&gt;This issue was masked by the page_kasan_tag_reset() call introduced in
commit e5b8d9218951 (&amp;#34;arm64: mte: reset the page tag in page-&amp;gt;flags&amp;#34;).
When this commit was reverted (20794545c146), KASAN started reporting
access faults because the overriding tags in a page did not match the
original page-&amp;gt;flags (with CONFIG_KASAN_HW_TAGS=y):&lt;/p&gt;
&lt;p&gt;BUG: KASAN: invalid-access in copy_page+0x10/0xd0 arch/arm64/lib/copy_page.S:26
  Read at addr f5ff000017f2e000 by task syz-executor.1/2218
  Pointer tag: [f5], memory tag: [f2]&lt;/p&gt;
&lt;p&gt;Move the PG_mte_tagged bit setting from mte_sync_tags() to the actual
place where tags are cleared (mte_sync_page_tags()) o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-50675</guid>
    </item>
  </channel>
</rss>
