{"id":21482,"date":"2026-09-12T04:31:14","date_gmt":"2026-09-11T20:31:14","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89560"},"modified":"2026-09-12T04:31:14","modified_gmt":"2026-09-11T20:31:14","slug":"cve-2026-89560","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89560","title":{"rendered":"CVE-2026-89560 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Require LAN"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation<\/p>\n<p>Whiteout objects are used in the upper layer of an OverlayFS to<br \/>\nindicate that the file with this name does not exist in the unified<br \/>\nview, even if it is present in one of the lower layer file systems.<\/p>\n<p>For the userspace implementations of OverlayFS (fuse-overlayfs),<br \/>\nwhiteout objects can be created from userspace as well:<\/p>\n<p>* mknod(2) with S_IFCHR and makedev(0, 0)<br \/>\n* renameat2(2) with RENAME_WHITEOUT,<br \/>\n  creating the whiteout in the old place of the moved file.<\/p>\n<p>This commit guards whiteout creation in both of these cases with<br \/>\nLANDLOCK_ACCESS_FS_MAKE_REG.  Whiteout objects are *not* considered<br \/>\ncharacter devices and are not bound to a driver.<\/p>\n<p>LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a<br \/>\nwhiteout object: creating one is the only S_IFCHR creation that the VFS<br \/>\nexempts from CAP_MKNOD, so it is as unprivileged as creating a regular<br \/>\nfile, while LANDLOCK_ACCESS_FS_MAKE_CHAR and<br \/>\nLANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that<br \/>\nexpose a kernel interface [1].<\/p>\n<p>For the mknod(2) case, introduce a Landlock erratum.  The creation of<br \/>\nwhiteout objects through mknod(2) was previously guarded using<br \/>\nLANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using<br \/>\nLANDLOCK_ACCESS_FS_MAKE_REG.<\/p>\n<p>For the renameat2(2) case, fix a bug: Before this commit, renameat2(2)<br \/>\nwith RENAME_WHITEOUT would create a directory entry even when all<br \/>\nLANDLOCK_ACCESS_FS_MAKE_* rights were denied.<\/p>\n<p>This does not affect normal renames within layered OverlayFS mounts:<br \/>\nWhen doing a regular rename() on a mounted fuse-overlayfs, it is the<br \/>\nfuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT,<br \/>\nand only the Landlock domain of that daemon is checked there.<\/p>\n<p>Depends-on: 49c9e09d9610 (&#8220;landlock: Fix handling of disconnected directories&#8221;)<br \/>\nDepends-on: fe72ce6710cb (&#8220;landlock: Add errata documentation section&#8221;)<br \/>\n[mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and<br \/>\nadd link(2) to the user doc]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation<\/p>\n<p>Whiteout objects are used in the upper layer of an OverlayFS t<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21482","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21482","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21482"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21482"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21482"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}