Changes between v2.42.3 and v2.42.4 -------------------------------------------- commit d76cbf8f13e65ff657344f7f6a90042cf755ba59 Author: Karel Zak Date: Mon Sep 21 12:33:11 2026 +0200 build-sys: update release dates Signed-off-by: Karel Zak NEWS | 2 +- configure.ac | 2 +- meson.build | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) commit c600b65ca8662ab6c1412b15c76cac6e18640110 Author: Karel Zak Date: Mon Sep 21 12:32:48 2026 +0200 docs: add v2.42.4-ReleaseNotes Signed-off-by: Karel Zak Documentation/releases/v2.42.4-ReleaseNotes | 47 +++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) commit 44903bfd188c8d900c4e2e1ca720cd9a9fd65f51 Author: Karel Zak Date: Mon Sep 21 11:45:20 2026 +0200 po: merge changes po/ar.po | 236 +- po/ca.po | 236 +- po/cs.po | 236 +- po/da.po | 236 +- po/de.po | 236 +- po/es.po | 236 +- po/et.po | 236 +- po/eu.po | 236 +- po/fi.po | 236 +- po/fr.po | 236 +- po/gl.po | 236 +- po/hr.po | 236 +- po/hu.po | 236 +- po/id.po | 236 +- po/it.po | 236 +- po/ja.po | 236 +- po/ka.po | 236 +- po/ko.po | 236 +- po/nl.po | 9611 +++++++++++++++++++++++++++++++---------------------- po/pl.po | 236 +- po/pt.po | 236 +- po/pt_BR.po | 236 +- po/ro.po | 236 +- po/ru.po | 236 +- po/sk.po | 236 +- po/sl.po | 236 +- po/sr.po | 236 +- po/sv.po | 2215 ++++++------ po/tr.po | 236 +- po/uk.po | 236 +- po/util-linux.pot | 239 +- po/vi.po | 236 +- po/zh_CN.po | 236 +- po/zh_TW.po | 236 +- 34 files changed, 10574 insertions(+), 8807 deletions(-) commit 1344363edf1527acb2c75c872eaa5b6b902c7cd1 Author: Daniel Nylander Date: Mon Sep 21 11:45:10 2026 +0200 po: update sv.po (from translationproject.org) po/sv.po | 3779 +++++++++++++++++++++++++++----------------------------------- 1 file changed, 1626 insertions(+), 2153 deletions(-) commit cc2c03f2ea93d2ce4ec7bf055975f86105f65bdf Author: Benno Schulenberg Date: Mon Sep 21 11:45:10 2026 +0200 po: update nl.po (from translationproject.org) po/nl.po | 9630 ++++++++++++++++++++++++++------------------------------------ 1 file changed, 4017 insertions(+), 5613 deletions(-) commit 3e7ce49f1e252afb79988e97c8e1b152cafabdfc Author: Karel Zak Date: Mon Sep 21 11:45:09 2026 +0200 po-man: merge changes po-man/ar.po | 1855 +-- po-man/cs.po | 2022 +-- po-man/de.po | 1855 +-- po-man/es.po | 1930 +-- po-man/fr.po | 1832 +-- po-man/ko.po | 1993 +-- po-man/pl.po | 1855 +-- po-man/pt_BR.po | 2008 +-- po-man/ro.po | 1855 +-- po-man/sr.po | 1855 +-- po-man/sv.po | 32842 +++++++++++++++++++++++++++++++++++--------- po-man/uk.po | 1814 +-- po-man/util-linux-man.pot | 2016 +-- 13 files changed, 37635 insertions(+), 18097 deletions(-) commit eeb135325142e3860aa04065e47ea57907dd9c88 Author: Daniel Nylander Date: Mon Sep 21 11:44:56 2026 +0200 po-man: update sv.po (from translationproject.org) po-man/sv.po | 36086 +++++++++++++-------------------------------------------- 1 file changed, 7830 insertions(+), 28256 deletions(-) commit 73e4d67685b11e8b24c62dc294fd1c32d4141493 Author: Clayton Craft Date: Wed Aug 5 15:22:56 2026 -0700 libblkid: minix: don't detect erofs images as minix The erofs superblock starts at 0x400, the same offset as the minix superblock, and its inode count field overlaps the offset where minix keeps its magic. An erofs image that has an inode count which happens to equal the minix magic can be incorrectly reported as containing both filesystems, and probe fails with an ambivalent result. This can lead to e.g. so udev failing to create by-partuuid symlink for the partition. This reject a minix match when the erofs magic is present at 0x400, the same way an ext superblock is already handled in probe_minix. Fixes: #4529 (cherry picked from commit cf479ca5f61d5342d1c66952161136efbd183911) libblkid/src/superblocks/minix.c | 12 ++++++++++++ tests/expected/blkid/low-probe-erofs-minix-magic | 7 +++++++ tests/ts/blkid/images-fs/erofs-minix-magic.img.xz | Bin 0 -> 1720 bytes 3 files changed, 19 insertions(+) commit 6af82b144d157fa5cb8cadee37202c4cae0d997b Author: Karel Zak Date: Thu Jun 25 12:32:31 2026 +0200 libmount: add mnt_fs_fetch_ids() and populate uniq_id for utab Add mnt_fs_fetch_ids() helper that fetches mount IDs from the kernel via statx(). It prefers STATX_MNT_ID_UNIQUE and falls back to the old STATX_MNT_ID on older kernels. Accepts an optional fd argument; when fd < 0 it falls back to path-based lookup via fs->target. Use it in hook_create_mount() (new mount API) with fd_tree for robust fd-based ID, and in hook_mount() (legacy mount(2)) after reopen_target_fd with fd_target when available. This ensures utab entries contain UNIQID, which is needed for reliable utab merging with listmount-based tables. Signed-off-by: Karel Zak (cherry picked from commit 1cb24d37de96f32596164ce738713c0c04086044) libmount/src/context_mount.c | 4 ++-- libmount/src/fs.c | 39 +++++++++++++++++++++++++++++++++++++++ libmount/src/hook_mount.c | 4 +++- libmount/src/hook_mount_legacy.c | 2 +- libmount/src/mountP.h | 1 + 5 files changed, 46 insertions(+), 4 deletions(-) commit 481f447f214144a94646507f5652328435ec166e Author: Karel Zak Date: Thu Sep 10 09:54:41 2026 +0200 libmount: use fchmodat2() for X-mount.mode= The mount target is pinned by an O_PATH descriptor, and fchmod() returns EBADF for such a descriptor. The mode was therefore applied by chmod("/proc/self/fd/"), which needs /proc mounted and walks four procfs components to get back to the dentry we already hold. fchmodat2() (Linux 6.6) accepts AT_EMPTY_PATH. With an empty pathname the kernel does no name resolution at all -- path_init() takes the path directly from the descriptor and link_path_walk() returns immediately -- so this is fchmod() on the pinned dentry. It is also what the fchownat(AT_EMPTY_PATH) call above already does for the owner and group. Keep the /proc based chmod() as a fallback for older kernels, now using ul_fd_mkpath() for the pathname. Signed-off-by: Karel Zak (cherry picked from commit a975f85af1008f370348eae5b15f965489b57fc0) configure.ac | 1 + include/fileutils.h | 9 +++++++++ libmount/src/hook_owner.c | 23 +++++++++++++++++++---- meson.build | 1 + 4 files changed, 30 insertions(+), 4 deletions(-) commit 14077d595ecc93ab5fc2f37d95a9e68067a69dec Author: Karel Zak Date: Thu Sep 10 09:54:41 2026 +0200 libmount: restore the original namespace on error paths mnt_context_do_mount() switches to the target namespace, but it returns directly when a MNT_STAGE_MOUNT_PRE or MNT_STAGE_MOUNT_POST hook fails, so the caller is left in the target namespace. The same in is_shared_tree() when no directory is specified and in mnt_context_prepare_umount() when the helper preparation fails. Use the common exit path with mnt_context_switch_ns() in all these cases. Signed-off-by: Karel Zak (cherry picked from commit 6fd29143378bc4b19bc3e4f3430c2a00fc195c9d) libmount/src/context_mount.c | 11 +++++++---- libmount/src/context_umount.c | 5 +++-- 2 files changed, 10 insertions(+), 6 deletions(-) commit 70dae206e8fd3f7dbc8a920e1e243568943bb73f Author: Karel Zak Date: Thu Sep 10 09:54:01 2026 +0200 libmount: secure the idmapped mount replacement X-mount.idmap= on the classic mount(2) path clones the mount, applies the ID-mapping to the clone, detaches the original mount and moves the clone to the target. Two problems for non-root users: The mount at the target is another mount than the one created by mount(2), but cxt->fs still keeps the mount ID of the original mount. mnt_context_finalize_target() then verifies the re-opened target against this obsolete ID. The IDs never match, so the freshly attached idmapped mount is detached again and the mount fails with EPERM. For root the obsolete ID ends up in utab. Read the ID from the clone FD before the target is finalized, the same way as hook_create_mount() does it for the new mount API. The umount2() call resolves the target path for the second time, which is exactly what the FD pinning avoids elsewhere. Detach the mount through the /proc/self/fd/ name of the pinned target instead. The FD refers to the root of the mount we detach, so it has to be re-opened after the umount2() call, otherwise it points into the detached tree and move_mount() fails with ENOENT. Signed-off-by: Karel Zak (cherry picked from commit 4270231d9d7fb773446306142de2895074b3fb88) libmount/src/hook_idmap.c | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-) commit 85d16b341f7232c9dbb4884b632e1e956584bee9 Author: Karel Zak Date: Thu Sep 10 09:53:35 2026 +0200 libmount: pin the legacy mount target and bind/move source For non-root users prepare_target() opens the target with RESOLVE_NO_SYMLINKS and keeps the FD in the context. The new mount API attaches to that FD, but classic mount(2) accepts a path only and it resolves the path for the second time. The result does not have to be the directory we have already verified. mount(2) cannot take a FD, but it can take /proc/self/fd/. The kernel follows the magic link directly to the pinned directory, so the second path lookup is gone. mountinfo still reports the real mountpoint path, the /proc/ name is never stored anywhere. Fall back to the plain path if /proc is not available; mount(2) stays as weak as it has always been in this case, but we do not break mounts in environments without /proc. The source of a bind or move operation is a pathname resolved by mount(2) too, so a symlink in it is followed and the kernel attaches something else than the directory from fstab. Pin it with ul_open_no_symlinks() and pass /proc/self/fd/, the same way as the target. The new mount API already behaves like this for the very same operations: init_sysapi() takes the source path for MS_BIND and MS_MOVE and mnt_context_open_tree() calls open_tree() with RESOLVE_NO_SYMLINKS for restricted contexts. This only makes the classic mount(2) path consistent with it. Filesystem sources are not affected, only bind and move are pinned. A /dev/ source is not affected either, mnt_context_prepare_srcpath() canonicalizes such a path and verifies the result stays in /dev/ before we get here, so /dev/disk/by-* keeps working. Finally, drop the open-coded mount ID handling; the target finalization reads the IDs for utab when the mount operation has not provided them, which is always the case here. Signed-off-by: Karel Zak (cherry picked from commit 2c773f336134acf016e639abb6f12ba7341fe4b8) libmount/src/hook_mount_legacy.c | 78 +++++++++++++++++++++++++++++++++++++--- sys-utils/mount.8.adoc | 2 +- 2 files changed, 75 insertions(+), 5 deletions(-) commit 472cc3fb2d4d47cca7aab2e0b59eb3fb8a9359ec Author: Karel Zak Date: Thu Sep 10 09:52:51 2026 +0200 libmount: harden restricted mount targets and post-mount handling The target of a non-root mount always comes from fstab, but any component of that path may be a symlink the user controls. prepare_target() resolved it with mnt_resolve_path(), which follows symlinks with root privileges, so the mount could be redirected: fstab: /dev/sdb1 /mnt/usb vfat user,noauto 0 0 user: rmdir /mnt/usb; ln -s /etc /mnt/usb result: mount lands on /etc The RESOLVE_NO_SYMLINKS pin was useless against this, because it was applied to the already resolved path. Invert the order for non-root users: open the fstab path as it is (so a symlink anywhere in it is refused by the kernel), then read the name of the pinned directory back from /proc/self/fd/. The name is symlink free and normalized, and it is the very name the kernel later reports in mountinfo, which is what utab and non-root umount need. This also means that a symlink in the target path of an fstab entry is no longer usable by non-root users, root has to write the real path. Once the filesystem is attached the pinned FD has to be re-opened, so that it refers to the root of the new mount and not to the directory covered by it. This "re-open the target, read the mount IDs, store them to the utab entry" sequence was open-coded on more places; move it all to mnt_context_finalize_target(). The original name "reopen target fd" no longer describes what the function does, for root there is no FD to re-open at all. * The mount IDs are read only when the mount operation has not provided them. The new mount API knows them from the detached tree FD before it is attached; classic mount(2) and external mount helpers give us no handle to the new mount, so in this case the IDs are read from the new mount point. * The re-opened target is verified against the ID of the mount we have created. The comparison was done only when the second statx() succeeded, so an unexpected failure silently disabled the check. Handle it as a mismatch; the ID has already been read once for this mount, so the kernel supports it. Old kernels are unaffected, there is no ID at all and the whole verification is skipped. * On a mismatch the mount we cannot account for is detached through the /proc/self/fd/ name of the pinned target, rather than by the target path which would be resolved for the second time. This is a best effort cleanup and the FD does not make it exact -- there is no umount-by-FD in the kernel, umount2() looks up the name with LOOKUP_MOUNTPOINT and detaches the topmost mount at the resolved place, so an overmount is still removed instead of our mount. What the FD does buy us is that no symlink is resolved on the way there. Note that umount2() resolves the trailing symlink, so the /proc name works and UMOUNT_NOFOLLOW must not be used with it. * hook_attach_target() ended with "return rc == 0 ? 0 : -errno", where rc could also come from the re-open. That function returns a negative error code, not -1/errno, so a failed re-open (for example -EPERM on a mount ID mismatch) was converted to whatever errno happened to be left over -- possibly 0, turning the failure into success. Return the result directly and set errno on all error paths of the FD helpers, so the callers which use -errno keep working. do_mount() returned directly from exec_helper(), so the target FD stayed as it was pinned by prepare_target(), before anything was mounted. The MNT_STAGE_POST hooks run for a successful helper too, and the only one we have is hook_owner.c. In restricted mode it takes the cached FD, so X-mount.owner=, X-mount.group= and X-mount.mode= chown/chmod the directory which the helper has just covered instead of the root of the new filesystem. The mount point then keeps the new ownership and mode after umount, which is exactly what an unprivileged user must not be able to arrange. Finalize the target for a successful helper too. Bind and move operations done by the new mount API, where hook_create_mount() is not called, newly store the mount IDs to utab. Signed-off-by: Karel Zak (cherry picked from commit 708d1b3c51932dc5ba8082c7368187715e6a8d78) libmount/src/context.c | 132 ++++++++++++++++++++++++++++++++------- libmount/src/context_mount.c | 86 ++++++++++++++++++++++--- libmount/src/hook_idmap.c | 2 +- libmount/src/hook_mount.c | 43 +++++-------- libmount/src/hook_mount_legacy.c | 2 +- libmount/src/hook_owner.c | 6 +- libmount/src/mountP.h | 2 +- sys-utils/mount.8.adoc | 4 +- 8 files changed, 212 insertions(+), 65 deletions(-) commit 14cfec982d01c826293ead4c70d5e6a411abf82c Author: Karel Zak Date: Thu Sep 10 09:48:25 2026 +0200 lib/fileutils: add safe FD-path and no-symlink helpers Add the helpers needed to work with a pinned file descriptor instead of a pathname: * ul_fd_mkpath() composes "/proc/self/fd/". The pathname was open-coded on several places, each with its own buffer size calculation (and some of them differed); define the format and the size (UL_FDPATH_BUFSIZ) on one place only and convert the callers. * ul_fd_get_path() asks the kernel for the name of an already open file. It refuses pathnames which are not usable for open(), these are the " (deleted)" names for unlinked files and the pseudo-names for pipes, sockets, etc. The readlink() truncation is detected too; the function is used to canonicalize the pinned mount target, so a silently shortened name would be stored in the mount table and in utab. * ul_open_no_symlinks() gets a fallback for kernels without openat2(RESOLVE_NO_SYMLINKS) (Linux < 5.6). Without it all callers lose the protection; for libmount it means that mnt_context_get_target_fd() is unusable and no non-root mount works at all. The fallback opens the path and then asks the kernel for the name of the result. If any component of the path is a symbolic link then the name reported by the kernel differs from the requested path and the file descriptor is refused. A concurrent rename is detected the same way. The name always belongs to the file descriptor we return, so there is no time-of-check-to-time-of-use window between the check and the use. The path is opened with O_PATH to keep the check free of side effects (no device open, no blocking on a FIFO, ...) and the caller's flags are applied by re-opening the already verified file descriptor by its /proc/self/fd/ name. The fallback requires /proc. It also refuses "." and ".." components in the requested path as the comparison does not resolve them; such mount points are not a standard use-case and refusing them for non-root users is fine. The TEST_PROGRAM_FILEUTILS block has been moved to the end of the file so that the new static function is testable: test_fileutils --open-no-symlinks [--fallback] [--rdonly] Signed-off-by: Karel Zak (cherry picked from commit c197f0f37a5ea5ca65a48c47f98135d5d3dd9ec0) include/fileutils.h | 6 + lib/fileutils.c | 305 ++++++++++++++++++++++++++++++++++------ libmount/src/monitor_fanotify.c | 8 +- term-utils/mesg.c | 9 +- 4 files changed, 277 insertions(+), 51 deletions(-) commit 182587b6fb0b98ee4fcac884c9cbed698e0a623a Author: Karel Zak Date: Tue Sep 8 14:24:55 2026 +0200 libmount: fix X-mount.idmap ID names in code and man page The two IDs of an X-mount.idmap entry had two different sets of names. The code called them nsid/hostid, which invites reading the first one as "the ID I will see in the mount", and the man page called them id-mount/id-host and attached them to the wrong positions, claiming the first field is the ID in the new mount and the second the ID in the filesystem. It is the other way round. For an idmapped mount the kernel resolves the mapping downwards (map_id_down() in make_vfsuid()), so the ID stored in the filesystem is looked up in the first column of the map and the second column is what userspace sees through the mount: X-mount.idmap=1000:2000:1 -> file owned by 1000 on disk shows as 2000 Use the inner/outer terminology of /proc/[pid]/uid_map, unshare(1) and mount --map-users for both, and fix the man page description and example. No functional change. Addresses: https://github.com/util-linux/util-linux/issues/4608 Signed-off-by: Karel Zak (cherry picked from commit f2bfef30ded60f0a9b15d428f13f5fa5d19e4116) libmount/src/hook_idmap.c | 40 ++++++++++++++++++++++++++-------------- sys-utils/mount.8.adoc | 18 +++++++++--------- 2 files changed, 35 insertions(+), 23 deletions(-) commit ab76d580ad4467ce10e6f2df549bd2d882ababc4 Author: Karel Zak Date: Wed Jul 8 14:03:43 2026 +0200 mount: fix grammar and typo in X-mount.idmap documentation Apply grammar improvements from PR #4400 (field order change intentionally omitted as the current order matches the code). Also fix a GUID -> GID typo in the example. Signed-off-by: Karel Zak (cherry picked from commit b38324a9a4020123e8972079de51a2aed7e44c69) sys-utils/mount.8.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) commit fde56542caf5cbca449fe583cecca37d6bab71c6 Author: Karel Zak Date: Tue Sep 8 10:26:38 2026 +0200 lib/fileutils: fix RESOLVE_NO_SYMLINKS fallback value The fallback #define used 0x02, but that is RESOLVE_NO_MAGICLINKS. The correct value, as used by the kernel and glibc, is 0x04. The fallback is not dead code: no libmount source includes , and glibc provides the RESOLVE_* macros only via , which is a recent addition. On older glibc libmount then asks openat2() to block magic-links instead of symlinks. The syscall succeeds and follows the symlink, so the protection in mnt_context_open_tree(), hook_mount.c and hook_idmap.c is silently ineffective. Move the include from lib/fileutils.c to include/fileutils.h so all users get the kernel values, and correct the fallback. Fixes: b9e07ce6f ("lib/fileutils: add ul_openat_resolve() openat2 wrapper") Addresses: https://github.com/util-linux/util-linux/issues/4606 Signed-off-by: Karel Zak (cherry picked from commit 20361d66df4d3f32d5e137fe61a55cdf156c91f0) include/fileutils.h | 6 +++++- lib/fileutils.c | 4 ---- 2 files changed, 5 insertions(+), 5 deletions(-) commit c8d4919713be394015df356263e3fb44cee758ac Author: Karel Zak Date: Thu Sep 3 10:15:43 2026 +0200 tools: add non-newmount.conf config-gen profile Add a configuration profile to test builds with --disable-libmount-mountfd-support, useful for verifying that libmount compiles without the new fd-based mount API. Signed-off-by: Karel Zak (cherry picked from commit b8159405b99af7af2054f9f8222cf23901368a01) tools/config-gen.d/non-newmount.conf | 3 +++ 1 file changed, 3 insertions(+) commit 473b6a5a3adb4ba4a72ec3d391a4339f55433249 Author: Karel Zak Date: Thu Sep 3 10:01:29 2026 +0200 libmount: use USE_LIBMOUNT_MOUNTFD_SUPPORT for idmap hook The idmap hookset was originally guarded by HAVE_MOUNTFD_API (kernel headers have the new mount syscalls) rather than USE_LIBMOUNT_MOUNTFD_SUPPORT (libmount is built with mountfd support). This was intentional (commit 9040c0900, 2022) -- the idea was to keep idmap working even with --disable-libmount-mountfd-support by calling the raw open_tree() syscall directly, while using an inner #ifdef USE_LIBMOUNT_MOUNTFD_SUPPORT to optionally reuse the sysapi fd_tree. This fine-grained approach broke when the CVE-2026-78410 fix replaced the raw open_tree() call with mnt_open_tree(), which is only available under USE_LIBMOUNT_MOUNTFD_SUPPORT. The build fails with --disable-libmount-mountfd-support because mnt_open_tree() is undeclared. Rather than maintaining two code paths for a feature that fundamentally depends on the new mount API, gate the entire idmap hookset on USE_LIBMOUNT_MOUNTFD_SUPPORT -- consistent with how hookset_mount is guarded. Remove the now-redundant inner #ifdef. Also add a note to mount.8 that X-mount.idmap requires the new fd-based mount API. Addresses: https://github.com/util-linux/util-linux/issues/4598 Signed-off-by: Karel Zak (cherry picked from commit e06799ac325a881a297d2ffd6fe568cacdcd00ab) libmount/src/hook_idmap.c | 6 ++---- libmount/src/hooks.c | 2 +- libmount/src/version.c | 2 +- sys-utils/mount.8.adoc | 1 + 4 files changed, 5 insertions(+), 6 deletions(-) commit 67fd3bf434299c701c9361dca509d752e220ea7f Author: Karel Zak Date: Thu Sep 3 09:45:29 2026 +0200 lib/fileutils: fix unused parameter warnings without SYS_openat2 On systems without SYS_openat2 (older kernels), ul_openat_resolve() is a stub that returns -ENOSYS, making all parameters unused. With -Werror=unused-parameter this breaks the build. Move the #ifdef around the whole function so each branch has its own declaration — the SYS_openat2 branch uses all parameters normally, the fallback branch marks them __unused__. Fixes: fb8e26535 ("libmount: pin source path with openat2() for restricted users") Signed-off-by: Karel Zak (cherry picked from commit a471b62e732a491f1abe42450352fb0f9b5b43ea) lib/fileutils.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) commit 286dd3ff41526b582ef48830de239dffbaa61f90 Author: Karel Zak Date: Thu Sep 3 12:17:14 2026 +0200 nsenter: close cgroup.procs fd after join to prevent authority leak [CVE-2026-78408] The --join-cgroup option opens the target's cgroup.procs while running as root and writes nsenter's own PID to migrate itself. The descriptor was left open across subsequent namespace transitions, credential drops (setgroups/setgid/setuid) and execve(). The kernel performs cgroup migration permission checks using the credentials captured at open time (file->f_cred). An open cgroup.procs descriptor therefore carries the opener's migration authority regardless of later privilege changes. A program executed inside the target namespace inherits root's cgroup migration capability even when running as an unprivileged user with no capabilities. Fix this by: - closing the temporary /proc/PID/cgroup fd after reading the path - adding O_CLOEXEC to the cgroup.procs open as defense in depth - closing cgroup_procs_fd immediately after the self-migration write - initializing the temporary cgroup fd to -1 instead of 0 to avoid accidentally closing stdin via open_target_fd() The descriptor has no legitimate use after the single migration write. Introduced-by: b40650b71a74 ("nsenter: add option -c to join the cgroup of target process") References: b0cf1cf0d255 ("nsenter: close cgroup.procs fd after join to prevent authority leak") Signed-off-by: Karel Zak (cherry picked from commit afe067c979b9ba2cbe856f7c6411210120ea62aa) sys-utils/nsenter.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) commit a323dddbcd1ed05a10e7e870b3e1a48b4ed44a43 Author: Karel Zak Date: Wed Sep 2 13:32:27 2026 +0200 libmount: add missing fileutils.h include to hook_idmap.c The hook_idmap.c uses RESOLVE_NO_SYMLINKS (added by commit fb8e26535) but does not include fileutils.h, which provides the fallback #define for this constant. On Fedora (glibc 2.40+), this is masked because glibc's transitively includes , which defines RESOLVE_NO_SYMLINKS. On Ubuntu (and other distros with older glibc), does not pull in openat2.h, so the build fails: hook_idmap.c:335:33: error: 'RESOLVE_NO_SYMLINKS' undeclared Fixes: fb8e26535 ("libmount: pin source path with openat2() for restricted users") Signed-off-by: Karel Zak (cherry picked from commit 7e2e010874b10b3aabdc3c4c844c9ffc46a4a374) libmount/src/hook_idmap.c | 1 + 1 file changed, 1 insertion(+)