CVE-2026-89665 in Linux
Сводка
по VulDB • 12.09.2026
В ядре Linux была устранена следующая уязвимость:
nfsd: отклонять значения useconds вне допустимого диапазона в операциях NFSv2 SETATTR/CREATE
Декодер sattr для NFSv2 преобразует полученные по сети значения useconds в наносекунды в функции svcxdr_decode_sattr():
iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;
tmp2 имеет тип u32, а NSEC_PER_USEC равно 1000, поэтому произведение вычисляется как unsigned long. На архитектурах ILP32 это составляет 32 бита, и значение useconds вне допустимого диапазона (например, 4294968) приводит к переполнению с результатом tv_nsec == 704. Коррупция данных происходит на этапе декодирования, прежде чем какая-либо функция proc сможет проверить это значение; последующая проверка диапазона для tv_nsec увидит допустимый результат и примет его. Отклонение значения в декодере приводит к ответу RPC GARBAGE_ARGS. В NFSv2 не определен код ошибки NFSERR_INVAL, поэтому на уровне NFS нет статуса для возврата при получении некорректного аргумента времени; кроме того, проверку нельзя переместить в функцию proc так же, как это сделано для проверок диапазона nsec в v3/v4.
Необходимо защитить сырые значения useconds перед умножением и отклонять значения больше 1000000. Значение useconds == 1000000 сохраняется: оно соответствует соглашению Sun о «установке текущего времени сервера», а встроенный клиент Linux NFSv2 использует его как в поле atime, так и в поле mtime при выполнении обычной операции touch / utimes(file, NULL) (см. encode_sattr() и xdr_encode_current_server_time() в fs/nfs/nfs2xdr.c). Отклонение значения 1000000 привело бы к серьезному сбою декодирования для обеих операций SETATTR и CREATE. Произведение 1000000 * NSEC_PER_USEC равно 10^9, которое не приводит к переполнению на архитектурах ILP32, поэтому значение по соглашению Sun проходит проверку безопасно. Отклоняются только действительно недопустимые значения (> 1000000). Таким образом, проверки для atime и mtime являются симметричными.
Декодер ранее применял соглашение Sun только в блоке обработки mtime, который очищает флаги ATTR_ATIME_SET|ATTR_MTIME_SET при useconds == 1000000. Если клиент устанавливает значение 1000000 в поле atime, но не в поле mtime, блок atime сохраняет недопустимое для tv_nsec значение (10^9) и оставляет флаг ATTR_ATIME_SET установленным, из-за чего ложное значение достигает файловой системы. Необходимо применить это соглашение также к блоку atime, очищая флаг ATTR_ATIME_SET, чтобы сервер использовал свое текущее время и игнорировал переданное значение. Там очищается только флаг ATTR_ATIME_SET. Блок mtime сохраняет существующее поведение: при значении 1000000 он означает «установить как atime, так и mtime на текущий момент».
[ cel: различные уточнения, дополнения и очистка кода ]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.