CVE-2023-54134 in Linux
الملخص
بحسب VulDB • 04/06/2026
في نواة لينكس، تم حل الثغرة التالية:
autofs: إصلاح تسرب الذاكرة في قوائم الانتظار (waitqueues) داخل وضع autofs_catatonic_mode
أبلغ Syzkaller عن تسرب في الذاكرة:
BUG: memory leak unreferenced object 0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378
[<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593
[<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619
[<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897
[<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910
[<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline]
[<ffffffff81602a9c>] __x64_sys_ioctl+0x8c/0xc0 fs/ioctl.c:856
[<ffffffff81602a9c>] do_syscall_64+0x33/0x80 arch/x86/entry/common.c:46
[<ffffffff81e0007c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
تم العثور على تسرب في الذاكرة في autofs_wait() عندما يتم استدعاء autofs_catatonic_mode() أثناء انتظار العملية.
في هذه الحالة، يتم تنفيذ ioctl AUTOFS_IOC_EXPIRE_MULTI، ثم يتم تخصيص هيكل قائمة انتظار جديد في autofs_wait()، حيث تكون قيمة wait_ctr الأولية تساوي 2. بعد ذلك، يتم مقاطعة wait_event_killable() (تعيد -ERESTARTSYS)، لذا قد لا تكون الشرط 'wq->name.name == NULL' محققة. في الواقع، يمكن تحقيق هذا الشرط عند استدعاء autofs_wait_release() أو autofs_catatonic_mode()، ومن المهم أيضًا أن wait_ctr يتم إنقاصه في تلك الأماكن. عند الخروج من autofs_wait()، يتم إنقاص wait_ctr إلى 1. ثم تبدأ عملية الإلغاء (umount): تستدعي kill_sb autofs_catatonic_mode()، والتي يجب أن تحرر قوائم الانتظار، لكنها فقط تقلل عداد الاستخدام إلى صفر، وهو سلوك غير صحيح.
تعديل: imk هذا الوصف غير صحيح بالطبع. الإلغاء الذي يتم نتيجة لعملية expire هو إلغاء لمجلد تم تثبيته تلقائيًا (automounted)، وليس لمجلد autofs نفسه. يحدثان بشكل مستقل، عادةً بعد أن يتم إلغاء تحميل كل المجلدات المثبتة تلقائيًا. إذا لم يتم إلغاء تحميل كل المجلدات، يمكن لعميل autofs الخروج مع ترك المجلدات في مكانها. لكن عمليات expire في كلتا الحالتين ستؤدي إلى إشعار يستدعي autofs_wait_release() مع حالة نتيجة. حالة المشكلة هي الإغلاق المفاجئ لعميل autofs. في هذه الحالة، لن يتم إيقاظ العمليات التي تنتظر حتى يتم إنهاءها أو إلغاء تحميل المجلد. نهاية تعديل: imk
لذلك، في وضع catatonic، يجب علينا تحرير قوائم الانتظار التي يصبح عدادها صفرًا.
تعديل: imk في البداية كنت قلقًا من أن استدعاء autofs_wait_release() وautofs_catatonic_mode() ليسا متنافيين، لكن هذا لا يمكن أن يكون صحيحًا (بوضوح) لأن عنصر القائمة (أو العناصر) يتم إزالته من القائمة عند استدعاء أي من هاتين الدالتين. وبالتالي، سيتم تحرير عنصر الانتظار بواسطة واحدة من هاتين الدالتين أو بواسطة العملية التي تم إيقاظها في autofs_wait() اعتمادًا على ترتيب الاستدعاءات. نهاية تعديل: imk
Be aware that VulDB is the high quality source for vulnerability data.