🤶🏿 👩🏿‍✈️ 🕙 लिनक्स 5.1 में एक बग डेटा हानि का कारण बना - एक सुधार पैच पहले ही जारी किया जा चुका है 🤟 🧙🏿 🏌️

कुछ हफ़्ते पहले, लिनक्स 5.1 कर्नेल संस्करण में एक बग की खोज की गई थी जिससे एसएसडी पर डेटा हानि हुई थी। हाल ही में, डेवलपर्स ने लिनक्स 5.1.5 पैच पैच जारी किया , जिसने "अंतराल" भर दिया।

हम चर्चा करते हैं कि क्या कारण था।

/ अनप्लैश / ग्लेन कैरी

क्या बग?

वर्ष की शुरुआत में, डेवलपर्स ने लिनक्स 5.1 कर्नेल में कई बदलाव किए। उसके बाद, सैमसंग से SSDs के साथ सिस्टम पर जो डिवाइस-मैपर / LVM के साथ dm-crypt / LUKS एन्क्रिप्शन का उपयोग करते हैं, एक त्रुटि दिखाई देने लगी , जिससे डेटा लॉस हो गया। लेकिन समस्या मई के मध्य में ही ज्ञात हो गई - उस समय वे इसे विषयगत मंचों पर सक्रिय रूप से चर्चा करने लगे।

बग के बारे में जानने वाले कम से कम दो लोग जाने जाते हैं: LKML मेलिंग सूची के सदस्य माइकल लॉ are, जिन्होंने पहली बार समस्या की रिपोर्ट की , और ArchLinux उपयोगकर्ता ।

माइकल ने फ्रॉस्टिम कमांड चलाया , जो ड्राइव को बताता है कि माउंट किए गए btrfs वॉल्यूम के लिए कौन से डेटा ब्लॉक अब उपयोग में नहीं हैं। निम्नलिखित सिस्टम संदेश प्राप्त करने के बाद:

attempt to access beyond end of device sda1: rw=16387, want=252755893, limit=250067632 BTRFS warning (device dm-5): failed to trim 1 device(s), last error -5 BTRFS warning (device dm-5): csum failed root 257 ino 16634085 off 21504884736 csum 0xd47cc2a2 expected csum 0xcebd791b mirror 1

उसके बाद, उन्होंने पाया कि btrfs वॉल्यूम दूषित हो गया था और भौतिक डिवाइस पर शेष तार्किक वॉल्यूम नष्ट हो गए थे।

ArchLinux उपयोगकर्ता के मामले में, समस्या ने LUKS के क्रिप्टोग्राफ़िक संरक्षण को प्रभावित किया। ऑपरेटिंग सिस्टम को रिबूट करने और फ्रॉस्टिम चलाने के बाद, एलयूकेएस हेडर (जो वॉल्यूम की खोज के लिए उपयोग किए जाते हैं) अपठनीय थे, जो डिक्रिप्ट किए गए एन्क्रिप्टेड डेटा को अनुमति नहीं देते थे।

क्या कारण है

समस्या डिवाइस मैपर (डीएम) सबसिस्टम थी, जिसका कार्य वर्चुअल ब्लॉक डिवाइस बनाना था। इसका उपयोग LVM लॉजिकल वॉल्यूम मैनेजर, सॉफ्टवेयर RAID और डीएम-क्रिप्ट डिस्क एन्क्रिप्शन सिस्टम को लागू करने के लिए किया जाता है।

“फ्रॉस्टिम टीम ने एक बार में अधिकतम_io_len_target_boundary सीमा को ध्यान में रखे बिना कई ब्लॉकों को चिह्नित किया। नतीजतन, जो मेमोरी सेगमेंट अभी भी उपयोग में हैं, उन्हें मुक्त कर दिया गया है। ”टिप्पणी सेर्गेई बेलकिन, विकास विभाग के प्रमुख 1cloud.ru । "चूंकि त्रुटि डिवाइस मैपर से संबंधित थी, सिद्धांत रूप में, डेटा हानि किसी भी फाइल सिस्टम पर हो सकती है।"

पैच

कर्नेल डेवलपर्स ने मई के अंत में बग के लिए एक पैच जारी किया। ड्राइवर / md / dm.c फ़ाइल में केवल चार लाइनें बदल दी गईं । संबंधित परिवर्तन आगामी लिनक्स 5.2 कर्नेल में भी किए गए (क्रमशः और हटाए गए लाइनों को "+" और "-" के साथ चिह्नित किया गया है):

 @@ -1467,7 +1467,7 @@ static unsigned get_num_write_zeroes_bios(struct dm_target *ti) static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti, unsigned num_bios) { - unsigned len = ci->sector_count; + unsigned len; @@ -1478,6 +1478,8 @@ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target * if (!num_bios) return -EOPNOTSUPP; + len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti)); + __send_duplicate_bios(ci, ti, num_bios, &len); ci->sector += len;

पैच को पहले से ही ArchLinux / Manjaro और Fedora वितरण डेवलपर्स द्वारा लागू किया गया है। उबंटू वितरण ने त्रुटि को प्रभावित नहीं किया , क्योंकि इसे लिनक्स 5.1 कर्नेल संस्करण में अनुवादित नहीं किया गया था।

/ फ़्लिकर / एंडी मेल्टन / सीसी बाय-एसए

आप पैच को स्थापित किए बिना डेटा हानि के साथ स्थिति को समाप्त कर सकते हैं। कमांड का उपयोग करके fstrim.service / टाइमर सेवा को अक्षम करना पर्याप्त है:

 systemctl disable fstrim.timer systemctl stop fstrim.timer

दूसरा विकल्प यह है कि फ़्रेस्सिम निष्पादन योग्य का नाम बदलें या फ़ेस्टब बढ़ते समय ध्वज को हटा दें। आप एलईकेएस में डीएमएसईटूप के माध्यम से अनुमति-डिस्कार्ड को भी बंद कर सकते हैं। हालांकि, ये सभी विधियां अस्थायी से ज्यादा कुछ नहीं हैं और समस्या का सार हल नहीं करती हैं।

पहली बार नहीं

यह पहली बार नहीं है कि लिनक्स कर्नेल में एक स्मृति स्मृति भ्रष्टाचार स्थितियों की ओर जाता है। इसी तरह की कहानी लिनक्स संस्करण 4.19 में हुई थी - तब BLK-MQ I / O शेड्यूलर्स को दोष देना था। CONFIG_SCSI_MQ_DEFAULT = y विकल्प के साथ कर्नेल बनाते समय समस्या प्रकट हुई, डिफ़ॉल्ट रूप से सेट की गई। कुछ मामलों में, वॉल्यूम डेटा दूषित हो गया था ।

 sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107 sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107

सबसे अधिक बार, समस्या खुद EXT4 के साथ प्रकट हुई, लेकिन सिद्धांत रूप में यह अन्य फाइल सिस्टम को प्रभावित कर सकती है।

फिर कर्नेल में से एक अनुरक्षक ने एक छोटा फिक्स तैयार किया जो समस्या को हल करता है। हालाँकि, बाद में उसी बग को लिनक्स 4.20 बिल्ड में खोजा गया था। नए वैश्विक अपडेट के साथ दिसंबर 2018 के अंत में इसे समाप्त करना संभव था।

^{हमारे अतिरिक्त संसाधन और स्रोत:} ^{फ़ाइल बैकअप: डेटा हानि से सुरक्षित कैसे रहें} ^{जोखिम कम से कम: कैसे अपना डेटा खोना नहीं है} ^{बैकअप और रिकवरी: स्ट्रीमिंग और स्मार्ट डुप्लीकेशन, स्नैपशॉट और सेकेंडरी स्टोरेज} ^{एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस का उपयोग करके पैसे कैसे बचाएं} ^{एक उदाहरण के रूप में 1cloud.ru का उपयोग करके क्लाउड सेवा में DevOps} ^{1 क्लॉउड क्लाउड आर्किटेक्चर इवोल्यूशन} ^{हम कैसे काम करते हैं: 1 पच पच} ^{HTTPS पर संभावित हमले और उनसे बचाव के तरीके}

लिनक्स 5.1 में एक बग डेटा हानि का कारण बना - एक सुधार पैच पहले ही जारी किया जा चुका है

क्या बग?

क्या कारण है

पैच

पहली बार नहीं

More articles: