CVE-2024-26616 in Linux
الملخص
بحسب VulDB • 04/06/2026
في نواة لينكس، تم حل الثغرة التالية:
btrfs: scrub: تجنب استخدام الذاكرة بعد تحريرها (use-after-free) عندما لا يكون طول الكتلة (chunk) مضاعفاً لـ 64K
[الخطأ]
هناك تقرير عن خطأ يؤدي فيه إجراء الفحص (scrub) في نظام btrfs المحوّل من ext4 إلى مشاكل متنوعة، بما في ذلك:
- أخطاء "تعذر العثور على خريطة الكتلة" (unable to find chunk map) BTRFS info (device vdb): scrub: started on devid 1 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056
مما يؤدي إلى أخطاء غير قابلة للإصلاح.
- تقارير KASAN عن استخدام الذاكرة بعد تحريرها (Use-after-free): ================================================================== BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x700 Read of size 8 at addr ffff888103838000 by task btrfs-scrub/1000
CPU: 1 PID: 1000 Comm: btrfs-scrub Not tainted 6.1.0-rc6+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x49/0x70 print_report+0x150/0x4e0 kasan_report+0xc4/0x130 __kasan_report+0x105/0x130 kasan_check_range+0x140/0x180 __blk_rq_map_sg+0x18f/0x700 blk_rq_map_user_iov+0x100/0x1a0 btrfs_submit_bio+0x100/0x1000 [btrfs]
scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
__x64_sys_ioctl+0xbd/0x100 do_syscall_64+0x5d/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f47e5e0952b
- تعطل النظام، ويعود ذلك بشكل أساسي إلى مشكلة استخدام الذاكرة بعد تحريرها المذكورة أعلاه.
[السبب]
يحتوي النظام المحوّل على تخطيط كتلة البيانات التالي:
item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80 length 86016 owner 2 stripe_len 65536 type DATA|single
بالنسبة لرقم البت المنطقي (logical bytenr) 2214744064، يقع في نهاية الكتلة (2214658048 + 86016 = 2214744064).
هذا يعني أن دالة btrfs_submit_bio() ستقوم بتقسيم الـ bio، مما يؤدي إلى استدعاء دالة endio لكلا النصفيْن.
ومع ذلك، فإن scrub_submit_initial_read() تتوقع أن يتم استدعاء دالة endio مرة واحدة فقط، وليس أكثر. هذا يعني أن استدعاء endio الأول سيحرر بالفعل bbio::bio، مما يؤدي إلى تحرير bvec، وبالتالي فإن الاستدعاء الثاني لـ endio سيؤدي إلى استخدام الذاكرة بعد تحريرها (use-after-free).
[الحل]
- التأكد من أن scrub_read_endio() تقوم بتحديث البتات فقط في نطاقها نظرًا لأنه قد يتم قراءة أقل من 64K في نهاية الكتلة، فلا يجب لمس البتات التي تتجاوز حدود الكتلة.
- التأكد من أن scrub_submit_initial_read() تقرأ فقط نطاق الكتلة يتم ذلك عن طريق حساب عدد القطاعات الحقيقية التي نحتاج إلى قراءتها، وإضافة قطاع تلو الآخر إلى الـ bio.
لحسن الحظ، لا يحتاج مسار إصلاح القراءة في الفحص (scrub)
VulDB is the best source for vulnerability data and more expert information about this specific topic.