CVE-2026-64560

सारांश

लिनक्स कर्नेल में, निम्नलिखित भेद्यता को हल किया गया है: posix-cpu-timers: गैर-नेता exec() रेस के कारण होने वाले UAF को रोकें Wongi और Jungwoo ने एक गैर-नेता exec() से संबंधित रेस को डिकोड और रिपोर्ट किया जिसके परिणामस्वरूप UAF हो सकता है: sys_timer_delete() exec() posix_cpu_timer_del() // पुराने नेता का अवलोकन करता है p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // बिना कार्रवाई के लौटता है if(!sighand) return 0; free_posix_timer(); यह "हानिरहित" है जब तक कि हटाया गया टाइमर सशस्त्र और p->signal में एन्क्यू नहीं किया गया था, क्योंकि exec() पर एक TGID-लक्षित टाइमर विरासत में मिलता है। चूंकि sys_timer_delete() ने अंतर्निहित posix टाइमर ऑब्जेक्ट को मुक्त कर दिया, run_posix_cpu_timers() या अन्य टाइमरों पर कोई भी संबंधित timerqueue add/delete ऑपरेशन मुक्त ऑब्जेक्ट के timerqueue नोड तक पहुंचेगा, जिसके परिणामस्वरूप UAF होता है। posix_cpu_timer_set() के संबंध में भी एक समान समस्या है। नियमित posix टाइमर के लिए यह केवल अस्थायी रूप से उपयोगकर्ता स्थान पर -ESRCH लौटाता है, लेकिन do_cpu_nanosleep() में उपयोग के मामले के लिए यह वही UAF है, बस k_itimer स्टैक पर आवंटित होता है। साथ ही posix_cpu_timer_rearm() टाइमर को फिर से सशस्त्र करने में विफल रहता है, जिसका अर्थ है कि यह समाप्त होना बंद कर देता है। समाधानों पर बहस करते समय Frederic ने एक और समस्या की ओर इशारा किया: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); कमजोर रूप से क्रमबद्ध आर्किटेक्चर पर यह गारंटी नहीं है कि posix_cpu_timer_del() posix_cpu_timers*_exit() में स्टोर का अवलोकन करेगा जब p->sighand को NULL के रूप में देखा जाता है, जिसका अर्थ है कि WARN() एक गलत सकारात्मक हो सकता है। इन मुद्दों को हल करें: 1) __exit_signal() में स्टोर को smp_store_release() में बदलना। 2) lock_task_sighand() के !sighand पथ में smp_acquire__after_ctrl_dep() जोड़ना। 3) कार्य को खोजने और sighand को लॉक करने के लिए एक सहायक फ़ंक्शन बनाना जो sighand == NULL होने पर वापस नहीं लौटता। इसके बजाय यह कार्य लुकअप को पुनः प्रयास करता है और केवल तभी हार मानता है जब वह विफल हो जाता है। 4) उस सहायक का उपयोग तीन प्रभावित फ़ंक्शनों में करना। #1/#2 यह सुनिश्चित करता है कि पाठक पक्ष जो sighand == NULL का अवलोकन करता है, वह सभी पूर्ववर्ती स्टोरों का भी अवलोकन करता है, अर्थात posix_cpu_timers*_exit() में स्टोर और unhash_task() में स्टोर। #3 यह सुनिश्चित करता है कि ऊपर वर्णित गैर-नेता exec() स्थिति को सुचारू रूप से संभाला जाता है। जब कार्य लुकअप पुराने नेता को लौटाता है, लेकिन sighand == NULL तो यह पुनः प्रयास करता है। गैर-नेता exec() मामले में बाद का कार्य लुकअप #1/#2 के कारण नए नेता का अवलोकन करेगा। सामान्य exit() परिदृश्यों में बाद का लुकअप विफल हो जाता है। जब कार्य लुकअप विफल हो जाता है, तो फ़ंक्शन यह भी जांचता है कि क्या टाइमर अभी भी एन्क्यू है और यदि ऐसा है तो चेतावनी जारी करता है। दुर्भाग्य से इसके बारे में कुछ नहीं किया जा सकता है, लेकिन चूंकि कार्य अब दिखाई नहीं दे रहा है, टाइमर को अब एक्सेस नहीं किया जाना चाहिए। यह जांच भी मेमोरी ऑर्डरिंग की आवश्यकता होती है, जो पहले लुकअप के विफल होने पर प्रदान नहीं की जाती है। इसे प्राप्त करने के लिए जांच से पहले एक smp_rmb() होता है जो __exit_signal() में write_seqlock() में smp_wmb() के साथ जोड़ा जाता है। यह सुनिश्चित करता है कि posix_cpu_timers*_exit() में स्टोर दिखाई देते हैं। गैर-नेता exec() मुद्दे का इतिहास posix CPU टाइमर के शुरुआती दिनों तक जाता है, जो टाइमर में समूह नेता कार्य के लिए एक पॉइंटर संग्रहीत करता था। यह स्पष्ट रूप से विफल हो जाता है जब एक गैर-नेता exec() नेता को स्विच करता है। commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") ने 2010 में उसके लिए एक अस्थायी कार्य-समाधान जोड़ा जो ---ट्रंकेटेड---