В ядре Linux устранена следующая уязвимость:
nfsd: блокировать операции, не относящиеся к SAVEFH, после FOREIGN PUTFH, чтобы предотвратить разыменование NULL
Когда CONFIG_NFSD_V4_2_INTER_SSC включен, nfsd4_putfh() может вернуть
успех с fh_dentry и fh_export, оба NULL, если fh_verify() возвращает результат
nfserr_stale и putfh->no_verify имеют значение true. Флаг NFSD4_FH_FOREIGN
установлен, но составной цикл диспетчеризации использует этот флаг только для обхода
проверка nfserr_nofilehandle — она не предотвращает последующие операции
от запуска с NULL fh_dentry. Удаленный клиент может воспользоваться этим, создав СОЕДИНЕНИЕ, включающее в себя
КОПИЯ между SSC (которая заставляет check_if_stalefh_allowed() устанавливать
no_verify=true для сохраненного PUTFH) с вставленной дополнительной операцией
между исходным PUTFH и SAVEFH.
Например, SETATTR вызывает
fh_want_write(), который разыменовывает fh_export->ex_path.mnt без
сначала вызывая fh_verify(), вызывая разыменование нулевого указателя в
nfsd kthread. Исправьте это, отключив цикл диспетчеризации: когда установлен NFSD4_FH_FOREIGN
и fh_dentry имеет значение NULL, только OP_SAVEFH (необходим для потока между SSC)
и работает с ALLOWED_WITHOUT_FH (который не требует разрешения
дескриптор файла) может продолжиться. Все остальные операции получают nfserr_stale, согласно
Раздел 15.2.3 RFC 7862, в котором указано, что внешний дескриптор файла
проверка откладывается до операции-потребителя и NFS4ERR_STALE
вернулся в этот момент.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.
Характеристики атаки
Последствия
Строка CVSS v3.1