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-47671 – USB: usbtmc: prevent kernel-usb-infoleak
https://notcve.org/view.php?id=CVE-2024-47671
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. • https://git.kernel.org/stable/c/4ddc645f40e90fa3bc7af3a3f3bd7d29e671a775 https://git.kernel.org/stable/c/fa652318887da530f2f9dbd9b0ea4a087d05ee12 https://git.kernel.org/stable/c/16e0ab9ed3ae7d19ca8ee718ba4e09d5c0f909ca https://git.kernel.org/stable/c/0c927dfc0b9bd177f7ab6ee59ef0c4ea06c110a7 https://git.kernel.org/stable/c/ba6269e187aa1b1f20faf3c458831a0d6350304b https://git.kernel.org/stable/c/51297ef7ad7824ad577337f273cd092e81a9fa08 https://git.kernel.org/stable/c/e872738e670ddd63e19f22d0d784f0bdf26ecba5 https://git.kernel.org/stable/c/6c7fc36da021b13c34c572a26ba336cd1 •
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 •