CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50016 – drm/amd/display: Avoid overflow assignment in link_dp_cts
https://notcve.org/view.php?id=CVE-2024-50016
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. • https://git.kernel.org/stable/c/a1495acc6234fa79b775599d3f49009afd53299f https://git.kernel.org/stable/c/26ced9d86240868f5b41708ceee02e6ec2924498 https://git.kernel.org/stable/c/adeed800bc30ef718478b28c08f79231e5980e3d https://git.kernel.org/stable/c/a15268787b79fd183dd526cc16bec9af4f4e49a1 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50014 – ext4: fix access to uninitialised lock in fc replay path
https://notcve.org/view.php?id=CVE-2024-50014
In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? • https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508 https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1 •
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 •