
خلاصه
CVE-2026-98432 یک باگ use-after-free در بخش مدیریت اتصالهای TCP روی IPv4 در کرنل لینوکس است که امتیاز CVSS آن ۹٫۸ و در رده «بحرانی» است [1]. این باگ از نسخه 4.4 لینوکس وجود داشته و در نسخه 7.3 و چند نسخه پایدار برطرف شده است [2]. مهاجم از راه دور برای سوءاستفاده به ورود به سیستم نیازی ندارد [1]. نصب کرنل وصلهشده و راهاندازی دوباره سیستم تنها راهحل کامل است [6].
نکتههای کلیدی
- CVE-2026-98432 در ۱۵ اکتبر ۲۰۲۶ از سوی تیم CVE کرنل لینوکس منتشر شد؛ امتیاز CVSS 3.1 آن ۹٫۸ (بحرانی) و بردار حمله آن شبکه است [1].
- این باگ در لینوکس 4.4 وارد کد شد و در نسخههای 5.10.272، 5.15.223، 6.1.190، 6.6.159، 6.12.113، 6.18.56، 7.2.10 و 7.3 برطرف شده است [2].
- Anthropic میگوید اثبات مفهوم (PoC) آن به مهاجم راه دور امکان اجرای فرمان با دسترسی root را روی سرورهای لینوکسی دارای شنونده Multipath TCP (MPTCP) داد [4]، اما Red Hat میگوید MPTCP شرط لازم این آسیبپذیری نیست [6].
- تا ۳ نوامبر ۲۰۲۶، Red Hat، Debian و AlmaLinux کرنلهای وصلهشده را برای نسخههای تحت پشتیبانی خود منتشر کردهاند [7][9][10]، در حالی که Ubuntu وصلههای خود را «در حال انجام» اعلام کرده است [8].
- به گفته Red Hat و Ubuntu، قواعد دیواره آتش که بستههای TCP روی IPv4 دارای گزینههای IP را دور میریزند، میزان در معرض خطر بودن را کاهش میدهند اما جلوی سوءاستفاده را بهطور کامل نمیگیرند [6][8].
- تا ۳ نوامبر ۲۰۲۶ این CVE در فهرست آسیبپذیریهای شناختهشده مورد سوءاستفاده (KEV) سازمان CISA نیست [14] و Akamai میگوید از وجود اکسپلویت عمومی کارآمدی اطلاع ندارد [11].
در این صفحه ۱۲ بخش
- CVE-2026-98432 چیست؟
- این آسیبپذیری چگونه عمل میکند؟
- Anthropic چه چیزی را افشا کرد و MPTCP چه نقشی دارد؟
- کدام نسخههای کرنل و کدام توزیعها وصله شدهاند؟
- چگونه بفهمیم یک سرور آسیبپذیر است یا نه؟
- چگونه CVE-2026-98432 را برطرف یا خطر آن را کاهش دهیم؟
- آیا از CVE-2026-98432 سوءاستفاده میشود؟
- در ادامه چه اتفاقی میافتد؟
- اشتباههای رایج
- پرسشهای پرتکرار
- واژهنامه
- منابع
CVE-2026-98432 چیست؟
CVE-2026-98432 آسیبپذیریای در کرنل لینوکس، یعنی هسته سیستمعاملهای لینوکسی، است. عنوان رسمی آن ipv4: free inet_opt and ireq_opt after an RCU grace period است [1]. تیم CVE کرنل لینوکس این شناسه را اختصاص داد و رکورد آن را در ۱۵ اکتبر ۲۰۲۶ منتشر کرد [1]. در این رکورد، امتیاز پایه CVSS 3.1 آن ۹٫۸ ثبت شده که در رده «بحرانی» قرار میگیرد [1].
این نقص از نوع use-after-free (استفاده پس از آزادسازی) است: برنامه پس از آزاد کردن بخشی از حافظه همچنان از آن استفاده میکند، در حالی که ممکن است آن حافظه دیگر دادههای دیگری را در خود داشته باشد. در اینجا، نقص در کدی قرار دارد که درخواستهای ورودی اتصال TCP روی IPv4 را پردازش میکند [10]. بردار CVSS آن AV:N/AC:L/PR:N/UI:N است؛ یعنی حمله از طریق شبکه انجام میشود، پیچیدگی کمی دارد و به هیچ سطح دسترسی یا تعاملی از سوی کاربر نیاز ندارد [1].
این باگ از لینوکس 4.4 وجود داشته و با کامیت 079096f103fa وارد کد شده است [2]. وصلهای که Eric Dumazet نوشته در ۵ اکتبر ۲۰۲۶ ثبت شد و اکنون در کرنل اصلی (mainline) قرار دارد [3]. این وصله به شاخههای پایدار تحت نگهداری نیز منتقل (backport) شده است [2][4].
چه سیستمهایی تحت تأثیر قرار میگیرند؟
به گفته Red Hat، این نقص هر سیستمی را که کرنل آسیبپذیر دارد و شبکه TCP روی IPv4 در آن فعال است تحت تأثیر قرار میدهد. سیستمهایی که اتصالهای ورودی TCP را میپذیرند بیش از همه در معرض خطر مستقیماند [6]. AlmaLinux توصیه میکند هر سیستمی که اتصالهای TCP روی IPv4 را از شبکههای غیرقابلاعتماد میپذیرد در معرض خطر تلقی شود [10]. مشکل اصلی بر IPv6 اثری ندارد [2].
این آسیبپذیری چگونه عمل میکند؟
هر اتصال TCP با یک دستدهی (handshake) آغاز میشود. کلاینت یک بسته SYN میفرستد، سرور با SYN-ACK پاسخ میدهد و کلاینت آن را تأیید میکند. بسته SYN میتواند گزینههای IPv4 را با خود حمل کند؛ این گزینهها فیلدهای اضافی و اختیاری در سرآیند IP هستند. Record Route و Timestamp دو نمونه از آنها هستند [1].
طبق توضیح کرنل، تابع tcp_v4_syn_recv_sock() گزینههای ذخیرهشده را بدون کپی کردن به سوکت فرزند جدید میسپارد [2]. در همین حال، هسته دیگری از پردازنده ممکن است یک SYN بازارسالشده را برای همان درخواست پردازش کند و SYN-ACKای بسازد که این گزینهها را میخواند [2]. هیچ سازوکاری مانع آزاد شدن سوکت فرزند در حین ساخته شدن SYN-ACK نمیشود. گزینههای آن با یک kfree() ساده آزاد میشوند و در نتیجه کرنل در تابع ip_options_build() حافظه آزادشده را میخواند [2].
وضعیت رقابتی (race) دوم و مشابهی نیز هنگامی رخ میدهد که انتقال سوکت درخواست (request-socket migration) فعال باشد؛ چه از طریق net.ipv4.tcp_migrate_req=1 و چه از طریق یک برنامه BPF reuseport [2]. وصله، هر دو مسیر آزادسازی را وادار میکند تا پایان یک دوره مهلت RCU صبر کنند؛ این کار با استفاده از kfree_rcu() در inet_sock_destruct() و tcp_v4_reqsk_destructor() انجام میشود [2]. RCU (خواندن-کپی-بهروزرسانی) روشی در کرنل است که آزادسازی حافظه را تا زمانی که هیچ خوانندهای دیگر از آن استفاده نکند به تأخیر میاندازد.
مهاجم با آن چه میتواند بکند؟
یادداشتهای امتیازدهی در رکورد CVE سه پیامد را شرح میدهند [1]:
- افشای اطلاعات: حافظه آزادشده ممکن است با دادههای دیگری پر شود و محتوای آن در SYN-ACKای که به مهاجم بازگردانده میشود کپی شود [1].
- تخریب حافظه: طولها و آفستهای کهنه میتوانند عملیات نوشتن کرنل را به خارج از محدوده مجاز هدایت کنند و احتمالاً جریان کنترل را مختل کنند [1].
- از کار افتادن سیستم: یک مقدار طول بازاستفادهشده میتواند kernel panic ایجاد کند و نوشتنهای نابجا نیز میتوانند کرنل را از کار بیندازند [1].
Red Hat میافزاید که اجرای قابلاتکای کد از طریق این باگ حساس به زمانبندی، به کنترل دقیق heap نیاز دارد. با این حال، Red Hat همچنان آن را «بحرانی» ارزیابی میکند، زیرا هیچ پیششرط شبکهای ندارد و میتواند ناپایداری شدیدی ایجاد کند [7].
Anthropic چه چیزی را افشا کرد و MPTCP چه نقشی دارد؟
در ۲۷ اکتبر ۲۰۲۶، تیم Frontier Red Team شرکت Anthropic گزارشی از آسیبپذیریهایی منتشر کرد که با استفاده از مدلهای Claude یافته بود [4][11]. این گزارش درباره CVE-2026-98432 میگوید تیم اکسپلویتی ساخته است که به مهاجم راه دور اجازه میدهد روی سرورهای لینوکسی دارای شنونده Multipath TCP (MPTCP)، بدون اطلاعات ورود و بدون تعامل کاربر، فرمانهای دلخواه را با دسترسی root اجرا کند [4]. MPTCP افزونهای بر TCP است که به یک اتصال اجازه میدهد همزمان از چند مسیر شبکه استفاده کند.
Anthropic دو مرحله را شرح میدهد. نخست، اکسپلویت یک اشارهگر کرنل را نشت میدهد تا KASLR، یعنی تصادفیسازی نشانیهای کرنل، را خنثی کند. سپس یک اشارهگر callback را بازنویسی میکند تا کرنل فرمانی را که مهاجم انتخاب کرده با دسترسی root اجرا کند [4]. شکست در رقابت فقط باعث ناکامی دستدهی میشود و سیستم را از کار نمیاندازد؛ بنابراین مهاجم میتواند بارها تلاش کند [4]. در اثبات مفهوم Anthropic، نشت دادن اشارهگر کرنل ۴۸ دقیقه و اجرای فرمان پنج دقیقه دیگر طول کشید [4].
آیا MPTCP لازم است؟
به گفته فروشندگانی که آن را بررسی کردهاند، خیر. Red Hat اعلام میکند که MPTCP شرط لازم این نقص نیست و سیستمهایی که MPTCP در آنها غیرفعال است همچنان آسیبپذیرند [6]. تیم امنیتی Go میگوید اکسپلویت نمایشدادهشده به شنونده MPTCP نیاز دارد، اما باگ زیربنایی مختص MPTCP نیست [5]. Go از این جهت اهمیت دارد که از نسخه Go 1.24، برنامههای Go بهطور پیشفرض MPTCP را برای سوکتهای شنونده در لینوکس فعال میکنند [5].
به گفته Akamai، شرکت Anthropic اکسپلویت دسترسی root خود را منتشر نکرده است و Akamai در ۲ نوامبر ۲۰۲۶ اعلام کرد که از وجود اکسپلویت عمومی کارآمدی اطلاع ندارد [11].
کدام نسخههای کرنل و کدام توزیعها وصله شدهاند؟
تیم CVE کرنل این وصلههای بالادستی (upstream) را فهرست کرده است: 5.10.272، 5.15.223، 6.1.190، 6.6.159، 6.12.113، 6.18.56، 7.2.10 و نسخه اصلی 7.3 [2]. با این حال، بیشتر کاربران کرنلی را اجرا میکنند که توزیع لینوکسشان ساخته و شماره نسخه خاص خود را دارد. به جای مقایسه شمارههای بالادستی، اطلاعیه امنیتی توزیع خود را بررسی کنید.
وضعیت تا ۳ نوامبر ۲۰۲۶:
- Red Hat Enterprise Linux: کرنلهای وصلهشده در ۱ نوامبر ۲۰۲۶ برای RHEL 8، 9 و 10 منتشر شدند. RHEL 6 و 7 «تحت تأثیر نیست» اعلام شدهاند. کرنل بیدرنگ (real-time) RHEL 9 و ایمیجهای گره OpenShift همچنان «تحت تأثیر» فهرست شدهاند [7].
- Ubuntu: Ubuntu این مسئله را «بحرانی» ارزیابی میکند. ردیاب آن نسخههای 26.10، 26.04 LTS، 24.04 LTS و 22.04 LTS را آسیبپذیر و وصلههایشان را در حال آمادهسازی نشان میدهد؛ نسخههای 20.04، 18.04 و 16.04 نیز آسیبپذیر و نسخه 14.04 «تحت تأثیر نیست» فهرست شدهاند [8].
- Debian: وصلهها برای Debian 12 bookworm (linux 6.1.190-1 و linux-6.12 6.12.113-1~deb12u1)، Debian 13 trixie (linux 6.12.113-1) و نیز شاخه unstable در دسترساند [9].
- AlmaLinux: کرنلهای وصلهشده برای AlmaLinux 8، 9 و 10 در مخازن production قرار گرفتهاند [10].
- سایر توزیعها: Akamai گزارش داد که SUSE، Oracle Linux و Amazon Linux 2023 تا ۳۰ اکتبر ۲۰۲۶ برای برخی نسخهها کرنل وصلهشده منتشر کرده بودند [11].
گوشیهای اندرویدی چه وضعی دارند؟
اندروید از کرنل لینوکس استفاده میکند، اما بولتن امنیتی اندروید که در ۲ نوامبر ۲۰۲۶ منتشر شد CVE-2026-98432 را فهرست نکرده است [13]. دارندگان گوشی باید بهروزرسانیهای امنیتی را هر زمان سازنده دستگاهشان منتشر کرد نصب کنند.
چگونه بفهمیم یک سرور آسیبپذیر است یا نه؟
- کرنل در حال اجرا را پیدا کنید. فرمان
uname -rرا اجرا کنید. وصله فقط زمانی مؤثر است که دستگاه با کرنل جدید دوباره راهاندازی شده باشد. AlmaLinux به کاربران میگوید سیستم را دوباره راهاندازی کنند و نسخه را باuname -rتأیید کنند [10]. - با ردیاب فروشنده خود مقایسه کنید. CVE-2026-98432 را در صفحه امنیتی توزیع خود جستوجو کنید. Red Hat [7]، Ubuntu [8]، Debian [9] و AlmaLinux [10] هر کدام نسخههای بستهای را که وصله را دارند فهرست کردهاند.
- MPTCP را بررسی کنید. فرمان
sysctl net.mptcp.enabledنشان میدهد MPTCP روشن است یا نه. فرمانsudo ss -lnMpشنوندههای MPTCP و فرایندهای مالک آنها را فهرست میکند [10]. Akamai همچنین بررسیnet.ipv4.tcp_migrate_reqرا پیشنهاد میکند [11]. - سرویسهای Go را پیدا کنید. برنامههایی که با Go 1.24 یا نسخههای بعدی ساخته شدهاند بهطور پیشفرض در لینوکس شنونده MPTCP باز میکنند [5]. بنابراین هر سرویس Go که اجرا میکنید ممکن است همان مسیری را که Anthropic از آن سوءاستفاده کرد در معرض حمله قرار دهد.
- محصولات لایهبالاتر را بررسی کنید. Red Hat هشدار میدهد که هر محصولی که بر پایه کرنل RHEL ساخته شده، از جمله OpenShift، OpenStack و Red Hat Virtualization، ممکن است تحت تأثیر باشد [6].
چگونه CVE-2026-98432 را برطرف یا خطر آن را کاهش دهیم؟
راهحل واقعی، کرنل وصلهشده است. Red Hat اعمال بهروزرسانیهای کرنل را تنها راهحل کامل میداند [6] و تیم امنیتی Go میگوید بهترین راهحل، ارتقا به کرنل وصلهشده است [5]. بهروزرسانی کرنل توزیع خود را نصب کنید، سیستم را دوباره راهاندازی کنید و نسخه در حال اجرا را تأیید کنید.
پیش از رسیدن وصله چه میتوان کرد؟
- بستههای TCP دارای گزینههای IPv4 را دور بریزید. Red Hat یک قاعده nftables منتشر کرده است، و ردیاب Ubuntu نیز آن را بهعنوان راهحل موقتِ پیشنهادی کاربران فهرست کرده، که بستههای ورودی TCP روی IPv4 را که سرآیند IP آنها از ۲۰ بایتِ پایه بلندتر است، یعنی بستههای حاوی گزینه (
ip hdrlength > 5)، دور میریزد [6][8]. گزینههای معمول TCP مانند timestamp و window scaling در سرآیند TCP قرار دارند و تحت تأثیر این قاعده نیستند [8]. هر دو فروشنده میگویند این قاعده خطر را کاهش میدهد اما نمیتواند بهطور کامل جلوی سوءاستفاده را بگیرد [6][8]. - محدودیتهای این قاعده را بشناسید. AlmaLinux یادآوری میکند که نسخه پیشنهادیاش پس از راهاندازی دوباره باقی نمیماند، ترافیک میان کانتینرهای روی یک میزبان ممکن است از آن عبور کند، روی میزبانهایی که نقش مسیریاب دارند بستههای عبوری را هم دور میریزد و شبکههایی را که به برچسبهای CIPSO/NetLabel متکیاند مختل میکند [10]. Ubuntu یادآوری میکند که برای کانتینرهایی که شبکه جداگانه دارند باید این قاعده جداگانه اعمال شود [8].
- اگر به MPTCP نیاز ندارید، آن را غیرفعال کنید. تنظیم
net.mptcp.enabled=0MPTCP را در کل سیستم خاموش میکند [10]. Akamai همچنین تنظیمnet.ipv4.tcp_migrate_req=0را پیشنهاد میکند [11]. Akamai هشدار میدهد که غیرفعال کردن MPTCP بهتنهایی جلوی سوءاستفاده را نمیگیرد و فقط احتمال ایجاد وضعیت رقابتی را کم میکند [11]. برنامههای Go نیز میتوانند باGODEBUG=multipathtcp=0از آن صرفنظر کنند، اما تیم Go اینگونه غیرفعالسازی برنامهبهبرنامه را شکننده میداند [5]. - در لبه شبکه فیلتر کنید. Red Hat درباره OpenShift یادآوری میکند که قواعد روی یک گره، ترافیک پاد به پاد را فیلتر نمیکنند، اما فیلتر کردن در مرز شبکه و پیش از خوشه (cluster) این محدودیت را ندارد [6].
آیا init_on_free=1 کمکی میکند؟
در یکی از پستهای فهرست oss-security، گزینه راهاندازی init_on_free=1 بهعنوان یک راهحل موقت اضافی پیشنهاد شد. یکی از اعضای تیم کرنل در CIQ پاسخ داد که این گزینه خطر این CVE را بهطور معناداری کاهش نمیدهد و نباید در اطلاعیههای امنیتی بر آن تکیه شود [12]. آن را یک اقدام عمومی برای مقاومسازی بدانید، نه راهی برای کاهش خطر این باگ.
آیا از CVE-2026-98432 سوءاستفاده میشود؟
تا ۳ نوامبر ۲۰۲۶، CVE-2026-98432 در فهرست آسیبپذیریهای شناختهشده مورد سوءاستفاده (KEV) سازمان CISA، یعنی فهرست دولت آمریکا از نقصهایی که سوءاستفاده واقعی از آنها تأیید شده، دیده نمیشود [14]. Akamai در ۲ نوامبر ۲۰۲۶ اعلام کرد که از وجود اکسپلویت عمومی کارآمدی اطلاع ندارد [11]. این به معنای اثبات این نیست که هیچکس از این باگ سوءاستفاده نمیکند. وجود یک اکسپلویت قابلاتکا نشان داده شده است [4] و جزئیات فنی در وصله کرنل بهطور عمومی در دسترس است [3].
تصویر شدت این آسیبپذیری نیز به مرور تغییر کرد. CVE نخستین بار در ۱۵ اکتبر ۲۰۲۶ منتشر شد [1]. توجه گستردهتر پس از گزارش ۲۷ اکتبر Anthropic جلب شد [4][11]. بولتنهای فروشندگان همراه با راهحلهای موقت میان ۲۹ اکتبر و ۲ نوامبر منتشر شدند [5][6][10]. مدیرانی که فقط نگاهی گذرا به رکورد اولیه انداختهاند ممکن است راهنماییهای بعدی را از دست داده باشند.
در ادامه چه اتفاقی میافتد؟
Red Hat بررسی خود را در جریان توصیف میکند و میگوید بولتنش با روشن شدن اطلاعات تازه بهروزرسانی خواهد شد [6]. انتظار میرود بستههای باقیمانده، مانند کرنل بیدرنگ RHEL 9 و ایمیجهای OpenShift [7] و کرنلهای Ubuntu که هنوز در دست آمادهسازیاند [8]، طی روزها یا هفتههای آینده وصله شوند. به جای خلاصههای خبری، ردیابهای فروشندگان را بررسی کنید، زیرا این صفحهها در هفتههای نخست چند بار تغییر کردند.
وصله کرنل یک مسئله مرتبط را نیز باز گذاشته است. توضیح کرنل میگوید تابع tcp_v6_reqsk_destructor() در IPv6 همین مشکل انتقال را برای گزینههایی دارد که فقط CALIPSO تنظیم میکند و این مشکل در وصلهای جداگانه رسیدگی خواهد شد [2]. طبق سیاست افشای هماهنگ Anthropic، این شرکت ۹۰ روز برای وصله کردن و ۴۵ روز دیگر پیش از بحث درباره جزئیاتی فراتر از اطلاعیه عمومی فرصت میدهد [4]. بنابراین ممکن است جزئیات فنی بیشتری بعداً منتشر شود.
این نوشته اطلاعات فنی عمومی است و جایگزین اطلاعیه امنیتی فروشنده شما یا فرایند واکنش به رخداد سازمانتان نیست.
| کرنل یا توزیع | نسخه وصلهشده یا وضعیت | توضیحات |
|---|---|---|
| شاخههای پایدار بالادستی 5.10 / 5.15 / 6.1 | 5.10.272، 5.15.223، 6.1.190 [2] | باگ در 4.4 وارد کد شد [2] |
| شاخههای پایدار بالادستی 6.6 / 6.12 / 6.18 | 6.6.159، 6.12.113، 6.18.56 [2] | وصله به شاخههای تحت نگهداری منتقل شده است [4] |
| بالادستی 7.2 / شاخه اصلی (mainline) | 7.2.10 و 7.3 [2] | وصله شاخه اصلی در ۵ اکتبر ۲۰۲۶ ثبت شد [3] |
| Red Hat Enterprise Linux 8 / 9 / 10 | کرنلهای وصلهشده در ۱ نوامبر ۲۰۲۶ منتشر شدند [7] | kernel-rt در RHEL 9 و OpenShift همچنان «تحت تأثیر» فهرست شدهاند [7] |
| Ubuntu 22.04، 24.04، 26.04، 26.10 | آسیبپذیر، وصله در حال آمادهسازی [8] | اولویت Ubuntu: بحرانی [8] |
| Debian 12 و 13 | 6.1.190-1 و 6.12.113-1~deb12u1 (نسخه 12)؛ 6.12.113-1 (نسخه 13) [9] | وصلهشده از طریق DLA-4841-1، DLA-4850-1 و DSA-6568-1 [9] |
| AlmaLinux 8 / 9 / 10 | کرنلهای وصلهشده در مخازن production [10] | MPTCP بهطور پیشفرض غیرفعال است، اما وصله همچنان لازم است [10] |
اشتباههای رایج
نصب بسته کرنل بدون راهاندازی دوباره سیستم
راه درست: کرنل قدیمی تا راهاندازی دوباره همچنان اجرا میشود. همانطور که AlmaLinux توصیه میکند، سیستم را دوباره راهاندازی کنید و سپس نسخه در حال اجرا را با uname -r تأیید کنید [10].
امن فرض کردن سرور به این دلیل که MPTCP خاموش است
راه درست: Red Hat میگوید MPTCP شرط لازم نیست و سیستمهایی که آن را غیرفعال کردهاند همچنان آسیبپذیرند [6]. Akamai میگوید غیرفعال کردن MPTCP فقط احتمال ایجاد وضعیت رقابتی را کم میکند [11]. کرنل را وصله کنید.
راهحل دانستن قاعده nftables
راه درست: Red Hat و Ubuntu هر دو میگویند قاعده مربوط به گزینههای IPv4 میزان در معرض خطر بودن را کم میکند اما نمیتواند بهطور کامل جلوی سوءاستفاده را بگیرد [6][8]. فقط تا زمان نصب کرنل وصلهشده از آن استفاده کنید و سپس، همانطور که Red Hat شرح داده، آن را حذف کنید [6].
مقایسه شماره نسخههای بالادستی با کرنلهای توزیعها
راه درست: توزیعها وصلهها را با شماره نسخههای خودشان منتقل میکنند. این CVE را در ردیاب فروشنده خود، مانند ردیاب Red Hat [7]، Ubuntu [8] یا Debian [9]، بررسی کنید.
فراموش کردن کانتینرها و خوشهها
راه درست: ترافیک میان کانتینرهای روی یک میزبان ممکن است از قواعد دیواره آتش میزبان عبور کند [10] و قواعد گرههای OpenShift ترافیک پاد به پاد را فیلتر نمیکنند [6]. کرنل میزبان را وصله کنید، زیرا کانتینرها از همان کرنل مشترک استفاده میکنند.
پرسشهای پرتکرار
آیا CVE-2026-98432 واقعی است و چقدر جدی است؟
بله. این یک رکورد CVE منتشرشده از سوی تیم CVE کرنل لینوکس به تاریخ ۱۵ اکتبر ۲۰۲۶ با امتیاز CVSS 3.1 برابر ۹٫۸ (بحرانی) است [1]. Red Hat [7] و Ubuntu [8] نیز آن را «بحرانی» ارزیابی میکنند.
آیا CVE-2026-98432 بر رایانه خانگی یا گوشی من اثر میگذارد؟
Red Hat میگوید سیستمهایی که بیش از همه در معرض خطر مستقیماند آنهایی هستند که اتصالهای ورودی TCP را میپذیرند [6]؛ یعنی عمدتاً سرورها. بولتن اندروید منتشرشده در ۲ نوامبر ۲۰۲۶ این CVE را فهرست نکرده است [13]. در هر حال، بهروزرسانیهای فروشنده خود را نصب کنید.
آیا برای آسیبپذیر بودن باید MPTCP فعال باشد؟
خیر. اکسپلویت Anthropic از یک شنونده MPTCP استفاده کرد [4]، اما Red Hat میگوید MPTCP شرط لازم نیست [6] و تیم امنیتی Go میگوید باگ زیربنایی مختص MPTCP نیست [5].
کدام نسخههای کرنل لینوکس CVE-2026-98432 را برطرف میکنند؟
وصلههای بالادستی در نسخههای 5.10.272، 5.15.223، 6.1.190، 6.6.159، 6.12.113، 6.18.56، 7.2.10 و 7.3 قرار دارند [2]. کرنلهای توزیعها شمارههای خاص خود را دارند، پس اطلاعیه امنیتی فروشنده خود را بررسی کنید [7][8][9].
آیا اکسپلویت عمومی برای CVE-2026-98432 وجود دارد؟
Anthropic یک اثبات مفهوم کارآمد را توصیف کرده اما آن را منتشر نکرده است [4][11]. تا ۲ نوامبر ۲۰۲۶، Akamai از وجود اکسپلویت عمومی کارآمدی اطلاع نداشت [11] و تا ۳ نوامبر این CVE در فهرست KEV سازمان CISA نبود [14].
آیا IPv6 تحت تأثیر است؟
نه از سوی مشکل اصلی. توضیح کرنل میگوید IPv6 گزینهها را به جای انتقال، تکثیر میکند، اما به یک مشکل مرتبط در انتقال با گزینههای CALIPSO اشاره دارد که در وصلهای جداگانه برطرف خواهد شد [2].
واژهنامه
- CVE
- Common Vulnerabilities and Exposures (آسیبپذیریها و مواجهههای رایج): شناسهای عمومی برای یک نقص امنیتی مشخص و مستند، مانند CVE-2026-98432 [1].
- Use-after-free (استفاده پس از آزادسازی)
- نوعی باگ ایمنی حافظه که در آن نرمافزار پس از آزاد کردن حافظه همچنان از آن استفاده میکند، در حالی که ممکن است آن حافظه اکنون دادههای دیگری را در خود داشته باشد.
- CVSS
- Common Vulnerability Scoring System (سامانه امتیازدهی رایج آسیبپذیری): امتیاز شدت از ۰ تا ۱۰؛ امتیاز ۹٫۸ در رده «بحرانی» قرار دارد [1].
- MPTCP
- Multipath TCP: افزونهای که به یک اتصال TCP اجازه میدهد از چند مسیر شبکه استفاده کند. Go 1.24 و نسخههای بعدی آن را بهطور پیشفرض برای سوکتهای شنونده در لینوکس فعال میکنند [5].
- گزینههای IPv4
- فیلدهای اختیاری در سرآیند IPv4، مانند Record Route و Timestamp، که مهاجم میتواند آنها را در یک بسته SYN قرار دهد تا به کد آسیبپذیر برسد [1].
- KASLR
- Kernel Address Space Layout Randomisation (تصادفیسازی چیدمان فضای نشانی کرنل): سازوکاری دفاعی که کرنل را در نشانی غیرقابلپیشبینی از حافظه قرار میدهد. اکسپلویت Anthropic ابتدا یک اشارهگر را نشت میدهد تا آن را خنثی کند [4].
- RCU
- Read-copy-update (خواندن-کپی-بهروزرسانی): روشی در کرنل که آزادسازی حافظه را تا زمانی که هیچ خوانندهای دیگر از آن استفاده نکند به تأخیر میاندازد. وصله، دو عمل آزادسازی را به kfree_rcu() تغییر میدهد [2].
منابع
- CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period CVE Program (record assigned by the Linux kernel CNA) · 2026-10-15
- CVE-2026-98432 announcement: description, severity and affected/fixed versions Linux kernel CVE team (kernel.org) · 2026-10-15
- ipv4: free inet_opt and ireq_opt after an RCU grace period (mainline commit e3f33b0a1d89) Linux kernel source tree (kernel.org) · 2026-10-05
- Discovering vulnerabilities with Claude Anthropic · 2026-10-27
- Fwd: Protecting against CVE-2026-98432 when using Go programs (Go Security Team announcement) oss-security mailing list (Openwall) · 2026-10-30
- RHSB-2026-016 Use-after-free - kernel IPv4 (CVE-2026-98432) Red Hat Product Security · 2026-10-30
- CVE-2026-98432 (Red Hat CVE database: severity, statement and affected packages) Red Hat; live page, retrieved 2026-11-03 · 2026-10-15
- CVE-2026-98432 | Ubuntu Canonical Ubuntu Security; live page, retrieved 2026-11-03 · 2026-10-15
- CVE-2026-98432 (Debian Security Bug Tracker) Debian Security Team; live page, retrieved 2026-11-03
- CVE-2026-98432: fixed kernels and interim mitigations for AlmaLinux AlmaLinux OS Foundation (Andrew Lukoshko) · 2026-10-30
- CVE-2026-98432: A Remote Use-After-Free in the Linux Kernel's TCP Stack Akamai Security Intelligence Group · 2026-11-02
- Re: CVE-2026-98432: init_on_free=1 as an additional interim mitigation oss-security mailing list (Openwall) · 2026-11-03
- Android Security Bulletin, November 2026 Android Open Source Project (Google) · 2026-11-02
- Known Exploited Vulnerabilities Catalog US Cybersecurity and Infrastructure Security Agency (CISA); checked 2026-11-03
نظرات
نظرهای برتر