В ядре Linux устранена следующая уязвимость:
lockd: устранение утечки счетчика ссылок nlm_file при кэшировании сбоя nlm_do_fopen()
Путь к кэшированному файлу в nlm_lookup_file() достигает метки найдено:
безусловно, даже если nlm_do_fopen() завершается неудачно. На этом лейбле
*result и file->f_count обновляются до возврата ошибки. Обертки nlm3svc_lookup_file() и nlm4svc_lookup_file() затем
выйти из своего коммутатора, не копируя *result обратно в свой
вызывающий, поэтому локальный указатель nlm_file обработчика процесса остается NULL
и путь очистки пропускает nlm_release_file(). f_count
приращение никогда не высвобождается, и nlm_traverse_files() не может
дольше жать файл, потому что его счетчик ссылок никогда не возвращается к нулю
между запросами.
Сократите путь кеширования, чтобы ни *result, ни f_count не
затрагивается, когда nlm_do_fopen() завершается сбоем в хешированном nlm_file.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.