Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Improve SCSI abort handling<br /> <br /> The following has been observed on a test setup:<br /> <br /> WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c<br /> Call trace:<br /> ufshcd_queuecommand+0x468/0x65c<br /> scsi_send_eh_cmnd+0x224/0x6a0<br /> scsi_eh_test_devices+0x248/0x418<br /> scsi_eh_ready_devs+0xc34/0xe58<br /> scsi_error_handler+0x204/0x80c<br /> kthread+0x150/0x1b4<br /> ret_from_fork+0x10/0x30<br /> <br /> That warning is triggered by the following statement:<br /> <br /> WARN_ON(lrbp-&gt;cmd);<br /> <br /> Fix this warning by clearing lrbp-&gt;cmd from the abort handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix memory ordering between normal and ordered work functions<br /> <br /> Ordered work functions aren&amp;#39;t guaranteed to be handled by the same thread<br /> which executed the normal work functions. The only way execution between<br /> normal/ordered functions is synchronized is via the WORK_DONE_BIT,<br /> unfortunately the used bitops don&amp;#39;t guarantee any ordering whatsoever.<br /> <br /> This manifested as seemingly inexplicable crashes on ARM64, where<br /> async_chunk::inode is seen as non-null in async_cow_submit which causes<br /> submit_compressed_extents to be called and crash occurs because<br /> async_chunk::inode suddenly became NULL. The call trace was similar to:<br /> <br /> pc : submit_compressed_extents+0x38/0x3d0<br /> lr : async_cow_submit+0x50/0xd0<br /> sp : ffff800015d4bc20<br /> <br /> <br /> <br /> Call trace:<br /> submit_compressed_extents+0x38/0x3d0<br /> async_cow_submit+0x50/0xd0<br /> run_ordered_work+0xc8/0x280<br /> btrfs_work_helper+0x98/0x250<br /> process_one_work+0x1f0/0x4ac<br /> worker_thread+0x188/0x504<br /> kthread+0x110/0x114<br /> ret_from_fork+0x10/0x18<br /> <br /> Fix this by adding respective barrier calls which ensure that all<br /> accesses preceding setting of WORK_DONE_BIT are strictly ordered before<br /> setting the flag. At the same time add a read barrier after reading of<br /> WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads<br /> would be strictly ordered after reading the bit. This in turn ensures<br /> are all accesses before WORK_DONE_BIT are going to be strictly ordered<br /> before any access that can occur in ordered_func.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf bpf: Avoid memory leak from perf_env__insert_btf()<br /> <br /> perf_env__insert_btf() doesn&amp;#39;t insert if a duplicate BTF id is<br /> encountered and this causes a memory leak. Modify the function to return<br /> a success/error value and then free the memory if insertion didn&amp;#39;t<br /> happen.<br /> <br /> v2. Adds a return -1 when the insertion error occurs in<br /> perf_env__fetch_btf. This doesn&amp;#39;t affect anything as the result is<br /> never checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()<br /> <br /> The following warning was observed running syzkaller:<br /> <br /> [ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;<br /> [ 3813.830724] program syz-executor not setting count and/or reply_len properly<br /> [ 3813.836956] ==================================================================<br /> [ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0<br /> [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549<br /> [ 3813.846612] Call Trace:<br /> [ 3813.846995] dump_stack+0x108/0x15f<br /> [ 3813.847524] print_address_description+0xa5/0x372<br /> [ 3813.848243] kasan_report.cold+0x236/0x2a8<br /> [ 3813.849439] check_memory_region+0x240/0x270<br /> [ 3813.850094] memcpy+0x30/0x80<br /> [ 3813.850553] sg_copy_buffer+0x157/0x1e0<br /> [ 3813.853032] sg_copy_from_buffer+0x13/0x20<br /> [ 3813.853660] fill_from_dev_buffer+0x135/0x370<br /> [ 3813.854329] resp_readcap16+0x1ac/0x280<br /> [ 3813.856917] schedule_resp+0x41f/0x1630<br /> [ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0<br /> [ 3813.862699] scsi_dispatch_cmd+0x330/0x950<br /> [ 3813.863329] scsi_request_fn+0xd8e/0x1710<br /> [ 3813.863946] __blk_run_queue+0x10b/0x230<br /> [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400<br /> [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420<br /> [ 3813.871637] sg_write+0x6c8/0xef0<br /> [ 3813.878853] __vfs_write+0xe4/0x800<br /> [ 3813.883487] vfs_write+0x17b/0x530<br /> [ 3813.884008] ksys_write+0x103/0x270<br /> [ 3813.886268] __x64_sys_write+0x77/0xc0<br /> [ 3813.886841] do_syscall_64+0x106/0x360<br /> [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> This issue can be reproduced with the following syzkaller log:<br /> <br /> r0 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)=&amp;#39;./file0\x00&amp;#39;, 0x26e1, 0x0)<br /> r1 = syz_open_procfs(0xffffffffffffffff, &amp;(0x7f0000000000)=&amp;#39;fd/3\x00&amp;#39;)<br /> open_by_handle_at(r1, &amp;(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)<br /> r2 = syz_open_dev$sg(&amp;(0x7f0000000000), 0x0, 0x40782)<br /> write$binfmt_aout(r2, &amp;(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)<br /> <br /> In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass<br /> the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This<br /> leads to OOB in sg_copy_buffer().<br /> <br /> To solve this issue, define alloc_len as u32.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: sysfs: Fix hang when device state is set via sysfs<br /> <br /> This fixes a regression added with:<br /> <br /> commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after<br /> offlinining device")<br /> <br /> The problem is that after iSCSI recovery, iscsid will call into the kernel<br /> to set the dev&amp;#39;s state to running, and with that patch we now call<br /> scsi_rescan_device() with the state_mutex held. If the SCSI error handler<br /> thread is just starting to test the device in scsi_send_eh_cmnd() then it&amp;#39;s<br /> going to try to grab the state_mutex.<br /> <br /> We are then stuck, because when scsi_rescan_device() tries to send its I/O<br /> scsi_queue_rq() calls -&gt; scsi_host_queue_ready() -&gt; scsi_host_in_recovery()<br /> which will return true (the host state is still in recovery) and I/O will<br /> just be requeued. scsi_send_eh_cmnd() will then never be able to grab the<br /> state_mutex to finish error handling.<br /> <br /> To prevent the deadlock move the rescan-related code to after we drop the<br /> state_mutex.<br /> <br /> This also adds a check for if we are already in the running state. This<br /> prevents extra scans and helps the iscsid case where if the transport class<br /> has already onlined the device during its recovery process then we don&amp;#39;t<br /> need userspace to do it again plus possibly block that daemon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cfg80211: call cfg80211_stop_ap when switch from P2P_GO type<br /> <br /> If the userspace tools switch from NL80211_IFTYPE_P2P_GO to<br /> NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it<br /> does not call the cleanup cfg80211_stop_ap(), this leads to the<br /> initialization of in-use data. For example, this path re-init the<br /> sdata-&gt;assigned_chanctx_list while it is still an element of<br /> assigned_vifs list, and makes that linked list corrupt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix use-after-free of the add_lock mutex<br /> <br /> Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on<br /> SPI buses") introduced a per-controller mutex. But mutex_unlock() of<br /> said lock is called after the controller is already freed:<br /> <br /> spi_unregister_controller(ctlr)<br /> -&gt; put_device(&amp;ctlr-&gt;dev)<br /> -&gt; spi_controller_release(dev)<br /> -&gt; mutex_unlock(&amp;ctrl-&gt;add_lock)<br /> <br /> Move the put_device() after the mutex_unlock().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Set send and receive CQ before forwarding to the driver<br /> <br /> Preset both receive and send CQ pointers prior to call to the drivers and<br /> overwrite it later again till the mlx4 is going to be changed do not<br /> overwrite ibqp properties.<br /> <br /> This change is needed for mlx5, because in case of QP creation failure, it<br /> will go to the path of QP destroy which relies on proper CQ pointers.<br /> <br /> BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib]<br /> Write of size 8 at addr ffff8880064c55c0 by task a.out/246<br /> <br /> CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> dump_stack_lvl+0x45/0x59<br /> print_address_description.constprop.0+0x1f/0x140<br /> kasan_report.cold+0x83/0xdf<br /> create_qp.cold+0x164/0x16e [mlx5_ib]<br /> mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib]<br /> create_qp.part.0+0x45b/0x6a0 [ib_core]<br /> ib_create_qp_user+0x97/0x150 [ib_core]<br /> ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]<br /> ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]<br /> __x64_sys_ioctl+0x866/0x14d0<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Allocated by task 246:<br /> kasan_save_stack+0x1b/0x40<br /> __kasan_kmalloc+0xa4/0xd0<br /> create_qp.part.0+0x92/0x6a0 [ib_core]<br /> ib_create_qp_user+0x97/0x150 [ib_core]<br /> ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]<br /> ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]<br /> __x64_sys_ioctl+0x866/0x14d0<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Freed by task 246:<br /> kasan_save_stack+0x1b/0x40<br /> kasan_set_track+0x1c/0x30<br /> kasan_set_free_info+0x20/0x30<br /> __kasan_slab_free+0x10c/0x150<br /> slab_free_freelist_hook+0xb4/0x1b0<br /> kfree+0xe7/0x2a0<br /> create_qp.part.0+0x52b/0x6a0 [ib_core]<br /> ib_create_qp_user+0x97/0x150 [ib_core]<br /> ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]<br /> ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]<br /> __x64_sys_ioctl+0x866/0x14d0<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: nullify cq-&gt;dbg pointer in mlx5_debug_cq_remove()<br /> <br /> Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds<br /> to rest of destroy operations. mlx5_core_destroy_cq() could be called again<br /> by user and cause additional call of mlx5_debug_cq_remove().<br /> cq-&gt;dbg was not nullify in previous call and cause the crash.<br /> <br /> Fix it by nullify cq-&gt;dbg pointer after removal.<br /> <br /> Also proceed to destroy operations only if FW return 0<br /> for MLX5_CMD_OP_DESTROY_CQ command.<br /> <br /> general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTI<br /> CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:lockref_get+0x1/0x60<br /> Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02<br /> 00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 8b 17<br /> 48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48<br /> RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206<br /> RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe<br /> RDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058<br /> RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000<br /> R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0<br /> FS: 00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0<br /> Call Trace:<br /> simple_recursive_removal+0x33/0x2e0<br /> ? debugfs_remove+0x60/0x60<br /> debugfs_remove+0x40/0x60<br /> mlx5_debug_cq_remove+0x32/0x70 [mlx5_core]<br /> mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core]<br /> devx_obj_cleanup+0x151/0x330 [mlx5_ib]<br /> ? __pollwait+0xd0/0xd0<br /> ? xas_load+0x5/0x70<br /> ? xa_load+0x62/0xa0<br /> destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs]<br /> uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs]<br /> uobj_destroy+0x54/0xa0 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs]<br /> ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs]<br /> ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs]<br /> __x64_sys_ioctl+0x3e4/0x8e0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine<br /> <br /> An error is detected with the following report when unloading the driver:<br /> "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"<br /> <br /> The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the<br /> flag is not cleared upon completion of the login.<br /> <br /> This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set<br /> to LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used<br /> as an rpi_ids array index.<br /> <br /> Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in<br /> lpfc_mbx_cmpl_fc_reg_login().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix link down processing to address NULL pointer dereference<br /> <br /> If an FC link down transition while PLOGIs are outstanding to fabric well<br /> known addresses, outstanding ABTS requests may result in a NULL pointer<br /> dereference. Driver unload requests may hang with repeated "2878" log<br /> messages.<br /> <br /> The Link down processing results in ABTS requests for outstanding ELS<br /> requests. The Abort WQEs are sent for the ELSs before the driver had set<br /> the link state to down. Thus the driver is sending the Abort with the<br /> expectation that an ABTS will be sent on the wire. The Abort request is<br /> stalled waiting for the link to come up. In some conditions the driver may<br /> auto-complete the ELSs thus if the link does come up, the Abort completions<br /> may reference an invalid structure.<br /> <br /> Fix by ensuring that Abort set the flag to avoid link traffic if issued due<br /> to conditions where the link failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm80xx: Fix memory leak during rmmod<br /> <br /> Driver failed to release all memory allocated. This would lead to memory<br /> leak during driver removal.<br /> <br /> Properly free memory when the module is removed.