Changes in Makefile

146cc263e457ff6055fe7829e4f4f4b0b5d5dd86 - Merge tag 'v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next

Tue, 18 Aug 2026 14:21:04 +0200

Merge tag 'v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-nextLinux 7.2 List of files: /linux/tools/testing/selftests/filesystems/fscontext_ns/Makefile

ad8d485e665829ecbf3c97b22ce251f8ff5f8037 - Merge tag 'vfs-7.2-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Fri, 14 Aug 2026 16:58:01 +0200

Merge tag 'vfs-7.2-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfsPull vfs fixes from Christian Brauner: - Don't warn when a mount is completed from another user namespace. fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. The task that calls fsconfig(FSCONFIG_CMD_CREATE) doesn't have to be the one that created the context, and mount_capable() lets it through as long as the caller has CAP_SYS_ADMIN over fc->user_ns, which anyone in an ancestor namespace does. So fc->user_ns != current_user_ns() is something an unprivileged user can arrange. Both overlayfs and binfmt_misc WARN_ON() that. Overlayfs already has the same check as a plain error return in ovl_parse_param(). Drop the WARN_ON() and just refuse. Add selftests for both cases. - Reject pid allocations through dead ancestor pid namespaces. Require PIDNS_ADDING in every namespace that will receive the pid before publishing any of them. That preserves the invariant that free_pid() never decrements pid_allocated in a namespace whose child_reaper is no longer live. The existing ENOMEM behavior is unchanged.* tag 'vfs-7.2-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: pid: reject allocations through dead ancestor pid namespaces selftests/filesystems: test completing a context from another user namespace binfmt_misc: don't warn when the mount is completed from another user namespace ovl: don't warn when the mount is completed from another user namespace List of files: /linux/tools/testing/selftests/filesystems/fscontext_ns/Makefile

86bcfe2e37cee93bb495ecd3238116ffd21183e9 - Merge patch series "fs: don't warn when a mount is completed from another user namespace"

Mon, 10 Aug 2026 09:36:06 +0200

Merge patch series "fs: don't warn when a mount is completed from another user namespace"Christian Brauner says:fsopen() records the caller's user namespace in fc->user_ns and hands backan ordinary file descriptor. The task that calls fsconfig(CMD_CREATE)doesn't have to be the one that created the context, and mount_capable()lets it through as long as the caller has CAP_SYS_ADMIN over fc->user_ns,which anyone in an ancestor namespace does. So fc->user_ns !=current_user_ns() is something an unprivileged user can arrange.Both overlayfs and binfmt_misc WARN_ON() that. They're plain WARN_ON()s, soit can be done in a loop to taint the kernel and flood the log, and itpanics a machine booted with panic_on_warn. Keep refusing the mount, juststop warning about it. Overlayfs already spells the same check as a plainerror return in ovl_parse_param() for Opt_override_creds.And add a selftest for both cases.* patches from https://patch.msgid.link/20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.org: selftests/filesystems: test completing a context from another user namespace binfmt_misc: don't warn when the mount is completed from another user namespace ovl: don't warn when the mount is completed from another user namespaceLink: https://patch.msgid.link/20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.orgSigned-off-by: Christian Brauner (Amutable) List of files: /linux/tools/testing/selftests/filesystems/fscontext_ns/Makefile

d64ba78b749ad6bae0e9a6f40614eda1c7db2f04 - selftests/filesystems: test completing a context from another user namespace

Sun, 02 Aug 2026 20:00:45 +0200

selftests/filesystems: test completing a context from another user namespacefsopen() records the caller's user namespace in fc->user_ns and handsback an ordinary file descriptor, so the task that issuesFSCONFIG_CMD_CREATE need not be the one that created the context.mount_capable() authorizes that for a caller holding CAP_SYS_ADMIN in anancestor of fc->user_ns, which any unprivileged user has over a usernamespace it just created.binfmt_misc and overlayfs used to WARN_ON() the mismatch. Add a test forboth. Also cover the handover within one user namespace. That is asupported thing to do and has to keep working.Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-3-4e987911a39a@kernel.orgSigned-off-by: Christian Brauner (Amutable) List of files: /linux/tools/testing/selftests/filesystems/fscontext_ns/Makefile