CVE-2022-50675 in Linuxالمعلومات

الملخص

بحسب VulDB • 10/06/2026

في نواة لينكس، تم حل الثغرة التالية:

arm64: mte: تجنب تعيين PG_mte_tagged إذا لم يتم مسح أو استعادة العلامات (tags)

قبل الالتزام 69e3b846d8a7 ("arm64: mte: مزامنة العلامات للصفحات التي يكون فيها PTE غير معلمّم")، كانت دالة `mte_sync_tags()` تُستدعى فقط للعناصر ذات العلامة (`pte_tagged()`) (تلك المرتبطة بـ PROT_MTE). لذلك، كان من الآمن لـ `mte_sync_tags()` استخدام `test_and_set_bit(PG_mte_tagged, &page->flags)` دون تعيين PG_mte_tagged عن غير قصد على صفحة غير معلمّمة.

كان الالتزام المذكور أعلاه ضروريًا لأن الضيوف (guests) قد يمكّنون MTE بدون أي تحكم في خريطة المرحلة الثانية (stage 2 mapping)، ولا يوجد ارتباط PROT_MTE في VMM. ومع ذلك، كان للأثر الجانبي أن أي صفحة تحتوي على PTE يبدو وكأنه تبديل (swap) أو هجرة كانت تحصل تلقائيًا على تعيين PG_mte_tagged. ونسخ الصفحة اللاحق (على سبيل المثال، الهجرة) نسخ العلامات إلى صفحة الوجهة حتى لو كانت العلامات مملوكة لـ KASAN.

تم إخفاء هذه المشكلة بواسطة استدعاء `page_kasan_tag_reset()` الذي أُدخل في الالتزام e5b8d9218951 ("arm64: mte: إعادة تعيين علامة الصفحة في page->flags"). عندما تم التراجع عن هذا الالتزام (20794545c146)، بدأ KASAN بالإبلاغ عن أخطاء الوصول لأن العلامات المتداخلة في صفحة ما لا تتطابق مع `page->flags` الأصلية (مع تفعيل 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]

نقل تعيين بت PG_mte_tagged من `mte_sync_tags()` إلى المكان الفعلي حيث يتم مسح العلامات (`mte_sync_page_tags()`) أو استعادتها (`mte_restore_tags()`).

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

مسؤول

Linux

حجز

09/12/2025

إفشاء

09/12/2025

الاعتدال

تمت الموافقة

إدخال

VDB-334942

EPSS

0.00211

KEV

لا

النشاطات

منخفض جدًا

القطاع

Energy, Police, ...

المصادر

Do you want to use VulDB in your project?

Use the official API to access entries easily!