CVE-2026-74580

सारांश

Linux कर्नेल में, निम्नलिखित भेद्यता को हल कर दिया गया है: vhost: vring पुनःकॉन्फ़िगरेशन पर vring मेटाडेटा कैश को रीसेट करें vq->meta_iotlb[] उस vhost_iotlb_map को कैश करता है जो प्रत्येक vring मेटाडेटा क्षेत्र को सहारा देता है, और iotlb_access_ok() कैश हिट पर जल्दी लौट आता है, इस हिट को इस प्रमाण के रूप में लेते हुए कि क्षेत्र पहले ही मान्य हो चुका है: if (vhost_vq_meta_fetch(vq, addr, len, type)) return true; कैश VHOST_IOTLB_UPDATE और VHOST_IOTLB_INVALIDATE पर, डिवाइस IOTLB (पुनः)आरंभीकरण पर और vq रीसेट पर रीसेट होता है, लेकिन तब नहीं जब VHOST_SET_VRING_ADDR vq->desc, vq->avail और vq->used को प्रतिस्थापित करता है, और न ही तब जब VHOST_SET_VRING_NUM क्षेत्र के आकार बदलता है। डिवाइस IOTLB संलग्न होने पर दोनों ioctl तब स्वीकार किए जाते हैं जब vq सक्रिय होता है, और ioctl के समय इनमें से कोई भी पतों को मान्य नहीं करता: vq_access_ok() और vq_log_used_access_ok() जल्दी true लौटाते हैं क्योंकि पते GIOVA हैं, जिससे मान्यकरण prefetch समय तक टाल दिया जाता है। एक बार कैश भर जाने के बाद वह टाला गया मान्यकरण अब नहीं चलता -- vq_meta_prefetch() पुरानी प्रविष्टि पर हिट करता है और true लौटाता है -- और vhost_vq_meta_fetch() पुराने मैपिंग के माध्यम से map->addr + addr - map->start के रूप में उस पते के लिए अनुवाद करता रहता है जिसे मैपिंग अब कवर नहीं करती। vhost_copy_to_user() और vhost_copy_from_user() परिणाम को __copy_to_user() और __copy_from_user() के साथ उपभोग करते हैं, जो इसे भी जाँचते नहीं हैं, इसलिए बाद में used ring अपडेट या descriptor fetch उस क्षेत्र के बाहर की मेमोरी तक पहुँचता है जिसे IOTLB वास्तव में मैप करता है। जब भी vring पुनःकॉन्फ़िगर हो, मेटाडेटा कैश को रीसेट करें, ताकि नए पते iotlb_access_ok() के धीमे पथ से फिर से गुजारे जाएँ।

स्रोत

• security-researchPoC

  Linux कर्नेल की प्रकट की गई कमज़ोरियों के लिए प्रूफ़-ऑफ़-कॉन्सेप्ट C कोड और राइटअप, जिनमें प्रति-CVE एक्सप्लॉइट स्रोत और तकनीकी विश्लेषण शामिल हैं।