В ядре Linux устранена следующая уязвимость:
fs: исправлен пользовательский путь к вложенным файлам резервного копирования.
backing_file_open() получает путь для сохранения в новой резервной копии.
файл из user_file->f_path. Это неверно, если сам user_file
является резервным файлом, что характерно для вложенных файловых систем стекирования,
например overlayfs монтируется там, где нижний каталог одного overlayfs является объединенным
каталог другого. С момента фиксации def3ae83da02 («fs: сохранить реальный путь
вместо поддельного пути в файле резервной копии f_path") f_path резервной копии
файл содержит реальный путь промежуточного слоя, а не путь, который
пользователь открыл.
Коммит 924577e4f6ca («ovl: исправить вложенные пути к резервным файлам») исправил это.
для таких конфигураций, передав file_user_path() из
ovl_open_realfile(). Однако зафиксируйте 6af36aeb147a ("lsm: add
backing_file LSM перехватчики") изменил первый аргумент
backing_file_open() из пользовательского пути обратно в пользовательский файл и
снова получил путь из user_file->f_path, молча повторно вводя
проблема. В результате файлы, сопоставленные с помощью вложенных наложений, отображают неправильные
путь в /proc/<pid>/maps и в записях mmap perf/ftrace.
Например,
с двумя вложенными монтированиями overlayfs:
mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested
эхо привет > /ovl/lower/foo
mount -t оверлей оверлей \
-o lowdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \
/ovl/объединен
# необходимы как минимум два нижних каталога, если верхний каталог не существует
mount -t оверлей оверлей \
-o lowdir=/ovl/merged:/ovl/lower /ovl/nested
отображение /ovl/nested/foo показывает отключенный путь вместо пользователя
путь:
# readlink /proc/self/fd/3
/ovl/вложенный/фу
# grep foo /proc/self/maps
7f6e2c100000-7f6e2c101000 р--с 00000000 00:24 15813027 /foo
Поддельный путь получен из f_path промежуточной поддержки.
файл, монтирование которого является частным клоном, который d_path() не может разрешить. Исправьте это, используя file_user_path(), который возвращает самый внешний
видимый пользователю путь для резервных файлов и возвращается к
&user_file->f_path для обычных файлов. Это восстанавливает поведение
зафиксируйте 924577e4f6ca («ovl: исправить вложенные пути к резервным файлам») для
overlayfs, а также исправляет ту же проблему для другого
вызывающие вызовы backing_file_open(), passthrough и erofs isshare, когда
их пользовательский файл сам по себе является файлом поддержки.
backing_tmpfile_open() имеет тот же шаблон, но на него не влияет: это
вызывается только ovl_create_tmpfile() для верхнего уровня, а другой
overlayfs отклоняется как верхний каталог при проверке DCACHE_OP_REAL
ovl_mount_dir_check(), поэтому его user_file никогда не может быть резервным файлом.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: fs: fix user path of nested backing files backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc/<pid>/maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested mapping /ovl/nested/foo shows a disconnected path instead of the user path: # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo The bogus path is derived from the f_path of the intermediate backing file, whose mount is a private clone that d_path() cannot resolve. Fix this by using file_user_path(), which returns the outermost user-visible path for backing files and falls back to &user_file->f_path for regular files. This restores the behavior of commit 924577e4f6ca ("ovl: Fix nested backing file paths") for overlayfs and also fixes the same problem for the other backing_file_open() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file. backing_tmpfile_open() has the same pattern but is not affected: it is only called by ovl_create_tmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHE_OP_REAL check in ovl_mount_dir_check(), so its user_file can never be a backing file.