Dirty Frag برای سرورهای هاستینگ، VPS، Docker، Kubernetes، CI/CD Runnerها و هر محیطی که کاربر یا Workload غیرقابل اعتماد اجرا میکند اهمیت زیادی دارد. در چنین محیطهایی، حتی یک دسترسی محدود میتواند نقطه شروع حمله باشد. مهاجم ابتدا کد را با سطح دسترسی عادی اجرا میکند، سپس از ضعف Kernel کمک میگیرد و به Root میرسد.
Dirty Frag دقیقاً چیست
Dirty Frag به دو ضعف امنیتی در Linux Kernel اشاره دارد. آسیبپذیری اول بخش IPsec ESP را هدف قرار میدهد و با CVE-2026-43284 شناخته میشود. آسیبپذیری دوم به RxRPC مربوط است و با CVE-2026-43500 دنبال میشود. AlmaLinux توضیح میدهد که Dirty Frag این دو ضعف را زنجیره میکند؛ بخش ESP ماژولهای esp4 و esp6 را درگیر میکند و بخش RxRPC مسیر rxrpc را هدف میگیرد.
ESP یا Encapsulating Security Protocol یکی از اجزای مهم IPsec است. مدیران شبکه از IPsec برای ساخت ارتباط امن، تونلهای VPN و محافظت از ترافیک شبکه استفاده میکنند. RxRPC نیز در برخی کاربردهای خاص مانند AFS نقش دارد. شاید بسیاری از سرورها مستقیماً از IPsec یا AFS استفاده نکنند، اما وجود ماژولهای آسیبپذیر در Kernel همچنان سطح حمله را باز نگه میدهد.
اوبونتو تأکید میکند که این دو آسیبپذیری مستقل هستند. بنابراین اگر مدیر سرور فقط esp4 و esp6 را غیرفعال کند اما rxrpc را فعال نگه دارد، هنوز بخشی از مسیر حمله باز میماند. برعکس این حالت نیز درست است. برای کاهش ریسک باید هر دو مسیر را بررسی کرد.
Dirty Frag چگونه کار میکند
Dirty Frag به نحوه مدیریت Fragmentها، Page Cache و مسیرهای شبکه در Kernel مربوط میشود. Kernel هنگام پردازش دادههای شبکه با Pageهایی کار میکند که همیشه مالکیت خصوصی و کامل آنها را در اختیار ندارد. اگر Kernel روی همان دادهها عملیات In-place انجام دهد، مهاجم میتواند از این رفتار برای دستکاری Page Cache کمک بگیرد.
AlmaLinux ریشه مشکل را در مسیرهای In-place Decryption مربوط به esp4، esp6 و rxrpc توضیح میدهد. وقتی Socket Buffer شامل Fragmentهایی باشد که Kernel مالکیت خصوصی کامل روی آنها ندارد، مسیر دریافت میتواند Decrypt را مستقیماً روی همان Pageها انجام دهد. همین رفتار به مهاجم امکان میدهد دادههایی را تغییر دهد که یک پردازش کمدسترسی هنوز به آنها Reference دارد.
اوبونتو نیز در توضیح CVE-2026-43284 به MSG_SPLICE_PAGES اشاره میکند. این مسیر میتواند Pageهای یک Pipe را مستقیماً به Socket Buffer متصل کند. برخی مسیرهای IPv4 و IPv6 هنگام Splice کردن Pageها به UDP Socket Buffer، Flag لازم را تنظیم نمیکردند. در نتیجه مسیرهایی که بعداً داده را تغییر میدادند، قبل از تغییر داده نسخه خصوصی نمیساختند.
این رفتار خطرناک است، چون مهاجم فقط باعث کرش یا اختلال ساده نمیشود. او میتواند Page Cache را هدف بگیرد. Page Cache همان لایهای است که Kernel برای نگهداری داده فایلها در حافظه استفاده میکند. اگر مهاجم بتواند داده حساس را در Page Cache تغییر دهد، ممکن است رفتار فایلهای سیستمی را تغییر دهد بدون اینکه الزاماً فایل روی دیسک تغییر کند.
چرا Dirty Frag خطرناک است
Dirty Frag از نوع Local Privilege Escalation است. یعنی مهاجم برای شروع حمله به دسترسی محلی نیاز دارد. این دسترسی میتواند از طریق SSH، Web Shell، یک سرویس آسیبدیده، یک Container، یک Runner یا یک حساب کاربری محدود به دست بیاید. بعد از این مرحله، مهاجم میتواند Dirty Frag را اجرا کند و به Root برسد.
وقتی مهاجم Root بگیرد، میتواند ابزارهای امنیتی را خاموش کند، Credentialها را بخواند، لاگها را تغییر دهد، در شبکه حرکت جانبی انجام دهد و دسترسی پایدار بسازد. خطر Dirty Frag فقط به شدت فنی آن محدود نمیشود؛ انتشار Proof of Concept عمومی برای این زنجیره امنیتی باعث میشود مدیران سرور زمان کمتری برای واکنش داشته باشند.
ارتباط Dirty Frag با Copy-Fail
Dirty Frag از نظر اثر امنیتی به Copy-Fail شباهت دارد، اما همان آسیبپذیری نیست. هر دو ضعف امنیتی در سطح Kernel عمل میکنند و میتوانند مسیر افزایش سطح دسترسی به Root را باز کنند. با این حال، مسیر فنی آنها متفاوت است.
مدیران سرور نباید تصور کنند Mitigation مربوط به Copy-Fail برای Dirty Frag هم کافی است. Copy-Fail روی مسیر algif_aead تمرکز داشت، اما Dirty Frag مسیرهای esp4، esp6 و rxrpc را درگیر میکند. بنابراین باید Dirty Frag را جداگانه بررسی و رفع کرد.
کدام سیستمها بیشتر در معرض خطر هستند
Dirty Frag بسیاری از توزیعهای لینوکسی را درگیر میکند. Ubuntu، RHEL، CentOS Stream، AlmaLinux، Fedora، openSUSE و OpenShift از جمله محیطهایی هستند که مدیران آنها باید وضعیت Kernel و ماژولهای آسیبپذیر را بررسی کنند.
وضعیت دقیق هر سرور به نسخه Kernel فعال، نسخه پکیجها، Patchهای نصبشده و Load بودن ماژولها بستگی دارد. در AlmaLinux نیز همه نسخههای پشتیبانیشده از نظر بخش ESP اهمیت دارند. بخش RxRPC در AlmaLinux 9 و ۱۰ زمانی اهمیت بیشتری پیدا میکند که پکیج kernel-modules-partner نصب باشد.
Dirty Frag در Docker و Kubernetes
محیطهای Container ریسک Dirty Frag را بیشتر میکنند. Docker، Podman و Kubernetes از Kernel میزبان استفاده میکنند. اگر Host آسیبپذیر باشد، Containerها نیز روی همان Kernel اجرا میشوند. بنابراین محدود بودن Container بهتنهایی امنیت کامل ایجاد نمیکند.
برای سرورهای هاستینگ، CI/CD Runnerها و Nodeهای Kubernetes، این موضوع بسیار مهم است. یک Container محدود میتواند در ظاهر ایزوله باشد، اما اگر Kernel میزبان ضعف داشته باشد، همان Container میتواند به نقطه شروع حمله تبدیل شود.
چرا آسیبپذیریهای Kernel خطرناکترند
آسیبپذیریهای معمولی معمولاً یک سرویس یا برنامه را درگیر میکنند. اما Kernel مرز اصلی اعتماد در سیستمعامل را میسازد. وقتی مهاجم این مرز را دور بزند، میتواند بسیاری از کنترلهای امنیتی دیگر را بیاثر کند.
وقتی مهاجم Root میگیرد، میتواند فایلهای سیستمی را تغییر دهد، سرویسهای امنیتی را خاموش کند، کلیدها و رمزها را بخواند، پردازشها را پنهان کند، لاگها را پاک کند و دسترسی دائمی بسازد. به همین دلیل آسیبپذیریهای Kernel معمولاً در مرحله دوم حمله نقش دارند. مهاجم ابتدا از یک مسیر سادهتر وارد میشود، سپس با یک LPE کرنلی به Root میرسد.
بررسی اولیه Dirty Frag روی سرور لینوکس
قبل از هر اقدام، نسخه Kernel فعال را بررسی کنید:
uname -rاین دستور Kernel فعال فعلی را نشان میدهد. اگر Kernel جدید را نصب کرده باشید اما سیستم را Reboot نکرده باشید، خروجی همچنان Kernel قدیمی را نشان میدهد. بنابراین همیشه uname -r را معیار وضعیت واقعی سیستم بدانید.
برای بررسی Load بودن ماژولهای مرتبط با Dirty Frag، این دستور را اجرا کنید:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"اگر خروجی نشان دهد ماژولها Load هستند، سطح حمله فعال است. اگر ماژولها Load نیستند، باز هم باید Kernel را Patch کنید؛ چون ممکن است یک سرویس یا کاربر در آینده آنها را Load کند.
Mitigation دستی در Ubuntu
اوبونتو برای کاهش فوری ریسک، غیرفعالسازی ماژولهای آسیبپذیر را پیشنهاد میکند. این روش سه کار انجام میدهد: از Load شدن ماژولها جلوگیری میکند، ماژولهای فعلی را Unload میکند و وضعیت را دوباره بررسی میکند.
ابتدا فایل تنظیمات بسازید:
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.confسپس initramfs را بازسازی کنید تا سیستم در Early Boot نیز این ماژولها را Load نکند:
sudo update-initramfs -u -k allاگر ماژولها از قبل Load شدهاند، آنها را خارج کنید:
sudo rmmod esp4 esp6 rxrpc 2>/dev/nullبعد وضعیت را بررسی کنید:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"اگر ماژولها همچنان Load هستند یا Unload موفق نشد، سرور را Reboot کنید:
sudo rebootحذف Mitigation در Ubuntu پس از نصب Kernel امن
وقتی Kernel امن را نصب کردید، میتوانید فایل Mitigation را حذف کنید:
sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k allقبل از حذف Mitigation، نسخه Kernel فعال را بررسی کنید:
uname -rریسک جانبی Mitigation در Ubuntu
غیرفعال کردن esp4، esp6 و rxrpc میتواند روی سرویسهایی مثل IPsec VPN، StrongSwan و AFS اثر بگذارد. قبل از اجرای Mitigation روی سرور Production، بررسی کنید سرویس VPN یا AFS فعال نباشد. اگر از این سرویسها استفاده میکنید، Patch Kernel را در اولویت قرار دهید و Mitigation را با برنامهریزی انجام دهید.
رفع Dirty Frag در AlmaLinux
AlmaLinux برای Dirty Frag مسیر اصلی را نصب Kernel Patch شده میداند. این توزیع Kernelهای اصلاحشده را برای نسخههای پشتیبانیشده منتشر کرده و مدیر سرور باید Kernel را به نسخه امن ارتقا دهد.
برای آپدیت Kernel در AlmaLinux این دستورات را اجرا کنید:
sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo rebootبعد از Reboot، نسخه Kernel را بررسی کنید:
uname -r
rpm -q kernelبرای AlmaLinux 8 باید Kernel برابر یا بالاتر از ۴.۱۸.۰-۵۵۳.۱۲۳.۲.el8_10 باشد. برا نسخه ۹ باید نسخه برابر یا بالاتر از ۵.۱۴.۰-۶۱۱.۵۴.۳.el9_7 باشد. برای ۱۰ باید نسخه برابر یا بالاتر از ۶.۱۲.۰-۱۲۴.۵۵.۲.el10_1 باشد.
Mitigation موقت در AlmaLinux
اگر در لحظه نمیتوانید Kernel را آپدیت و سرور را Reboot کنید، میتوانید Mitigation موقت اعمال کنید. این روش ماژولهای esp4، esp6 و rxrpc را Blacklist میکند و در صورت Load بودن، تلاش میکند آنها را Unload کند.
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"وضعیت را بررسی کنید:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"برای حذف Mitigation:
sudo rm /etc/modprobe.d/dirtyfrag.confاگر فکر میکنید سیستم پیش از Mitigation هدف حمله قرار گرفته، AlmaLinux پیشنهاد میکند Page Cache را Drop کنید:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'این دستور دادههای روی دیسک را حذف نمیکند، اما ممکن است برای مدتی فشار I/O ایجاد کند. روی سرور Production ابتدا اثر آن را بررسی کنید.
بررسی kernel-modules-partner در AlmaLinux
در AlmaLinux، بخش RxRPC همیشه در همه سیستمها فعال نیست. CVE-2026-43500 در AlmaLinux 9 و ۱۰ زمانی اهمیت دارد که پکیج kernel-modules-partner نصب باشد. این پکیج ماژول rxrpc.ko را ارائه میدهد. AlmaLinux 8 این ماژول را Build نمیکند.
برای بررسی نصب بودن این پکیج:
rpm -q kernel-modules-partnerاگر این پکیج نصب نیست، بخش RxRPC احتمالاً روی سیستم شما فعال نیست. با این حال، بخش ESP همچنان اهمیت دارد و باید Kernel را Patch کنید.
چکلیست عملی برای Ubuntu
برای Ubuntu ابتدا این بررسیها را انجام دهید:
uname -r
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"اگر فعلاً Kernel Patch شده ندارید یا نمیتوانید Update فوری انجام دهید، Mitigation را اعمال کنید:
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
sudo rmmod esp4 esp6 rxrpc 2>/dev/nullبعد دوباره بررسی کنید:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"اگر ماژولها همچنان Load هستند:
sudo rebootچکلیست عملی برای AlmaLinux
برای AlmaLinux ابتدا Kernel را بررسی کنید:
uname -r
rpm -q kernelسپس Kernel را آپدیت کنید:
sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo rebootبعد از Reboot:
uname -r
rpm -q kernelاگر فعلاً نمیتوانید Reboot کنید، Mitigation موقت را اجرا کنید:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"و بررسی کنید:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"بهترین روش برای سرورهای Production
در سرورهای Production، Patch را با برنامه اجرا کنید اما آن را طولانیمدت عقب نیندازید. Dirty Frag PoC عمومی دارد و همین موضوع ریسک عملیاتی را افزایش میدهد.
اگر چند سرور پشت Load Balancer دارید، هر بار یک Node را از چرخه خارج کنید. سپس Update یا Mitigation را اعمال کنید، Reboot انجام دهید، سلامت سرویس را بررسی کنید و Node را به چرخه برگردانید. این روش Downtime را کاهش میدهد.
اگر سرور Single Node دارید، یک Maintenance Window کوتاه تعریف کنید. قبل از تغییر Snapshot یا Backup معتبر بگیرید. سپس Mitigation یا Kernel Update را انجام دهید و Reboot را در زمان کمترافیک اجرا کنید.
اگر روی سرور IPsec، StrongSwan، AFS یا سرویسهای خاص شبکه دارید، قبل از Blacklist کردن ماژولها اثر عملیاتی را بررسی کنید.
اشتباهات رایج در مواجهه با Dirty Frag
مدیران سرور گاهی تصور میکنند Mitigation مربوط به Copy-Fail برای Dirty Frag هم کافی است. این تصور اشتباه است. Dirty Frag مسیرهای esp4، esp6 و rxrpc را هدف میگیرد و باید جداگانه بررسی شود.
اشتباه دوم این است که مدیر فقط ماژولها را Unload میکند اما جلوی Load شدن مجدد آنها را نمیگیرد. باید فایل modprobe.d بسازید تا سیستم دوباره ماژولها را Load نکند.
اشتباه سوم این است که مدیر Kernel را نصب میکند اما Reboot انجام نمیدهد. تا وقتی سیستم با Kernel امن بوت نشود، Patch بهطور عملی فعال نمیشود.
اشتباه چهارم نادیده گرفتن Hostهای کانتینری است. اگر Host آسیبپذیر باشد، محدودیت Container امنیت کامل ایجاد نمیکند.
چرا شرکتهای هاستینگ باید سریعتر اقدام کنند
شرکتهای هاستینگ، ارائهدهندگان VPS و تیمهای زیرساخت باید Dirty Frag را با اولویت بالا بررسی کنند. در این محیطها چندین کاربر، سرویس، سایت یا Container روی یک بستر مشترک اجرا میشوند. اگر یک کاربر محدود بتواند از Kernel ضعف بگیرد، کل سرور در معرض خطر قرار میگیرد.
به همین دلیل Patch Management، Kernel Update، بررسی ماژولها و Reboot کنترلشده باید بخشی از فرآیند دائمی امنیت زیرساخت باشد.
جمعبندی نهایی
Dirty Frag یک آسیبپذیری مهم در Linux Kernel است که از دو مسیر ESP و RxRPC سوءاستفاده میکند. جامعه امنیتی این ضعف را با CVE-2026-43284 و CVE-2026-43500 دنبال میکند. مهاجم با دسترسی محلی میتواند این زنجیره را اجرا کند و به Root برسد.
این ضعف برای سرورهای هاستینگ، VPS، Docker، Kubernetes، CI/CD Runnerها و محیطهای چندکاربره اهمیت زیادی دارد. Mitigation مربوط به Copy-Fail برای Dirty Frag کافی نیست و مدیر سرور باید ماژولهای esp4، esp6 و rxrpc را جداگانه بررسی کند.
در Ubuntu، مدیر سرور میتواند با Blacklist کردن ماژولها، بازسازی initramfs، Unload کردن ماژولها و Reboot کنترلشده ریسک را کاهش دهد. در AlmaLinux، مدیر سرور باید Kernel Patch شده را نصب کند و پس از Reboot نسخه فعال را بررسی کند. اگر امکان Reboot فوری ندارد، Mitigation موقت با Blacklist کردن ماژولها میتواند تا زمان Patch کامل کمک کند.
نوین هاست یار نوین شماست
نوین هاست آسیبپذیریهای Kernel مانند Dirty Frag و Copy-Fail را بهصورت فعال بررسی میکند و برای سرورهای Ubuntu، AlmaLinux، CloudLinux و سایر توزیعهای لینوکسی راهکار مناسب ارائه میدهد. تیم فنی نوین هاست میتواند نسخه Kernel، وضعیت ماژولهای esp4، esp6 و rxrpc، شرایط IPsec یا AFS، نیاز به Mitigation موقت و امکان Reboot کنترلشده را بررسی کند.
اگر سرور شما روی نوین هاست میزبانی میشود یا مدیریت سرور خود را به نوین هاست سپردهاید و میخواهید مطمئن شوید Dirty Frag روی سیستم شما کنترل شده است، از پنل کاربری تیکت ثبت کنید. تیم فنی وضعیت سرور را بررسی میکند و اقدامات لازم برای کاهش ریسک یا رفع کامل آسیبپذیری را انجام میدهد. نوین هاست یار نوین شماست.
