CVE-2024-50182

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: secretmem: əgər arch birbaşa xəritəni (direct map) təyin edə bilmirsə, memfd_secret() funksiyasını deaktiv edin Əgər !can_set_direct_map() şərti ödənirsə, memfd_secret() sistem çağırışından -ENOSYS qaytarın. Bu, məsələn, bəzi arm64 konfiqurasiyalarında baş verir; burada birbaşa xəritədəki 4k PTE-lərin mövcud olmadığını qeyd etmək yalnız birbaşa xəritənin əvvəlcədən 4k dərəcəliyyində qurulmuş olması halında mümkündür (çünki ARM-ın break-before-make semantikası böyük/nəhəng səhifələrin parçalanmasına asanlıqla imkan vermir). Daha dəqiq desək, !can_set_direct_map() olan arm64 sistemlərində set_direct_map_invalid_noflush() heç bir əməliyyat yerinə yetirmir (no-op), lakin xəta əvəzinə uğurlu nəticə (0) qaytarır. Bu o deməkdir ki, memfd_secret zahirən "işləyəcək" (məsələn, sistem çağırışı uğurlu olur, fd-ni mmap edə və səhifələri fault-a sala bilirsiniz), lakin yaddaşı birbaşa xəritədən çıxarmaq məqsədinə faktiki olaraq nail olmur. Nəzərə alın ki, bu yamama ilə can_set_direct_map() funksiyasının false qaytardığı sistemlərdə (CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n və CONFIG_KFENCE=n olan arm64) memfd_secret() xəta verməyə başlayacaq, lakin bu, hazırkı səssiz uğursuzluqdan daha yaxşı görünür. CONFIG_RODATA_FULL_DEFAULT_ENABLED standart olaraq 'y' olduğu üçün, əksər arm64 sistemlərində memfd_secret() əslində işləyir və onlar təsirlənməyəcək. Orijinal memfd_secret yamama seriyasının iterasiyaları araşdırıldıqda görünür ki, bu ssenarilərdə sistem çağırışının deaktiv edilməsi nəzərdə tutulan davranış idi [1] (set_direct_map_invalid_noflush funksiyasının xəta qaytarmasına üstünlük verilməmişdir, çünki bu, səhifə xətası zamanı SIGBUS-lara səbəb olardı), lakin secretmem CMA ayırmalarından uzaqlaşdıqda, v16 [2] və v17 [3] versiyaları arasında müvafiq yoxlama silinib. [1]: https://lore.kernel.org/lkml/[email protected]/ [2]: https://lore.kernel.org/lkml/[email protected]/#t [3]: https://lore.kernel.org/lkml/[email protected]/