flawopen.com/Teardowns/cve-2025-39682-linux-ktls-zero-length-record-mishandling
Linux CVE-2025-39682: kTLS में शून्य-लंबाई TLS रिकॉर्ड की समस्या
Linux kTLS receive queue में शून्य-लंबाई non-DATA TLS रिकॉर्ड प्रति recvmsg रिकॉर्ड-प्रकार जाँच को पार कर सकता था। सुधार copied bytes शून्य होने पर भी संसाधित रिकॉर्ड प्रकार जाँचता है। Linux के CVSS आकलन में kernel heap से userspace तक जानकारी उजागर होना, memory corruption और दूर से kernel crash होना संभावित प्रभाव बताए गए हैं; ये आकलित परिणाम हैं, यह दावा नहीं कि हर प्रभावित सिस्टम में सभी परिणाम होंगे।
CVSS वेक्टर
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hएक डाक छँटाई की कल्पना करें जिसमें हर ट्रे में केवल एक श्रेणी के पत्र रखे जा सकते हैं। खाली लिफ़ाफ़े की भी श्रेणी होती है, लेकिन पुरानी छँटाई मशीन ट्रे बदलने का निर्णय पत्रों की गिनती से करती थी। शून्य पत्र होने पर वह लिफ़ाफ़े की श्रेणी अनदेखी कर अगले प्रकार को उसी ट्रे में मिला देती थी। kernel सुधार डेटा न होने पर भी श्रेणी-चिह्न जाँचता है।
इस पेज के मुख्य शब्द
kTLS- Kernel TLS: Linux जुड़े TCP socket के लिए TLS records को kernel में संसाधित कर सकता है।
recvmsg()- Socket receive system call, जिसका उपयोग application और kTLS receive path करते हैं।
TLS content type- Record को वर्गीकृत करने वाला field, जैसे application data या control record।
rx_list- Pending receive records की queue, जिसे आगे के recvmsg calls संसाधित करते हैं।
CWE-754- असामान्य या अपवादात्मक स्थितियों की अनुचित जाँच। NVD में
CWE-754, CISA-ADP के स्रोत-निर्देश के साथ सूचीबद्ध है; Linux CVE रिकॉर्ड स्वयं कोई CWE निर्धारित नहीं करता।
फ्रेमवर्क मैपिंग
- इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-754
- CISA KEV — जोड़ा गया 2026-09-18 — CVE-2025-39682
मूल कारण विश्लेषण (Root Cause)
Linux kTLS receive path को हर recvmsg() call में contiguous DATA records या केवल एक non-DATA record लौटाना चाहिए। जब process_rx_list() शुरुआती zero-length non-DATA record संसाधित करता है, तो वह TLS type सेट करके err == 0 लौटा सकता है। tls_sw_recvmsg() उस शून्य को copied में रखता था और stop condition में (copied && control != TLS_RECORD_TYPE_DATA) इस्तेमाल करता था। copied शून्य होने से पहले से संसाधित record type की जाँच छूट जाती थी और आगे के data का processing जारी रहता था। upstream patch सीधे control जाँचता है: type रिपोर्ट हुआ है और DATA नहीं है तो रुकें; शून्य का अर्थ “अभी कोई type रिपोर्ट नहीं हुआ” बना रहता है। समस्या केवल तब लागू होती है जब Linux kernel TLS receive path (kTLS) सक्षम और उपयोग में हो; यह सभी userspace TLS libraries के parser की समस्या नहीं है। Linux का प्रकाशित CVSS 3.1 vector 9.8 Critical है (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)। वास्तविक kTLS उपयोग और vendor kernel स्थिति के आधार पर जोखिम आँकें।
हमले का चरण-दर-चरण प्रवाह
kTLS records प्राप्त करता है
Application kernel TLS receive enabled TCP socket उपयोग करती है।
Queue का zero-length non-DATA record संसाधित होता है
यह तब होता है जब rx_list का पहला record payload रहित हो। Processing type बता सकता है लेकिन copied bytes शून्य लौटाता है।
पुरानी जाँच copied bytes पर निर्भर थी
copied शून्य होने पर पुरानी condition नहीं देखती कि संसाधित type non-DATA था।
Receive loop type सीमा पार करता है
अगले data उसी recvmsg call में संसाधित हो सकते हैं, जो एक-type invariant के विरुद्ध है। Linux के CVSS आकलन में kernel heap से userspace तक जानकारी उजागर होना, memory corruption और दूर से kernel crash होना संभावित प्रभाव बताए गए हैं; ये आकलित परिणाम हैं, यह दावा नहीं कि हर प्रभावित सिस्टम में सभी परिणाम होंगे।
सुधार semantic marker जाँचता है
नई condition control में निर्धारित non-DATA type मिलने पर copied byte count से स्वतंत्र होकर रुकती है।
सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन
यह net/tls/tls_sw.c का अंश है, पूरा function नहीं। upstream सुधार stop predicate में copied bytes के बजाय रिपोर्ट किए गए content-type marker को जाँचता है। control == 0 का अर्थ है कि कोई type रिपोर्ट नहीं हुआ; निर्धारित non-DATA type इस recvmsg call को रोकता है। यह upstream patch का सटीक logic बदलाव है।
सोर्स अंश: स्रोत कोड: net/tls/tls_sw.c
copied = err;
if (len <= copied ||
(copied && control != TLS_RECORD_TYPE_DATA) || rx_more)
goto end;
copied = err;
if (len <= copied || rx_more ||
(control && control != TLS_RECORD_TYPE_DATA))
goto end;
इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट
- ✓Linux kTLS receive सक्षम workloads की सूची बनाएँ; सामान्य userspace TLS अपने-आप प्रभावित नहीं होता।
- ✓सुधार वाला vendor kernel package स्थापित करें और advisory में सटीक build की पुष्टि करें।
- ✓Invariant बनाए रखें: एक recvmsg call contiguous DATA records या एक non-DATA record ही संसाधित करे, type सीमा पार न करे।
- ✓upstream kTLS शून्य-लंबाई रिकॉर्ड regression test चलाएँ या बनाए रखें; downstream receive-path implementations में भी जाँचें कि खाली non-DATA रिकॉर्ड उसी call में अगले रिकॉर्ड को consume न करने दे।
- ✓“कोई type रिपोर्ट नहीं हुआ” और “शून्य bytes कॉपी हुए” को अलग रखें;
controlजैसी semantic state जाँचें। - ✓Patch में देर हो तो kTLS के लिए vendor mitigation अपनाएँ और आवश्यक workloads पर असर जाँचें।