CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47678 – icmp: change the order of rate limits
https://notcve.org/view.php?id=CVE-2024-47678
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. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation. • https://git.kernel.org/stable/c/4cdf507d54525842dfd9f6313fdafba039084046 https://git.kernel.org/stable/c/997ba8889611891f91e8ad83583466aeab6239a3 https://git.kernel.org/stable/c/662ec52260cc07b9ae53ecd3925183c29d34288b https://git.kernel.org/stable/c/a7722921adb046e3836eb84372241f32584bdb07 https://git.kernel.org/stable/c/483397b4ba280813e4a9c161a0a85172ddb43d19 https://git.kernel.org/stable/c/8c2bd38b95f75f3d2a08c93e35303e26d480d24e •
CVSS: -EPSS: 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
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 https://git.kernel.org/stable/c/790c630ab0e7d7aba6d186581d4627c09fce60f3 https://git.kernel.org/stable/c/7c1d782e5afbf7c50ba74ecc4ddc18a05d63e5ee https://git.kernel.org/stable/c/cdf27834c3dd5d9abf7eb8e4ee87ee9e307eb25c https://git.kernel.org/stable/c/5fe6e308abaea082c20fbf2aa5df8e14495622cf •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47674 – mm: avoid leaving partial pfn mappings around in error case
https://notcve.org/view.php?id=CVE-2024-47674
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 clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: evitar dejar asignaciones pfn parciales en caso de error Como señala Jann, las asignaciones PFN son especiales, porque a diferencia de las asignaciones de memoria normales, no hay información de duración asociada con la asignación: es solo una asignación sin procesar de PFN sin recuento de referencias de una 'página de estructura'. Todo eso es muy intencional, pero significa que es fácil arruinar la limpieza en caso de errores. Sí, un mmap() fallido siempre limpiará eventualmente cualquier asignación parcial, pero sin ninguna duración explícita en la asignación de la tabla de páginas en sí, es muy fácil hacer el manejo de errores en el orden incorrecto. • https://git.kernel.org/stable/c/5b2c8b34f6d76bfbd1dd4936eb8a0fbfb9af3959 https://git.kernel.org/stable/c/65d0db500d7c07f0f76fc24a4d837791c4862cd2 https://git.kernel.org/stable/c/a95a24fcaee1b892e47d5e6dcc403f713874ee80 https://git.kernel.org/stable/c/954fd4c81f22c4b6ba65379a81fd252971bf4ef3 https://git.kernel.org/stable/c/79a61cc3fc0466ad2b7b89618a6157785f0293b3 https://project-zero.issues.chromium.org/issues/366053091 •
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
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: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30 • https://git.kernel.org/stable/c/a15df5f37fa3a8b7a8ec7a339d1e897bc524e28f https://git.kernel.org/stable/c/5948a191906b54e10f02f6b7a7670243a39f99f4 https://git.kernel.org/stable/c/2c61b561baf92a2860c76c2302a62169e22c21cc https://git.kernel.org/stable/c/55086c97a55d781b04a2667401c75ffde190135c https://git.kernel.org/stable/c/0668ebc8c2282ca1e7eb96092a347baefffb5fe7 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 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
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, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running. [edit commit message] • https://git.kernel.org/stable/c/de46b1d24f5f752b3bd8b46673c2ea4239661244 https://git.kernel.org/stable/c/1afed66cb271b3e65fe9df1c9fba2bf4b1f55669 https://git.kernel.org/stable/c/1b0cd832c9607f41f84053b818e0b7908510a3b9 https://git.kernel.org/stable/c/4d0a900ec470d392476c428875dbf053f8a0ae5e https://git.kernel.org/stable/c/7188b7a72320367554b76d8f298417b070b05dd3 https://git.kernel.org/stable/c/3a84454f5204718ca5b4ad2c1f0bf2031e2403d1 •