היזהרו מפגיעות שמביאות לסבבי עבודה. חלק 1: FragmentSmack/SegmentSmack

שלום לכולם! שמי דמיטרי סמסונוב, אני עובד כמנהל מערכת מוביל ב- Odnoklassniki. יש לנו יותר מ-7 אלף שרתים פיזיים, 11 אלף קונטיינרים בענן שלנו ו-200 אפליקציות, אשר בתצורות שונות יוצרות 700 אשכולות שונים. הרוב המכריע של השרתים מריצים CentOS 7.
ב-14 באוגוסט 2018 פורסם מידע על פגיעות FragmentSmack
(CVE-2018-5391) ו- SegmentSmack (CVE-2018-5390). מדובר בנקודות תורפה עם וקטור התקפת רשת וציון גבוה למדי (7.5), המאיים על מניעת שירות (DoS) עקב מיצוי משאבים (CPU). תיקון ליבה עבור FragmentSmack לא הוצע באותו זמן; יתר על כן, הוא יצא הרבה יותר מאוחר מפרסום המידע על הפגיעות. כדי לחסל את SegmentSmack, הוצע לעדכן את הליבה. חבילת העדכון עצמה שוחררה באותו יום, כל שנותר היה להתקין אותה.
לא, אנחנו בכלל לא נגד עדכון הקרנל! עם זאת, יש ניואנסים...

כיצד אנו מעדכנים את הליבה בהפקה

באופן כללי, שום דבר לא מסובך:

1. הורדת חבילות;
2. התקן אותם במספר שרתים (כולל שרתים המארחים את הענן שלנו);
3. ודא ששום דבר לא שבור;
4. ודא שכל הגדרות הליבה הסטנדרטיות מיושמות ללא שגיאות;
5. המתן כמה ימים;
6. בדוק את ביצועי השרת;
7. החלף פריסה של שרתים חדשים לקרנל החדש;
8. עדכן את כל השרתים לפי מרכז נתונים (מרכז נתונים אחד בכל פעם כדי למזער את ההשפעה על המשתמשים במקרה של בעיות);
9. הפעל מחדש את כל השרתים.

חזור על כל הענפים של הגרעינים שיש לנו. כרגע זה:

• Stock CentOS 7 3.10 - עבור רוב השרתים הרגילים;
• וניל 4.19 - לשלנו עננים של ענן אחד, כי אנחנו צריכים BFQ, BBR וכו';
• Elrepo kernel-ml 5.2 - עבור מפיצים עמוסים מאוד, כי פעם 4.19 התנהג לא יציב, אבל יש צורך באותן תכונות.

כפי שאולי ניחשתם, אתחול מחדש של אלפי שרתים לוקח את הזמן הארוך ביותר. מכיוון שלא כל הפגיעויות קריטיות עבור כל השרתים, אנו מאתחלים רק את אלה שנגישים ישירות מהאינטרנט. בענן, כדי לא להגביל את הגמישות, אנחנו לא קושרים קונטיינרים נגישים חיצונית לשרתים בודדים עם קרנל חדש, אלא מאתחלים את כל המארחים ללא יוצא מן הכלל. למרבה המזל, ההליך שם פשוט יותר מאשר בשרתים רגילים. לדוגמה, קונטיינרים חסרי מדינה יכולים פשוט לעבור לשרת אחר במהלך אתחול מחדש.

עם זאת, יש עדיין הרבה עבודה, וזה יכול לקחת כמה שבועות, ואם יש בעיות עם הגרסה החדשה, עד כמה חודשים. התוקפים מבינים זאת היטב, אז הם צריכים תוכנית ב'.

FragmentSmack/SegmentSmack. דרך לעקיפת הבעיה

למרבה המזל, עבור נקודות תורפה מסוימות קיימת תוכנית B כזו, והיא נקראת Workaround. לרוב, זהו שינוי בהגדרות ליבה/אפליקציה שיכול למזער את ההשפעה האפשרית או לבטל לחלוטין את ניצול הפגיעויות.

במקרה של FragmentSmack/SegmentSmack הוצע הפתרון הזה:

«אתה יכול לשנות את ערכי ברירת המחדל של 4MB ו-3MB ב-net.ipv4.ipfrag_high_thresh ו-net.ipv4.ipfrag_low_thresh (והמקבילים שלהם עבור ipv6 net.ipv6.ipfrag_high_thresh ו-net.ipv6.ipfrag_low_thresh) ו-256 kB בהתאמה. נמוך יותר. בדיקות מראות ירידה קטנה עד משמעותית בשימוש במעבד במהלך התקפה בהתאם לחומרה, להגדרות ולתנאים. עם זאת, עשויה להיות השפעה מסוימת על הביצועים עקב ipfrag_high_thresh=192 בתים, מכיוון שרק שני מקטעים של 262144K יכולים להתאים לתור ההרכבה מחדש בכל פעם. לדוגמה, יש סיכון שיישומים שעובדים עם מנות UDP גדולות יישברו".

הפרמטרים עצמם בתיעוד הליבה מתואר כדלקמן:

ipfrag_high_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments before the kernel
    begins to remove incomplete fragment queues to free up resources.
    The kernel still accepts new fragments for defragmentation.

אין לנו UDPs גדולים על שירותי ייצור. אין תעבורה מקוטעת ברשת ה-LAN; יש תעבורה מקוטעת ב-WAN, אך לא משמעותית. אין סימנים - אתה יכול להפעיל פתרון לעקיפת הבעיה!

FragmentSmack/SegmentSmack. דם ראשון

הבעיה הראשונה שנתקלנו בה היא שמיכלי ענן הפעילו לפעמים את ההגדרות החדשות רק באופן חלקי (רק ipfrag_low_thresh), ולפעמים לא החילו אותן בכלל – הן פשוט קרסו בהתחלה. לא ניתן היה לשחזר את הבעיה ביציבות (כל ההגדרות הוחלו באופן ידני ללא קשיים). ההבנה מדוע המכולה קורסת בהתחלה היא גם לא כל כך קלה: לא נמצאו שגיאות. דבר אחד היה בטוח: ביטול ההגדרות לאחור פותר את הבעיה עם קריסות המכולה.

מדוע לא מספיק להחיל Sysctl על המארח? הקונטיינר חי ברשת ייעודית Namespace משלו, כך לפחות חלק מפרמטרי Sysctl של הרשת במיכל עשוי להיות שונה מהמארח.

איך בדיוק מוחלות הגדרות Sysctl בקונטיינר? מכיוון שהמכולות שלנו הן חסרות פריבילגיה, לא תוכל לשנות שום הגדרת Sysctl על ידי כניסה לקונטיינר עצמו - פשוט אין לך מספיק זכויות. כדי להפעיל קונטיינרים, הענן שלנו באותה תקופה השתמש ב-Docker (עכשיו פודמן). הפרמטרים של הקונטיינר החדש הועברו ל-Docker דרך ה-API, כולל הגדרות Sysctl הנחוצות.
תוך כדי חיפוש בגרסאות, התברר שה-Docker API לא החזיר את כל השגיאות (לפחות בגרסה 1.10). כשניסינו להפעיל את המיכל באמצעות "דוקר ריצת", סוף סוף ראינו לפחות משהו:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

ערך הפרמטר אינו חוקי. אבל למה? ולמה זה לא תקף רק לפעמים? התברר ש-Docker לא מבטיח את סדר החלת פרמטרי Sysctl (הגרסה האחרונה שנבדקה היא 1.13.1), ולכן לפעמים ניסו להגדיר את ipfrag_high_thresh ל-256K כאשר ipfrag_low_thresh עדיין היה 3M, כלומר, הגבול העליון היה נמוך יותר מהגבול התחתון, מה שהוביל לטעות.

באותו זמן, כבר השתמשנו במנגנון משלנו להגדרה מחדש של המיכל לאחר ההתחלה (הקפאת המיכל לאחר מקפיא קבוצתי וביצוע פקודות במרחב השמות של הקונטיינר via ip netns), וגם הוספנו לחלק הזה פרמטרים של כתיבת Sysctl. הבעיה נפתרה.

FragmentSmack/SegmentSmack. דם ראשון 2

לפני שהספקנו להבין את השימוש ב- Workaround בענן, התחילו להגיע תלונות נדירות ראשונות של משתמשים. באותו זמן, עברו מספר שבועות מאז תחילת השימוש לעקיפת הבעיה בשרתים הראשונים. החקירה הראשונית העלתה כי התקבלו תלונות כנגד שירותים בודדים, ולא כל השרתים של שירותים אלו. הבעיה שוב הפכה לא ודאית ביותר.

קודם כל, כמובן, ניסינו להחזיר את הגדרות Sysctl לאחור, אבל זה לא השפיע. גם מניפולציות שונות עם הגדרות השרת והאפליקציה לא עזרו. אתחול מחדש עזר. אתחול לינוקס הוא לא טבעי כמו שהיה רגיל עבור Windows בימים עברו. עם זאת, זה עזר, וגידנו את זה ל"תקלת ליבה" בעת החלת ההגדרות החדשות ב-Sysctl. כמה קל דעת זה היה...

שלושה שבועות לאחר מכן הבעיה חזרה על עצמה. התצורה של שרתים אלו הייתה פשוטה למדי: Nginx במצב פרוקסי/איזון. אין הרבה תנועה. הערת היכרות חדשה: מספר 504 שגיאות בלקוחות גדל מדי יום (פסק זמן של שער). הגרף מציג את מספר 504 השגיאות ליום עבור שירות זה:

כל השגיאות הן בערך אותו backend - על זה שנמצא בענן. גרף צריכת הזיכרון עבור קטעי חבילה ב-backend זה נראה כך:

זהו אחד הביטויים הברורים ביותר של הבעיה בגרפים של מערכת ההפעלה. בענן, בדיוק באותו זמן, תוקנה בעיית רשת נוספת בהגדרות QoS (בקרת תנועה). בגרף של צריכת זיכרון עבור שברי מנות, זה נראה בדיוק אותו הדבר:

ההנחה הייתה פשוטה: אם הם נראים אותו הדבר בגרפים, אז יש להם אותה סיבה. יתר על כן, כל בעיה בזיכרון מסוג זה היא נדירה ביותר.

המהות של הבעיה המתוקנת הייתה שהשתמשנו במתזמן מנות fq עם הגדרות ברירת המחדל ב-QoS. כברירת מחדל, עבור חיבור אחד, היא מאפשרת להוסיף 100 חבילות לתור, וחיבורים מסוימים, במצבים של מחסור בערוצים, החלו לסתום את התור עד לתפוסה. במקרה זה, מנות נשמטות. בסטטיסטיקות tc (tc -s qdisc) ניתן לראות זאת כך:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
 Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1024 flows (1021 inactive, 0 throttled)
  0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

"464545 flows_plimit" הוא החבילות שהורדו עקב חריגה ממגבלת התור של חיבור אחד, ו-"נפל 464545" הוא הסכום של כל החבילות שהורדו של מתזמן זה. לאחר הגדלת אורך התור לאלף והפעלה מחדש של המכולות, הבעיה הפסיקה להתרחש. אתה יכול לשבת בשקט ולשתות שייק.

FragmentSmack/SegmentSmack. דם אחרון

ראשית, מספר חודשים לאחר ההכרזה על פרצות בקרנל, סוף סוף הופיע תיקון עבור FragmentSmack (תן לי להזכיר לך שיחד עם ההכרזה באוגוסט, שוחרר תיקון רק עבור SegmentSmack), שנתן לנו הזדמנות לנטוש את Workaround, מה שגרם לנו די הרבה צרות. במהלך הזמן הזה, כבר הספקנו להעביר חלק מהשרתים לקרנל החדש, ועכשיו היינו צריכים להתחיל מההתחלה. מדוע עדכנו את הליבה מבלי לחכות לתיקון FragmentSmack? העובדה היא שתהליך ההגנה מפני הפגיעויות הללו עלה בקנה אחד (והתמזג) עם תהליך עדכון CentOS עצמו (שלוקח אפילו יותר זמן מעדכון הקרנל בלבד). בנוסף, SegmentSmack היא פגיעות מסוכנת יותר, ותיקון לה הופיע מיד, כך שזה היה הגיוני בכל מקרה. עם זאת, לא יכולנו פשוט לעדכן את הליבה ב-CentOS מכיוון שפגיעות FragmentSmack, שהופיעה במהלך CentOS 7.5, תוקנה רק בגרסה 7.6, אז נאלצנו לעצור את העדכון ל-7.5 ולהתחיל מחדש עם העדכון ל-7.6. וגם זה קורה.

שנית, תלונות נדירות של משתמשים על בעיות חזרו אלינו. עכשיו אנחנו כבר יודעים בוודאות שכולם קשורים להעלאת קבצים מלקוחות לחלק מהשרתים שלנו. יתרה מכך, מספר קטן מאוד של העלאות מכלל המסה עבר דרך השרתים הללו.

כפי שאנו זוכרים מהסיפור למעלה, החזרת Sysctl לא עזר. אתחול מחדש עזר, אבל באופן זמני.
החשדות לגבי Sysctl לא הוסרו, אך הפעם היה צורך לאסוף מידע רב ככל האפשר. היה גם חוסר עצום ביכולת לשחזר את בעיית ההעלאה על הלקוח כדי ללמוד בצורה מדויקת יותר מה קורה.

ניתוח כל הנתונים הסטטיסטיים והיומנים הזמינים לא קירב אותנו להבין מה קורה. היה חוסר אקוטי ביכולת לשחזר את הבעיה כדי "להרגיש" קשר ספציפי. לבסוף, המפתחים, באמצעות גרסה מיוחדת של האפליקציה, הצליחו להשיג שחזור יציב של בעיות במכשיר בדיקה כאשר הם מחוברים באמצעות Wi-Fi. זו הייתה פריצת דרך בחקירה. הלקוח התחבר ל-Nginx, ששלח פרוקסי ל-backend, שהיה אפליקציית Java שלנו.

הדיאלוג לבעיות היה כזה (תוקן בצד ה-Proxy של Nginx):

1. לקוח: בקשה לקבל מידע על הורדת קובץ.
2. שרת Java: תגובה.
3. לקוח: POST עם קובץ.
4. שרת Java: שגיאה.

במקביל, שרת ה-Java כותב ללוג ש-0 בתים של נתונים התקבלו מהלקוח, והפרוקסי של Nginx כותב שהבקשה ארכה יותר מ-30 שניות (30 שניות הן פסק הזמן של אפליקציית הלקוח). למה פסק הזמן ולמה 0 בתים? מנקודת מבט של HTTP, הכל עובד כמו שצריך, אבל נראה שה-POST עם הקובץ נעלם מהרשת. יתר על כן, הוא נעלם בין הלקוח ל-Nginx. הגיע הזמן להתחמש ב-Tcpdump! אבל קודם אתה צריך להבין את תצורת הרשת. פרוקסי Nginx נמצא מאחורי המאזן L3 NFware. מנהור משמש להעברת מנות מהמאזן L3 לשרת, שמוסיף את הכותרות שלו לחבילות:

במקרה זה, הרשת מגיעה לשרת זה בצורה של תעבורה מתויגת Vlan, אשר מוסיפה גם שדות משלה לחבילות:

ותעבורה זו יכולה להיות גם מפוצלת (אותו אחוז קטן של תעבורה מפוצלת נכנסת שעליה דיברנו בעת הערכת הסיכונים מעקיפה), מה שגם משנה את תוכן הכותרות:

שוב: מנות מובלעות בתגית Vlan, מכוסות במנהרה, מקוטעות. כדי להבין טוב יותר איך זה קורה, בואו נעקוב אחר מסלול החבילה מהלקוח ל-Proxy Nginx.

1. החבילה מגיעה למאזן L3. לניתוב נכון בתוך מרכז הנתונים, החבילה מכוסה במנהרה ונשלחת לכרטיס הרשת.
2. מכיוון שכותרות החבילות + המנהרה אינן מתאימים ל-MTU, החבילה נחתכת לפרגמנטים ונשלחת לרשת.
3. המתג שאחרי האיזון L3, בעת קבלת חבילה, מוסיף לו תג Vlan ושולח אותו הלאה.
4. המתג שלפני ה-Proxy של Nginx רואה (בהתבסס על הגדרות היציאה) שהשרת מצפה למנות מובלעת של Vlan, ולכן הוא שולח אותה כפי שהיא, מבלי להסיר את תג Vlan.
5. לינוקס לוקחת קטעים של חבילות בודדות וממזגת אותם לחבילה אחת גדולה.
6. לאחר מכן, החבילה מגיעה לממשק Vlan, שם מוסרת ממנו השכבה הראשונה - Vlan encapsulation.
7. לאחר מכן לינוקס שולחת אותו לממשק Tunnel, שם מוסרת שכבה נוספת ממנו - Tunnel encapsulation.

הקושי הוא להעביר את כל זה כפרמטרים ל-tcpdump.
נתחיל מהסוף: האם ישנן חבילות IP נקיות (ללא כותרות מיותרות) מלקוחות, כשה-vlan ו-tunnel encapsulation הוסר?

tcpdump host <ip клиента>

לא, לא היו חבילות כאלה בשרת. אז הבעיה חייבת להיות שם קודם. האם יש חבילות שהוסרה רק אנקפסולציה של Vlan?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx היא כתובת ה-IP של הלקוח בפורמט hex.
32:4 - כתובת ואורך השדה שבו נכתב ה-SCR IP בחבילת המנהרה.

כתובת השדה הייתה צריכה להיבחר בכוח גס, מכיוון שבאינטרנט כותבים בערך 40, 44, 50, 54, אבל לא הייתה שם כתובת IP. אתה יכול גם להסתכל על אחת החבילות ב-hex (הפרמטר -xx או -XX ב-tcpdump) ולחשב את כתובת ה-IP שאתה מכיר.

האם יש קטעי מנות ללא אנקפסולציה של Vlan ו-Tunnel?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

הקסם הזה יראה לנו את כל השברים, כולל האחרון. כנראה שאפשר לסנן את אותו הדבר לפי IP, אבל לא ניסיתי, כי אין הרבה מאוד חבילות כאלה, ואלה שהייתי צריך נמצאו בקלות בזרימה הכללית. הנה הם:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
    11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
        0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
        0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
        0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
        0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
        0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
        0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
        0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

מדובר בשני שברים של חבילה אחת (אותו תעודת זהות 53652) עם צילום (המילה Exif גלויה בחבילה הראשונה). בשל העובדה שיש חבילות ברמה זו, אך לא בצורה הממוזגת במזבלות, הבעיה היא בבירור בהרכבה. סוף סוף יש הוכחות תיעודיות לכך!

מפענח החבילות לא חשף בעיות שימנעו את הבנייה. ניסיתי את זה כאן: hpd.gasmi.net. בהתחלה, כשאתה מנסה למלא שם משהו, המפענח לא אוהב את פורמט החבילות. התברר שהיו כמה שני אוקטטים נוספים בין Srcmac לבין Ethertype (לא קשור לפרגמנט מידע). לאחר הסרתם, המפענח התחיל לעבוד. עם זאת, זה לא הראה בעיות.
לא משנה מה יגידו, שום דבר אחר לא נמצא מלבד אותם Sysctl. כל שנותר היה למצוא דרך לזהות שרתים בעייתיים כדי להבין את קנה המידה ולהחליט על פעולות נוספות. המונה הנדרש נמצא במהירות מספקת:

netstat -s | grep "packet reassembles failed”

זה גם ב-snmpd תחת OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"מספר התקלות שזוהו על ידי אלגוריתם ההרכבה מחדש של ה-IP (מכל סיבה שהיא: קצוב הזמן הקצוב, שגיאות וכו')."

בין קבוצת השרתים שבהם נחקרה הבעיה, בשניים המונה הזה עלה מהר יותר, בשניים יותר לאט, ובשניים נוספים הוא לא גדל כלל. השוואת הדינמיקה של מונה זה עם הדינמיקה של שגיאות HTTP בשרת Java גילתה מתאם. כלומר, ניתן היה לנטר את המונה.

חשוב מאוד שיהיה אינדיקטור אמין לבעיות כדי שתוכלו לקבוע במדויק האם החזרת Sysctl לאחור עוזרת, שכן מהסיפור הקודם אנו יודעים שלא ניתן להבין זאת מיד מהאפליקציה. מחוון זה יאפשר לנו לזהות את כל האזורים הבעייתיים בייצור לפני שמשתמשים מגלים אותו.
לאחר החזרת Sysctl לאחור נעצרו שגיאות הניטור, ובכך הוכחה סיבת הבעיות, כמו גם העובדה שהחזרה עוזרת.

החזרנו לאחור את הגדרות הפרגמנטציה בשרתים אחרים, שבהם ניטור חדש נכנס לפעולה, ואיפשהו הקצנו אפילו יותר זיכרון לפרגמנטים ממה שהיה בעבר ברירת המחדל (זו הייתה סטטיסטיקת UDP, שהאובדן החלקי שלה לא היה מורגש על הרקע הכללי) .

השאלות הכי חשובות

מדוע מנות מפוצלות במאזן L3 שלנו? רוב החבילות שמגיעות מהמשתמשים למאזנים הן SYN ו-ACK. הגדלים של החבילות הללו קטנות. אבל מכיוון שחלקן של מנות כאלה גדול מאוד, על הרקע שלהן לא הבחנו בנוכחותן של מנות גדולות שהחלו להתפצל.

הסיבה הייתה סקריפט תצורה שבור advmss בשרתים עם ממשקי Vlan (היו מעט מאוד שרתים עם תעבורה מתויגת בייצור באותה תקופה). Advmss מאפשרת לנו להעביר ללקוח את המידע שהמנות לכיווננו צריכות להיות קטנות יותר בגודלן כך שלאחר הצמדת כותרות המנהרות אליהן הן לא יצטרכו להיות מפוצלות.

מדוע החזרה לאחור של Sysctl לא עזר, אבל אתחול מחדש כן? ביטול Sysctl שינה את כמות הזיכרון הזמינה למיזוג חבילות. יחד עם זאת, ככל הנראה עצם הצפת הזיכרון לפרגמנטים הובילה להאטה של ​​החיבורים, מה שהוביל לעיכוב של פרגמנטים לאורך זמן בתור. כלומר, התהליך עבר במחזוריות.
האתחול ניקה את הזיכרון והכל חזר לסדר.

האם ניתן היה להסתדר ללא עקיפת הבעיה? כן, אבל יש סיכון גבוה להשאיר משתמשים ללא שירות במקרה של התקפה. כמובן שהשימוש ב- Workaround גרם לבעיות שונות, כולל האטה של ​​אחד השירותים למשתמשים, אך למרות זאת אנו סבורים שהפעולות היו מוצדקות.

תודה רבה לאנדריי טימופייב (אטימופיייב) לסיוע בניהול החקירה, וכן אלכסיי קרנב (devicex) - לעבודה הטיטאנית של עדכון Centos וקרנלים בשרתים. תהליך שבמקרה זה היה צריך להתחיל מההתחלה מספר פעמים, ולכן הוא נמשך חודשים ארוכים.

מקור: www.habr.com