CVE-2025-38349

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: eventpoll: ep mutex'i hâlâ tutulurken ep refcount'u azaltma Jann Horn, epoll'ün ep refcount'u azalttığını ve ardından mutex_unlock(&ep->mtx); işlemini gerçekleştirdiğini belirtiyor. Bu çok yanlıştır, çünkü serbest bırakıldıktan sonra kullanıma yol açabilir. Bu kalıp aslında en son referans için sorunsuzdur, çünkü söz konusu kod "ep_free(ep)" çağrısını mutex'in kilidini açtıktan sonrasına kadar geciktirir. Ancak başka birinin de kendi referansını bırakabileceği ve biz mutex'i hâlâ kullanırken ep'yi serbest bırakabileceği çok daha ince olan "sondan bir önceki" durum için yanlıştır. Bunun, diğer kullanıcı aynı ep mutex'ini kullanıyor olsa bile geçerli olduğunu unutmayın: mutex'ler, spinlock'ların aksine, karşılıklı dışlamayı garanti etseler bile nesne sahipliği için kullanılamaz. Bir mutex "unlock" işlemi atomik değildir ve bir kullanıcı kilidini açmanın parçası olarak mutex'e hâlâ erişirken, başka bir kullanıcı gelip artık serbest bırakılmış mutex'i alabilir ve ilk kullanıcı hâlâ temizlik yaparken veri yapısını serbest bırakabilir. Documentation/locking/mutex-design.rst içindeki mutex belgelerimize, özellikle anlambilim hakkındaki [1] bölümüne bakın: "mutex_unlock() kiliti dahili olarak zaten serbest bıraktıktan sonra bile mutex yapısına erişebilir - bu nedenle başka bir bağlamın mutex'i alması ve mutex_unlock() bağlamının yapıyı artık kullanmadığını varsayması güvenli değildir" Dolayısıyla, mutex kilidini açmadan önce ep referansımızı bırakırsak, ancak sonuncusu biz değilsek, ardından mutex'in kilidini açabiliriz, başka bir kullanıcı gelir, _kendi_ referansını bırakır ve artık kullanıcısı olmadığı için 'ep'yi serbest bırakır - tüm bunlar mutex_unlock() hâlâ ona erişirken gerçekleşir. Bunu, ep refcount'unun azaltılmasını basitçe mutex'in dışına taşıyarak düzeltin: refcount'un kendisi atomiktir ve mutex korumasına ihtiyaç duymaz (refcount'ların tüm _amacı_ budur: mutex'lerin aksine, doğası gereği nesne yaşam süreleriyle ilgilidirler).