CVE-2022-48853

Orta

Açıklama

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: swiotlb: DMA_FROM_DEVICE ile bilgi sızıntısı düzeltildi Ele aldığım sorun, cve-2018-1000204 kapsamındaki LTP testi tarafından keşfedilmiştir. Gerçekleşenlerin kısa bir açıklaması şöyledir: 1) Test durumu, SG_IO arayüzü üzerinden şu parametrelerle 00 komut kodunu (TEST UNIT READY) gönderir: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV ve ilgili bir dxferp. Buradaki tuhaflık, TUR'un cihazdan okuma yapmamasıdır. 2) sg_start_req() fonksiyonunda blk_rq_map_user() çağrısı, kullanıcı alanı tamponunu etkili bir şekilde sektirir (bounce). Sanki cihaz buraya veri aktaracakmış gibi işlem yapılır. a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_invite()") commit'inden beri bu ilk sektirme tamponunun GFP_ZERO ile tahsis edildiğinden emin oluyoruz. 3) Hikayenin geri kalanında bunun bir TUR olduğunu görmezden gelmeye devam ediyoruz, dolayısıyla cihaz, sanki bir DMA_FROM_DEVICE durumu varmış gibi hazırladığımız tampona dokunmayacaktır. Kurulumum bir virtio-scsi cihazı kullanır ve SG tarafından tahsis edilen tampon, "in" sg'ler (burada scsi generics değil, scatter-gather) için DMA_FROM_DEVICE kullanan virtqueue_add_split() fonksiyonu tarafından eşlenir. Bu eşleme, swiotlb aracılığıyla sektirmeyi içerir (s390 Secure Execution veya AMD SEV gibi korumalı konuklarda virtio gerçekleştirmek için swiotlb'ye ihtiyaç duyarız). 4) SCSI TUR tamamlandığında, önce ikinci (yani swiotlb) sektirme tamponunun içeriğini (ki bu büyük olasılıkla önceki bazı IO verilerini içerir), tamamı sıfırlardan oluşan birinci sektirme tamponuna geri kopyalarız. Ardından birinci sektirme tamponunun içeriğini kullanıcı alanı tamponuna geri kopyalarız. 5) Test durumu, sıfırla başlattığı tamponun tamamen sıfırlardan oluşmadığını tespit eder ve başarısız olur. Bunun bir swiotlb sorunu olduğu savunulabilir; çünkü swiotlb olmadan tüm değerler sıfır olarak sızmaktadır ve swiotlb, sonucu etkilememesi anlamında şeffaf olmalıdır (diğer tüm katılımcılar düzgün davrandığı sürece). Orijinal tamponun içeriğinin swiotlb tamponuna kopyalanması, bu tür senaryolarda swiotlb'yi şeffaf hale getirmek için düşünebildiğim tek yoldur. Bu nedenle, şüphe durumunda bunu yapalım ancak sürücünün bize eşlenen tüm tamponun üzerine yazılacağını bildirmesine izin verelim; bu durumda eski davranışı koruyabilir ve ekstra sektirme işleminin performans etkisinden kaçınabiliriz.

ÖnemOrta
CVSS5.5
İstismar olasılığı—
ÜrünLinux Kernel
Yayın16 Tem 2024
İlk görülme16 Tem 2024

Nasıl düzeltilir

Güncelleyin
  • linux linux_kernel4.9.320, 4.14.281, 4.19.245, 5.4.189, 5.10.110, 5.15.29, 5.16.15 ya da sonraki bir sürüm

Etkilenen ürünler

ÜrünEtkilenen sürümlerDüzeltildiği sürüm
linux linux_kernelv < 4.9.320, 4.10 ≤ v < 4.14.281, 4.15 ≤ v < 4.19.245, 4.20 ≤ v < 5.4.189, 5.5 ≤ v < 5.10.110, 5.11 ≤ v < 5.15.29, 5.16 ≤ v < 5.16.154.9.320, 4.14.281, 4.19.245, 5.4.189, 5.10.110, 5.15.29, 5.16.15

Sürümünüzü kontrol edin

Ürünü seçin ve kullandığınız sürümü yazın; sürümün etkilenen aralıkta olup olmadığını görün.

Intelligence 360 paketinde

Attack Surface Management

Alan adlarınıza bağlı varlıkları, bu varlıklarda çalışan teknolojileri ve bilinen zafiyetleri tek listede görün.