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
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/3213fdcab961026203dd587a4533600c70b3336b https://git.kernel.org/stable/c/35770ca6180caa24a2b258c99a87bd437a1ee10f 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: 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
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/ad2fcc2daa203a6ad491f00e9ae3b7867e8fe0f3 https://git.kernel.org/stable/c/16c1e5d5228f26f120e12e6ca55c59c3a5e6dece 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/3a84454f5204718ca5b4ad2c1f0bf2031 •
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
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. • https://git.kernel.org/stable/c/b49a786beb11ff740cb9e0c20b999c2a0e1729c2 https://git.kernel.org/stable/c/60c0d36189bad58b1a8e69af8781d90009559ea1 https://git.kernel.org/stable/c/34759b7e4493d7337cbc414c132cef378c492a2c https://git.kernel.org/stable/c/5bbe51eaf01a5dd6fb3f0dea81791e5dbc6dc6dd https://git.kernel.org/stable/c/9b32539590a8e6400ac2f6e7cf9cbb8e08711a2f https://git.kernel.org/stable/c/1f6e167d6753fe3ea493cdc7f7de8d03147a4d39 https://git.kernel.org/stable/c/8e7bef408261746c160853fc27df3139659f5f77 https://git.kernel.org/stable/c/9e3041fecdc8f78a5900c3aa51d3d756e •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47668 – lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()
https://notcve.org/view.php?id=CVE-2024-47668
In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path. • https://git.kernel.org/stable/c/0f27f4f445390cb7f73d4209cb2bf32834dc53da https://git.kernel.org/stable/c/99418ec776a39609f50934720419e0b464ca2283 https://git.kernel.org/stable/c/ad5ee9feebc2eb8cfc76ed74a2d6e55343b0e169 https://git.kernel.org/stable/c/ebeff038744c498a036e7a92eb8e433ae0a386d7 https://git.kernel.org/stable/c/d942e855324a60107025c116245095632476613e https://git.kernel.org/stable/c/0f078f8ca93b28a34e20bd050f12cd4efeee7c0f https://git.kernel.org/stable/c/b2f11c6f3e1fc60742673b8675c95b78447f3dae https://access.redhat.com/security/cve/CVE-2024-47668 •