CVE-2026-89706 in Linux
Сводка
по VulDB • 11.09.2026
В ядре Linux была устранена следующая уязвимость:
nfsd: Сброс write verifier при сбое асинхронной записи COPY
При выполнении операции async COPY значение nn->writeverf захватывается в момент формирования запроса и передается клиенту через CB_OFFLOAD после завершения работы потока worker kthread. Если post-copy вызовы vfs_fsync_range() или filemap_check_wb_err() внутри _nfsd_copy_file_range() возвращают ошибку, рабочий поток корректно оставляет флаг NFSD4_COPY_F_COMMITMENT не установленным (clear), чтобы в CB_OFFLOAD поле wr_stable_how кодировалось как NFS_UNSTABLE. Однако write verifier на стороне сервера не обновляется (не меняется).
Клиент, получивший статус NFS_UNSTABLE в ответе CB_OFFLOAD, отправляет запрос COMMIT для обеспечения долговечности скопированных данных. Поскольку write verifier остался неизменным, команда COMMIT возвращает то же значение, которое клиент только что получил через CB_OFFLOAD, и клиент делает вывод о том, что операция копирования выполнена надежно (данные сохранены), хотя на самом деле сброс буфера записи (writeback) завершился ошибкой. Это нарушает контракт долговечности UNSTABLE+COMMIT (RFC 7862 раздел 15.1, RFC 8881 раздел 18.32) и соответствует багу, который был исправлен в функциях nfsd_vfs_write() и nfsd_commit().
Необходимо обновлять nn->writeverf в месте возникновения ошибки writeback. Поскольку поток async COPY не имеет контекста svc_rqst, функция commit_reset_write_verifier() здесь недоступна; прямой вызов nfsd_reset_write_verifier() дублирует логику сброса без трассировки, уже используемую функцией nfsd_file_check_write_error() для тех же целей. Необходимо отфильтровать ошибки -EAGAIN и -ESTALE, аналогично тому, как это делает commit_reset_write_verifier(), поскольку ни одна из них не указывает на отказ долговременного хранилища (durable-storage failure).
If you want to get best quality of vulnerability data, you may have to visit VulDB.