In the Linux kernel, the following vulnerability has been resolved:
arm64: mte: Avoid setting PGmtetagged if no tags cleared or restored
Prior to commit 69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE is untagged"), mtesynctags() was only called for ptetagged() entries (those mapped with PROTMTE). Therefore mtesynctags() could safely use testandsetbit(PGmtetagged, &page->flags) without inadvertently setting PGmte_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 PROTMTE mapping in the VMM. However, the side-effect was that any page with a PTE that looked like swap (or migration) was getting PGmte_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 pagekasantagreset() 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 CONFIGKASANHWTAGS=y):
BUG: KASAN: invalid-access in copypage+0x10/0xd0 arch/arm64/lib/copypage.S:26 Read at addr f5ff000017f2e000 by task syz-executor.1/2218 Pointer tag: [f5], memory tag: [f2]
Move the PGmtetagged bit setting from mtesynctags() to the actual place where tags are cleared (mtesyncpagetags()) or restored (mterestore_tags()).
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/50xxx/CVE-2022-50675.json"
}