CVE-2026-98432

सारांश

Linux कर्नेल में, निम्नलिखित भेद्यता को हल किया गया है: ipv4: RCU grace period के बाद inet_opt और ireq_opt को मुक्त करें tcp_v4_syn_recv_sock() ireq->ireq_opt का स्वामित्व चाइल्ड सॉकेट (newinet->inet_opt) को कॉपी किए बिना स्थानांतरित करता है। एक अन्य cpu एक साथ उसी request socket के लिए पुनःप्रेषित SYN को प्रोसेस कर सकता है, और tcp_check_req() से SYNACK भेज सकता है। tcp_v4_send_synack() और inet_csk_route_req() केवल rcu_read_lock() के अंतर्गत ireq->ireq_opt पढ़ते हैं, और फिर ip_build_and_send_pkt() और ip_options_build() opt->optlen को दो बार पढ़ते हैं। ध्यान दें कि SYNACK टाइमर स्वयं कोई समस्या नहीं है: यह अपने request socket पर एक संदर्भ रखता है, और inet_csk_reqsk_queue_drop() चाइल्ड के मुक्त होने से पहले timer_delete_sync() को कॉल करता है। कमिट 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") के बाद से, request sockets को listener lock रखे बिना प्रोसेस किया जाता है, इसलिए SYNACK के अभी भी बनाए जाने के दौरान चाइल्ड सॉकेट को मुक्त होने से रोकने वाला कुछ भी नहीं है। TCP चाइल्ड सॉकेट्स में SOCK_RCU_FREE नहीं होता है, और inet_sock_destruct() inet_opt को एक साधारण kfree() के साथ मुक्त करता है, जिससे ip_options_build() में use-after-free होता है। इसी तरह की समस्या request socket migration (net.ipv4.tcp_migrate_req=1, या एक BPF_SK_REUSEPORT_SELECT_OR_MIGRATE प्रोग्राम) के साथ भी मौजूद है। reqsk_timer_handler() request socket को inet_reqsk_clone() के साथ क्लोन करता है, ताकि पुराना request socket और उसका क्लोन समान ireq_opt साझा करें, फिर reqsk_migrate_reset() पुराने में पॉइंटर को साफ़ करता है। पुराने request socket पर संदर्भ रखने वाला एक अन्य cpu अभी भी इन विकल्पों का उपयोग कर रहा हो सकता है (SYNACK भेजना, या tcp_v4_syn_recv_sock() में चाइल्ड बनाना) जब क्लोन मुक्त होता है, और tcp_v4_reqsk_destructor() भी एक साधारण kfree() का उपयोग करता है। पाठक पहले से ही RCU का उपयोग करते हैं, और inet_opt को प्रतिस्थापित करने वाले अन्य पथ (do_ip_setsockopt(), cipso_v4_sock_setattr()...) पहले से ही kfree_rcu() का उपयोग करते हैं। inet_sock_destruct() और tcp_v4_reqsk_destructor() में भी kfree_rcu() का उपयोग करें। IPv6 पहली समस्या से प्रभावित नहीं है, क्योंकि tcp_v6_syn_recv_sock() विकल्पों की प्रतिलिपि बनाता है। tcp_v6_reqsk_destructor() में ipv6_opt के साथ वही migration समस्या है, जो केवल CALIPSO द्वारा सेट किया जाता है। इसे एक अलग पैच में संबोधित किया जाएगा।

स्रोत

• kernel98scan