CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43882 – exec: Fix ToCToU between perm check and set-uid/gid usage
https://notcve.org/view.php?id=CVE-2024-43882
In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. • https://git.kernel.org/stable/c/d5c3c7e26275a2d83b894d30f7582a42853a958f https://git.kernel.org/stable/c/368f6985d46657b8b466a421dddcacd4051f7ada https://git.kernel.org/stable/c/15469d46ba34559bfe7e3de6659115778c624759 https://git.kernel.org/stable/c/9b424c5d4130d56312e2a3be17efb0928fec4d64 https://git.kernel.org/stable/c/f6cfc6bcfd5e1cf76115b6450516ea4c99897ae1 https://git.kernel.org/stable/c/d2a2a4714d80d09b0f8eb6438ab4224690b7121e https://git.kernel.org/stable/c/90dfbba89ad4f0d9c9744ecbb1adac4aa2ff4f3e https://git.kernel.org/stable/c/f50733b45d865f91db90919f8311e2127 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43879 – wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
https://notcve.org/view.php?id=CVE-2024-43879
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. • https://git.kernel.org/stable/c/c4cbaf7973a794839af080f13748335976cf3f3f https://git.kernel.org/stable/c/45d20a1c54be4f3173862c7b950d4468447814c9 https://git.kernel.org/stable/c/b289ebb0516526cb4abae081b7ec29fd4fa1209d https://git.kernel.org/stable/c/2e201b3d162c6c49417c438ffb30b58c9f85769f https://git.kernel.org/stable/c/576c64622649f3ec07e97bac8fec8b8a2ef4d086 https://git.kernel.org/stable/c/16ad67e73309db0c20cc2a651992bd01c05e6b27 https://git.kernel.org/stable/c/67b5f1054197e4f5553047759c15c1d67d4c8142 https://git.kernel.org/stable/c/19eaf4f2f5a981f55a265242ada2bf92b • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43872 – RDMA/hns: Fix soft lockup under heavy CEQE load
https://notcve.org/view.php?id=CVE-2024-43872
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler. • https://git.kernel.org/stable/c/a5073d6054f75d7c94b3354206eec4b804d2fbd4 https://git.kernel.org/stable/c/06580b33c183c9f98e2a2ca96a86137179032c08 https://git.kernel.org/stable/c/2fdf34038369c0a27811e7b4680662a14ada1d6b •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43871 – devres: Fix memory leakage caused by driver API devm_free_percpu()
https://notcve.org/view.php?id=CVE-2024-43871
In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). • https://git.kernel.org/stable/c/ff86aae3b4112b85d2231c23bccbc49589df1c06 https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85 https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85 https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96 https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701 https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43867 – drm/nouveau: prime: fix refcount underflow
https://notcve.org/view.php?id=CVE-2024-43867
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcount underflow Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5) • https://git.kernel.org/stable/c/ab9ccb96a6e6f95bcde6b8b2a524370efdbfdcd6 https://git.kernel.org/stable/c/3bcb8bba72ce89667fa863054956267c450c47ef https://git.kernel.org/stable/c/906372e753c5027a1dc88743843b6aa2ad1aaecf https://git.kernel.org/stable/c/16998763c62bb465ebc409d0373b9cdcef1a61a6 https://git.kernel.org/stable/c/ebebba4d357b6c67f96776a48ddbaf0060fa4c10 https://git.kernel.org/stable/c/f23cd66933fe76b84d8e282e5606b4d99068c320 https://git.kernel.org/stable/c/2a1b327d57a8ac080977633a18999f032d7e9e3f https://git.kernel.org/stable/c/a9bf3efc33f1fbf88787a277f73494592 •