CVE-2024-14040

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: net: nexthop: Ağırlığı u16'ya yükselt CLOS ağlarında, ağın çeşitli noktalarında bağlantı arızaları meydana geldikçe, ilgili düğümlerin ECMP ağırlıkları telafi etmek için ayarlanır. İlgili düğümlerin yüksek fan-out'u ve genel olarak yüksek düğüm sayısıyla birlikte, yapılandırmak istediğimiz (non-)ECMP ağırlık oranı 8 bite sığmaz. Örneğin 255:254 yerine 1000:999 gibi bir şey yapılandırmak isteyebiliriz. Bu dağıtımlar için 8 bitlik ağırlık yeterli olmayabilir. Bu amaçla, bu yamada sonraki atlama ağırlığı u8'den u16'ya yükseltilmiştir. Bir tam sayı türünün genişliğini artırmak zor olabilir, çünkü kod hâlâ derlense de türler artık uyuşmayabilir ve sayısal hatalar ortaya çıkabilir. Bunu önlemek için dönüşüm iki adımda yapılmıştır. Önce tür u8'den tek üyeli bir yapıya değiştirilmiş, bu da alanın tüm kullanımlarını geçersiz kılmıştır. Bu, bunların tek tek gözden geçirilmesine ve tür doğruluğu açısından denetlenmesine olanak tanımıştır. Ardından yapı yeniden sade bir u16 ile değiştirilmiştir. Bu, hiçbir yerin atlanmadığını garanti etmelidir. Nexthop grubu üyelerini yapılandırmaya yönelik UAPI, NHA_GROUP adlı bir özniteliğin struct nexthop_grp girdilerinden oluşan bir dizi taşıması şeklindedir: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 resvd1; __u16 resvd2; }; resvd1 alanı şu anda doğrulanmakta ve sıfır olması gerekmektedir. Bu gerekliliği kaldırabilir ve ağırlığın yüksek dereceli bitlerini ayrılmış alanda taşıyabiliriz: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 weight_high; __u16 resvd2; }; Alanları bu şekilde bölünmüş tutmak, mevcut bir kullanıcı alanının ağırlık alanının genişliği hakkında varsayımlarda bulunması durumuna karşı ve herhangi bir endianness sorununu önlemek için seçilmiştir. Ağırlık alanı şu anda ağırlık değerinin bir eksiği olarak kodlanmaktadır, çünkü 0 ağırlığı geçersizdir. Aynı hile yeni weight_high alanı için imkânsızdır, çünkü sıfır gerçek sıfır anlamına gelmelidir. Bu yerleştirildiğinde: - Eski kullanıcı alanının weight_high değerini 0 olarak taşıması garanti edilir, dolayısıyla 8 bitlik ağırlıkları uygun şekilde yapılandırır. 16 bitlik ağırlığa sahip nexthop'lar dökümü alındığında yalnızca alt 8 bit gösterilir. Ancak bu tür nexthop'ları yapılandırmak, uzantıdan haberdar olan bir kullanıcı alanının varlığını zaten ima eder. - Eski bir çekirdekle konuşan yeni kullanıcı alanı, yalnızca yüksek dereceli bitlerin sıfır olduğu 8 bitlik ağırlıkları yapılandırmaya çalıştığı sürece çalışacaktır. Eski çekirdek, 8 bitten büyük ağırlıkları yapılandırma girişimlerini reddedecektir. Ayrılmış alanların bir amaç için tahsis edildiklerinde yeniden adlandırılması Linux'ta yaygın olarak yapılır. Bir ayrılmış alana dokunan herkes bunu kendi riskiyle yapar. Özellikle nexthop_grp::resvd1 şu anda en azından strace tarafından kullanılmaktadır, ancak bunlar UAPI başlıklarının kendi kopyalarını taşır ve dönüşüm önemsiz olmalıdır. Ağırlığı iki alandan çözmek için bir yardımcı sağlanmıştır. Bir dönüşümü zorlamak, geriye doğru eğilip anonim birlikler veya benzeri şeyler sunmaktan tercih edilebilir görünmektedir.