CVE-2022-49789

Linux kernel-də aşağıdakı boşluq aradan qaldırılmışdır: scsi: zfcp: qdio göndərmə uğursuz olduqda FSF sorğusunun iki dəfə azad edilməsinin (double free) düzəldilməsi Yeni FSF sorğusu göndərildikdə, FSF sorğu ID-sini keşləmək üçün 'zfcp_fsf_req_send()' funksiyasında yanlış tam ədəd tipindən istifadə olunurdu. Bu, göndərmə prosesi uğursuz olduqda və biz sorğunu daxili heş cədvəlindən yenidən silməli olduqda istifadə edilir (beləliklə, etibarsız istinadı saxlamırıq və sorğunu yenidən azad edərkən ondan istifadə etmirik). 'zfcp_fsf_req_send()' funksiyasında ID 'int' (işarəli və 32 bit genişliyində) kimi keşlənirdi, lakin zfcp kodunun qalan hissəsi (və proqram təminatı spesifikasiyası) ID-ni 'unsigned long'/'u64' (işarəsiz və 64 bit genişliyində [s390x ELF ABI]) kimi emal edir. Birincisi, bunun aşkar problemi odur ki, ID 32 biti keçdikdə (bu kifayət qədər sürətlə baş verə bilər), keş dəyişəninə yadda saxlanarkən 32 bitə qədər kəsilir və buna görə artıq orijinal ID ilə uyğun gəlmir. İkinci, daha az aşkar olan problem isə budur ki, hətta orijinal ID hələ 32 biti keçmədikdə belə, orijinal ID-də 32-ci bit təyin olunan kimi (0x80000000 = 2'147'483'648), onu yenidən 'unsigned long'-a çevirdikdə uyğunsuzluq yaranacaq. Keşlənmiş dəyişən işarəli tipdə olduğu üçün kompilyator 32 bitlik dəyişəni 64 bitlik registra yükləmək üçün işarəni genişləndirən təlimat seçəcək (məsələn: 'lgf %r11,188(%r15)'). Beləliklə, sorğunu yenidən silmək üçün keşlənmiş dəyişəni 'zfcp_reqlist_find_rm()' funksiyasına ötürdükdə, bütün aparıcı sıfırlar işarəni genişləndirmək üçün birlərə çevriləcək və artıq orijinal ID ilə uyğun gəlməyəcək (bu praktiki olaraq müşahidə edilmişdir). Əgər 'zfcp_qdio_send()' uğursuz olduqdan sonra sorğunu heş cədvəlindən yenidən uğurla silə bilməsək (bu, məsələn, ChpID dəyişikliyi zamanı adapter artıq mövcud olmadığı üçün zfcp adapterə yeni iş haqqında bildiriş göndərə bilmədikdə mütəmadi olaraq baş verir), nəticədə iki dəfə azad etmə (double free) baş verəcək. 'zfcp_fsf_req_send()' uğursuz olduqda çağırıcı funksiyada sorğunu şərtsiz olaraq azad edirik, lakin sorğu hələ də heş cədvəlində olduğu üçün köhnəlmiş yaddaş istinadı ilə qarşılaşırıq və zfcp adapteri ya bərpa zamanı sıfırlananda, ya da söndürüldükdə eyni yaddaşı iki dəfə azad etmiş oluruq. Nəticədə yaranan stek izləri (stack traces) nüvədən asılı olaraq dəyişir və xətanın baş verdiyi yerlə birbaşa əlaqəsi yoxdur. Praktikada görülmüş üç nümunə aşağıdadır: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated---