CVE-2026-89560

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation<br /> <br /> Whiteout objects are used in the upper layer of an OverlayFS to<br /> indicate that the file with this name does not exist in the unified<br /> view, even if it is present in one of the lower layer file systems.<br /> <br /> For the userspace implementations of OverlayFS (fuse-overlayfs),<br /> whiteout objects can be created from userspace as well:<br /> <br /> * mknod(2) with S_IFCHR and makedev(0, 0)<br /> * renameat2(2) with RENAME_WHITEOUT,<br /> creating the whiteout in the old place of the moved file.<br /> <br /> This commit guards whiteout creation in both of these cases with<br /> LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered<br /> character devices and are not bound to a driver.<br /> <br /> LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a<br /> whiteout object: creating one is the only S_IFCHR creation that the VFS<br /> exempts from CAP_MKNOD, so it is as unprivileged as creating a regular<br /> file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and<br /> LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that<br /> expose a kernel interface [1].<br /> <br /> For the mknod(2) case, introduce a Landlock erratum. The creation of<br /> whiteout objects through mknod(2) was previously guarded using<br /> LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using<br /> LANDLOCK_ACCESS_FS_MAKE_REG.<br /> <br /> For the renameat2(2) case, fix a bug: Before this commit, renameat2(2)<br /> with RENAME_WHITEOUT would create a directory entry even when all<br /> LANDLOCK_ACCESS_FS_MAKE_* rights were denied.<br /> <br /> This does not affect normal renames within layered OverlayFS mounts:<br /> When doing a regular rename() on a mounted fuse-overlayfs, it is the<br /> fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT,<br /> and only the Landlock domain of that daemon is checked there.<br /> <br /> Depends-on: 49c9e09d9610 ("landlock: Fix handling of disconnected directories")<br /> Depends-on: fe72ce6710cb ("landlock: Add errata documentation section")<br /> [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and<br /> add link(2) to the user doc]