CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50010 – exec: don't WARN for racy path_noexec check
https://notcve.org/view.php?id=CVE-2024-50010
In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move S_ISREG() check earlier") 0fd338b2d2cd ("exec: move path_noexec() check earlier") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check] • https://git.kernel.org/stable/c/d62ba2a5536df83473a2ac15ab302258e3845251 https://git.kernel.org/stable/c/0d196e7589cefe207d5d41f37a0a28a1fdeeb7c6 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50009 – cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value
https://notcve.org/view.php?id=CVE-2024-50009
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/5f250d44b8191d612355dd97b89b37bbc1b5d2cb https://git.kernel.org/stable/c/5493f9714e4cdaf0ee7cec15899a231400cb1a9f •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50008 – wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()
https://notcve.org/view.php?id=CVE-2024-50008
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan->tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex] • https://git.kernel.org/stable/c/1756918f51e9ab247a0f4782cc28853c2bb457c1 https://git.kernel.org/stable/c/e59bdb1ba594104cd0ee0af3ee9e4435d842a8fe https://git.kernel.org/stable/c/17199b69a84798efffc475040fbef44374ef1de1 https://git.kernel.org/stable/c/fef7b51f22cf2049b0ca6740adeb0ba6f2e671dc https://git.kernel.org/stable/c/71267bd4e8c752d7af6c6b96bb83984a6a95273d https://git.kernel.org/stable/c/a3a12c30f9510f3753286fadbc6cdb7dad78c1d5 https://git.kernel.org/stable/c/498365e52bebcbc36a93279fe7e9d6aec8479cee •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50007 – ALSA: asihpi: Fix potential OOB array access
https://notcve.org/view.php?id=CVE-2024-50007
In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size. • https://git.kernel.org/stable/c/219587bca2678e31700ef09ecec178ba1f735674 https://git.kernel.org/stable/c/36ee4021bcc37b834996e79740d095d6f8dd948f https://git.kernel.org/stable/c/e658227d9d4f4e122d81690fdbc0d438b10288f5 https://git.kernel.org/stable/c/7a55740996701f7b2bc46dc988b60ef2e416a747 https://git.kernel.org/stable/c/ad7248a5e92587b9266c62db8bcc4e58de53e372 https://git.kernel.org/stable/c/876d04bf5a8ac1d6af5afd258cd37ab83ab2cf3d https://git.kernel.org/stable/c/7b986c7430a6bb68d523dac7bfc74cbd5b44ef96 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50006 – ext4: fix i_data_sem unlock order in ext4_ind_migrate()
https://notcve.org/view.php?id=CVE-2024-50006
In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add • https://git.kernel.org/stable/c/53b1999cfd2c7addf2e581a32865fe8835467b44 https://git.kernel.org/stable/c/ef05572da0c0eb89614ed01cc17d3c882bdbd1ff https://git.kernel.org/stable/c/9fedf51ab8cf7b69bff08f37fe0989fec7f5d870 https://git.kernel.org/stable/c/d43776b907659affef1de888525847d64b244194 https://git.kernel.org/stable/c/6252cb6bde7fc76cb8dcb49d1def7c326b190820 https://git.kernel.org/stable/c/d58a00e981d3118b91d503da263e640b7cde6729 https://git.kernel.org/stable/c/cc749e61c011c255d81b192a822db650c68b313f •