CVE-2026-98256

सारांश

Linux कर्नेल में, निम्नलिखित भेद्यता को हल किया गया है: signal: exec() रेस को रोकें Hyunwoo ने निम्नलिखित KASAN UAF splat को डीबग किया: BUG: KASAN: slab-use-after-free in __send_signal_locked+0xb27/0xba0 Write of size 8 at addr ffff888007ed80c8 by task poc/79 ... Call Trace: __send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0 __x64_sys_tgkill+0x193/0x270 ... Allocated by task 80: do_timer_create+0x1a4/0x1030 __x64_sys_timer_create+0x145/0x190 ... Freed by task 12: kmem_cache_free_bulk+0x1f8/0x4a0 kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... Last potentially related work creation: kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90 begin_new_exec+0xa6b/0x28c0 यह पता चला कि ऐसा non-leader exec() के साथ होता है, जैसा कि Hyunwoo ने समझाया: de_thread() release_task(leader) से पहले exchange_tids() को कॉल करता है, इसलिए leader के tid के विरुद्ध बनाए गए SIGEV_THREAD_ID टाइमर द्वारा धारित struct pid अब उस थ्रेड की ओर इंगित करता है जिसने execve() को कॉल किया। pid_task() उस थ्रेड को लौटाता है और उस पर lock_task_sighand() सफल होता है। यदि टाइमर सिग्नल ब्लॉक है, तो उसका sigqueue leader के task::pending पर कतारबद्ध रहता है। उस टाइमर की अगली समाप्ति तब चल सकती है जब release_task() कतार को फ्लश कर रहा हो। posixtimer_send_sigqueue() जाँचता है कि sigqueue पहले से कतारबद्ध है या नहीं, एक सादे list_empty() से, जो केवल list_head::next को पढ़ता है। list_del_init() परमाणु (atomic) नहीं है और INIT_LIST_HEAD() list_head::prev से पहले list_head::next को संग्रहीत करता है, इसलिए जाँच बीच में पास हो सकती है। list_add_tail() प्रविष्टि को जीवित थ्रेड के task::pending पर कतारबद्ध करता है, और फ्लश से list_head::prev का संग्रहण उस list_head::prev लिंक को अधिलेखित कर देता है जिसे list_add_tail() ने अभी सेट किया है। __flush_itimer_signals() भी उसे पूर्ववत नहीं करता। list_head::prev के प्रविष्टि स्वयं की ओर इंगित करने पर, इसका list_del_init() केवल वही मान फिर से संग्रहीत करता है, इसलिए प्रविष्टि सूची से हटाई नहीं जाती। अंतिम संदर्भ के हटने और टाइमर के RCU द्वारा मुक्त होने के बाद भी यह वहीं रहती है, और बाद के tgkill() का list_add_tail() उस list_head::prev का अनुसरण करते हुए मुक्त किए गए टाइमर में चला जाता है। यह समस्या हाल के उस commit के साथ सामने आई जिसने sigqueue फ्लश को sighand लॉक के अधीन क्षेत्र से बाहर स्थानांतरित किया था। Hyonwoo ने इसे list_del_init_careful() का उपयोग करके ठीक करने का प्रस्ताव रखा, लेकिन वह केवल समस्या को ढकता है। कुछ चर्चाओं और इसे हल करने के विभिन्न प्रयासों के बाद, Eric ने बताया कि release_task() में देर से task::pending को फ्लश करने का कोई कारण नहीं है और यह exit_signals() में ही किया जाना चाहिए। चूँकि मरते हुए कार्य की pending कतार में कतारबद्ध सिग्नलों को कोई एकत्र और वितरित नहीं कर सकता, इसे और अधिक विलंबित करने का कोई कारण नहीं है। लेकिन यह सुनिश्चित करना होगा कि उस बिंदु के बाद उसमें कोई सिग्नल कतारबद्ध न हो सके। exit_signals() task::flags में PF_EXITING सेट करता है, जिसे इसके संकेतक के रूप में उपयोग किया जा सकता है। इसे निम्न प्रकार से ठीक करें: - __send_signal_locked() और posixtimer_send_sigqueue() में जब कार्य में PF_EXITING सेट हो तो task private सिग्नलों (PIDTYPE_PID) के लिए सिग्नल कतारबद्ध करने से रोकें। - exit_signals() में task group खाली होने और group exit मामले के लिए PF_EXITING के बिना लॉक वाले सेटिंग को sighand लॉक के साथ सुरक्षित करें। - वहीं task::pending सिग्नलों को फ्लश करें। इसे अनुकूलित करें: sighand लॉक के अधीन पूरी pending सूची को on-stack सूची शीर्ष पर ले जाएँ और सिग्नलों को लॉक के बिना मुक्त करें। लॉकलेस फ्लश और कमजोर क्रम वाले सिस्टम पर non-leader exec मामले के बारे में काफी चर्चा हुई है। समस्या यह है कि एक तीसरा पक्ष जो posix टाइमर सिग्नल भेजने का प्रयास करता है, लक्ष्य कार्य को खोजने के लिए PID लुकअप पर निर्भर करता है और वह लुकअप नए leader में परिणत हो सकता है जब सिग्नल मूल रूप से पुराने leader को निर्देशित था। यदि सिग्नल पुराने leader पर कतारबद्ध था तो लॉकलेस फ्लश ने निम्नलिखित स्थिति पर चिंता जताई: old_leader new_leader third party A: flush_list() // list_del_in ---truncated---