CVE-2025-40007
Açıklama
Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: netfs: başvuru sızıntısı düzeltildi 20d72b00ca81 ("netfs: Fix the request's work item to not require a ref") commit'i, netfs_alloc_request() fonksiyonunu başvuru sayacını 1 yerine 2 olarak başlatacak şekilde değiştirmişti. Gerekçe, isteğin "work" öğesinin tamamlanmanın ardından ikinci başvuruyu serbest bırakacağıydı (netfs_{read,write}_collection_worker() aracılığıyla). Her şey yolunda giderse bu çoğu zaman çalışır. Ancak, istek G/Ç işlemi gönderilmeden önce serbest bırakılırsa bu ek başvuru sızar: hata kodu yolu başvuru sayacını yalnızca bir kez azaltır ve hiçbir zaman tamamlanma olmayacağı için work öğesi hiçbir zaman kuyruğa alınmaz. Bu durum bugün tüm sunucu kümemizde kesintilere yol açtı çünkü görevler netfs_wait_for_outstanding_io() içinde bloke oldu ve Ceph'te kilitlenmelere neden oldu (başka bir yamada yakında ele alacağım başka bir hata). Buna fscache_begin_write_operation() içinde başarısız olan bir netfs_pgpriv2_begin_copy_to_cache() çağrısı neden oldu. Sızan netfs_io_request hiçbir zaman tamamlanmadı ve `netfs_inode.io_count` değerini sonsuza kadar pozitif bir değerde bıraktı. Tüm bunlar son derece kırılgan bir koddur. Hangi kod yollarının nihai bir tamamlanmaya yol açacağını ve hangilerinin açmayacağını anlamak zordur: - netfs_create_write_req() gibi bazı fonksiyonlar bir istek ayırır ancak hiçbir zaman G/Ç göndermez. - netfs_unbuffered_read_iter_locked() fonksiyonu netfs_unbuffered_read() fonksiyonunu çağırır ve ardından netfs_put_request() çağrısını yapar; ancak netfs_unbuffered_read() G/Ç isteğini göndermeden önce de erken başarısız olabilir, bu nedenle oraya bir netfs_put_request() çağrısı daha eklenmelidir. Pratik bir kural olarak, `netfs_io_request` döndüren fonksiyonlar G/Ç göndermez ve tüm çağıranları kontrol edilmelidir. Bana kalırsa, tüm netfs kodunun başvuru sayımını anlamayı kolaylaştırmak ve daha az kırılgan ve belirsiz hale getirmek için elden geçirilmesi gerekiyor. Ancak bu hatayı şimdi ve burada düzeltmek ve kararlı bir geri aktarıma uygun bir yama üretmek için, erken başarısızlık durumunda istek nesnesini hızlıca serbest bırakan minimal bir yaklaşım denedim. Her seferinde ikinci bir netfs_put_request() eklememeye karar verdim çünkü bu, kodu daha da belirsizleştiren kod tekrarına yol açardı. Bunun yerine, başvuru sayısının tam olarak 2 olduğu (netfs_alloc_request() tarafından başlangıçta ayarlandığı ve hiç dokunulmadığı) varsayımıyla böyle başarısız bir isteği eşzamanlı olarak serbest bırakan ve bir WARN_ON_ONCE() ile doğrulanan netfs_put_failed_request() fonksiyonunu ekledim. Ardından istek nesnesini ("cleanup_work" dolaylılığından geçmeden) başlatılmamış duruma getirir ve ayırmayı serbest bırakır (netfs_requests_seq_start() tarafından eşzamanlı erişime karşı korunmak için RCU korumasıyla). Erken başarısız olan tüm kod yolları, netfs_put_request() yerine netfs_put_failed_request() çağıracak şekilde değiştirilmiştir. Ayrıca, yukarıda açıklandığı gibi netfs_unbuffered_read() fonksiyonuna bir netfs_put_request() çağrısı ekledim çünkü netfs_put_failed_request() yaklaşımı orada işe yaramıyor.
Nasıl düzeltilir
- Linux Linux8df142e93098b4531fadb5dfcf93087649f570b3, 4d428dca252c858bfac691c31fa95d26cd008706, 6.16 ya da sonraki bir sürüm
Etkilenen ürünler
| Ürün | Etkilenen sürümler | Düzeltildiği sürüm |
|---|---|---|
| Linux Linux | 20d72b00ca814d748f5663484e5c53bb2bf37a3a ≤ v < 8df142e93098b4531fadb5dfcf93087649f570b3, 20d72b00ca814d748f5663484e5c53bb2bf37a3a ≤ v < 4d428dca252c858bfac691c31fa95d26cd008706, 1a8360c2eed3b292ed654c2ac61b09de4a80e298, 6.15.3 ≤ v < 6.16, 6.16 | 8df142e93098b4531fadb5dfcf93087649f570b3, 4d428dca252c858bfac691c31fa95d26cd008706, 6.16 |
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.
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.