In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
fs: fix user path of nested backing files<\/p>\n
backing_file_open() derives the path to be stored in the new backing
\nfile from user_file->f_path. This is incorrect when user_file itself
\nis a backing file, which is the case for nested stacking filesystems,
\ne.g. overlayfs mounts where the lowerdir of one overlayfs is the merged
\ndirectory of another. Since commit def3ae83da02 (“fs: store real path
\ninstead of fake path in backing file f_path”) the f_path of a backing
\nfile holds the real path of the intermediate layer, not the path that
\nthe user opened.<\/p>\n
Commit 924577e4f6ca (“ovl: Fix nested backing file paths”) fixed this
\nfor such configurations by passing file_user_path() from
\novl_open_realfile(). However, commit 6af36aeb147a (“lsm: add
\nbacking_file LSM hooks”) changed the first argument of
\nbacking_file_open() from the user path back to the user file and
\nderived the path from user_file->f_path again, silently re-introducing
\nthe problem.<\/p>\n
As a result, files mapped through a nested overlayfs show the wrong
\npath in \/proc\/\/maps and in perf\/ftrace mmap records. For example,
\nwith two nested overlayfs mounts:<\/p>\n
mkdir -p \/ovl\/{lower,upper,work,merged} \/ovl\/nested
\n echo hello > \/ovl\/lower\/foo
\n mount -t overlay overlay
\n\t-o lowerdir=\/ovl\/lower,upperdir=\/ovl\/upper,workdir=\/ovl\/work
\n\t\/ovl\/merged
\n # at least two lowerdirs are needed when upperdir is nonexistent
\n mount -t overlay overlay
\n\t-o lowerdir=\/ovl\/merged:\/ovl\/lower \/ovl\/nested<\/p>\n
mapping \/ovl\/nested\/foo shows a disconnected path instead of the user
\npath:<\/p>\n
# readlink \/proc\/self\/fd\/3
\n \/ovl\/nested\/foo
\n # grep foo \/proc\/self\/maps
\n 7f6e2c100000-7f6e2c101000 r–s 00000000 00:24 15813027 \/foo<\/p>\n
The bogus path is derived from the f_path of the intermediate backing
\nfile, whose mount is a private clone that d_path() cannot resolve.<\/p>\n
Fix this by using file_user_path(), which returns the outermost
\nuser-visible path for backing files and falls back to
\n&user_file->f_path for regular files. This restores the behavior of
\ncommit 924577e4f6ca (“ovl: Fix nested backing file paths”) for
\noverlayfs and also fixes the same problem for the other
\nbacking_file_open() callers, fuse passthrough and erofs ishare, when
\ntheir user file is itself a backing file.<\/p>\n
backing_tmpfile_open() has the same pattern but is not affected: it is
\nonly called by ovl_create_tmpfile() for the upper layer, and another
\noverlayfs is rejected as upperdir by the DCACHE_OP_REAL check in
\novl_mount_dir_check(), so its user_file can never be a backing file.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
fs: fix user path of nested backing files<\/p>\n
backing_file_open() derives the path to be stored in the new backing
\nfile from user_file<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21690","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21690","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21690"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21690"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21690"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}