CVE-2026-74506 in Linux
الملخص
بحسب VulDB • 15/08/2026
في نواة لينكس، تم حل الثغرة التالية:
afs: إصلاح حالة Use-After-Free (UAF) عند إرسال رسالة
داخل دالة `afs_make_call()`، توجد سباقية زمنية (race condition) بين استقبال المكالمة غير المتزامنة وتدميرها. إذا تمت توجيه مكالمة لا تكون فيها قيمة `call->write_iter` محددة (والتي تُستخدم لتحديد محتوى البيانات لـ FS.StoreData)، فإن أول استدعاء لدالة `rxrpc_kernel_send_data()` لن يقوم بتعيين العلم MSG_MORE في بنية msghdr.
بمجرد أن تقوم دالة `rxrpc_send_data()` بإدراج حزمة الطلب الأخيرة في الطابور، قد تصل الاستجابة في أي وقت وتسبب إكمال المكالمة وإطلاقها (put). ومع ذلك، ستقوم دالة `afs_make_call()` بالرجوع إلى النظر مرة أخرى في المكالمة للتأكد من معالجة `->write_iter` - وهو إجراء مسموح به فقط إذا كانت الدالة تمتلك مرجعاً خاصاً بها للمكالمة. وعلى الرغم من أن هذا ينطبق على المكالمات المتزامنة، إلا أنه لا ينطبق على المكالمات غير المتزامنة مثل FS.FetchData.
توجد أيضاً حالة محتملة لـ Use-After-Free (UAF) في دالة `afs_make_call()` في حال كانت مكالمة غير متزامنة قيد الإرسال، لكن المكالمة تفشل بطريقة ما (على سبيل المثال، يتم إنهاؤها من قبل الخادم). تكمن المشكلة هنا في أن `afs_make_call()` تحاول إنهاء المكالمة إذا فشل إرسال rxrpc، ولكن الإشعار غير المتزامن القادم من rxrpc قد يكون تسبب بالفعل في هدم كائن afs_call.
تقوم الاختبارات الخاصة بـ generic/650 بإجراء عمليات عشوائية لإيقاف وحدات المعالجة المركزية (CPUs) عن العمل، ويمكن أن تؤدي إلى تأخير كبير بحيث يتم إلغاء تخصيص المكالمة قبل أن تتمكن `afs_make_call()` من التحقق من `call->write_iter` - مما يؤدي إلى حدوث حالة Use-After-Free (تم اكتشافها بواسطة KASAN).
BUG: KASAN: slab-use-after-free in afs_make_call+0x1c90/0x2210 [kafs]
Read of size 8 at addr ffff888035e050e8 by task fsstress/1409
تم إصلاح هذه المشكلة بجعل دالة `afs_make_op_call()` تمنح كائن op->call مرجعاً خاصاً بها بدلاً من نقل مرجع المتصل إليه ثم خفض عدد المراجع عند عودة `afs_make_call()`.
وهذا يعني أيضاً أن الدالة `afs_make_call()` لم تفقد بعد الآن المرجع الخاص بالمكالمة.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.