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: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47669 – nilfs2: fix state management in error path of log writing function
https://notcve.org/view.php?id=CVE-2024-47669
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix state management in error path of log writing function After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared. • https://git.kernel.org/stable/c/a694291a6211537189c6080f77f63cdabfc9b63e https://git.kernel.org/stable/c/40a2757de2c376ef8a08d9ee9c81e77f3c750adf https://git.kernel.org/stable/c/036441e8438b29111fa75008f0ce305fb4e83c0a https://git.kernel.org/stable/c/efdde00d4a1ef10bb71e09ebc67823a3d3ad725b https://git.kernel.org/stable/c/3e349d7191f0688fc9808ef24fd4e4b4ef5ca876 https://git.kernel.org/stable/c/30562eff4a6dd35c4b5be9699ef61ad9f5f20a06 https://git.kernel.org/stable/c/0a1a961bde4351dc047ffdeb2f1311ca16a700cc https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe •