CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47679 – vfs: fix race between evice_inodes() and find_inode()&iput()
https://notcve.org/view.php?id=CVE-2024-47679
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() ... • https://git.kernel.org/stable/c/63997e98a3be68d7cec806d22bf9b02b2e1daabb •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47678 – icmp: change the order of rate limits
https://notcve.org/view.php?id=CVE-2024-47678
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. B... • https://git.kernel.org/stable/c/4cdf507d54525842dfd9f6313fdafba039084046 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47677 – exfat: resolve memory leak from exfat_create_upcase_table()
https://notcve.org/view.php?id=CVE-2024-47677
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000 • https://git.kernel.org/stable/c/a13d1a4de3b0fe3c41d818697d691c886c5585fa •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47676 – mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway
https://notcve.org/view.php?id=CVE-2024-47676
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read(). • https://git.kernel.org/stable/c/9acad7ba3e25d11f4c96df1b7312ae89e6faca5c •
CVSS: 6.7EPSS: 0%CPEs: 4EXPL: 0CVE-2024-47675 – bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()
https://notcve.org/view.php?id=CVE-2024-47675
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list. • https://git.kernel.org/stable/c/89ae89f53d201143560f1e9ed4bfa62eee34f88e • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47674 – mm: avoid leaving partial pfn mappings around in error case
https://notcve.org/view.php?id=CVE-2024-47674
15 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually ... • https://git.kernel.org/stable/c/3213fdcab961026203dd587a4533600c70b3336b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47673 – wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
https://notcve.org/view.php?id=CVE-2024-47673
09 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pause TCM when the firmware is stopped Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING. bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace:
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47672 – wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
https://notcve.org/view.php?id=CVE-2024-47672
09 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead. Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, ... • https://git.kernel.org/stable/c/ad2fcc2daa203a6ad491f00e9ae3b7867e8fe0f3 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47671 – USB: usbtmc: prevent kernel-usb-infoleak
https://notcve.org/view.php?id=CVE-2024-47671
09 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields. Ubuntu Security Notice 7166-3 - Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. • https://git.kernel.org/stable/c/4ddc645f40e90fa3bc7af3a3f3bd7d29e671a775 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47670 – ocfs2: add bounds checking to ocfs2_xattr_find_entry()
https://notcve.org/view.php?id=CVE-2024-47670
09 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_xattr_find_entry() Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images. Ubuntu Security Notice 7166-3 - Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. • https://git.kernel.org/stable/c/b49a786beb11ff740cb9e0c20b999c2a0e1729c2 •