CVE-2023-52920

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: bpf: hassasiyet takibinde yığından/yığına r10 dışındaki kaydedici döküm/doldurma (spill/fill) desteği Bu işlemin salt okunur r10 kaydedicisi aracılığıyla mı yoksa r10 başka bir kaydediciye kopyalandıktan *ve* potansiyel olarak ofset ayarlandıktan sonra herhangi bir başka kaydedici üzerinden mi yapıldığına bakılmaksızın, yığından/yığına kaydedici döküm/doldurma işlemi gerçekleştiren talimatları kaydetmek için talimat ( Atlama) geçmişini kullanın. Bunun güvenilir şekilde çalışmasını sağlamak için, talimat geçmişindeki prev_idx alanından aldığımız ekstra 10 bitlik bayraklarda yığın yuva dizinini (spi) ve yığın çerçeve numarasını kodlayarak, her talimata özel ek bayrakları talimat geçmişine ekliyoruz. Geri izleme sırasında en sık kontrol edilen alan olduğu için maksimum performans adına idx alanına dokunmuyoruz. Bu değişiklik, BPF doğrulayıcısındaki hassasiyet geri izleme mantığının temel olarak geriye kalan son pratik sınırlamasını kaldırmaktadır. Bilinen eksiklikleri gidermenin yanı sıra, sonraki yamalarda incelenen doğrulanmış durum sayısını azaltmak için yeni fırsatlar sunmaktadır. veristat'e göre selftest'lerin BPF nesne dosyalarında yalnızca üç fark vardır ve bunların tamamı olumlu yöndedir (daha az durum). Dosya Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) -------------------------------------- ------------- --------- --------- ------------- ---------- ---------- ------------- test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%) Not: Değiştirilen satır sayısını ve bpf ile bpf-next ağaçları arasındaki potansiyel birleştirme çakışmalarını en aza indirmek için jmp_history ismini daha genel olan insn_hist ile değiştirmekten kaçındım. Ayrıca, talimat doğrulama döngüsünün başında cur_hist_entry işaretçisinin NULL değerine sıfırlandığını fark edin. Bu işaretçi, mevcut talimat için halihazırda bir girişimiz olup olmadığını belirlemek için son atlama geçmişi girişinin insn_idx değerine güvenme sorununu önler. Mevcut talimat is_jmp_point() olduğu için bir atlama geçmişi girişi eklemiş olabiliriz ancak aynı zamanda yığın erişimi için talimat bayraklarını da eklememiz gerekebilir. Bu durumda iki ayrı giriş istemiyoruz, bu nedenle eğer mevcutsa son eklenen girişi yeniden kullanmamız gerekir. insn_idx karşılaştırmasına güvenmek, yakın zamanda [0]'da düzeltilen belirsizlik sorunuyla aynı probleme sahiptir, bu yüzden bundan kaçınıyoruz. [0] https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/