آسیب‌پذیری Copy-Fail چیست و چگونه آن را در Ubuntu و AlmaLinux رفع کنیم

آسیب‌پذیری‌های Kernel همیشه از مهم‌ترین تهدیدهای امنیتی در زیرساخت‌های لینوکسی محسوب می‌شوند، چون مستقیماً با هسته سیستم‌عامل، مدیریت حافظه، مجوزهای پردازش‌ها و مرز امنیتی میان کاربران عادی و سطح Root درگیر هستند. آسیب‌پذیری جدیدی که با نام Copy-Fail شناخته می‌شود و با شناسه CVE-2026-31431 ثبت شده، دقیقاً در همین دسته قرار می‌گیرد. این ضعف امنیتی از نوع Local Privilege Escalation است؛ یعنی مهاجم برای سوءاستفاده ابتدا به دسترسی محلی روی سیستم نیاز دارد، اما پس از آن می‌تواند سطح دسترسی خود را تا Root افزایش دهد. اوبونتو این آسیب‌پذیری را با شدت High معرفی کرده و امتیاز CVSS آن را ۷.۸ اعلام کرده است. (Ubuntu)

Copy-Fail فقط یک باگ ساده در یک ابزار کاربری نیست. این مشکل در Linux Kernel و در مسیر Crypto API رخ می‌دهد و با ماژول algif_aead، رابط AF_ALG و سیستم‌کال splice() در ارتباط است. طبق توضیح AlmaLinux، این آسیب‌پذیری در زیرسیستم رمزنگاری Kernel قرار دارد و از یک Logic Flaw در authencesn استفاده می‌کند؛ ضعفی که می‌تواند به کاربر محلی غیرمجاز امکان افزایش سطح دسترسی بدهد. (AlmaLinux OS)

اهمیت این موضوع زمانی بیشتر می‌شود که بدانیم بسیاری از سرورهای هاستینگ، VPS، محیط‌های کانتینری، CI/CD Runnerها و سرورهای چندکاربره دقیقاً در همان نقطه‌ای آسیب‌پذیر هستند که Copy-Fail بیشترین اثر را دارد؛ یعنی جایی که یک کاربر یا پردازش محدود می‌تواند کد اجرا کند اما نباید به Root دسترسی داشته باشد.

Copy-Fail دقیقاً چیست

Copy-Fail یک آسیب‌پذیری Local Privilege Escalation در Linux Kernel است که به مهاجم محلی اجازه می‌دهد از ضعف موجود در مسیر پردازش رمزنگاری و کپی داده استفاده کند و به Root برسد. این آسیب‌پذیری با نام CVE-2026-31431 شناخته می‌شود و بخش آسیب‌پذیر آن با algif_aead و رابط AF_ALG در Kernel ارتباط دارد. CERT-EU نیز این آسیب‌پذیری را یک نقص Local Privilege Escalation در ماژول algif_aead معرفی کرده است. (CERT-EU)

در لینوکس، AF_ALG به برنامه‌های User Space اجازه می‌دهد از قابلیت‌های رمزنگاری Kernel استفاده کنند. ماژول algif_aead نیز بخشی از همین مسیر است و برای الگوریتم‌های AEAD یا Authenticated Encryption with Associated Data کاربرد دارد. در حالت عادی، این مکانیزم باید داده‌ها را به شکل کنترل‌شده و امن میان Bufferها جابه‌جا کند. اما در Copy-Fail، یک بهینه‌سازی قدیمی باعث می‌شود بخشی از مسیر کپی داده به شکل ناامن رفتار کند و امکان نوشتن کنترل‌شده در Page Cache ایجاد شود. CERT-EU اعلام کرده ریشه این مشکل به یک بهینه‌سازی In-place مربوط است که در سال ۲۰۱۷ وارد Kernel شده و باعث می‌شود Page-cache Pageها در یک Scatterlist قابل نوشتن قرار بگیرند. (CERT-EU)

چرا Copy-Fail خطرناک است

خطر اصلی Copy-Fail در این است که مهاجم به آسیب‌پذیری Remote نیاز ندارد. کافی است به سیستم دسترسی محلی داشته باشد؛ مثلاً یک User محدود، یک اکانت Shell، یک اسکریپت در محیط آموزشی، یک Container با امکان اجرای Command یا یک سرویس آسیب‌دیده که اجازه اجرای کد می‌دهد. در چنین شرایطی، مهاجم می‌تواند از ضعف Kernel استفاده کند و سطح دسترسی خود را ارتقا دهد.

این نوع آسیب‌پذیری برای سرورهای اشتراکی و هاستینگ اهمیت بسیار بالایی دارد. در یک سرور اشتراکی، چندین کاربر یا سایت روی یک سیستم اجرا می‌شوند. اگر یکی از آن‌ها بتواند از سطح محدود خود خارج شود، امنیت کل سرور در معرض خطر قرار می‌گیرد. همین موضوع برای VPSهایی که چند سرویس داخلی دارند، سرورهای DevOps، Nodeهای Kubernetes و Runnerهای CI/CD نیز صادق است.

در محیط‌های Container نیز ریسک بالاتر می‌رود. بسیاری از مدیران سیستم Container را یک مرز امنیتی کامل تصور می‌کنند، اما Containerها از Kernel میزبان استفاده می‌کنند. وقتی آسیب‌پذیری در Kernel وجود داشته باشد، ضعف امنیتی می‌تواند مرز میان Container و Host را تهدید کند. اوبونتو نیز در مقاله خود اشاره کرده که در Deployments کانتینری که Workloadهای بالقوه مخرب اجرا می‌کنند، این آسیب‌پذیری می‌تواند سناریوهای Container Escape را آسان‌تر کند، هرچند در زمان انتشار اطلاعیه، Proof of Concept عمومی برای Container Escape منتشر نشده بود. (Ubuntu)

ریشه فنی آسیب‌پذیری در Kernel Crypto Subsystem

برای درک بهتر Copy-Fail باید نقش AF_ALG و algif_aead را بشناسیم. AF_ALG یک Socket Family در Linux Kernel است که به برنامه‌های User Space اجازه می‌دهد از الگوریتم‌های رمزنگاری Kernel استفاده کنند. این طراحی برای سناریوهایی مفید است که برنامه می‌خواهد عملیات رمزنگاری را با کمک Kernel یا شتاب‌گیری سخت‌افزاری انجام دهد.

ماژول algif_aead رابط مربوط به الگوریتم‌های AEAD را فراهم می‌کند. AEAD هم‌زمان محرمانگی و صحت داده را مدیریت می‌کند و در بسیاری از کاربردهای رمزنگاری اهمیت دارد. مشکل Copy-Fail در مسیر ترکیب AF_ALG، splice() و منطق داخلی authencesn ایجاد می‌شود. طبق توضیح AlmaLinux، این باگ در Kernel Crypto Subsystem قرار دارد و مسیر authencesn از طریق AF_ALG و splice() می‌تواند به افزایش سطح دسترسی محلی منجر شود. (AlmaLinux OS)

در سطح مفهومی، مهاجم می‌تواند از این ضعف برای دستکاری Page Cache استفاده کند. Page Cache بخشی از Kernel است که داده‌های فایل‌ها را در حافظه نگه می‌دارد تا دسترسی به آن‌ها سریع‌تر شود. وقتی امکان نوشتن کنترل‌شده در Page Cache ایجاد شود، مهاجم ممکن است رفتار فایل‌هایی را که سیستم از حافظه می‌خواند تغییر دهد، بدون اینکه الزاماً محتوای روی دیسک به همان شکل تغییر کند. همین موضوع باعث می‌شود برخی ابزارهای مانیتورینگ مبتنی بر بررسی Checksum فایل روی دیسک، تغییر را تشخیص ندهند. گزارش‌های فنی منتشرشده نیز به همین ویژگی اشاره کرده‌اند که Page-cache corruption می‌تواند برای ابزارهایی که فقط فایل روی دیسک را بررسی می‌کنند قابل مشاهده نباشد. (The Verge)

کدام سیستم‌ها بیشتر در معرض خطر هستند

تقریباً هر سیستم لینوکسی آسیب‌پذیر که به کاربر محلی یا پردازش غیرقابل اعتماد اجازه اجرا بدهد، باید این مشکل را جدی بگیرد. اما چند گروه در اولویت بالاتری قرار دارند.

سرورهای هاستینگ اشتراکی یکی از مهم‌ترین گروه‌ها هستند، چون چندین کاربر روی یک Kernel مشترک فعالیت می‌کنند. VPSها و سرورهای Cloud نیز باید بررسی شوند، به‌ویژه اگر چند سرویس یا کاربر روی آن‌ها فعال باشد. محیط‌های Docker، Podman و Kubernetes هم به دلیل اشتراک Kernel با Host اهمیت ویژه‌ای دارند. سرورهای CI/CD نیز خطر بالایی دارند، چون Runnerها معمولاً کدهای متنوع و گاهی غیرقابل اعتماد را اجرا می‌کنند.

در سرورهای شخصی تک‌کاربره ریسک کمتر است، اما همچنان باید Patch انجام شود. امنیت سرور فقط به این وابسته نیست که امروز چه کسی دسترسی دارد؛ ممکن است در آینده یک سرویس آسیب‌پذیر امکان اجرای کد محدود ایجاد کند و همان دسترسی محدود برای سوءاستفاده کافی باشد.

رویکرد کلی برای رفع Copy-Fail

برای رفع Copy-Fail باید سه کار اصلی انجام دهیم. اول باید نسخه سیستم و Kernel را بررسی کنیم. دوم باید Update رسمی توزیع را نصب کنیم. سوم باید مطمئن شویم سیستم واقعاً با Kernel یا Mitigation امن اجرا می‌شود.

در Ubuntu، Canonical ابتدا Mitigation را از طریق پکیج kmod منتشر کرده تا بارگذاری ماژول آسیب‌پذیر algif_aead غیرفعال شود. در اطلاعیه امنیتی USN-8226-1 نیز آمده که آپدیت kmod بارگذاری ماژول algif_aead را به‌عنوان اقدام Mitigation غیرفعال می‌کند تا Kernel Updateها در دسترس قرار بگیرند. (Ubuntu)

در AlmaLinux، مسیر اصلی رفع مشکل نصب Kernel Patch شده است. AlmaLinux اعلام کرده که همه Releaseهای پشتیبانی‌شده تحت تأثیر قرار گرفته‌اند و نسخه‌های Patch شده Kernel برای AlmaLinux 8، ۹، ۱۰ و AlmaLinux Kitten 10 منتشر شده‌اند. (AlmaLinux OS)

بررسی آسیب‌پذیری در Ubuntu

برای بررسی اولیه در Ubuntu، ابتدا نسخه Kernel در حال اجرا را ببینید:

uname -r

این دستور فقط Kernel فعال فعلی را نشان می‌دهد. اگر Kernel جدید نصب شده باشد اما سیستم Reboot نشده باشد، خروجی همچنان نسخه قدیمی را نشان می‌دهد. بنابراین همیشه uname -r را معیار Kernel فعال بدانید.

برای مشاهده Kernel Packageهای نصب‌شده:

dpkg -l 'linux-image*' | grep ^ii

برای بررسی نسخه kmod:

dpkg -l kmod

در Ubuntu، این بررسی اهمیت دارد چون Mitigation اولیه از طریق kmod ارائه شده است. طبق مقاله اوبونتو، نسخه‌های قبل از Ubuntu 26.04 تحت تأثیر قرار گرفته‌اند و Ubuntu 26.04 نیازی به این به‌روزرسانی ندارد. اوبونتو برای Releaseهای مختلف نسخه امن kmod منتشر کرده است. (Ubuntu)

نسخه‌های تحت تأثیر در Ubuntu

طبق اطلاعات منتشرشده توسط Ubuntu، وضعیت کلی نسخه‌ها به این شکل است:

این جدول به این معنا نیست که همه سرورها در وضعیت یکسانی قرار دارند. وضعیت واقعی به Kernel فعال، پکیج‌های نصب‌شده و اعمال شدن Mitigation بستگی دارد. بنابراین باید روی هر سرور بررسی عملی انجام شود.

رفع Copy-Fail در Ubuntu با آپدیت کامل سیستم

روش پیشنهادی برای بیشتر سرورها این است که Updateهای امنیتی را کامل نصب کنید:

sudo apt update && sudo apt upgrade

این دستور فهرست پکیج‌ها را به‌روزرسانی می‌کند و آپدیت‌های موجود را نصب می‌کند. در سرورهای Production، بهتر است قبل از اجرای آن Snapshot یا Backup داشته باشید و تغییرات را در Maintenance Window انجام دهید.

اگر Kernel جدید نصب شود، باید سرور را Reboot کنید:

sudo reboot

بعد از Reboot نسخه Kernel فعال را بررسی کنید:

uname -r

اگر فقط پکیج نصب شود اما Reboot انجام نشود، Kernel قبلی همچنان فعال می‌ماند و Patch Kernel به‌صورت عملی وارد مدار نمی‌شود.

نصب هدفمند Mitigation در Ubuntu با kmod

اگر نمی‌خواهید همه پکیج‌ها را آپدیت کنید و فقط قصد دارید Mitigation مربوط به Copy-Fail را نصب کنید، می‌توانید پکیج kmod را به‌صورت هدفمند ارتقا دهید:

sudo apt update && sudo apt install --only-upgrade kmod

این روش زمانی کاربرد دارد که سرور حساس است و نمی‌خواهید تغییرات گسترده روی همه پکیج‌ها اعمال شود. با این حال، از دید امنیتی بهتر است در اولین فرصت همه Patchهای امنیتی مهم را نصب کنید.

بررسی Load بودن ماژول algif_aead در Ubuntu

بعد از نصب Mitigation یا قبل از Reboot، باید بررسی کنید ماژول آسیب‌پذیر در حال حاضر Load شده یا نه:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

اگر خروجی این دستور نشان دهد ماژول Load نیست، مسیر سوءاستفاده فعلی از این ماژول فعال نیست. اگر خروجی نشان دهد ماژول Load شده است، باید تلاش کنید آن را Unload کنید:

sudo rmmod algif_aead 2>/dev/null

سپس دوباره بررسی کنید:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

اگر ماژول همچنان Load باقی ماند، احتمالاً یک سرویس یا پردازش از آن استفاده می‌کند. در این حالت Reboot کنترل‌شده بهترین مسیر است.

Mitigation دستی در Ubuntu اگر امکان آپدیت kmod ندارید

اگر به هر دلیل امکان آپدیت kmod وجود ندارد، می‌توانید ماژول را به شکل دستی Block کنید:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf

سپس اگر ماژول از قبل Load شده است، آن را خارج کنید:

sudo rmmod algif_aead 2>/dev/null

و وضعیت را بررسی کنید:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

اگر خروجی همچنان Load بودن ماژول را نشان دهد، سرور را Reboot کنید:

sudo reboot

این روش باید Mitigation موقت محسوب شود. راهکار اصلی همچنان نصب آپدیت رسمی توزیع است.

اگر Mitigation در Ubuntu باعث اختلال شد

غیرفعال‌سازی algif_aead ممکن است روی برخی برنامه‌هایی که از مسیر رمزنگاری Kernel استفاده می‌کنند اثر بگذارد. اوبونتو توضیح داده که برنامه‌ها معمولاً باید به مسیر رمزنگاری User Space برگردند، اما ممکن است برخی سرویس‌ها چنین رفتاری نداشته باشند. در شرایط اضطراری و پس از تحلیل ریسک، می‌توانید Mitigation مربوط به فایل رسمی را Comment کنید:

sudo sed -i 's/^/#/' /etc/modprobe.d/disable-algif_aead.conf

سپس Reboot کنید:

sudo reboot

این کار امنیت سیستم را کاهش می‌دهد و فقط زمانی باید انجام شود که مشکل سازگاری جدی وجود داشته باشد و جایگزین عملی دیگری ندارید.

بررسی آسیب‌پذیری در AlmaLinux

AlmaLinux مسیر متفاوتی نسبت به Ubuntu دارد. در AlmaLinux، راهکار اصلی نصب Kernel Patch شده است. AlmaLinux در اطلاعیه رسمی خود نسخه‌های امن Kernel را برای Releaseهای پشتیبانی‌شده معرفی کرده و اعلام کرده است که نسخه‌های Production در Repositoryهای اصلی در دسترس هستند.

برای بررسی Kernel فعال در AlmaLinux:

uname -r

برای مشاهده Kernelهای نصب‌شده:

rpm -q kernel

اگر rpm -q kernel نسخه امن را نشان دهد اما uname -r نسخه قدیمی را نمایش دهد، یعنی Kernel جدید نصب شده اما سیستم هنوز با آن بوت نشده است. در این حالت باید Reboot انجام دهید.

نسخه‌های امن Kernel در AlmaLinux

طبق اطلاعیه AlmaLinux، نسخه‌های امن Kernel به این شکل هستند: (AlmaLinux OS)

این نسخه‌ها باید با خروجی uname -r و rpm -q kernel مقایسه شوند. اگر Kernel فعال پایین‌تر از نسخه امن باشد، سرور همچنان نیاز به Patch یا Reboot دارد.

رفع Copy-Fail در AlmaLinux با آپدیت Kernel

برای به‌روزرسانی Kernel در AlmaLinux، ابتدا Metadata را پاک‌سازی کنید:

sudo dnf clean metadata

سپس Kernel را آپدیت کنید:

sudo dnf update kernel

در بسیاری از سرورها بهتر است کل سیستم را نیز به‌روزرسانی کنید:

sudo dnf update

بعد از نصب Kernel جدید، Reboot ضروری است:

sudo reboot

پس از بالا آمدن سرور:

uname -r

اگر نسخه Kernel برابر یا بالاتر از نسخه امن مربوط به Release شما باشد، Patch اصلی اعمال شده است. cPanel نیز برای سیستم‌های AlmaLinux مسیر dnf clean metadata و dnf update kernel را به‌عنوان روش رفع معرفی کرده است.

رفع Copy-Fail در AlmaLinux 8

اگر سرور شما AlmaLinux 8 است، باید Kernel شما برابر یا بالاتر از نسخه زیر باشد:

kernel-4.18.0-553.121.1.el8_10

برای آپدیت:

sudo dnf clean metadata
sudo dnf update kernel
sudo reboot

بعد از Reboot:

uname -r

اگر خروجی نسخه ۴.۱۸.۰-۵۵۳.۱۲۱.۱.el8_10 یا بالاتر را نشان دهد، سیستم از نظر Kernel اصلی Patch شده است.

رفع Copy-Fail در AlmaLinux 9

اگر سرور شما AlmaLinux 9 است، نسخه امن Kernel برابر یا بالاتر از این نسخه است:

kernel-5.14.0-611.49.2.el9_7

برای آپدیت:

sudo dnf clean metadata
sudo dnf update kernel
sudo reboot

بعد از Reboot:

uname -r

اگر خروجی نسخه ۵.۱۴.۰-۶۱۱.۴۹.۲.el9_7 یا بالاتر را نشان دهد، سیستم Patch شده است.

رفع Copy-Fail در AlmaLinux 10

اگر سرور شما AlmaLinux 10 است، نسخه امن Kernel برابر یا بالاتر از این نسخه است:

kernel-6.12.0-124.52.2.el10_1

برای آپدیت:

sudo dnf clean metadata
sudo dnf update kernel
sudo reboot

بعد از Reboot:

uname -r

اگر خروجی نسخه ۶.۱۲.۰-۱۲۴.۵۲.۲.el10_1 یا بالاتر را نشان دهد، Patch اصلی فعال شده است.

Mitigation موقت در AlmaLinux اگر آپدیت Kernel ممکن نیست

اگر امکان آپدیت فوری Kernel ندارید، می‌توانید از Mitigation موقت استفاده کنید. در خانواده RHEL و AlmaLinux، گاهی غیرفعال‌سازی ساده ماژول از طریق modprobe.d کافی نیست، چون در برخی Kernelها بخش مربوطه ممکن است به شکل Built-in یا متفاوتی فعال شده باشد. cPanel برای این شرایط استفاده از grubby و پارامتر initcall_blacklist را پیشنهاد کرده است.

برای اعمال Mitigation موقت:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

سپس Reboot کنید:

sudo reboot

این دستور باعث می‌شود Init Function مربوط به algif_aead هنگام Boot غیرفعال شود. این روش جایگزین دائمی Patch نیست و فقط باید تا زمان نصب Kernel امن استفاده شود.

حذف Mitigation موقت در AlmaLinux بعد از نصب Kernel امن

اگر Kernel امن را نصب کردید و خواستید پارامتر موقت را حذف کنید:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"

سپس Reboot کنید:

sudo reboot

بعد از Reboot، نسخه Kernel را بررسی کنید:

uname -r

اگر Kernel فعال برابر یا بالاتر از نسخه امن باشد، سیستم از نظر Patch اصلی در وضعیت مناسب قرار دارد.

Mitigation عمومی با Block کردن algif_aead

CERT-EU نیز غیرفعال‌سازی algif_aead را به‌عنوان Mitigation موقت برای کاهش ریسک معرفی کرده است. (CERT-EU)

Block کردن ماژول:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf

Unload کردن  اگر در حال اجراست:

sudo rmmod algif_aead 2>/dev/null

برای بررسی وضعیت:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

در AlmaLinux، اگر این روش کافی نبود یا مطمئن نبودید، از روش grubby استفاده کنید و در اولین فرصت Kernel امن را نصب کنید.

سخت‌سازی محیط‌های Container

در محیط‌های Container، فقط Patch کردن سیستم‌عامل کافی نیست. چون Containerها از Kernel میزبان استفاده می‌کنند، باید Host را Patch کنید. اگر Node میزبان آسیب‌پذیر باشد، حتی Containerهایی که ظاهر محدود دارند می‌توانند خطرساز شوند.

CERT-EU توصیه کرده در محیط‌های Container، علاوه بر Patch، ایجاد AF_ALG Socket از طریق Seccomp Policy محدود شود، چون مسیر سوءاستفاده به AF_ALG وابسته است. (CERT-EU)

برای مدیران Kubernetes، Docker و Podman، این سه اقدام اهمیت دارد:

Patch کردن Kernel میزبان
محدود کردن AF_ALG با Seccomp یا Policyهای امنیتی
بررسی اجرای Workloadهای غیرقابل اعتماد

در سرورهای هاستینگ و CI/CD Runnerها، بهتر است Runnerهای عمومی یا کاربران غیرقابل اعتماد را تا زمان Patch کامل محدود کنید.

چک‌لیست نهایی برای Ubuntu

برای Ubuntu این چک‌لیست را اجرا کنید:

uname -r
dpkg -l kmod
dpkg -l 'linux-image*' | grep ^ii

سپس Update را نصب کنید:

sudo apt update && sudo apt upgrade

یا فقط kmod را هدفمند ارتقا دهید:

sudo apt update && sudo apt install --only-upgrade kmod

وضعیت ماژول را بررسی کنید:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

اگر لازم بود:

sudo rmmod algif_aead 2>/dev/null

اگر Kernel جدید نصب شد یا ماژول همچنان Load بود:

sudo reboot

بعد از Reboot:

uname -r

چک‌لیست نهایی برای AlmaLinux

برای AlmaLinux این چک‌لیست را اجرا کنید:

uname -r
rpm -q kernel

Kernel را به‌روزرسانی کنید:

sudo dnf clean metadata
sudo dnf update kernel

یا کل سیستم را آپدیت کنید:

sudo dnf update

سپس Reboot کنید:

sudo reboot

بعد از Reboot:

uname -r

اگر امکان آپدیت فوری ندارید، Mitigation موقت با grubby را اعمال کنید:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

بعد از نصب Kernel امن، در صورت نیاز Mitigation موقت را حذف کنید:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

تفاوت مسیر رفع در Ubuntu و AlmaLinux

در Ubuntu، Canonical ابتدا Mitigation را از طریق kmod منتشر کرد تا بارگذاری algif_aead غیرفعال شود. بنابراین مدیر سرور باید هم نسخه kmod را بررسی کند، هم وضعیت Load بودن ماژول را ببیند و هم در صورت نصب Kernel جدید، Reboot انجام دهد.

در AlmaLinux، تمرکز اصلی روی نصب Kernel Patch شده است. نسخه‌های امن Kernel برای AlmaLinux 8، ۹، ۱۰ و Kitten 10 معرفی شده‌اند و مسیر اصلی رفع، اجرای dnf update kernel و Reboot است. اگر امکان Update فوری وجود نداشته باشد، می‌توان از Mitigation موقت با grubby یا Block کردن algif_aead استفاده کرد.

اشتباهات رایج هنگام رفع Copy-Fail

یکی از اشتباهات رایج این است که مدیر سرور فقط Update را نصب می‌کند اما Reboot انجام نمی‌دهد. در آسیب‌پذیری‌های Kernel، نصب پکیج کافی نیست و سیستم باید با Kernel جدید بوت شود.

اشتباه دیگر این است که مدیر سیستم فقط خروجی Package Manager را بررسی می‌کند اما uname -r را نمی‌بیند. معیار Kernel فعال همیشه خروجی uname -r است.

برخی مدیران نیز فقط روی Ubuntu یا فقط روی AlmaLinux تمرکز می‌کنند، در حالی که زیرساخت واقعی ممکن است ترکیبی باشد. ممکن است سرور اصلی Ubuntu باشد، اما Nodeهای cPanel روی AlmaLinux یا CloudLinux اجرا شوند. همه این سیستم‌ها باید جداگانه بررسی شوند.

اشتباه مهم دیگر اعتماد بیش از حد به Container Isolation است. Containerها Kernel جداگانه ندارند و اگر Host آسیب‌پذیر باشد، همه Workloadهای روی آن در معرض ریسک قرار می‌گیرند.

پیشنهاد عملی برای سرورهای Production

در سرورهای Production بهتر است Patch را با برنامه اجرا کنید اما آن را به تعویق نیندازید. این آسیب‌پذیری High Severity است و برای محیط‌های چندکاربره ریسک جدی دارد.

اگر چند Node پشت Load Balancer دارید، یک Node را از چرخه خارج کنید، Update را نصب کنید، Reboot انجام دهید، سلامت سرویس را بررسی کنید و سپس آن را به چرخه بازگردانید. بعد همین فرآیند را برای Nodeهای بعدی تکرار کنید.

اگر سرور Single Node دارید، یک Maintenance Window کوتاه تعریف کنید. قبل از Update، Snapshot یا Backup معتبر بگیرید. سپس Patch را نصب کنید و Reboot را در زمان کم‌ترافیک انجام دهید.

اگر سرور میزبان cPanel، DirectAdmin، Docker یا Kubernetes است، بعد از Reboot حتماً وضعیت سرویس‌ها، Containerها، وب‌سرورها، دیتابیس و سرویس‌های امنیتی را بررسی کنید.

چرا این آسیب‌پذیری برای هاستینگ مهم است

در هاستینگ، Local Privilege Escalation بسیار جدی است. چون کاربران مختلف، وب‌سایت‌های مختلف و سرویس‌های متعدد روی یک زیرساخت اجرا می‌شوند. حتی اگر یک حساب کاربری محدود شود، آسیب‌پذیری Kernel می‌تواند همان حساب محدود را به نقطه شروع حمله تبدیل کند.

در VPS نیز اهمیت موضوع کمتر نیست. بسیاری از کاربران تصور می‌کنند چون سرور اختصاصی مجازی دارند، فقط اپلیکیشن خودشان مهم است. اما اگر Kernel سیستم‌عامل داخل VPS آسیب‌پذیر باشد، یک سرویس آسیب‌دیده داخل همان VPS می‌تواند مسیر افزایش دسترسی را باز کند.

در محیط‌های Managed Hosting، ارائه‌دهنده زیرساخت باید این موضوع را فعالانه بررسی کند. Patch کردن Kernel، بررسی ماژول‌ها، برنامه‌ریزی Reboot و هماهنگی با مشتریان بخشی از مسئولیت عملیاتی زیرساخت حرفه‌ای است.

جمع‌بندی نهایی

Copy-Fail یا CVE-2026-31431 یک آسیب‌پذیری مهم در Linux Kernel است که با زیرسیستم رمزنگاری، ماژول algif_aead، رابط AF_ALG و سیستم‌کال splice() ارتباط دارد. این ضعف می‌تواند به Local Privilege Escalation منجر شود و به کاربر محلی امکان افزایش سطح دسترسی تا Root بدهد. ریسک این آسیب‌پذیری در سرورهای چندکاربره، هاستینگ اشتراکی، VPS، CI/CD Runnerها و محیط‌های Container بسیار بالاتر است.

در Ubuntu، مسیر اصلی کنترل ریسک شامل به‌روزرسانی سیستم، ارتقای kmod، غیرفعال‌سازی algif_aead و در صورت نیاز Reboot است. در AlmaLinux، مسیر اصلی رفع مشکل نصب Kernel Patch شده با dnf update kernel و Reboot است. اگر امکان Patch فوری وجود ندارد، Mitigation موقت با grubby یا Block کردن algif_aead می‌تواند ریسک را تا زمان نصب Kernel امن کاهش دهد.

امنیت سرور یک کار یک‌باره نیست. مدیران سیستم باید CVEها را دنبال کنند، Patchهای امنیتی را سریع اعمال کنند، Kernel فعال را بررسی کنند و در محیط‌های حساس، فرآیند Reboot و Failover کنترل‌شده داشته باشند.

نوین هاست یار نوین شماست

نوین هاست این آسیب‌پذیری را برای سرورهای Ubuntu، AlmaLinux، CloudLinux و سایر توزیع‌های لینوکسی بررسی می‌کند و در صورت نیاز، اقدامات لازم برای رفع آن را انجام می‌دهد. این اقدامات می‌تواند شامل بررسی نسخه Kernel، بررسی وضعیت kmod، بررسی Load بودن algif_aead، نصب Patch، اعمال Mitigation موقت، برنامه‌ریزی Reboot کنترل‌شده و بررسی سلامت سرویس‌ها پس از راه‌اندازی مجدد باشد.

اگر سرور شما روی نوین هاست میزبانی می‌شود یا مدیریت آن را به نوین هاست سپرده‌اید و می‌خواهید مطمئن شوید آسیب‌پذیری Copy-Fail روی آن رفع شده است، از پنل کاربری تیکت ثبت کنید. تیم فنی نوین هاست وضعیت سرور شما را بررسی می‌کند و راهکار مناسب را برای رفع کامل مشکل اجرا می‌کند. نوین هاست یار نوین شماست.