CVE-2024-43882

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exec: Fix ToCToU between perm check and set-uid/gid usage<br /> <br /> When opening a file for exec via do_filp_open(), permission checking is<br /> done against the file&amp;#39;s metadata at that moment, and on success, a file<br /> pointer is passed back. Much later in the execve() code path, the file<br /> metadata (specifically mode, uid, and gid) is used to determine if/how<br /> to set the uid and gid. However, those values may have changed since the<br /> permissions check, meaning the execution may gain unintended privileges.<br /> <br /> For example, if a file could change permissions from executable and not<br /> set-id:<br /> <br /> ---------x 1 root root 16048 Aug 7 13:16 target<br /> <br /> to set-id and non-executable:<br /> <br /> ---S------ 1 root root 16048 Aug 7 13:16 target<br /> <br /> it is possible to gain root privileges when execution should have been<br /> disallowed.<br /> <br /> While this race condition is rare in real-world scenarios, it has been<br /> observed (and proven exploitable) when package managers are updating<br /> the setuid bits of installed programs. Such files start with being<br /> world-executable but then are adjusted to be group-exec with a set-uid<br /> bit. For example, "chmod o-x,u+s target" makes "target" executable only<br /> by uid "root" and gid "cdrom", while also becoming setuid-root:<br /> <br /> -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> becomes:<br /> <br /> -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> But racing the chmod means users without group "cdrom" membership can<br /> get the permission to execute "target" just before the chmod, and when<br /> the chmod finishes, the exec reaches brpm_fill_uid(), and performs the<br /> setuid to root, violating the expressed authorization of "only cdrom<br /> group members can setuid to root".<br /> <br /> Re-check that we still have execute permissions in case the metadata<br /> has changed. It would be better to keep a copy from the perm-check time,<br /> but until we can do that refactoring, the least-bad option is to do a<br /> full inode_permission() call (under inode lock). It is understood that<br /> this is safe against dead-locks, but hardly optimal.