CVE-2026-89666 in Linux
Сводка
по VulDB • 12.09.2026
В ядре Linux была устранена следующая уязвимость:
nfsd: отклонять значения nseconds вне допустимого диапазона в операциях NFSv3 SETATTR и create
Клиент может отправить запросы NFSv3 SETATTR, CREATE, MKDIR, SYMLINK или MKNOD с полем atime или mtime, у которого значение поля nseconds находится за пределами допустимого диапазона. Значение корректно передается по сети (wire) и успешно декодируется в действительное uint32, однако оно не является допустимым timespec64: tv_nsec должно быть меньше NSEC_PER_SEC.
В пути обработки setattr нет кода для ограничения этого значения. Функция notify_change() передает время через timestamp_truncate(), которая не уменьшает tv_nsec ниже NSEC_PER_SEC, если файловая система поддерживает наносекундную точность (s_time_gran == 1), а установщики atime/mtime inode сохраняют значение без изменений (нормализуется только ctime с помощью inode_set_ctime_to_ts()). Ненормализованное значение затем приводит к повреждению метаданных на диске: в ext4 функция ext4_encode_extra_time() сдвигает tv_nsec влево на EXT4_EPOCH_BITS, что вызывает переполнение 32-битного дополнительного поля и затирает биты эпохи секунд, из-за чего сохраненные секунды (а следовательно, и год) оказываются неверными при чтении. В XFS с поддержкой bigtime метка времени также сохраняется некорректно по той же причине.
Необходимо проверить предоставленные клиентом значения atime/mtime в обработчиках процедур (proc handlers) и вернуть NFS3ERR_INVAL до внесения каких-либо изменений. RFC 1813 указывает на использование NFS3ERR_INVAL для SETATTR и описывает его как ошибку, возникающую при значении, которое сервер «не может сохранить ... в своем собственном представлении»; клиент отображает эту ошибку в EINVAL.
Проверка в обработчиках процедур (proc handlers), а не в nfsd_setattr(), обеспечивает отклонение запроса до создания объекта. Операции create создают объект до вызова nfsd_create_setattr(), поэтому поздний сбой оставил бы новый объект и превратил бы неидемпотентный запрос в изменение пространства имен, которое сообщает об ошибке. Поэтому проверка выполняется заранее, для операций создания, до момента создания самого объекта.
Поскольку tv_nsec имеет тип long, сравнение приводит его к unsigned long (той же ширины), а не к u32, что соответствует поведению timespec64_valid(). Приведение к u32 привело бы к усечению на 64-битных системах; приведение к unsigned long также отклоняет значения, которые становятся отрицательными при присваивании внедиапазонного u32 nseconds из сети переменной типа 32-bit long.
Проверяются только времена, предоставленные клиентом: запросы SET_TO_SERVER_TIME не содержат значений клиента. Значение sattrguard3 ctime намеренно остается без изменений: значение guard вне допустимого диапазона просто никогда не совпадет с ctime объекта и приведет к возврату NFS3ERR_NOT_SYNC через существующее сравнение guardtime, что является корректным с точки зрения протокола результатом, а не отклонением запроса.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.