Hi,

On Fri, Sep 04, 2026 at 06:38:13PM +0100, Sam James wrote: +util-linux 2.42.3 Release Notes +=============================== + +Security fixes: [...] + CVE-2026-78408 - nsenter(1), unshare(1) file descriptor leak. + File descriptors in nsenter and unshare were not created with + OCLOEXEC, potentially leaking them across exec. Added OCLOEXEC + as defense in depth. Note this needs a followup fix in the stable branches: https://github.com/util-linux/util-linux/commit/286dd3ff41526b582ef48830de239dffbaa61f90

Regards, Salvatore

util-linux versions through 2.41.5 and 2.42.2 fail to check mount helper exit status before running post-mount hooks, allowing unprivileged users to execute privileged operations on pre-existing filesystems. Attackers can exploit X-mount.idmap or X-mount.owner hooks to clone filesystems with inherited suid bits or modify target inode permissions after a helper fails, achieving privilege escalation.

A flaw was found in util-linux. Restricted bind mounts take the source path from fstab but do not pin that source before the privileged mount. A local unprivileged user who can replace the authorized source or a writable ancestor can redirect SUID mount(8) to bind another host directory. If the fstab entry also sets X-mount.owner, X-mount.group, or X-mount.mode, root then changes ownership or mode on that redirected inode.

Restricted-user bind/rbind mounts authorize the source from /etc/fstab but do not pin that source inode before the privileged mount. libmount later opens the source as a pathname via opentree(ATFDCWD, source, OPENTREECLONE|...) (mntcontextopentree in context.c / hookmount.c). A local unprivileged user who can replace the fstab bind source or a writable ancestor with a symlink can redirect SUID mount(8) to bind an attacker-selected host directory. When the same fstab entry includes X-mount.owner=, X-mount.group=, or X-mount.mode=, hookowner.c then applies root-privileged fchownat()/chmod() to the mounted root, which for a bind mount is the redirected source inode. This is a source-side pathname TOCTOU; current HEAD already pins the target and uses fd-based owner hooks (the CVE-2026-53612 target-path fix), but that fd now refers to the attacker-redirected bind source. Distinct from the public loop backing-file TOCTOU and from CVE-2026-76642 (failed external helper still running post-hooks). X-mount.owner/group/mode was introduced with v2.39; no upstream fix as of 2026-08-24. Reported upstream by Alex0Young. GHSA-rh77-686x-2f2m.

libmount's X-mount.subdir option on Linux >= 6.15 uses a detached-tree fast path (hooksubdir.c / hookmount.c). The configured subdirectory string is passed to opentree() with ATSYMLINKNOFOLLOW, but that flag does not block intermediate-component symlinks and does not provide RESOLVEBENEATH-style containment. An unprivileged user with an fstab-authorized X-mount.subdir= entry can therefore resolve outside the newly mounted filesystem (for example via an intermediate symlink to /etc, or via procfs self/root) and attach a host path at the fstab mountpoint. Restricted-user SUID mount(8) reproduction requires Linux >= 6.15; current HEAD gates that detached path on that kernel version. Introduced by ae19f7546ccb (2025-04-15); first released in util-linux v2.42. Affects v2.42 through v2.42.2 and current master. No upstream fix as of 2026-08-24. Reported upstream by Alex0Young. GHSA-8f2p-47x3-43mv.

libmount's X-mount.subdir option on Linux >= 6.15 uses a detached-tree fast path (hooksubdir.c / hookmount.c). The configured subdirectory string is passed to opentree() with ATSYMLINKNOFOLLOW, but that flag does not block intermediate-component symlinks and does not provide RESOLVEBENEATH-style containment. An unprivileged user with an fstab-authorized X-mount.subdir= entry can therefore resolve outside the newly mounted filesystem (for example via an intermediate symlink to /etc, or via procfs self/root) and attach a host path at the fstab mountpoint. Restricted-user SUID mount(8) reproduction requires Linux >= 6.15; current HEAD gates that detached path on that kernel version. Introduced by ae19f7546ccb (2025-04-15); first released in util-linux v2.42. Affects v2.42 through v2.42.2 and current master. No upstream fix as of 2026-08-24. Reported upstream by Alex0Young. GHSA-8f2p-47x3-43mv.

nsenter --join-cgroup (sys-utils/nsenter.c) opens the target cgroup v2 cgroup.procs while still running as root, writes nsenter's own PID to join that cgroup, and then leaves the descriptor open across later namespace/credential transitions and execve(). The FD is neither closed nor marked OCLOEXEC. Linux performs later cgroup migration checks using the credentials captured in file->fcred at open time, so a program executed inside an attacker-controlled target inherits root's cgroup-migration authority even after dropping to an unprivileged UID with no capabilities. A privileged operator must invoke the documented --join-cgroup operation against the attacker-controlled target (nsenter is not SUID on typical distros). After the FD is inherited, an unprivileged process can migrate an unrelated host root PID into an attacker-owned systemd user-service cgroup and terminate it via cgroup.kill. This is not an autonomous LPE. Introduced by b40650b71a74 (2023-06-28); first released in util-linux v2.40. Affects v2.40 through v2.42.2 and current master (confirmed on Debian 13 util-linux 2.41-5). No upstream fix as of 2026-08-24. Reported upstream by 4drez. GHSA-55fx-f4gg-cfhj.

nsenter --join-cgroup (sys-utils/nsenter.c) opens the target cgroup v2 cgroup.procs while still running as root, writes nsenter's own PID to join that cgroup, and then leaves the descriptor open across later namespace/credential transitions and execve(). The FD is neither closed nor marked OCLOEXEC. Linux performs later cgroup migration checks using the credentials captured in file->fcred at open time, so a program executed inside an attacker-controlled target inherits root's cgroup-migration authority even after dropping to an unprivileged UID with no capabilities. A privileged operator must invoke the documented --join-cgroup operation against the attacker-controlled target (nsenter is not SUID on typical distros). After the FD is inherited, an unprivileged process can migrate an unrelated host root PID into an attacker-owned systemd user-service cgroup and terminate it via cgroup.kill. This is not an autonomous LPE. Introduced by b40650b71a74 (2023-06-28); first released in util-linux v2.40. Affects v2.40 through v2.42.2 and current master (confirmed on Debian 13 util-linux 2.41-5). No upstream fix as of 2026-08-24. Reported upstream by 4drez. GHSA-55fx-f4gg-cfhj.

A flaw was found in the libblkid library of util-linux. During nested partition probing, the BSD, Minix, Solaris x86, and UnixWare partition probers cache a raw pointer to a parent partition entry in a dynamically allocated array. When subsequent partition additions cause the array to be reallocated, this pointer becomes stale, leading to a heap use-after-free read. An attacker who can present a crafted block device image (for example, via USB insertion or a loop-mounted disk image) can trigger this flaw without user interaction, as libblkid is invoked automatically by udev/udisks as root on block-device hot-plug events. This could lead to limited information disclosure or denial of service.

A heap use-after-free vulnerability was found in libblkid's nested partition probing code in util-linux. The probebsdpt() function in libblkid/src/partitions/bsd.c caches a blkidpartition parent pointer into the partlist's heap-allocated parts[] array, then loops calling blkidpartlistaddpartition(), which may reallocarray() the same array. After reallocation, the stale parent pointer is dereferenced via blkidpartitiongetstart() — an 8-byte heap use-after-free read. The same dangling-pointer pattern exists in the minix, solarisx86, and unixware nested probers.

A crafted 2 MiB DOS/MBR disk image with three BSD-typed primaries (each holding >=16 slices) plus an md-raid 0.90 superblock triggers the issue via stock blkid -p. libblkid runs as root via udev/udisks on every block-device hot-plug event.

Upstream fix: https://github.com/util-linux/util-linux/commit/c0186f14fbdb02f64c8e0ba701ce727ea764ff4c

A flaw was found in util-linux. Improper hostname canonicalization in the login(1) utility, when invoked with the -h option, can modify the supplied remote hostname before setting PAMRHOST. A remote attacker could exploit this by providing a specially crafted hostname, potentially bypassing host-based Pluggable Authentication Modules (PAM) access control rules that rely on fully qualified domain names. This could lead to unauthorized access.

Summary: Improper hostname canonicalization in util-linux login(1) when invoked with -h can modify the supplied remote hostname before setting PAMRHOST, potentially allowing bypass of host-based PAM access control rules (e.g., pamaccess) that rely on fully qualified domain names.

Requirements to exploit: An attacker must be able to access a remote login pathway that invokes login(1) with the -h <remotehost> option (e.g., telnet/rlogin-style daemons or custom wrappers). The target system must use PAM modules relying on PAMRHOST for authorization decisions (such as pamaccess) and have rules that distinguish between FQDNs and short hostnames. The local system hostname must share the same domain suffix as the attacker-supplied hostname.

A flaw was found in util-linux. Heap buffer overread when processing 256-byte usernames. Affects any SUID login-utils utility writing to password database. The setpwnam() function allocates a 256-byte buffer but accesses linebuf[256] when username length equals 256, causing a heap buffer overread.

A flaw was found in util-linux. Heap buffer overread when processing 256-byte usernames. Affects any SUID login-utils utility writing to password database. The setpwnam() function allocates a 256-byte buffer but accesses linebuf[256] when username length equals 256, causing a heap buffer overread.

Here is the fourth Landlock newsletter!

Official website: https://landlock.io Previews newsletter: https://lore.kernel.org/landlock/d4ed5733-d07b-5548-2534-a63e22906778 () digikod net

Articles and conferences ------------------------

We wrote a detailed article about Landlock explaining the underlying concepts, the implementation, and the community: https://landlock.io/talks/2024-06-06landlock-article.pdf This was written for the SSTIC conference: https://www.sstic.org/2024/presentation/landlock-design/

I did a workshop at the Pass the Salt conference to explain how to mitigate security vulnerabilities with Landlock (demonstrated with ImageMagick): https://cfp.pass-the-salt.org/pts2024/talk/8FVYDF/ Related materials are freely available to do it at home: https://github.com/landlock-lsm/workshop-imagemagick

Arto Niemi published a "Survey of Real-World Process Sandboxing" at the Conference of Open Innovations Association (FRUCT): https://fruct.org/publications/volume-35/fruct35/files/Niem.pdf Their conclusion: "[...] we found Landlock and minijail [which uses Landlock] to be relatively convenient from a developer perspective. In general, process self-containment and process-wrapping seems to be an order of magnitude easier to configure than MAC policies."

Researchers from University of Bergamo gave a talk at ASIA CCS conference about Cage4Deno: A Fine-Grained Sandbox for Deno Subprocesses (leveraging Landlock) https://cs.unibg.it/seclab-papers/2023/ASIACCS/paper/cage4deno.pdf They also gave a talk at the RAID conference about NatiSand: Native Code Sandboxing for JavaScript Runtimes (leveraging Landlock) https://cs.unibg.it/seclab-papers/2023/RAID/natisand.pdf

Eric Leblond gave a talk (in French) at the SSTIC conference about sandboxing with Landlock to mitigate real world security issues: https://www.sstic.org/2023/presentation/attaquesupplychainsuricata/

Günther Noack will give a talk at LSS Europe about Landlock and the new IOCTL support: https://sched.co/1ebVW

I'll give a talk at OSS Europe to better explain sandboxing with Landlock: https://sched.co/1ej3a

The XZ backdoor ---------------

XZ Utils is a widely used compression tool and library. The main maintainer implemented sandboxing with Landlock, and released a new version 5.6.0 with this feature. In March 2024, a backdoor was found and reported. It was introduced in February by a new maintainer who earned this trust after more than two years of effort.

Among the malicious changes, the attacker disabled Landlock's support for XZ Utils and released a new version 5.6.1: https://research.swtch.com/xz-timeline The sabotaged configuration check has since been fixed with version 5.6.2, but this effort to stealthily disable sandboxing is a clear sign that Landlock disturbs attackers: https://github.com/tukaani-project/xz/commit/f9cf4c05edd1

Merged kernel features ----------------------

Linux 6.7 (Landlock ABI 4) supports initial network access control with the LANDLOCKACCESSNETBINDTCP and LANDLOCKACCESSNETCONNECTTCP rights thanks to Konstantin Meskhidze. We can now control inbound and outbound TCP connections according to the source or the destination port. This led to kernel code refactoring which opens the way to more network protocol support. See user space documentation: https://docs.kernel.org/userspace-api/landlock.html#network-flags

Linux 6.10 (Landlock ABI 5) supports IOCTL control with the new LANDLOCKACCESSFSIOCTLDEV right thanks to Günther Noack. This restriction only applies to IOCTL commands implemented by device drivers (i.e. block or character devices). As other file system access rights, this can be used to only allow such IOCTL commands on a specified set of file hierarchies per sandbox. See user space documentation: https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags

We also added a slight change in all supported kernels to inform system administrators (with kernel logs) how they can configure the system to support Landlock, if a process tried to sandbox itself on a kernel where Landlock is disabled. New documentation will help enable Landlock on systems when it is not already the case: https://docs.kernel.org/userspace-api/landlock.html#kernel-support

Since Linux 6.3, we improved documentation and kselftests (user space testing), and added support for KUnit (kernel testing). Part of this work lead us to support the UML architecture to easily run application tests in a CI against different kernel versions. With this support we can make sure that backward compatibility works fine for the tested applications. I encourage to take a look at landlock-test-tools and the GitHub CI configuration for the Rust library: https://github.com/landlock-lsm/landlock-test-tools https://github.com/landlock-lsm/rust-landlock/blob/main/.github/workflows/rust.yml#L166-L179

Roadmap and ongoing development -------------------------------

We created GitHub issues to track ongoing and future work: https://github.com/landlock-lsm/linux/issues https://github.com/orgs/landlock-lsm/projects/1

Feel free to reach out if you want to contribute! https://github.com/landlock-lsm/linux/contribute

We also plan to improve the website with extended documentation and examples.

Kernel development highlights -----------------------------

Günther Noack is now an official reviewer of Landlock! https://git.kernel.org/torvalds/c/5bf9e57e634b After the IOCTL feature, he is now working on improving the documentation, including man pages.

Mikhail Ivanov is working on socket type control. This is an important feature that will make it possible to create sandboxes without any network access, except for an explicit list of allowed protocols. This will nicely complement the TCP port control (and future ones for other protocols): https://github.com/landlock-lsm/linux/issues/6 He is also working on controlling TCP listen calls: https://github.com/landlock-lsm/linux/issues/15

Tahera Fahimi was selected as an Outreachy intern to work on IPC restrictions (e.g. abstract unix socket, signals) to better isolate a Landlock domain: https://github.com/landlock-lsm/linux/issues/7 https://github.com/landlock-lsm/linux/issues/8

I'm working on bringing audit support to Landlock: https://github.com/landlock-lsm/linux/issues/3

Landlock libraries ------------------

As explained by Günther Noack, the Go library now supports TCP and IOCTL restrictions: https://blog.gnoack.org/post/landlock-v4/ https://blog.gnoack.org/post/landlock-ioctl/

A new version of the Rust crate was released, with support for TCP control and some miscellaneous improvements: https://github.com/landlock-lsm/rust-landlock/releases/tag/v0.4.0

Please update your dependencies and use the latest Landlock ABI version for improved sandboxing.

We are also working on a new minimal C library: https://github.com/landlock-lsm/linux/issues/38

New Landlock user space supports --------------------------------

Firejail 0.9.74 (sandboxer) will be able to use landlock: https://github.com/netblue30/firejail/pull/6078

setpriv 2.40 (sandboxer): https://github.com/util-linux/util-linux/pull/2628

extrasafe 0.4.0 (sandbox library): https://github.com/boustrophedon/extrasafe/pull/28

bevymodlockdown (sandbox library): https://github.com/FrTerstappen/bevymodlockdown

Cloud Hypervisor (VM monitor) will be sandboxed with Landlock: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/6214

Ukuleleweb (wiki server): https://github.com/gnoack/ukuleleweb/commit/0ecdd54b36fa

websrv 3.2.0 (web server): https://github.com/ngergs/websrv/commit/40fa2d7d2bbb

egress-eddie 0.5.0 (network filtering): https://github.com/capnspacehook/egress-eddie/releases/tag/v0.5.0

Suricata 7.0.0 (network security monitoring engine): https://docs.suricata.io/en/latest/configuration/landlock.html

sslh 2.1.0 (protocol multiplexer): https://lore.kernel.org/landlock/Zfq6f30spnYCx9Y () rutschle net/ https://github.com/yrutschle/sslh/releases/tag/v2.1.0

wireproxy 1.0.8 (Wireguard client): https://github.com/pufferffish/wireproxy/pull/108

Emilua 0.5.0 (Lua runtime): https://lore.kernel.org/landlock/CAK9RveLxro4zUG4jfFB=UNgcv5gdc8JuzNhMt=YbNhH=35ADzg () mail gmail com/ https://docs.emilua.org/api/0.5/changelog.html

Polkadot (blockchain SDK): https://github.com/paritytech/polkadot/pull/7303

XZ Utils 5.6.2 (archive manager): https://github.com/tukaani-project/xz/commit/374868d81d47

Zathura (document viewer) will be sandboxed with Landlock: https://github.com/pwmt/zathura/pull/575

Pacman 7.0.0 (Arch Linux's package manager): https://gitlab.archlinux.org/pacman/pacman/-/mergerequests/167

Thanks to all contributors!

Regards, Mickaël

The following vulnerability in util-linux was announced (taken from http://seclists.org/oss-sec/2015/q3/423):

""" If the chfn and chsh binaries (both setuid-root) from util-linux/login-utils are compiled WITHOUT libuser support, they eventually call mkostemp(localtmp, ORDWR|OCREAT|OEXCL|OCLOEXEC); where localtmp is "/etc/%s.XXXXXX" and %s is progname (i.e., argv[0]'s basename).

An attacker could repeatedly execve chfn as "ld.so" until mkostemp() creates "/etc/ld.so.preload" (after a few days, in our tests). This particular example doesn't actually work, because "preload" is 7 chars and "XXXXXX" is 6 chars, but it seems there are other interesting possibilities, like "/etc/rc.status" and "/etc/krb5.keytab".

The impact of this vulnerability is probably very limited: most Linux distributions ship either the chfn/chsh binaries from the shadow-utils (NOT the login-utils ones), or the login-utils ones but WITH libuser support. """

Upstream patch: https://github.com/karelzak/util-linux/commit/bde91c85bdc77975155058276f99d2e0f5eab5a9

Dan Rosenberg reported a flaw with suid mount helpers handle access to /etc/mtab [1], which could allow an unprivileged user to corrupt /etc/mtab and possibly manipulate mountpoint options or unmount a filesystem.

The original report follows.

This was originally sent to the now-defunct vendor-sec mailing list. Seeing how it's a relatively low-severity issue and that we're currently lacking a mechanism for coordination among package maintainers and vendors, this list seems like a perfectly acceptable venue for discussing how to fix it.

I discovered that essentially every suid mount helper that uses addmntent() (or invokes util-linux mount, which in turn calls addmntent()) to add entries to /etc/mtab fails to anticipate a low value for RLIMITFSIZE, allowing unprivileged users to corrupt /etc/mtab and possibly manipulate mountpoint options. Affected software includes at least:

mount.cifs (samba) fusermount (FUSE) mount (util-linux) ncpmount (ncpfs) vmware-hgfsmounter (open-vm-tools)

Also affected are all their unmount equivalents.

This can be exploited by checking the current size of /etc/mtab, setting an RLIMITFSIZE of some small amount greater than that, and invoking a suid mount helper. The edits to /etc/mtab will be truncated to the ulimit and no newline will be appended, so multiple invocations allow near-arbitrary appending to /etc/mtab. addmntent() will octal-encode most special characters, which makes exploitation beyond simple corruption not quite as straightforward, but I'm confident that with some creativity it would be possible to perform unauthorized unmounting, for example.

There are a few possible options We could patch glibc to try to raise the rlimit in addmntent(). Or we could fix every suid mount helper to raise the rlimit or have proper error handling for the case when addmntent() fails. This final option requires that mtab editing be done in a temporary file and aborted on failure, which isn't the case for all helpers.

Of course, once we figure out how to fix this, we can talk about assigning CVEs, etc.

And a followup regarding specific mount helpers:

I did a survey of some suid helpers I'm aware of. Here's the existing behavior:

util-linux mount ============= Edits /etc/mtab.tmp with custom myaddmntent(), behaves identically to glibc addmntent() in terms of return code Succeeds on partial writes, does not remove temp file on failure (could result in additional corruption of /etc/mtab through multiple invocations), does not remove lock file /etc/mtab~ on failure (also an issue)

fusermount (FUSE) ================ Does not edit mtab directly, calls into util-linux mount/umount, no changes needed

mount.cifs (samba) ================ mount.cifs edits /etc/mtab directly, no cleanup on addmntent() failure umount.cifs edits /etc/mtab.tmp but does not check return code of addmntent()

ncpmount (ncpfs) ============== ncpmount edits /etc/mtab directly, no cleanup on failure, does not remove lock file /etc/mtab~ on failure ncpumount edits /etc/mtab.tmp but does not check return code of addmntent()

vmware-hgfsmounter (open-vm-tools) =============================== edits /etc/mtab directly, no cleanup on failure

Further discussion is ongoing via the oss-security mailing list.

[1] http://thread.gmane.org/gmane.comp.security.oss.general/4374

A system is running a version of software that was replaced with a Trojan Horse at one of its distribution points, such as (1) TCP Wrappers 7.6, (2) util-linux 2.9g, (3) wuarchive ftpd (wuftpd) 2.2 and 2.1f, (4) IRC client (ircII) ircII 2.2.9, (5) OpenSSH 3.4p1, or (6) Sendmail 8.12.6.