Roger Pau

x86 PV guests can free memory pages while maintaining a stale TLB (Translation Lookaside Buffer) entry pointing to them. A TLB flush is only issued by Xen when the page is re-used. Because a page can be scrubbed before the TLB flush occurs, a window exists where a PV guest can modify a page that has already been scrubbed.

تقوم بعض مسارات أخطاء الترحيل الظلي بتبديل جداول الصفحات دون تحديث مرجع وحدة المعالجة المركزية الافتراضية (vCPU) قيد التشغيل حاليًا. ويؤدي ذلك إلى حدوث عدم تطابق بين جداول الصفحات المحملة وبيانات تعريف ذاكرة التخزين المؤقتة (mapcache)، مما قد يؤدي إلى تلف ذاكرة التخزين المؤقتة.

يتضمن كود الترحيل (paging) الخاص بـ Intel EPT تحسينًا يؤجل مسح حالة EPT المخزنة مؤقتًا حتى يتم تحرير قفل p2m. ومع ذلك، لا يتم تأجيل تحرير هياكل الترحيل، مما قد يؤدي إلى وجود إدخالات قديمة تشير إلى مناطق ذاكرة لا يملكها الضيف. وقد يتيح ذلك الوصول إلى مناطق ذاكرة غير مقصودة. قد تسمح هذه المشكلة لرمز ذي امتيازات في جهاز افتراضي ضيف بتعريض نظام المضيف للخطر.

اسم البرنامج المعرض للثغرة والإصدارات المتأثرة: لا يمكن تحديد اسم المنتج. (الإصدارات المتأثرة غير محددة) **الوصف** الثغرة قيد التحليل حاليًا. **التوصيات** لا توجد حاليًا أي معلومات حول إصدار أحدث يتضمن تصحيحًا لهذه الثغرة.

تتعلق المشكلة ببرنامج Xen، وهو برنامج تشغيل افتراضي متعدد المنصات موجود في نواة نظام التشغيل Linux. وترتبط هذه المشكلة بأخطاء في التزامن عند استخدام مورد مشترك، وبحالة تنافس أثناء تعيين صفحة مرجعية لـ «عداد الطابع الزمني» (TSC). وقد يؤدي الاستغلال الناجح لهذه الثغرة إلى تمكين مهاجم عن بُعد من اختراق برنامج التشغيل الافتراضي أو النظام المعرض للخطر.

الثغرة قيد التحليل حاليًا.

The issue arises from a mismatch in the IOMMU quarantine page table levels. On systems with no RAM above the 512GB mark, only 3 page-table levels are configured in the IOMMU, while the quarantine domain is initialized with 4 page table levels. This results in a device in quarantine mode gaining write access to the page destined to be a PDE, potentially leading to data leaks. The sink page the device gets read/write access to is no longer cleared between device assignment.

The caching invalidation guidelines from the AMD-Vi specification are incorrect on some hardware, leading to devices malfunctioning if some fields of the DTE are updated but the IOMMU TLB is not flushed. This can cause stale DMA mappings, allowing access to unintended memory regions not owned by the guest.

The issue is related to the functionality of phantom functions in PCI devices, which can generate requests using the IDs of unpopulated functions, allowing a device to extend the number of outstanding requests. However, failure to set up the IOMMU context for these phantom functions is not fatal when the device is assigned, leading to potential security issues. This can result in the primary device being assigned to a guest, while some phantom functions are assigned to a different domain. The vulnerability is related to insufficient access control due to incorrect input validation when generating requests.

The issue arises in environments where host assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, causing Xen to run guests in shadow mode. Due to insufficient checks in hypervisor routines for shadow page handling, a guest with a passed-through PCI device can cause the hypervisor to access an arbitrary pointer partially under guest control.

The issue is related to information disclosure in the Xen hypervisor and Linux kernel. It may allow an attacker to gain unauthorized access to protected information or cause a denial of service.

The issue is related to information disclosure in the Xen hypervisor and Linux kernel. It may allow an attacker to gain unauthorized access to protected information or cause a denial of service.

The issue is related to a disclosure of information in the Xen hypervisor and Linux kernel. It may allow a remote attacker to gain unauthorized access to protected information.

The issue is related to a disclosure of information in the Xen hypervisor Linux kernel. It may allow a remote attacker to gain unauthorized access to protected information.

The issue arises from racy interactions between dirty vram tracking and paging log dirty hypercalls. Activation of log dirty mode done by `XEN DMOP track dirty vram` (previously named `HVMOP track dirty vram` before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to `XEN DMOP track dirty vram` can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (`XEN DOMCTL SHADOW OP OFF`). This is due to the lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak.