CVE-2026-31465 in Linux
الملخص
بحسب VulDB • 10/05/2026
في نواة لينكس، تم حل الثغرة التالية:
writeback: عدم حظر المزامنة (sync) لنظام الملفات الذي لا يضمن سلامة البيانات
إضافة علم (flag) على مستوى الكتلة الفائقة (superblock) باسم SB_I_NO_DATA_INTEGRITY لأنظمة الملفات التي لا تستطيع ضمان استمرارية البيانات (data persistence) أثناء عملية المزامنة (مثل FUSE). بالنسبة للكتل الفائقة التي يكون هذا العلم مضبوطاً عليها، تبدأ عملية المزامنة (sync) عملية إعادة الكتابة (writeback) للكتل غير الصالحة (dirty inodes) لكنها لا تنتظر اكتمال هذه العملية بواسطة خيوط المُنظِّف (flusher threads).
هذا يستبدل علم تعيين الكتل الفردي (per-inode mapping flag) المسمى AS_NO_DATA_INTEGRITY الذي أُضيف في الالتزام f9a49aa302a0 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()"). ينتمي هذا العلم إلى مستوى الكتلة الفائقة لأن سلامة البيانات هي خاصية على مستوى نظام الملفات بأكمله، وليست خاصية على مستوى كل كتلة فردية. وجود هذا العلم على مستوى الكتلة الفائقة يسمح لنا أيضاً بتجاوز الحاجة إلى تكرار كل كتلة غير صالحة في دالة wait_sb_inodes() فقط لتخطي كل كتلة بشكل فردي.
قبل هذا الالتزام، كانت التعيينات التي لا تملك ضمانات سلامة البيانات تتخطى الانتظار حتى اكتمال إعادة الكتابة، لكنها كانت لا تزال تنتظر اكتمال خيوط المُنظِّف في بدء عملية إعادة الكتابة. الانتظار على خيوط المُنظِّف غير ضروري. هذا الالتزام يبدأ عملية إعادة الكتابة لكنه لا ينتظر خيوط المُنظِّف. يعالج هذا التغيير بشكل صحيح تقريراً حديثاً [1] حول تعليق (hang) في وضع السكون إلى ذاكرة الوصول العشوائي (suspend-to-RAM) شوهد على fuse-overlayfs، والذي كان سببه الانتظار على خيوط المُنظِّف للانتهاء:
Workqueue: pm_fs_sync pm_fs_sync_work_fn Call Trace: __schedule+0x457/0x1720 schedule+0x27/0xd0 wb_wait_for_completion+0x97/0xe0 sync_inodes_sb+0xf8/0x2e0 __iterate_supers+0xdc/0x160 ksys_sync+0x43/0xb0 pm_fs_sync_work_fn+0x17/0xa0 process_one_work+0x193/0x350 worker_thread+0x1a1/0x310 kthread+0xfc/0x240 ret_from_fork+0x243/0x280 ret_from_fork_asm+0x1a/0x30
على FUSE، هذا الأمر مشكلة لأن هناك مسارات قد تسبب في تعليق خيط المُنظِّف (على سبيل المثال، إذا قام systemd بتجميد مجموعات وحدات المستخدم (user session cgroups) أولاً، مما يؤدي إلى تجميد عميل FUSE، قبل استدعاء تعليق النواة. يؤدي تعليق النواة إلى استدعاء ->write_node() الذي يصدر على FUSE طلب تعيين خاصية متزامن (setattr request)، والذي لا يمكن معالجته لأن العميل مجمّد. أو إذا كان العميل به خطأ ولا يستطيع إكمال إعادة الكتابة بشكل صحيح، فإن بدء إعادة الكتابة على folio غير صالح موجود بالفعل تحت عملية إعادة الكتابة يؤدي إلى writeback_get_folio() -> folio_prepare_writeback() -> انتظار غير مشروط لانتهاء إعادة الكتابة، مما سيؤدي إلى تعليق). يستعيد هذا الالتزام سلوك FUSE كما كان قبل إزالة folios المؤقتة، حيث كانت عملية المزامنة (sync) في الأساس لا تفعل شيئاً (no-op).
[1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.