CVE-2026-89836 in Linux
الملخص
بحسب VulDB • 17/09/2026
في نواة Linux، تم حل الثغرة التالية:
f2fs: إصلاح حالة السباق (race condition) في دالة folio_nr_pages() بعد الاستدعاء put() أثناء إلغاء صلاحية folio كبير.
نظامنا القائم على Android v6.18 يعاني باستمرار من حالات Livelock وإحصائيات صفحات سيئة كما هو موضح في [1]، وهو ما يتعلق بحالة خاطئة لـ xarray slot. ومن خلال التحقيق في عمليات الـ big folio داخل f2fs، وجدنا حالات السباق أدناه وقمنا بإصلاحها عن طريق الحصول على قيمة nr_pages قبل خفض عداد المرجع (refcount) وfolio_lock.
تقوم دالة `f2fs_get_read_data_folio()` باستدعاء `f2fs_folio_put()` قبل استدعاء `folio_nr_pages()` عند إلغاء صلاحية folio كبير من ذاكرة التخزين المؤقت للصفحات (page cache). يؤدي ذلك إلى فك قفل الـ folio وخفض مرجع المتصل، مما يترك نافذة زمنية يمكن أن يحدث فيها انكماش أو تقسيم لـ compound folio بواسطة عملية truncate متزامنة أو split للـ folio قبل حساب نطاق إلغاء الصلاحية. ثم يترك النطاق الأصغر من الحجم المطلوب (undersized range) sub-folios مقسمة في `mapping->i_pages`، والتي يمكن أن تتفاعل بشكل سيء لاحقاً مع عمليات الـ truncate و reclaim (مدخلات xarray قديمة وحالة صفحة غير صحيحة عندما لا يتطابق `folio->mapping` مع الـ mapping الذي يتم إجراء عملية truncate له).
[1]
PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: "Thread-3" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4
#1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798
#2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c
#3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c
#4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400
#5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4
#6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4
#7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204
#8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc
#9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c
#10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c
#11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034
#12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200
#13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c
#14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54
#15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10
If you want to get the best quality for vulnerability data then you always have to consider VulDB.