CVE-2024-26958

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: nfs: doğrudan yazmalarda UAF hatası düzeltildi Üretim ortamında sürekli olarak şu uyarı ile karşılaşılmaktadır: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 Bu durum, nfs_direct_request işleminin art arda iki kez tamamlanmasından kaynaklanmaktadır. Bunun kaynağı, gönderilecek commit isteklerimiz olduğunda bunları işleyip göndermemiz ve ardından commit isteklerinin tamamlama yolunda şunların yer almasıdır: if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); Ancak asenkron istekler gönderdiğimiz için bazen bir istek, bir sonrakini göndermeden önce tamamlanmakta ve sonuç olarak nfs_direct_request üzerinde complete fonksiyonunu iki kez çağırmaktayız. nfs_generic_commit_list() fonksiyonunu kullandığımız diğer tek yer olan __nfs_commit_inode, bu çağrıyı şu şekilde sarmalamaktadır: nfs_commit_begin(); nfs_commit_end(); Bu, bu tarz tamamlama yönetimi için yaygın bir kalıptır; aynı yöntem, olayları işlediğimiz yerlerde ve tamamlama yollarında get_dreq()/put_dreq() çağrılarıyla birlikte doğrudan kodlarda da tekrarlanmıştır. Commit istekleri için de aynı kalıp kullanılarak bu sorun giderilmiştir. Daha önce 200 düğümlü rocksdb stres testi çalıştırırken bu uyarı her 10 dakikada bir ortaya çıkıyordu. Yama sonrası stres testi birkaç saattir herhangi bir uyarı vermeden çalışmaktadır.