CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50012 – cpufreq: Avoid a bad reference count on CPU node
https://notcve.org/view.php?id=CVE-2024-50012
In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute. • https://git.kernel.org/stable/c/6c3d8387839252f1a0fc6367f314446e4a2ebd0b https://git.kernel.org/stable/c/0f41f383b5a61a2bf6429a449ebba7fb08179d81 https://git.kernel.org/stable/c/77f88b17387a017416babf1e6488fa17682287e2 https://git.kernel.org/stable/c/47cb1d9278f179df8250304ec41009e3e836a926 https://git.kernel.org/stable/c/c0f02536fffbbec71aced36d52a765f8c4493dc2 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 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/c9b77438077d5a20c79ead95bcdaf9bd4797baaf https://git.kernel.org/stable/c/b723f96407a0a078cf75970e4dbf16b46d286a61 https://git.kernel.org/stable/c/0bdf77be2330062b3a64f2bec39f62ab874a6796 https://git.kernel.org/stable/c/0d16f53c91111cec914f0811fcc526a2ba77b20d 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: 9EXPL: 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/b55c8848fdc81514ec047b2a0ec782ffe9ab5323 https://git.kernel.org/stable/c/f9310a6704bf52e2493480edea896e1f9b795d40 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/a3a12c30f9510f3753286fadbc6cdb7da •
CVSS: -EPSS: 0%CPEs: 9EXPL: 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/a6bdb691cf7b66dcd929de1a253c5c42edd2e522 https://git.kernel.org/stable/c/ce2953e44829ec54bcbb57e9d890fc8af0900c80 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/876d04bf5a8ac1d6af5afd258cd37ab83 •