Ad

CVE-2026-89666

NONE EPSS 0.17%
Обновлено 11 сентября 2026
Linux
Параметр Значение
Поставщик Linux
Публичный эксплойт Нет

В ядре Linux устранена следующая уязвимость: nfsd: отклонить nсекунд, выходящих за пределы диапазона, в NFSv3 SETATTR и создать операции Клиент может отправить NFSv3 SETATTR, CREATE, MKDIR, SYMLINK или MKNOD. перенос atime или mtime, поле nсекунд которых находится за пределами допустимого диапазона. значение правильно сформировано на проводе и четко декодируется в допустимое значение. uint32, но это недопустимая спецификация time64: tv_nsec должно быть меньше NSEC_PER_SEC. Ничто в пути setattr не ограничивает его. notify_change() запускает время через timestamp_truncate(), который не уменьшает tv_nsec ниже NSEC_PER_SEC, когда файловая система поддерживает наносекундную детализацию (s_time_gran == 1), а установщики inode atime/mtime сохраняют его дословно. (нормализуется только ctime через inode_set_ctime_to_ts()). ненормализованное значение затем повреждает метаданные на диске: ext4 ext4_encode_extra_time() сдвигает tv_nsec влево на EXT4_EPOCH_BITS, что переполняет 32-битное дополнительное поле и затирает биты секундной эпохи, поэтому сохраненные секунды (и, следовательно, год) при обратном чтении неверны. XFS с bigtime неправильно сохраняет метку времени по той же причине.

Проверьте предоставленное клиентом значение atime/mtime в обработчиках процедур и верните NFS3ERR_INVAL, прежде чем что-либо изменится. В RFC 1813 указан NFS3ERR_INVAL. для SETATTR и описывает это как ошибку для значения, которое сервер «может не хранить... в своем собственном представлении»; клиент сопоставляет его с EINVAL. Проверка обработчиков процедур, а не nfsd_setattr(), сохраняет отказ перед созданием объекта.

Операции создания создают объект до запуска nfsd_create_setattr(), поэтому поздний сбой приведет к выходу новый объект позади и превратить неидемпотентный запрос в пространство имен изменение, сообщающее о сбое. Таким образом, проверка производится заранее, т. операции создания перед созданием объекта. tv_nsec имеет длинный тип, поэтому сравнение приводит его к unsigned long (тот же самый width), а не u32, что соответствует timespec64_valid(). Приведение u32 будет обрезать на 64-битной версии; беззнаковое длинное приведение также отклоняет значение, которое стал отрицательным, когда провод nсекунд u32 был назначен вне диапазона 32-битная длина.

Проверяются только времена, предоставленные клиентом: запросы SET_TO_SERVER_TIME. не несут никакой клиентской ценности. sattrguard3 ctime намеренно оставлен в покое: защита, находящаяся вне диапазона, просто никогда не соответствует времени объекта и выдает NFS3ERR_NOT_SYNC через существующее сравнение защитного времени, которое правильный для протокола результат, а не отклонение запроса.

Показать оригинальное описание (EN)

In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC. Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for SETATTR and describes it as the error for a value the server 'can not store ... in its own representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-idempotent request into a namespace change that reports failure. The check is therefore done up front, for the create operations before the object is created. tv_nsec is a long, so the comparison casts it to unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the protocol-correct outcome rather than rejecting the request.