В ядре Linux устранена следующая уязвимость:
configfs_lookup(): не оставляйте ->s_dentry висящим в случае сбоя
Обычно ->s_dentry очищается, когда dentry, на который он указывает, становится
отрицательный (о выселении, реально). Однако это происходит только
если стоматология вообще окажется положительной; в случае индексного дескриптора
dentry ошибки распределения никогда не становится положительным, поэтому ->d_iput()
вообще не вызывается. Мы делаем часть того, что обычно делает configfs_d_iput().
(удаляя ссылку на configfs_dirent) вручную, но мы это делаем
непонятно -> там s_dentry.
Как бы неряшливо это ни было, это не имеет значения.
случай configfs_create_{dir,link}() - там configfs_dirent делает
не выжить, упустив единственную ссылку на него. Однако для configfs_lookup() он *действительно* сохраняется, с висячим
указатель на то, что дентри скоро будет освобожден, сидя на нем ->s_dentry. Последующие getdents(2) в этом каталоге в конечном итоге будут разыменованы.
этот указатель, чтобы выбрать номер индексного дескриптора.
Используйте после бесплатного... Это минимальное исправление; правильный подход - установить связь
между dentry и configfs_dirent только после того, как мы узнаем, что у нас есть
индексный дескриптор, но для этого требуется больше операций, и ошибка была там
с 2006 года, так что...
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...
Характеристики атаки
Последствия
Строка CVSS v3.1