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 ? • 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. • 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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/6c7fc36da021b13c34c572a26ba336cd102418f8 https://git.kernel.org/stable/c/625fa77151f00c1bd00d34d60d6f2e710 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 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. • 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/9e3041fecdc8f78a5900c3aa51d3d756e73264d6 •
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. • 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 •