CVE-2026-68398

सारांश

# लिनक्स कर्नेल में निम्नलिखित भेद्यता का समाधान किया गया है: ppp: pppol2tp RX UAF को ठीक करने के लिए चैनल मुक्ति को RCU ग्रेस अवधि तक स्थगित करें pppol2tp_recv() L2TP UDP-encap softirq RX पथ में चलता है: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) यह rcu_read_lock() के अंतर्गत केवल l2tp_session संदर्भ धारण करके चलता है और आंतरिक PPP चैनल (struct channel, chan->ppp) पर कोई संदर्भ नहीं लेता है, जिसे ppp_input() डीरेफरेंस करता है। pppox सॉकेट SOCK_RCU_FREE है, इसलिए 'po' और एम्बेडेड ppp_channel RCU-सुरक्षित हैं। लेकिन आंतरिक struct channel एक अलग आवंटन है जिसे ppp_release_channel() एक साधारण kfree() के साथ मुक्त करता है: close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) एक ऐसे चैनल के लिए जो बाउंड (PPPIOCGCHAN) है लेकिन किसी ppp यूनिट से जुड़ा नहीं है (कोई PPPIOCCONNECT नहीं, pch->ppp == NULL) और ब्रिज्ड नहीं है, टियरडाउन ppp_disconnect_channel() के synchronize_net() और ppp_unbridge_channels() के synchronize_rcu() दोनों को छोड़ देता है, इसलिए kfree() में कोई ग्रेस अवधि नहीं होती। pppol2tp_recv() में rcu_read_lock() एक साधारण kfree() के विरुद्ध सुरक्षा नहीं करता है, इसलिए एक CPU पर चल रहा ppp_input() दूसरे CPU पर close() द्वारा अभी-अभी मुक्त किए गए चैनल को डीरेफरेंस कर सकता है। यह बग एक अन-प्रिविलेज्ड उपयोगकर्ता द्वारा पहुंच योग्य है। चैनल मुक्ति को call_rcu() के माध्यम से RCU कॉलबैक में स्थगित करें ताकि ग्रेस अवधि किसी भी चल रहे ppp_input() को अवरुद्ध कर सके। डिस्कनेक्ट और अनब्रिज टियरडाउन पथ पहले से ही synchronize_net()/synchronize_rcu() के साथ अवरोधित हैं; call_rcu() यहाँ भी वही करता है बिना close() पथ को रोके।

• CVE-2026-68398एक्सप्लॉइट

  CVE-2026-68398 Ubuntu PPPoL2TP use-after-free स्थानीय विशेषाधिकार वृद्धि