linux.git/fs/open.c, branch v7.3-rc2

fs: support FD_FAILFS_ROOT in fchroot()

2026-07-27T15:18:00+00:00

Allow a process to move its root directory into failfs via
fchroot(FD_FAILFS_ROOT). From that point on every absolute path lookup
and every absolute symlink fails with EOPNOTSUPP. Combined with
fchdir(FD_FAILFS_ROOT) this leaves the process with lookups anchored
at explicit directory file descriptors only. It is the fs_struct
equivalent of RESOLVE_BENEATH. This allows taks to drop their filesystem
state completely.

Callers with CAP_SYS_CHROOT in their user namespace may always do
this, mirroring chroot(2). Unprivileged callers are subject to three
requirements (which may be loosened later):

(1) no_new_privs must be set

    After entering failfs suid binaries on regular mounts remain
    reachable via inherited directory file descriptors or the working
    directory. A setuid program executing with an unusable root
    directory might be tricked by this. I'm not 100% convinced that this
    is needed but it feels more secure initially and it also forces more
    no_new_privs on userspace. So win-win imo.

(2) The caller must not already be chrooted.

    The root directory is what confines .. resolution. The failfs root
    can never be reached by walking up a real mount tree. A task whose
    root is failfs has no .. barrier left below the top of its mount
    tree. A .. walk from any real directory fd it still holds climbs
    to the mount-namespace root. Which is kinda the point if you want to
    do fd-based lookup only. If failfs prevented you from doing that
    then it doesn't make a lot of sense.

    A task that a privileged manager chrooted into a subtree could use
    chroot()ing into failfs as a way to allow for an inherited fd to
    resolve it again.

    So reject already-chrooted callers closing that issue without losing
    anything for the intended self-sandboxing use case.

(3) The caller must not share its fs_struct.

    Requirement (1) is checked on the calling thread, but the root
    lives in the fs_struct which may be shared via CLONE_FS. A sibling
    thread without no_new_privs could then execute a setuid binary with
    the failfs root and defeat (1). setns() to a mount or user namespace
    refuses a shared fs_struct for the same kind of reason, so do the
    same here and require fs->users == 1. no_new_privs is inherited
    across clone() and can never be cleared, so any CLONE_FS child
    created afterwards carries it too and the guarantee holds.

Privileged callers (CAP_SYS_CHROOT) are not subject to these
requirements and may share the fs_struct. They can already chroot and
exec a setuid binary today, so failfs hands them nothing new.

Backing out is currently hard, but that is a property of the current
implementation and not a promise. current_chrooted() treats a failfs
root as chrooted so for now the task cannot create user namespaces to
regain CAP_SYS_CHROOT and chroot()/fchroot() back out require
CAP_SYS_CHROOT. This is not guaranteed though. current_chrooted() may
change, or an unprivileged no_new_privs task could be allowed to chroot
to a real directory, either of which would loosen this. So don't treat
it as a permanent one-way door.

The remaining way out today is setns() to a mount namespace file
descriptor which requires CAP_SYS_ADMIN over the target namespace plus
CAP_SYS_CHROOT and CAP_SYS_ADMIN in the caller's user namespace and
resets both root and working directory. A task that closes or never had
such file descriptors and restricts *chdir()/*chroot()/setns() via
seccomp currently cannot get back out.

Link: https://patch.msgid.link/20260724-work-failfs-v2-4-485dabbae185@kernel.org
Signed-off-by: Christian Brauner (Amutable)

fs: add fchroot()

2026-07-27T15:18:00+00:00

Add a file descriptor based counterpart to chroot(2). This has been
overdue for a long time. It is the natural companion to fchdir() and
avoids re-resolving a path that the caller already holds a file
descriptor to. No TOCTOU between resolving the target and changing the
root. It composes with modern fd-based APIs meaning it works with O_PATH
file descriptors and file descriptors to detached mount trees created
via open_tree(OPEN_TREE_CLONE).

The permission model is identical to chroot(2). The caller must have
CAP_SYS_CHROOT in its user namespace, must pass MAY_EXEC | MAY_CHDIR
permission checks on the target directory, and LSMs are consulted via
the same security_path_chroot() hook.

The system call takes a flags argument for future extensibility which
must currently be zero.

Link: https://patch.msgid.link/20260724-work-failfs-v2-3-485dabbae185@kernel.org
Signed-off-by: Christian Brauner (Amutable)

fs: support FD_FAILFS_ROOT in fchdir()

2026-07-27T15:17:59+00:00

Add a new file descriptor sentinel FD_FAILFS_ROOT following
FD_PIDFS_ROOT and FD_NSFS_ROOT and teach fchdir() to accept it. A
process calling fchdir(FD_FAILFS_ROOT) moves its working directory
into failfs. Every AT_FDCWD-relative lookup afterwards fails with
EOPNOTSUPP including "." and ".." and getcwd() reports the working
directory as unreachable from the process root by returning a path
prefixed with "(unreachable)". Lookups relative to explicit directory
file descriptors are unaffected.

The sentinel is the only way in. No privilege or gating is required.
Setting the working directory to a directory in which every operation
fails grants nothing and loses nothing that closing file descriptors
couldn't lose. An unlinked working directory behaves the same way today
modulo errno. The working directory also plays no role in confining ".."
resolution so no boundary is weakened.

Link: https://patch.msgid.link/20260724-work-failfs-v2-2-485dabbae185@kernel.org
Signed-off-by: Christian Brauner (Amutable)

Merge tag 'mm-stable-2026-06-23-08-55' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-06-23T19:03:44+00:00

Pull more MM updates from Andrew Morton:

 - "khugepaged: add mTHP collapse support" (Nico Pache)

   Provide khugepaged with the capability to collapse anonymous memory
   regions to mTHPs

 - "Remove CONFIG_READ_ONLY_THP_FOR_FS and enable file THP for writable
   files" (Zi Yan)

   Remove the READ_ONLY_THP_FOR_FS check in file_thp_enabled(), so that
   khugepaged and MADV_COLLAPSE can run on filesystems with PMD THP
   pagecache support even without READ_ONLY_THP_FOR_FS enabled

 - "make MM selftests more CI friendly" (Mike Rapoport)

   General fixes and cleanups to the MM selftests. Also move more MM
   selftests under the kselftest framework, making them more amenable to
   ongoing CI testing

 - "selftests/mm: fix failures and robustness improvements" and
   "selftests/mm: assorted fixes for hmm-tests" (Sayali Patil)

   Fix several issues in MM selftests which were revealed by powerpc 64k
   pagesize

* tag 'mm-stable-2026-06-23-08-55' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (118 commits)
  Revert "mm: limit filemap_fault readahead to VMA boundaries"
  mm/vmscan: pass NULL to trace vmscan node reclaim
  mm: use mapping_mapped to simplify the code
  selftests/mm: fix exclusive_cow test fork() handling
  selftests/mm: remove hardcoded THP sizing assumptions in hmm tests
  selftests/mm: allow PUD-level entries in compound testcase of hmm tests
  mm/gup_test: reject wrapped user ranges
  mm/page_frag: reject invalid CPUs in page_frag_test
  mm/damon/core: always put unsuccessfully committed target pids
  mm: page_isolation: avoid unsafe folio reads while scanning compound pages
  mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()
  selftests: mm: fix and speedup "droppable" test
  mm: merge writeout into pageout
  MAINTAINERS: add Hao Ge as reviewer for codetag and alloc_tag
  selftests/mm: clarify alternate unmapping in compaction_test
  selftests/mm: move hwpoison setup into run_test() and silence modprobe output for memory-failure category
  selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero
  selftests/mm: skip uffd-wp-mremap if UFFD write-protect is unsupported
  selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap
  selftest/mm: register existing mapping with userfaultfd in hugetlb-mremap
  ...

mm: fs: remove filemap_nr_thps*() functions and their users

2026-06-21T18:37:15+00:00

They are used by READ_ONLY_THP_FOR_FS to handle writes to FSes without
large folio support, so that read-only THPs created in these FSes are not
seen by the FSes when the underlying fd becomes writable.  Now read-only
PMD THPs only appear in a FS with large folio support and the supported
orders include PMD_ORDER.

READ_ONLY_THP_FOR_FS was using mapping->nr_thps, inode->i_writecount, and
smp_mb() to prevent writes to a read-only THP and collapsing writable
folios into a THP.  In collapse_file(), mapping->nr_thps is increased,
then smp_mb(), and if inode->i_writecount > 0, collapse is stopped, while
do_dentry_open() first increases inode->i_writecount, then a full memory
fence, and if mapping->nr_thps > 0, all read-only THPs are truncated.

Now this mechanism can be removed along with READ_ONLY_THP_FOR_FS code,
since a dirty folio check has been added after try_to_unmap() in
collapse_file() to prevent dirty folios from being collapsed as clean.

Link: https://lore.kernel.org/20260517135416.1434539-7-ziy@nvidia.com
Signed-off-by: Zi Yan 
Reviewed-by: Matthew Wilcox (Oracle) 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Baolin Wang 
Reviewed-by: Lance Yang 
Cc: Al Viro 
Cc: Barry Song 
Cc: Chris Mason 
Cc: Christian Brauner 
Cc: David Sterba 
Cc: Dev Jain 
Cc: Jan Kara 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Nico Pache 
Cc: Ryan Roberts 
Cc: Shuah Khan 
Cc: Song Liu 
Cc: Suren Baghdasaryan 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

openat2: new OPENAT2_REGULAR flag support

2026-05-21T13:33:47+00:00

This flag indicates the path should be opened if it's a regular file.
This is useful to write secure programs that want to avoid being
tricked into opening device nodes with special semantics while thinking
they operate on regular files. This is a requested feature from the
uapi-group[1].

The previously introduced EFTYPE error code is returned when the path
doesn't refer to a regular file. For example, if openat2 is called on
path /dev/null with OPENAT2_REGULAR in the flag param, it will return
-EFTYPE.

When used in combination with O_CREAT, either the regular file is
created, or if the path already exists, it is opened if it's a regular
file. Otherwise, -EFTYPE is returned.

When OPENAT2_REGULAR is combined with O_DIRECTORY, -EINVAL is returned
as it doesn't make sense to open a path that is both a directory and a
regular file.

The UAPI bit lives in the upper 32 bits of open_how::flags
(((__u64)1 << 32)) so that open(2) and openat(2) -- whose @flags
argument is a C int -- cannot physically express it. This is a
structural guarantee, not a runtime mask: the bit is unrepresentable in
32 bits.

Because the rest of the VFS open path narrows to 32 bits in several
places (op->open_flag, f->f_flags, the unsigned open_flag argument of
i_op->atomic_open()), build_open_flags() translates OPENAT2_REGULAR
into a kernel-internal lower-32-bit carrier __O_REGULAR (bit 4, unused
as an O_* on every architecture) before the assignment to op->open_flag.
__O_REGULAR then rides through the existing channels exactly like
__FMODE_EXEC. do_dentry_open() strips it so it cannot leak back to
userspace via fcntl(F_GETFL).

Four BUILD_BUG_ON_MSG() invariants in build_open_flags() prevent any
future bit collision or accidental low-32 redefinition:

  - VALID_OPEN_FLAGS fits in 32 bits.
  - OPENAT2_REGULAR lives in the upper 32 bits.
  - OPENAT2_REGULAR does not alias any open()/openat() flag.
  - __O_REGULAR does not alias any user-visible flag.

[1]: https://uapi-group.org/kernel-features/#ability-to-only-open-regular-files

Christian Brauner  says:

Move OPENAT2_REGULAR to the upper 32 bits of open_how::flags with a
kernel-internal __O_REGULAR carrier so that open(2)/openat(2) cannot
encode the flag; add BUILD_BUG_ON_MSG() invariants and register
__O_REGULAR in the fcntl_init() allocation-uniqueness BUILD_BUG_ON()
(bit count 21 -> 22).

Signed-off-by: Dorjoy Chowdhury 
Link: https://patch.msgid.link/20260328172314.45807-2-dorjoychy111@gmail.com
Reviewed-by: Jeff Layton 
Reviewed-by: Aleksa Sarai 
Signed-off-by: Christian Brauner (Amutable)

vfs: add O_EMPTYPATH to openat(2)/openat2(2)

2026-05-21T08:53:33+00:00

To get an operable version of an O_PATH file descriptor, it is possible
to use openat(fd, ".", O_DIRECTORY) for directories, but other files
currently require going through open("/proc//fd/"), which
depends on a functioning procfs.

This patch adds the O_EMPTYPATH flag to openat(2)/openat2(2). If passed,
LOOKUP_EMPTY is set at path resolution time.

Note: This implies that you cannot rely anymore on disabling procfs from
being mounted (e.g. inside a container without procfs mounted and with
CAP_SYS_ADMIN dropped) to prevent O_PATH fds from being re-opened
read-write.

Signed-off-by: Jori Koolstra 
Link: https://patch.msgid.link/20260424114611.1678641-2-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable)

fs: remove do_sys_truncate

2026-03-23T11:41:58+00:00

do_sys_truncate ist only used to implement ksys_truncate and the native
truncate syscalls.  Merge do_sys_truncate into ksys_truncate and return
int from it as it only returns 0 or negative errnos.

Signed-off-by: Christoph Hellwig 
Link: https://patch.msgid.link/20260323070205.2939118-4-hch@lst.de
Reviewed-by: Jan Kara 
Signed-off-by: Christian Brauner

fs: pass on FTRUNCATE_* flags to do_truncate

2026-03-23T11:41:57+00:00

Pass the flags one level down to replace the somewhat confusing small
argument, and clean up do_truncate as a result.

Signed-off-by: Christoph Hellwig 
Link: https://patch.msgid.link/20260323070205.2939118-3-hch@lst.de
Reviewed-by: Jan Kara 
Signed-off-by: Christian Brauner

fs: fix archiecture-specific compat_ftruncate64

2026-03-23T11:41:57+00:00

The "small" argument to do_sys_ftruncate indicates if > 32-bit size
should be reject, but all the arch-specific compat ftruncate64
implementations get this wrong.  Merge do_sys_ftruncate and
ksys_ftruncate, replace the integer as boolean small flag with a
descriptive one about LFS semantics, and use it correctly in the
architecture-specific ftruncate64 implementations.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: 3dd681d944f6 ("arm64: 32-bit (compat) applications support")
Signed-off-by: Christoph Hellwig 
Link: https://patch.msgid.link/20260323070205.2939118-2-hch@lst.de
Reviewed-by: Jan Kara 
Signed-off-by: Christian Brauner