CVE-2026-46242

सारांश

लिनक्स कर्नेल में, निम्नलिखित भेद्यता हल की गई है: eventpoll: ep_remove struct eventpoll / struct file UAF को ठीक करता है ep_remove() (ep_remove_file() के माध्यम से) ने file->f_ep को file->f_lock के अंतर्गत साफ़ किया, लेकिन फिर क्रिटिकल सेक्शन के अंदर @file का उपयोग करता रहा (is_file_epoll(), हेड के माध्यम से hlist_del_rcu(), spin_unlock)। उस विंडो में eventpoll_release() fastpath लेने वाले एक समवर्ती __fput() ने क्षणिक NULL देखा, eventpoll_release_file() को छोड़ दिया और f_op->release / file_free() तक चला गया। epoll-watches-epoll मामले के लिए, f_op->release, ep_eventpoll_release() -> ep_clear_and_put() -> ep_free() है, जो देखे गए struct eventpoll को kfree() करता है। इसका एम्बेडेड ->refs hlist_head ठीक वही है जहाँ epi->fllink.pprev इंगित करता है, इसलिए बाद में hlist_del_rcu() का "*pprev = next" मुक्त किए गए kmalloc-192 मेमोरी में लिखता है। इसके अलावा, struct file SLAB_TYPESAFE_BY_RCU है, इसलिए @file को बैक करने वाला स्लॉट alloc_empty_file() द्वारा पुनर्चक्रित किया जा सकता है -- f_lock और f_ep को फिर से आरंभ करते हुए -- जबकि ep_remove() नाममात्र रूप से अभी भी उस लॉक के अंदर है। परिणाम गलत स्लैब कैश के खिलाफ एक हमलावर-नियंत्रणीय kmem_cache_free() है। ep_remove() के शीर्ष पर epi_fget() के माध्यम से @file को पिन करें और पिन सफल होने पर क्रिटिकल सेक्शन को गेट करें। पिन पकड़े रहने पर @file refcount शून्य तक नहीं पहुँच सकता, जो __fput() को रोके रखता है और परोक्ष रूप से देखे गए struct eventpoll को hlist_del_rcu() और f_lock उपयोग के दौरान जीवित रखता है, जिससे दोनों UAF बंद हो जाते हैं। यदि पिन विफल हो जाता है, तो @file पहले ही refcount शून्य तक पहुँच चुका है और इसका __fput() चालू है। चूँकि हम f_ep को साफ़ करने से पहले बाहर निकल गए, वह पथ eventpoll_release() slow path को eventpoll_release_file() में ले जाता है और तब तक ep->mtx पर ब्लॉक करता है जब तक वेटर पक्ष का ep_clear_and_put() इसे छोड़ नहीं देता। बाहर निकले epi का ep->refcount में हिस्सा बरकरार रहता है, इसलिए ep_clear_and_put() में अंतिम ep_refcount_dec_and_test() eventpoll_release_file() के नीचे से eventpoll को मुक्त नहीं कर सकता; अनाथ epi को फिर वहाँ साफ़ किया जाता है। एक सफल पिन यह भी साबित करता है कि हम इस epi पर eventpoll_release_file() के साथ रेस नहीं कर रहे हैं, इसलिए f_lock के अंतर्गत epi->dying की अब अनावश्यक पुनर्जाँच को हटा दें। सस्ता lockless READ_ONCE(epi->dying) fast-path बेलआउट बना रहता है।