Vulnerabilities

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 /> i40e: Fix NULL ptr dereference on VSI filter sync<br /> <br /> Remove the reason of null pointer dereference in sync VSI filters.<br /> Added new I40E_VSI_RELEASING flag to signalize deleting and releasing<br /> of VSI resources to sync this thread with sync filters subtask.<br /> Without this patch it is possible to start update the VSI filter list<br /> after VSI is removed, that&amp;#39;s causing a kernel oops.

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 /> 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 /> 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 /> 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

Cross-Site Request Forgery (CSRF) vulnerability in Octolize USPS Shipping for WooCommerce – Live Rates.This issue affects USPS Shipping for WooCommerce – Live Rates: from n/a through 1.9.2.

Cross-Site Request Forgery (CSRF) vulnerability in Octolize WooCommerce UPS Shipping – Live Rates and Access Points.This issue affects WooCommerce UPS Shipping – Live Rates and Access Points: from n/a through 2.2.4.

Traccar is an open source GPS tracking system. Traccar versions 5.1 through 5.12 allow arbitrary files to be uploaded through the device image upload API. Attackers have full control over the file contents, full control over the directory where the file is stored, full control over the file extension, and partial control over the file name. While it&amp;#39;s not for an attacker to overwrite an existing file, an attacker can create new files with certain names and attacker-controlled extensions anywhere on the file system. This can potentially lead to remote code execution, XSS, DOS, etc. The default install of Traccar makes this vulnerability more severe. Self-registration is enabled by default, allowing anyone to create an account to exploit this vulnerability. Traccar also runs by default with root/system privileges, allowing files to be placed anywhere on the file system. Version 6.0 contains a fix for the issue. One may also turn off self-registration by default, as that would make most vulnerabilities in the application much harder to exploit by default and reduce the severity considerably.<br />