Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()<br /> <br /> If track_pfn_copy() fails, we already added the dst VMA to the maple<br /> tree. As fork() fails, we&amp;#39;ll cleanup the maple tree, and stumble over<br /> the dst VMA for which we neither performed any reservation nor copied<br /> any page tables.<br /> <br /> Consequently untrack_pfn() will see VM_PAT and try obtaining the<br /> PAT information from the page table -- which fails because the page<br /> table was not copied.<br /> <br /> The easiest fix would be to simply clear the VM_PAT flag of the dst VMA<br /> if track_pfn_copy() fails. However, the whole thing is about "simply"<br /> clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()<br /> and performed a reservation, but copying the page tables fails, we&amp;#39;ll<br /> simply clear the VM_PAT flag, not properly undoing the reservation ...<br /> which is also wrong.<br /> <br /> So let&amp;#39;s fix it properly: set the VM_PAT flag only if the reservation<br /> succeeded (leaving it clear initially), and undo the reservation if<br /> anything goes wrong while copying the page tables: clearing the VM_PAT<br /> flag after undoing the reservation.<br /> <br /> Note that any copied page table entries will get zapped when the VMA will<br /> get removed later, after copy_page_range() succeeded; as VM_PAT is not set<br /> then, we won&amp;#39;t try cleaning VM_PAT up once more and untrack_pfn() will be<br /> happy. Note that leaving these page tables in place without a reservation<br /> is not a problem, as we are aborting fork(); this process will never run.<br /> <br /> A reproducer can trigger this usually at the first try:<br /> <br /> https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c<br /> <br /> WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110<br /> Modules linked in: ...<br /> CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:get_pat_info+0xf6/0x110<br /> ...<br /> Call Trace:<br /> <br /> ...<br /> untrack_pfn+0x52/0x110<br /> unmap_single_vma+0xa6/0xe0<br /> unmap_vmas+0x105/0x1f0<br /> exit_mmap+0xf6/0x460<br /> __mmput+0x4b/0x120<br /> copy_process+0x1bf6/0x2aa0<br /> kernel_clone+0xab/0x440<br /> __do_sys_clone+0x66/0x90<br /> do_syscall_64+0x95/0x180<br /> <br /> Likely this case was missed in:<br /> <br /> d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")<br /> <br /> ... and instead of undoing the reservation we simply cleared the VM_PAT flag.<br /> <br /> Keep the documentation of these functions in include/linux/pgtable.h,<br /> one place is more than sufficient -- we should clean that up for the other<br /> functions like track_pfn_remap/untrack_pfn separately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix page_size variable overflow<br /> <br /> Change all variables storing mlx5_umem_mkc_find_best_pgsz() result to<br /> unsigned long to support values larger than 31 and avoid overflow.<br /> <br /> For example: If we try to register 4GB of memory that is contiguous in<br /> physical memory, the driver will optimize the page_size and try to use<br /> an mkey with 4GB entity size. The &amp;#39;unsigned int&amp;#39; page_size variable will<br /> overflow to &amp;#39;0&amp;#39; and we&amp;#39;ll hit the WARN_ON() in alloc_cacheable_mr().<br /> <br /> WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> Modules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core]<br /> CPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43<br /> Tainted: [W]=WARN<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:alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41<br /> RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246<br /> RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001<br /> RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600<br /> RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240<br /> R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00<br /> FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn+0x81/0x130<br /> ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> ? report_bug+0xfc/0x1e0<br /> ? handle_bug+0x55/0x90<br /> ? exc_invalid_op+0x17/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> create_real_mr+0x54/0x150 [mlx5_ib]<br /> ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs]<br /> ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs]<br /> ? walk_system_ram_range+0x79/0xd0<br /> ? ___pte_offset_map+0x1b/0x110<br /> ? __pte_offset_map_lock+0x80/0x100<br /> ib_uverbs_ioctl+0xac/0x110 [ib_uverbs]<br /> __x64_sys_ioctl+0x94/0xb0<br /> do_syscall_64+0x50/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fb7ecf0737b<br /> Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b<br /> RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003<br /> RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4<br /> R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4<br /> R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix NULL dereference in SR-IOV VF creation error path<br /> <br /> Clean up when virtfn setup fails to prevent NULL pointer dereference<br /> during device removal. The kernel oops below occurred due to incorrect<br /> error handling flow when pci_setup_device() fails.<br /> <br /> Add pci_iov_scan_device(), which handles virtfn allocation and setup and<br /> cleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn&amp;#39;t need<br /> to call pci_stop_and_remove_bus_device(). This prevents accessing<br /> partially initialized virtfn devices during removal.<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000d0<br /> RIP: 0010:device_del+0x3d/0x3d0<br /> Call Trace:<br /> pci_remove_bus_device+0x7c/0x100<br /> pci_iov_add_virtfn+0xfa/0x200<br /> sriov_enable+0x208/0x420<br /> mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core]<br /> sriov_numvfs_store+0xae/0x1a0<br /> <br /> [bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: avoid NPD when ASIC does not support DMUB<br /> <br /> ctx-&gt;dmub_srv will de NULL if the ASIC does not support DMUB, which is<br /> tested in dm_dmub_sw_init.<br /> <br /> However, it will be dereferenced in dmub_hw_lock_mgr_cmd if<br /> should_use_dmub_lock returns true.<br /> <br /> This has been the case since dmub support has been added for PSR1.<br /> <br /> Fix this by checking for dmub_srv in should_use_dmub_lock.<br /> <br /> [ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> [ 37.447808] #PF: supervisor read access in kernel mode<br /> [ 37.452959] #PF: error_code(0x0000) - not-present page<br /> [ 37.458112] PGD 0 P4D 0<br /> [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88<br /> [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023<br /> [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0<br /> [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5<br /> [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202<br /> [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358<br /> [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000<br /> [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5<br /> [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000<br /> [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000<br /> [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000<br /> [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0<br /> [ 37.572697] Call Trace:<br /> [ 37.575152] <br /> [ 37.577258] ? __die_body+0x66/0xb0<br /> [ 37.580756] ? page_fault_oops+0x3e7/0x4a0<br /> [ 37.584861] ? exc_page_fault+0x3e/0xe0<br /> [ 37.588706] ? exc_page_fault+0x5c/0xe0<br /> [ 37.592550] ? asm_exc_page_fault+0x22/0x30<br /> [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0<br /> [ 37.601107] dcn10_cursor_lock+0x1e1/0x240<br /> [ 37.605211] program_cursor_attributes+0x81/0x190<br /> [ 37.609923] commit_planes_for_stream+0x998/0x1ef0<br /> [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0<br /> [ 37.619703] dc_update_planes_and_stream+0x78/0x140<br /> [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0<br /> [ 37.629832] ? srso_return_thunk+0x5/0x5f<br /> [ 37.633847] ? mark_held_locks+0x6d/0xd0<br /> [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50<br /> [ 37.642135] ? srso_return_thunk+0x5/0x5f<br /> [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150<br /> [ 37.650510] ? srso_return_thunk+0x5/0x5f<br /> [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50<br /> [ 37.658883] ? srso_return_thunk+0x5/0x5f<br /> [ 37.662897] ? wait_for_common+0x186/0x1c0<br /> [ 37.666998] ? srso_return_thunk+0x5/0x5f<br /> [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170<br /> [ 37.675983] commit_tail+0xf5/0x1c0<br /> [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0<br /> [ 37.684186] drm_atomic_commit+0xd6/0x100<br /> [ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10<br /> [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130<br /> [ 37.698054] drm_mode_cursor_common+0x501/0x670<br /> [ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10<br /> [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70<br /> [ 37.711851] drm_ioctl_kernel+0xf2/0x150<br /> [ 37.715781] drm_ioctl+0x363/0x590<br /> [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10<br /> [ 37.724165] amdgpu_drm_ioctl+0x41/0x80<br /> [ 37.728013] __se_sys_ioctl+0x7f/0xd0<br /> [ 37.731685] do_syscall_64+0x87/0x100<br /> [ 37.735355] ? vma_end_read+0x12/0xe0<br /> [ 37.739024] ? srso_return_thunk+0x5/0x5f<br /> [ 37.743041] ? find_held_lock+0x47/0xf0<br /> [ 37.746884] ? vma_end_read+0x12/0xe0<br /> [ 37.750552] ? srso_return_thunk+0x5/0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/perf: Fix ref-counting on the PMU &amp;#39;vpa_pmu&amp;#39;<br /> <br /> Commit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa<br /> counters") introduced &amp;#39;vpa_pmu&amp;#39; to expose Book3s-HV nested APIv2 provided<br /> L1L2 context switch latency counters to L1 user-space via<br /> perf-events. However the newly introduced PMU named &amp;#39;vpa_pmu&amp;#39; doesn&amp;#39;t<br /> assign ownership of the PMU to the module &amp;#39;vpa_pmu&amp;#39;. Consequently the<br /> module &amp;#39;vpa_pmu&amp;#39; can be unloaded while one of the perf-events are still<br /> active, which can lead to kernel oops and panic of the form below on a<br /> Pseries-LPAR:<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x00000058<br /> <br /> NIP [c000000000506cb8] event_sched_out+0x40/0x258<br /> LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0<br /> Call Trace:<br /> [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (unreliable)<br /> [c00000025fc3fc80] [fffffffffffffee0] 0xfffffffffffffee0<br /> [c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120<br /> <br /> Kernel panic - not syncing: Aiee, killing interrupt handler!<br /> <br /> Fix this by adding the module ownership to &amp;#39;vpa_pmu&amp;#39; so that the module<br /> &amp;#39;vpa_pmu&amp;#39; is ref-counted and prevented from being unloaded when perf-events<br /> are initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: brcmstb: Fix error path after a call to regulator_bulk_get()<br /> <br /> If the regulator_bulk_get() returns an error and no regulators<br /> are created, we need to set their number to zero.<br /> <br /> If we don&amp;#39;t do this and the PCIe link up fails, a call to the<br /> regulator_bulk_free() will result in a kernel panic.<br /> <br /> While at it, print the error value, as we cannot return an error<br /> upwards as the kernel will WARN() on an error from add_bus().<br /> <br /> [kwilczynski: commit log, use comma in the message to match style with<br /> other similar messages]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/gem: Fix error code msm_parse_deps()<br /> <br /> The SUBMIT_ERROR() macro turns the error code negative. This extra &amp;#39;-&amp;#39;<br /> operation turns it back to positive EINVAL again. The error code is<br /> passed to ERR_PTR() and since positive values are not an IS_ERR() it<br /> eventually will lead to an oops. Delete the &amp;#39;-&amp;#39;.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/637625/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/erdma: Prevent use-after-free in erdma_accept_newconn()<br /> <br /> After the erdma_cep_put(new_cep) being called, new_cep will be freed,<br /> and the following dereference will cause a UAF problem. Fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vchiq_arm: Fix possible NPR of keep-alive thread<br /> <br /> In case vchiq_platform_conn_state_changed() is never called or fails before<br /> driver removal, ka_thread won&amp;#39;t be a valid pointer to a task_struct. So<br /> do the necessary checks before calling kthread_stop to avoid a crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: validate l_tree_depth to avoid out-of-bounds access<br /> <br /> The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is<br /> limited to OCFS2_MAX_PATH_DEPTH.<br /> <br /> Add a check to prevent out-of-bounds access if l_tree_depth has an invalid<br /> value, which may occur when reading from a corrupted mounted disk [1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: backend: make sure to NULL terminate stack buffer<br /> <br /> Make sure to NULL terminate the buffer in<br /> iio_backend_debugfs_write_reg() before passing it to sscanf(). It is a<br /> stack variable so we should not assume it will 0 initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint<br /> <br /> If vhost_scsi_set_endpoint is called multiple times without a<br /> vhost_scsi_clear_endpoint between them, we can hit multiple bugs<br /> found by Haoran Zhang:<br /> <br /> 1. Use-after-free when no tpgs are found:<br /> <br /> This fixes a use after free that occurs when vhost_scsi_set_endpoint is<br /> called more than once and calls after the first call do not find any<br /> tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds<br /> tpgs to add to the vs_tpg array match=true, so we will do:<br /> <br /> vhost_vq_set_backend(vq, vs_tpg);<br /> ...<br /> <br /> kfree(vs-&gt;vs_tpg);<br /> vs-&gt;vs_tpg = vs_tpg;<br /> <br /> If vhost_scsi_set_endpoint is called again and no tpgs are found<br /> match=false so we skip the vhost_vq_set_backend call leaving the<br /> pointer to the vs_tpg we then free via:<br /> <br /> kfree(vs-&gt;vs_tpg);<br /> vs-&gt;vs_tpg = vs_tpg;<br /> <br /> If a scsi request is then sent we do:<br /> <br /> vhost_scsi_handle_vq -&gt; vhost_scsi_get_req -&gt; vhost_vq_get_backend<br /> <br /> which sees the vs_tpg we just did a kfree on.<br /> <br /> 2. Tpg dir removal hang:<br /> <br /> This patch fixes an issue where we cannot remove a LIO/target layer<br /> tpg (and structs above it like the target) dir due to the refcount<br /> dropping to -1.<br /> <br /> The problem is that if vhost_scsi_set_endpoint detects a tpg is already<br /> in the vs-&gt;vs_tpg array or if the tpg has been removed so<br /> target_depend_item fails, the undepend goto handler will do<br /> target_undepend_item on all tpgs in the vs_tpg array dropping their<br /> refcount to 0. At this time vs_tpg contains both the tpgs we have added<br /> in the current vhost_scsi_set_endpoint call as well as tpgs we added in<br /> previous calls which are also in vs-&gt;vs_tpg.<br /> <br /> Later, when vhost_scsi_clear_endpoint runs it will do<br /> target_undepend_item on all the tpgs in the vs-&gt;vs_tpg which will drop<br /> their refcount to -1. Userspace will then not be able to remove the tpg<br /> and will hang when it tries to do rmdir on the tpg dir.<br /> <br /> 3. Tpg leak:<br /> <br /> This fixes a bug where we can leak tpgs and cause them to be<br /> un-removable because the target name is overwritten when<br /> vhost_scsi_set_endpoint is called multiple times but with different<br /> target names.<br /> <br /> The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup<br /> a vhost-scsi device to target/tpg mapping, then calls<br /> VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we<br /> haven&amp;#39;t seen before (target1 has tpg1 but target2 has tpg2). When this<br /> happens we don&amp;#39;t teardown the old target tpg mapping and just overwrite<br /> the target name and the vs-&gt;vs_tpg array. Later when we do<br /> vhost_scsi_clear_endpoint, we are passed in either target1 or target2&amp;#39;s<br /> name and we will only match that target&amp;#39;s tpgs when we loop over the<br /> vs-&gt;vs_tpg. We will then return from the function without doing<br /> target_undepend_item on the tpgs.<br /> <br /> Because of all these bugs, it looks like being able to call<br /> vhost_scsi_set_endpoint multiple times was never supported. The major<br /> user, QEMU, already has checks to prevent this use case. So to fix the<br /> issues, this patch prevents vhost_scsi_set_endpoint from being called<br /> if it&amp;#39;s already successfully added tpgs. To add, remove or change the<br /> tpg config or target name, you must do a vhost_scsi_clear_endpoint<br /> first.