CVE-2026-89518

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: sched_ext: dispatch kfunc'larındaki this_rq() varsayımları düzeltildi Core scheduling altında, dispatch işlemi çekirdek genelindeki pick içerisinden çalışır ve kardeş bir rq'yu hedefleyebilir; bu nedenle ops.dispatch(), gönderilen rq'dan farklı bir CPU üzerinde yürütülebilir. Birkaç kfunc yolu, bu ikisinin her zaman örtüştüğünü varsaymaktaydı: - scx_dsq_move(), this_rq()'nun rq bayraklarını test ederek bir rq kilidinin tutulup tutulmadığına karar veriyor ve buna göre kilit yönetimi yapıyordu. Kardeş bir işlem için yapılan dispatch, kilitlenmemiş bağlam dalına giriyor ve halihazırda tutulan gönderilmiş rq kilidinin üzerine kaynak rq kilidini alıyordu, bu da ölü kilitlemeye (deadlock) yol açabiliyordu. - scx_bpf_sub_dispatch(), this_rq()'yu saklanmış sub_dispatch_prev ile gönderiyordu; ancak kardeş bir işlem için gönderim yapılırken bu değer NULL olur. - finish_dispatch(), scx_bpf_dsq_reenq() ve scx_bpf_dsq_nr_queued(), SCX_DSQ_LOCAL ifadesini gönderilen rq yerine mevcut CPU'nun yerel DSQ'su olarak çözümlüyordu. Son iki fonksiyon, SCX_DSQ_LOCAL'in artık işlemin rq'suna çözümlendiği diğer rq-kilitli işlemlerden de çağrılabilir durumdadır. Bu durum, core scheduling olmadan da davranışı değiştirir (örneğin, uyandıran CPU üzerinde uzak uyandırma çalıştıran ops.enqueue() için) ve bu amaçlıdır: bir işlemin hangi CPU tarafından yürütüldüğü tesadüfidir, işlemin rq'su üzerinde işlem yaptığı yapıdır ve çözümleme artık SCX_DSQ_LOCAL gönderimlerinin görevin rq'suna ulaştığı ekleme tarafıyla eşleşmektedir. ops çağırmaları sırasında gönderilen rq olarak ayarlanan ve kilitlenmemiş bağlamlarda NULL olan scx_locked_rq() tarafından takip edilen rq kullanın.