بازیابی checkpoint در CRI-O security context پاد مقصد را دور می‌زند

ایدهٔ checkpoint/restore ساده به‌نظر می‌رسد: وضعیت کانتینر را ذخیره کن، جای دیگر بالا بیاور. در CRI-O این مسیر یک سوراخ اعتماد ساخته است. طبق CVE Red Hat و رکورد CVE.org، شناسه CVE-2026-92574 با CVSS ۸٫۸ می‌گوید وقتی یک checkpoint مخرب restore می‌شود، تنظیمات حساس امنیتی می‌توانند از خود checkpoint بیایند، نه از security context پاد مقصد.

آن «تنظیمات حساس» فهرست کوتاهی نیست: credentials، capabilities، no_new_privs، و seccomp. یعنی سیاستی که روی PodSpec نوشته‌اید ممکن است موقع restore نادیده گرفته شود و کانتینر با امتیاز یا پروفایل قدیمی/جعلی زنده شود. محدودهٔ اثر اعلام‌شده: CRI-O 1.34 به بعد و OpenShift از OCP 4.17 به بعد.

هدف فیکس‌ها در advisory: 1.36.6 / 1.35.9 / 1.34.14 — با این قید که ممکن است در لحظهٔ انتشار advisory هنوز همه‌جا general availability نشده باشند. تا آن بسته‌ها برسند، مسیر عملیاتی روشن است:

1. قابلیت checkpoint restore را خاموش کنید: gate مربوط به ContainerCheckpoint / تنظیم enable_criu_support = false
2. RBAC ایجاد Pod را محدود کنید تا هر حساب نتواند restore دلخواه بزند
3. registryها را allowlist کنید تا image/checkpoint از منبع کنترل‌نشده نیاید

اگر کلاستر CRI-O یا OpenShift دارید و CRIU/checkpoint روشن است، این CVE را مثل یک باگ «اختیاری آزمایشگاهی» نبینید؛ مسیر restore همان جایی است که فرض security context می‌شکند. تا فیکس نسخه، خاموش کردن restore امن‌تر از «ما checkpoint نمی‌سازیم پس اوکی است» است — چون وجود قابلیت روی نود، سطح حمله را باز می‌گذارد.