CVE-2026-82390

Espressif AES sürücüsü drivers/crypto/crypto_esp32_aes.c, çoklu oturum şifreleme API'si sunmaktadır; her biri kendi anahtarını ve yönünü taşıyan, CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (varsayılan 4) değerine kadar bağımsız oturum sağlamaktadır. Ancak, AES çevre birimi tek bir çip genelinde anahtar ve mod kayıt setine sahiptir ve aes_begin_session() bunları dönüşümleri serileştiren aes_lock mutex'inin dışında, oturum başlangıcında yalnızca bir kez programlamıştır. Ardından işlem başına yürütülen aes_ecb_op(), aes_cbc_op() ve aes_ctr_op() işleyicileri, kayıtların o an hangi anahtarı ve yönü tuttuğuna bakmaksızın aes_hal_transform_block() fonksiyonunu çalıştırmıştır. Sonuç olarak, farklı bir anahtarla ikinci bir oturum açıldığında, ilk oturum üzerindeki tüm sonraki işlemler sessizce ikinci oturumun anahtarını ve yönünü kullanır ve herhangi bir hata raporlanmaz. Anahtar programlama işlemi kilit dışında gerçekleştiği için, "her iş parçacığının kendi oturumu üzerinde önce begin, ardından op ve sonra free yapması" şeklindeki doğru kullanım modeli de yarış durumuna (race condition) girer: İkinci bir iş parçacığının cipher_begin_session() çağrısının, birinci iş parçacığının begin ve operasyon işlemleri arasına girmesi, söz konusu operasyonun ikinci iş parçacığının anahtarı altında çalışmasına neden olur. Cihazda oturum oluşturulmasını tetikleyebilen bir saldırgan — örneğin bağlantısı bir oturum anahtarının yüklenmesine neden olan bir protokol eşi — mağdur bir işlem çalıştığında hangi anahtarın yerleşik olduğunu etkileyebilir. Etki, bellek bozulmasından ziyade kriptografik bir hatadır: uygulamanın bir anahtar altında koruduğuna inandığı veriler başka bir anahtar altında şifrelenir veya şifresi çözülür. Yerleşik anahtarın saldırgan tarafından bilindiği veya sağlandığı durumlarda, etkilenen açık metin bu saldırgan tarafından geri kazanılabilir hale gelir ve işlemin yönü (şifreleme yerine şifre çözme gibi) aynı şekilde tersine çevrilebilir. Bu durumun ortaya çıkması için uygulamanın bu sürücü ile farklı anahtarlara sahip iki veya daha fazla eşzamanlı oturum tutması gerekir; şu anda hiçbir Zephyr alt sistemi bunu yapmamaktadır (iki oturum açan 802.15.4 güvenlik katmanı, bu sürücünün reddettiği CCM modunu kullanır), dolayısıyla risk dokümante edilmiş çoklu oturum API'sini kullanan uygulama kodlarına düşmektedir. Düzeltme, aes_begin_session() içerisindeki tüm donanım erişimlerini kaldırır ve anahtar ile yönü her işlemin başında, aes_lock içerisinde yeniden programlar; böylece çip genelindeki kayıtlar artık başka bir oturum tarafından güncelliğini yitirmiş şekilde gözlemlenemez.