CVE-2022-50675

arm64: mte: Avoid setting PG_mte_tagged if no tags cleared or restored

N/A
Published: December 9, 2025 at 01:29 AM UTC
Updated: June 17, 2026 at 05:23 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: arm64: mte: Avoid setting PG_mte_tagged if no tags cleared or restored Prior to commit 69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE is untagged"), 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, &page->flags) without inadvertently setting PG_mte_tagged on an untagged page. 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. This issue was masked by the page_kasan_tag_reset() call introduced in commit e5b8d9218951 ("arm64: mte: reset the page tag in page->flags"). When this commit was reverted (20794545c146), KASAN started reporting access faults because the overriding tags in a page did not match the original page->flags (with CONFIG_KASAN_HW_TAGS=y): 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] Move the PG_mte_tagged bit setting from mte_sync_tags() to the actual place where tags are cleared (mte_sync_page_tags()) or restored (mte_restore_tags()).

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

5.14 ≤ v < 5.15.825.14 ≤ v < 6.0.35.14 ≤ v < 6.15.1469e3b846d8a753f9f279f29531ca56b0f7563ad0
Vendor states this is fixed in 749e9fc18b1e1a3f93a9512e91bd7f93002d2821 (fixed)
Vendor states this is fixed in 918002bdbe4328c8c0164a22e8ebf2384b80dc23 (fixed)
Vendor states this is fixed in a8e5e5146ad08d794c58252bab00b261045ef16d (fixed)
Vendor states this is fixed in 5.14 (unaffected)
Vendor states this is fixed in 5.15.82 (unaffected)
Vendor states this is fixed in 6.0.3 (unaffected)
Vendor states this is fixed in 6.1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusDEFERRED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card