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: 7EXPL: 0CVE-2024-50013 – exfat: fix memory leak in exfat_load_bitmap()
https://notcve.org/view.php?id=CVE-2024-50013
In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak. • https://git.kernel.org/stable/c/1e49a94cf707204b66a3fb242f2814712c941f52 https://git.kernel.org/stable/c/f692160d3e1e5450605071b8df8f7d08d9b09a83 https://git.kernel.org/stable/c/ddf704c2ce3b73f38d2dd8cf1bb0f7ec038bdf63 https://git.kernel.org/stable/c/4e1813e52f86eb8db0c6c9570251f2fcbc571f5d https://git.kernel.org/stable/c/bf0b3b35259475d1fe377bcaa565488e26684f7a https://git.kernel.org/stable/c/dca359db1eb37f334267ebd7e3cab9a66d191d5b https://git.kernel.org/stable/c/89081e8407e637463db5880d168e3652fb9f4330 https://git.kernel.org/stable/c/d2b537b3e533f28e0d97293fe9293161f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 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/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: 2EXPL: 0CVE-2024-50011 – ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item
https://notcve.org/view.php?id=CVE-2024-50011
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required. • https://git.kernel.org/stable/c/65ab45b90656e9b7ed51bce27ab7d83618167e76 https://git.kernel.org/stable/c/aa3109ee91fe09e696274e6ac44813df8d13678f https://git.kernel.org/stable/c/5afc29ba44fdd1bcbad4e07246c395d946301580 •
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 •