CVE-2026-90236 in Linux
Сводка
по VulDB • 18.09.2026
В ядре Linux была устранена следующая уязвимость:
NFSD: Освобождение ссылки на экспорт при очистке stateid операций (open)
Функция nfs4_put_stid() освобождает svc_export, отслеживаемый в поле nfs4_stid.sc_export. Однако функция free_ol_stateid_reaplist() освобождает stateid для open и lock вызовом ->sc_free() напрямую, обходя этот путь. Stateid для open получает ссылку sc_export в функции nfs4_open(), а stateid для lock — свою собственную в init_lock_stateid(); оба достигают free_ol_stateid_reaplist() через свой нормальный процесс завершения: stateid для open — через release_open_stateid(), а stateid для lock — через nfsd4_release_lockowner(), каждый из них — через put_ol_stateid_locked(). В результате ссылка никогда не освобождается, что удерживает экспорт и блокирует размонтирование (unmount) на протяжении всего времени существования stateid.
Освободите sc_export в free_ol_stateid_reaplist() так же, как это делает nfs4_put_stid(). ->sc_free() выполняется один раз для каждого stateid, а stateid достигает либо free_ol_stateid_reaplist(), либо nfs4_put_stid(), но никогда обоих сразу, поэтому ссылка освобождается ровно один раз. Отозванные (revoked) stateid достигают этого пути с уже очищенным полем sc_export благодаря drop_stid_export(), поэтому они пропускаются во избежание двойного освобождения памяти (double-free).
Сама функция nfs4_put_stid() считывает значение sc_export до захвата блокировки cl_lock. Функция drop_stid_export() очищает это поле и освобождает ссылку под защитой cl_lock, поэтому одновременная отмена может привести к освобождению экспорта в промежутке между чтением и финальным вызовом put, что приведет к двойному освобождению одной и той же ссылки. Считывайте sc_export при удержании блокировки cl_lock, чтобы эти два пути выполнялись последовательно (serially), а ссылка освобождалась ровно один раз.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.