CVE-2026-98432․ ինչ գիտենք Linux-ի միջուկի TCP խոցելիության մասին

Պատկերացրեք սերվերը թարմացրել եք, SSH-ով միանում եք միայն բանալիով, firewall-ն էլ բաց է թողնում միայն անհրաժեշտ պորտերը։ Թվում է՝ ամեն ինչ կարգին է։ Բայց այդ պորտերին եկող յուրաքանչյուր նոր միացում նախ մշակում է Linux-ի միջուկը՝ մինչև ձեր ծրագիրը որևէ բան կտեսնի։ Եթե խնդիրը հենց այդտեղ է, ծրագրի ոչ մի կարգավորում չի օգնի։

Հենց այսպիսի խնդիր է CVE-2026-98432-ը։ Այն Linux-ի միջուկի այն հատվածում է, որը հաստատում է նոր IPv4 TCP միացումները։ Լինուքս միջուկի CVE թիմը խոցելիությունը գնահատել է 9.8՝ 10-ից․ հարձակման համար բավական է ցանցով հասնել սերվերին։ Սխալը միջուկում կա դեռ Linux 4.4-ից՝ 2016 թվականից։

Մեծ ուշադրություն խոցելիությունը ստացավ հոկտեմբերի 27-ին, երբ Anthropic-ը հայտնեց, որ իր AI մոդելը դրա համար աշխատող exploit է գրել, որը հեռակա root իրավունքներ է տալիս։ Իսկ հոկտեմբերի 31-ի դրությամբ Ubuntu-ն ու Red Hat Enterprise Linux-ը դեռ ուղղված միջուկ չեն թողարկել։

​

Ինչպես է սկսվում TCP կապը

Երբ բրաուզերը կամ որևէ ծրագիր միանում է սերվերին, TCP-ն նախ կատարում է այսպես կոչված եռաքայլ ձեռքսեղմում․

1. Հաճախորդն ուղարկում է SYN՝ «ուզում եմ միանալ»։

2. Սերվերը պատասխանում է SYN-ACK՝ «համաձայն եմ, միացիր»։

3. Հաճախորդը պատասխանում է ACK, և կապը բացվում է։

Քանի դեռ ձեռքսեղմումն ավարտված չէ, միջուկը կապի մասին տվյալները պահում է ժամանակավոր հայտի մեջ՝ request socket։ Ավարտից հետո այդ հայտից ստեղծվում է իսկական socket, որը հանձնվում է ծրագրին։

IPv4 փաթեթի վերնագիրը կարող է ունենալ նաև լրացուցիչ դաշտեր՝ IP options։ Օրինակ՝ Record Route-ը խնդրում է ճանապարհին հանդիպող երթուղիչներին գրանցել իրենց հասցեները, իսկ Timestamp-ը՝ ժամանակի նշումներ։ Այսօր դրանք գրեթե չեն հանդիպում, բայց միջուկը դեռ աջակցում է դրանq։ Եթե SYN-ը նման options ունի, միջուկը պահում է դրանք հայտի մեջ, որպեսզի օգտագործի իր պատասխաններում։

​

Իսկ որտեղ է սխալը

Միջուկի CVE թիմի նկարագրության համաձայն՝ խնդիրն առաջանում է երեք բանի համընկնումից․

• Options-ը չի պատճենվում։ Երբ ձեռքսեղմումն ավարտվում է, միջուկը հայտի մեջ պահված IP options-ի պատճենը չի ստեղծում, այլ նույն հիշողության կտորը հանձնում է նոր socket-ին։

• Մեկ այլ CPU դեռ կարդում է դրանք։ Նույն պահին պրոցեսորի մեկ այլ միջուկ կարող է մշակել նույն կապի կրկնակի ուղարկված SYN-ը և պատասխան SYN-ACK կառուցել՝ կարդալով նույն options-ը։

• Հիշողությունն ազատվում է անմիջապես։ Եթե այդ ընթացքում նոր socket-ը փակվում ու ջնջվում է, options-ի հիշողությունն անմիջապես ազատվում է, իսկ երկրորդ CPU-ն շարունակում է կարդալ այն։

Արդյունքում միջուկն օգտագործում է արդեն ազատված հիշողություն։ Սա use-after-free է։ Իսկ երբ արդյունքը կախված է նրանից, թե երկու զուգահեռ գործողություններից որն ավելի շուտ կավարտվի, դա կոչվում է race condition։

sequenceDiagram
    participant H as Հարձակվող
    participant C1 as CPU 1
    participant O as IP options-ի հիշողություն
    participant C2 as CPU 2
    H->>C1: SYN՝ IPv4 options-ով
    C1->>O: options-ը պահվում է հայտի մեջ
    H->>C1: ACK, ձեռքսեղմումն ավարտվում է
    C1->>O: options-ը տրվում է նոր socket-ին՝ առանց պատճենի
    H->>C2: նույն SYN-ի կրկնօրինակը
    C2->>O: SYN-ACK-ի համար կարդում է options-ը
    H->>C1: կապի փակում
    C1->>O: socket-ը ջնջվում է, հիշողությունն ազատվում է
    C2->>O: շարունակում է կարդալ արդեն ազատված հիշողությունը

Սխեման պարզեցված է։ Իրականում երկու գործողությունները պետք է համընկնեն շատ կարճ ժամանակահատվածում, բայց հարձակվողը կարող է փորձել բազմաթիվ անգամներ։

Միջուկի CVE թիմը նկարագրում է երեք հնարավոր հետևանք․

• Տվյալների արտահոսք։ Ազատված տեղում արդեն ուրիշ տվյալներ կարող են լինել, և միջուկը դրանք կարող է SYN-ACK-ի հետ ուղարկել հարձակվողին։

• Հիշողության վնասում։ Միջուկը կարող է գրել իր հիշողության այնպիսի հատվածներում, որտեղ չպետք է գրեր։ Սա կարող է հնարավորություն տալ փոխելու միջուկի աշխատանքի ընթացքը։

• Համակարգի խափանում։ Միջուկը կարող է կանգնել՝ kernel panic։

Նման խնդիր կա նաև request socket-ների «տեղափոխման» ժամանակ (net.ipv4.tcp_migrate_req=1 կամ հատուկ BPF ծրագիր), բայց այս հնարավորությունը հիմնականում անջատված է։

IPv6-ը հիմնական խնդրից չի տուժում, քանի որ IPv6 կապերի համար միջուկը options-ը պատճենում է։

​

Ինչպես է այն ուղղվել

Ուղղումը գրել է Էրիկ Դյումազեն (Eric Dumazet), իսկ սխալի մասին հայտնել է Anthropic-ի հետազոտող Սինյան Գեն (Xinyang Ge)։ Փոփոխությունը շատ փոքր է․ net/ipv4/af_inet.c ֆայլի inet_sock_destruct() և net/ipv4/tcp_ipv4.c ֆայլի tcp_v4_reqsk_destructor() ֆունկցիաներում kfree()-ն փոխարինվել է kfree_rcu()-ով։

Տարբերությունը հետևյալն է․ kfree()-ն հիշողությունն ազատում է անմիջապես, իսկ kfree_rcu()-ն սպասում է, մինչև բոլոր CPU-ները, որոնք կարող էին դեռ կարդալ այդ տվյալները, ավարտեն իրենց աշխատանքը։ Այս մեխանիզմը կոչվում է RCU՝ Read-Copy-Update։ Options-ը կարդացող կոդն արդեն օգտագործում էր RCU, իսկ միջուկի այլ հատվածներ նույն options-ը հենց այսպես էին ազատում։ Պարզապես այս երկու տեղում մնացել էր սովորական kfree()-ն։

​

Anthropic-ի exploit-ը և MPTCP-ն

Հոկտեմբերի 27-ին Anthropic-ը հրապարակեց հետազոտություն, որտեղ նկարագրում է, թե ինչպես է իր դեռ չթողարկված ներքին հետազոտական մոդելը, հետազոտողի սկզբնական հրահանգից հետո, գրել աշխատող exploit։ Ըստ ընկերության՝ այն թույլ է տալիս հեռավոր հարձակվողին՝ առանց հաշվի կամ օգտատիրոջ մասնակցության, root իրավունքներով հրամաններ կատարել Linux սերվերների վրա, որոնք ունեն MPTCP listener։

Anthropic-ը exploit-ը նկարագրել է այսպես․

1. Նախ հարձակվողը, ՛մրցավազքում՛ հաղթելով, ստիպում է միջուկին պատասխանի հետ ավելորդ բայթեր ուղարկել։ Եթե դրանց մեջ միջուկի հասցե է հայտնվում, հարձակվողը շրջանցում է KASLR-ը՝ պաշտպանությունը, որը թաքցնում է, թե հիշողության որ հատվածում է միջուկը։ Փորձարկման ժամանակ սա տևել է 48 րոպե։

2. Այնուհետև նույն սխալի միջոցով հարձակվողը փոխում է միջուկի աշխատանքի ընթացքը և root իրավունքներով կատարում իր ընտրած հրամանը։ Սա պահանջել է ևս 5 րոպե։

Ըստ Anthropic-ի՝ եթե հարձակվողը մրցավազքում պարտվում է, ձախողվում է միայն տվյալ կապը, իսկ համակարգը չի խափանվում։ Այսինքն՝ հարձակվողը կարող է փորձել այնքան, մինչև հաջողի։ Exploit-ի կոդը չի հրապարակվել։

Ինչ է MPTCP-ն։ Multipath TCP-ն TCP-ի ընդլայնում է, որը թույլ է տալիս մեկ կապի համար միաժամանակ օգտագործել մի քանի ցանցային ճանապարհ, օրինակ՝ Wi-Fi-ն ու բջջային ինտերնետը։ Linux-ում ծրագիրը պետք է հատուկ խնդրի MPTCP socket։ Բայց կա կարևոր բացառություն․ Go-ի անվտանգության թիմի խոսքով՝ Go 1.24-ից սկսած Go ծրագրերը Linux-ում MPTCP են միացնում իրենց listening socket-ների համար։ Այսինքն՝ եթե միջուկում MPTCP-ն միացված է, Go-ով գրված ցանկացած սերվեր կարող է MPTCP listener ունենալ, նույնիսկ եթե դրա ծրագրավորողը դա չի էլ նկատել։

Բայց պետք է հիշել․ CVE գրառումն ու ուղղումը MPTCP-ի մասին ոչինչ չեն ասում։ Սխալը սովորական IPv4 TCP կոդում է։ Go-ի թիմն էլ ընդգծում է, որ խնդիրը MPTCP-ին հատուկ չէ, և առանց MPTCP listener-ի համակարգերը նույնպես կարող են խոցելի լինել նմանատիպ հարձակումների նկատմամբ։

​

Որ տարբերակներն են ուղղված

Հոկտեմբերի 30–31-ի դրությամբ իրավիճակը այսպիսին է․

TuxCare-ի տվյալներով՝ Rocky Linux-ի և Oracle Linux-ի RHCK միջուկի համար նույնպես ուղղում դեռ չկա։ Իրավիճակը արագ է փոխվում, ուստի նայեք ձեր դիստրիբյուտիվի էջը, օրինակ՝ Debian-ի security tracker-ը։

​

Ինչպես ստուգել ձեր սերվերը

Սկսեք ցանկից․ որ սերվերներն են հասանելի ինտերնետից կամ անվստահելի ցանցից, և ինչ դիստրիբյուտիվ ու միջուկ ունեն։ Մի մոռացեք վիրտուալ մեքենաները, Kubernetes-ի node-երն ու հին, մոռացված սերվերները։ Կոնտեյներները սեփական միջուկ չունեն․ դրանք աշխատում են host-ի միջուկով, ուստի թարմացնել պետք է հենց host-ը։

Սերվերի տերմինալում գործարկեք․

# Այս պահին աշխատող միջուկի տարբերակը
uname -r

# MPTCP-ն միացվա՞ծ է, և request socket-ների տեղափոխումն անջատվա՞ծ է
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req

# MPTCP listener-ների ցանկը
sudo ss -lnMp

​

Ինչպես համոզվել, որ թարմացումն աշխատել է

Միջուկի նոր փաթեթը տեղադրելը դեռ աշխատանքի ավարտը չէ․ նոր միջուկը սկսում է աշխատել միայն սերվերը վերագործարկելուց հետո, եթե չեք օգտագործում live patching՝ առանց վերագործարկման թարմացման ծառայություն։

1. Տեղադրեք ձեր դիստրիբյուտիվի ուղղված միջուկը (apt, dnf կամ zypper)։

2. Վերագործարկեք սերվերը։

3. Նորից գործարկեք uname -r-ը և համոզվեք, որ աշխատում է հենց նոր միջուկը։

4. Ստուգեք հիմնական ծառայությունների աշխատանքը։

​

Եթե ուղղված միջուկ դեռ չկա

RHEL-ի և Ubuntu-ի օգտատերերի համար սա հիմա ամենակարևոր հարցն է։ Կան ժամանակավոր միջոցներ, որոնք նվազեցնում են ռիսկը, բայց դրանք չեն փոխարինում թարմացմանը։

1. Մերժել IP options ունեցող TCP փաթեթները

Հարձակումը սկսվում է IPv4 options ունեցող SYN-ով։ Հիմնականում նման փաթեթներ գրեթե չկան, ուստի դրանք կարելի է մերժել։ Red Hat-ն իր բյուլետենում առաջարկում է հետևյալ nftables կանոնը։ Պահեք այն cve-2026-98432.nft ֆայլում․

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

ip hdrlength > 5 պայմանը նշանակում է՝ «IPv4 վերնագիրը սովորականից երկար է»։ Առանց options-ի վերնագիրը հինգ 32-բիթանոց բառ է՝ 20 բայթ, ուստի ավելի երկար վերնագիրը նշանակում է, որ options կան։ Սովորական TCP options-ը (MSS, SACK, window scaling) գտնվում են TCP-ի վերնագրում, ոչ թե IP-ի, ուստի այս կանոնը դրանց չի դիպչում։

Ստուգեք, կիրառեք և համոզվեք, որ կանոնը բեռնված է․

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

counter-ը ցույց կտա, թե քանի փաթեթ է արդեն մերժվել։ Ուղղված միջուկին անցնելուց հետո կանոնը հեռացրեք․

sudo nft delete table inet cve_2026_98432

2. Անջատել MPTCP-ն, եթե այն պետք չէ

Սա փակում է Anthropic-ի ցուցադրած ճանապարհը։ AlmaLinux-ի ցուցումով․

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0

Այս կարգավորումն ազդում է միայն նոր socket-ների վրա։ Արդեն բացված MPTCP listener-ները չեն փակվի, ուստի sudo ss -lnMp-ով գտեք դրանք և վերագործարկեք համապատասխան ծառայությունները։

Go ծառայությունների համար MPTCP-ն կարելի է անջատել նաև ծրագրի մակարդակում․ գործարկելիս նշել GODEBUG=multipathtcp=0 միջավայրի փոփոխականը կամ հիմնական մոդուլի go.mod ֆայլում ավելացնել godebug multipathtcp=0 տողը։

3. Համոզվել, որ request socket-ների տեղափոխումն անջատված է

net.ipv4.tcp_migrate_req-ը պետք է լինի 0, և BPF_SK_REUSEPORT_SELECT_OR_MIGRATE տեսակի BPF ծրագիր չպետք է միացված լինի։ Եթե դրանք հատուկ չեք միացրել, ամենայն հավանականությամբ այստեղ ամեն ինչ կարգին է։

​

Ինչ անել հիմա

CVE-2026-98432-ը հազվադեպ դեպք է․ սխալը Linux-ի ամենահիմնական ցանցային կոդում է, հասանելի է առանց մուտքի, և դրա համար արդեն ցուցադրվել է աշխատող exploit։ Այդ պատճառով արժե այն դիտարկել որպես առաջնահերթ։

flowchart TD
    S["Ինտերնետին բաց Linux սերվեր"] --> Q{"Դիստրիբյուտիվը ուղղված միջուկ թողարկե՞լ է"}
    Q -->|Այո| P["Տեղադրել միջուկը և վերագործարկել սերվերը"]
    P --> V["Ստուգել uname -r հրամանով"]
    V --> X["Հեռացնել ժամանակավոր կանոնները"]
    Q -->|Ոչ| F["Ավելացնել nftables կանոնը"]
    F --> M["Անջատել MPTCP-ն, եթե պետք չէ"]
    M --> W["Հետևել մատակարարի էջին"]
    W -->|Ուղղումը թողարկվեց| P

1. Կազմեք ցանկը՝ որ սերվերներն են բաց ինտերնետին, ինչ դիստրիբյուտիվ ու միջուկ ունեն։

2. Առաջինը թարմացրեք MPTCP listener ունեցող սերվերները, հատկապես նրանք, որոնց վրա Go ծառայություններ են աշխատում։

3. Եթե ուղղումը կա՝ տեղադրեք, վերագործարկեք և ստուգեք։

4. Եթե ուղղումը դեռ չկա՝ կիրառեք ժամանակավոր կանոնը, անջատեք ավելորդ MPTCP-ն, հետևեք ձեր դիստրիբյուտիվի հաղորդագրություններին և նախապես պլանավորեք վերագործարկման ժամը։

Ժամանակավոր միջոցները նախատեսված են միայն սպասելու համար։ Վերջնական լուծումը մեկն է՝ ուղղված միջուկ։