این گزارش با تمرکز بر آسیب پذیری Linux Kernel نوشته شده است تا مدیران بتوانند بین خطر واقعی، پیش‌شرط‌های بهره‌برداری و راهکارهای کاهش ریسک تفاوت بگذارند.
چهار آسیب پذیری Linux Kernel در زیرسیستم شبکه
Red Hat در بولتن امنیتی به‌روزشدهٔ ۲۶ سپتامبر ۲۰۲۶ از چهار نقص مهم در زیرسیستم‌های شبکهٔ هستهٔ لینوکس خبر داده است. این موارد با شناسه‌های CVE-۲۰۲۶-۸۰۸۴۴، CVE-۲۰۲۶-۸۱۰۰۰، CVE-۲۰۲۶-۶۸۱۲۱ و CVE-۲۰۲۶-۷۴۴۶۹ ثبت شده‌اند و نام‌های DirtyAH6، TUNderflow، PPPoEject و DiagSpill را دارند. شدت همهٔ موارد در سطح Important ارزیابی شده، اما میزان خطر به فعال‌بودن قابلیت‌های شبکه، سطح دسترسی پردازش‌ها و نوع محصول بستگی دارد.
این آسیب پذیری Linux Kernel به یک مسیر واحد محدود نیست. هر نقص بخش متفاوتی مانند IPv6 AH، درایور TUN/TAP، PPPoE یا رابط تشخیصی SCTP را هدف می‌گیرد. سه مورد نخست در صورت برقراربودن پیش‌شرط‌ها می‌توانند به کاربر محلی اجازه دهند دسترسی خود را تا root افزایش دهد. DiagSpill نیز در پیکربندی‌های خاص SCTP می‌تواند باعث اختلال از راه دور شود؛ بنابراین مدیران سرور نباید فقط به فایروال مرزی اکتفا کنند.
جزئیات فنی و دامنهٔ اثر
DirtyAH6 در پردازش IPv6 Authentication Header رخ می‌دهد و با یک بستهٔ دست‌کاری‌شده می‌تواند به دسترسی خارج از محدوده منجر شود. TUNderflow در مسیر پردازش دستگاه‌های TUN/TAP، مقدار headroom را به شکل ناامن مدیریت می‌کند و در شرایط مشخص امکان خراب‌شدن حافظه را ایجاد می‌کند. PPPoEject نیز هنگام تغییر بافر بسته، به داده‌ای اشاره می‌کند که ممکن است دیگر معتبر نباشد. این سه مسیر معمولاً به namespaceهای کاربر و شبکه یا قابلیت‌های قدرتمند مانند CAP_NET_ADMIN وابسته‌اند.
DiagSpill در رابط sctp_diag قرار دارد. در این نقص، تعداد transportهای SCTP می‌تواند سرریز شود و اندازهٔ پاسخ Netlink با دادهٔ واقعی هماهنگ نباشد. طبق توضیح Red Hat، این مسیر به namespace کاربر غیرمجاز یا قابلیت ویژه نیاز ندارد، هرچند برای سوءاستفادهٔ عملی، SCTP و sctp_diag باید در محیط فعال باشند. در برخی تنظیمات ASCONF و SCTP-AUTH نیز امکان ایجاد denial of service مطرح است.
آیا همهٔ سرورها در معرض خطر یکسان هستند؟
خیر. یک آسیب پذیری Linux Kernel زمانی به تهدید عملی تبدیل می‌شود که قابلیت مربوطه در هسته یا ماژول‌ها فعال باشد و مهاجم بتواند پیش‌شرط لازم را فراهم کند. Red Hat نسخه‌های RHEL ۶ تا RHEL ۱۰ و محصولات وابسته به هستهٔ RHEL، از جمله OpenShift و RHEL CoreOS، را در دامنهٔ بررسی قرار داده است. با این حال، ارزیابی OpenShift با تنظیمات پیش‌فرض restricted-v2 کم‌خطر اعلام شده، چون این سیاست بسیاری از قابلیت‌های لازم برای سه نقص اول را محدود می‌کند.
مدیران باید فهرست قابلیت‌های فعال را با معماری واقعی سرویس مقایسه کنند. سروری که VPN، شبکهٔ کانتینری، IPv6 IPsec، PPPoE یا SCTP ندارد، سطح حملهٔ کوچک‌تری دارد؛ اما این موضوع جایگزین وصله‌کردن نیست. همچنین اعطای قابلیت‌های اضافه به کانتینرها یا پردازش‌ها می‌تواند ارزیابی پیش‌فرض را بی‌اعتبار کند.
در چنین ارزیابی‌ای، آسیب پذیری Linux Kernel را نباید جدا از تنظیمات عملیاتی سرور تحلیل کرد؛ همان نقص ممکن است روی یک میزبان عمومی، یک نود OpenShift یا یک ماشین توسعه ریسک متفاوتی داشته باشد.
اقدام فوری برای مدیران Linux و OpenShift
اولین اقدام، بررسی نسخهٔ kernel و نصب بستهٔ اصلاحی ارائه‌شده توسط توزیع لینوکس است. پس از به‌روزرسانی، در صورت نیاز reboot انجام دهید تا هستهٔ جدید واقعاً در حال اجرا باشد و سپس وضعیت سرویس‌های حیاتی، شبکهٔ کانتینری و VPN را کنترل کنید. برای سرورهای Red Hat، وضعیت errata و نسخهٔ اصلاحی را از پورتال رسمی همان محصول بررسی کنید.
اگر یک آسیب پذیری Linux Kernel در محیط شما فعال است اما هنوز بستهٔ اصلاحی در دسترس نیست، می‌توان قابلیت‌های غیرضروری را موقتاً محدود کرد. غیرفعال‌کردن user namespace مسیر عادی سوءاستفاده از DirtyAH6، TUNderflow و PPPoEject را کاهش می‌دهد، اما ممکن است sandbox مرورگر، runtime کانتینر یا سرویس‌های دیگر را مختل کند. مسدودکردن ماژول‌های ah6، tun، pppoe، sctp یا sctp_diag نیز فقط پس از بررسی وابستگی‌ها انجام شود؛ این کار برای محیطی که به VPN، شبکهٔ VM یا SCTP نیاز دارد مناسب نیست.
چک‌لیست بررسی و پایش
لاگ‌های kernel، سرویس‌های شبکه و رخدادهای کانتینر را برای خطاهای غیرعادی، crash یا تلاش برای ایجاد namespace بررسی کنید. تغییرات اخیر در capabilityها، سیاست‌های seccomp، تنظیمات sysctl و ماژول‌های بارگذاری‌شده را با baseline سازمان مقایسه کنید. اگر نشانه‌ای از دسترسی غیرمجاز وجود دارد، سیستم را ایزوله، شواهد را حفظ و بررسی پاسخ‌گویی به رخداد را آغاز کنید؛ خاموش‌کردن یا پاک‌سازی عجولانه می‌تواند شواهد را از بین ببرد.
برای جزئیات کامل، بولتن رسمی Red Hat دربارهٔ آسیب پذیری Linux Kernel، راهنمای امنیت سرور لینوکس در تکتاز مگ و مستندات امنیت OpenShift را بررسی کنید.
جمع‌بندی
چهار نقص شبکه‌ای جدید نشان می‌دهند که به‌روزرسانی kernel فقط یک کار نگهداری عادی نیست. هر آسیب پذیری Linux Kernel باید با توجه به قابلیت‌های فعال، سطح دسترسی پردازش‌ها و نقش سرور ارزیابی شود. نصب وصلهٔ رسمی کامل‌ترین راهکار است و mitigationهای موقت باید با آزمون سازگاری و برنامهٔ بازگشت اجرا شوند. مدیران Linux و OpenShift بهتر است همین حالا نسخهٔ kernel، ماژول‌های شبکه و capabilityهای کانتینر را بازبینی کنند.
بازبینی دوره‌ای آسیب پذیری Linux Kernel، نسخهٔ در حال اجرا و ماژول‌های شبکه باید بخشی از فرایند معمول نگهداری سرور باشد.
