Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: fix use-after-free<br /> <br /> If no firmware was present at all (or, presumably, all of the<br /> firmware files failed to parse), we end up unbinding by calling<br /> device_release_driver(), which calls remove(), which then in<br /> iwlwifi calls iwl_drv_stop(), freeing the &amp;#39;drv&amp;#39; struct. However<br /> the new code I added will still erroneously access it after it<br /> was freed.<br /> <br /> Set &amp;#39;failure=false&amp;#39; in this case to avoid the access, all data<br /> was already freed anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-rdma: fix possible use-after-free in transport error_recovery work<br /> <br /> While nvme_rdma_submit_async_event_work is checking the ctrl and queue<br /> state before preparing the AER command and scheduling io_work, in order<br /> to fully prevent a race where this check is not reliable the error<br /> recovery work must flush async_event_work before continuing to destroy<br /> the admin queue after setting the ctrl state to RESETTING such that<br /> there is no race .submit_async_event and the error recovery handler<br /> itself changing the ctrl state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix possible use-after-free in transport error_recovery work<br /> <br /> While nvme_tcp_submit_async_event_work is checking the ctrl and queue<br /> state before preparing the AER command and scheduling io_work, in order<br /> to fully prevent a race where this check is not reliable the error<br /> recovery work must flush async_event_work before continuing to destroy<br /> the admin queue after setting the ctrl state to RESETTING such that<br /> there is no race .submit_async_event and the error recovery handler<br /> itself changing the ctrl state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix a possible use-after-free in controller reset during load<br /> <br /> Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl<br /> readiness for AER submission. This may lead to a use-after-free<br /> condition that was observed with nvme-tcp.<br /> <br /> The race condition may happen in the following scenario:<br /> 1. driver executes its reset_ctrl_work<br /> 2. -&gt; nvme_stop_ctrl - flushes ctrl async_event_work<br /> 3. ctrl sends AEN which is received by the host, which in turn<br /> schedules AEN handling<br /> 4. teardown admin queue (which releases the queue socket)<br /> 5. AEN processed, submits another AER, calling the driver to submit<br /> 6. driver attempts to send the cmd<br /> ==&gt; use-after-free<br /> <br /> In order to fix that, add ctrl state check to validate the ctrl<br /> is actually able to accept the AER submission.<br /> <br /> This addresses the above race in controller resets because the driver<br /> during teardown should:<br /> 1. change ctrl state to RESETTING<br /> 2. flush async_event_work (as well as other async work elements)<br /> <br /> So after 1,2, any other AER command will find the<br /> ctrl state to be RESETTING and bail out without submitting the AER.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix use-after-free for aborted TMF sas_task<br /> <br /> Currently a use-after-free may occur if a TMF sas_task is aborted before we<br /> handle the IO completion in mpi_ssp_completion(). The abort occurs due to<br /> timeout.<br /> <br /> When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the<br /> sas_task is freed in pm8001_exec_internal_tmf_task().<br /> <br /> However, if the I/O completion occurs later, the I/O completion still<br /> thinks that the sas_task is available. Fix this by clearing the ccb-&gt;task<br /> if the TMF times out - the I/O completion handler does nothing if this<br /> pointer is cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task<br /> <br /> Currently a use-after-free may occur if a sas_task is aborted by the upper<br /> layer before we handle the I/O completion in mpi_ssp_completion() or<br /> mpi_sata_completion().<br /> <br /> In this case, the following are the two steps in handling those I/O<br /> completions:<br /> <br /> - Call complete() to inform the upper layer handler of completion of<br /> the I/O.<br /> <br /> - Release driver resources associated with the sas_task in<br /> pm8001_ccb_task_free() call.<br /> <br /> When complete() is called, the upper layer may free the sas_task. As such,<br /> we should not touch the associated sas_task afterwards, but we do so in the<br /> pm8001_ccb_task_free() call.<br /> <br /> Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: parsers: qcom: Fix kernel panic on skipped partition<br /> <br /> In the event of a skipped partition (case when the entry name is empty)<br /> the kernel panics in the cleanup function as the name entry is NULL.<br /> Rework the parser logic by first checking the real partition number and<br /> then allocate the space and set the data for the valid partitions.<br /> <br /> The logic was also fundamentally wrong as with a skipped partition, the<br /> parts number returned was incorrect by not decreasing it for the skipped<br /> partitions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: Fix a deadlock in the error handler<br /> <br /> The following deadlock has been observed on a test setup:<br /> <br /> - All tags allocated<br /> <br /> - The SCSI error handler calls ufshcd_eh_host_reset_handler()<br /> <br /> - ufshcd_eh_host_reset_handler() queues work that calls<br /> ufshcd_err_handler()<br /> <br /> - ufshcd_err_handler() locks up as follows:<br /> <br /> Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt<br /> Call trace:<br /> __switch_to+0x298/0x5d8<br /> __schedule+0x6cc/0xa94<br /> schedule+0x12c/0x298<br /> blk_mq_get_tag+0x210/0x480<br /> __blk_mq_alloc_request+0x1c8/0x284<br /> blk_get_request+0x74/0x134<br /> ufshcd_exec_dev_cmd+0x68/0x640<br /> ufshcd_verify_dev_init+0x68/0x35c<br /> ufshcd_probe_hba+0x12c/0x1cb8<br /> ufshcd_host_reset_and_restore+0x88/0x254<br /> ufshcd_reset_and_restore+0xd0/0x354<br /> ufshcd_err_handler+0x408/0xc58<br /> process_one_work+0x24c/0x66c<br /> worker_thread+0x3e8/0xa4c<br /> kthread+0x150/0x1b4<br /> ret_from_fork+0x10/0x30<br /> <br /> Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved<br /> request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/fixmap: Fix VM debug warning on unmap<br /> <br /> Unmapping a fixmap entry is done by calling __set_fixmap()<br /> with FIXMAP_PAGE_CLEAR as flags.<br /> <br /> Today, powerpc __set_fixmap() calls map_kernel_page().<br /> <br /> map_kernel_page() is not happy when called a second time<br /> for the same page.<br /> <br /> WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8<br /> CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682<br /> NIP: c0017cd4 LR: c00187f0 CTR: 00000010<br /> REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty)<br /> MSR: 00029032 CR: 42000208 XER: 00000000<br /> <br /> GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c<br /> GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000<br /> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000<br /> NIP [c0017cd4] set_pte_at+0xc/0x1e8<br /> LR [c00187f0] map_kernel_page+0x9c/0x100<br /> Call Trace:<br /> [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable)<br /> [e1011e30] [c0165fec] __set_fixmap+0x30/0x44<br /> [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170<br /> [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0<br /> [e1011e90] [c0c03634] do_one_initcall+0x80/0x178<br /> [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250<br /> [e1011f20] [c0007e34] kernel_init+0x24/0x140<br /> [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64<br /> Instruction dump:<br /> 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010<br /> 4e800020 81250000 712a0001 41820008 9421ffe0 93e1001c 48000030<br /> <br /> Implement unmap_kernel_page() which clears an existing pte.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change<br /> <br /> The refcount leak issues take place in an error handling path. When the<br /> 3rd argument buf doesn&amp;#39;t match with "offline", "online" or "remove", the<br /> function simply returns -EINVAL and forgets to decrease the reference<br /> count of a rpc_xprt object and a rpc_xprt_switch object increased by<br /> rpc_sysfs_xprt_kobj_get_xprt() and<br /> rpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference count leaks of<br /> both unused objects.<br /> <br /> Fix this issue by jumping to the error handling path labelled with<br /> out_put when buf matches none of "offline", "online" or "remove".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create<br /> <br /> If there are failures then we must not leave the non-NULL pointers with<br /> the error value, otherwise `rpcrdma_ep_destroy` gets confused and tries<br /> free them, resulting in an Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ptdma: Fix the error handling path in pt_core_init()<br /> <br /> In order to free resources correctly in the error handling path of<br /> pt_core_init(), 2 goto&amp;#39;s have to be switched. Otherwise, some resources<br /> will leak and we will try to release things that have not been allocated<br /> yet.<br /> <br /> Also move a dev_err() to a place where it is more meaningful.