Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t trust firmware n_channels<br /> <br /> If the firmware sends us a corrupted MCC response with<br /> n_channels much larger than the command response can be,<br /> we might copy far too much (uninitialized) memory and<br /> even crash if the n_channels is large enough to make it<br /> run out of the one page allocated for the FW response.<br /> <br /> Fix that by checking the lengths. Doing a

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop<br /> <br /> With this refcnt added in sctp_stream_priorities, we don&amp;#39;t need to<br /> traverse all streams to check if the prio is used by other streams<br /> when freeing one stream&amp;#39;s prio in sctp_sched_prio_free_sid(). This<br /> can avoid a nested loop (up to 65535 * 65535), which may cause a<br /> stuck as Ying reported:<br /> <br /> watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]<br /> Call Trace:<br /> <br /> sctp_sched_prio_free_sid+0xab/0x100 [sctp]<br /> sctp_stream_free_ext+0x64/0xa0 [sctp]<br /> sctp_stream_free+0x31/0x50 [sctp]<br /> sctp_association_free+0xa5/0x200 [sctp]<br /> <br /> Note that it doesn&amp;#39;t need to use refcount_t type for this counter,<br /> as its accessing is always protected under the sock lock.<br /> <br /> v1-&gt;v2:<br /> - add a check in sctp_sched_prio_set to avoid the possible prio_head<br /> refcnt overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sifive: Fix refcount leak in sifive_gpio_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix deadlock in tc route query code<br /> <br /> Cited commit causes ABBA deadlock[0] when peer flows are created while<br /> holding the devcom rw semaphore. Due to peer flows offload implementation<br /> the lock is taken much higher up the call chain and there is no obvious way<br /> to easily fix the deadlock. Instead, since tc route query code needs the<br /> peer eswitch structure only to perform a lookup in xarray and doesn&amp;#39;t<br /> perform any sleeping operations with it, refactor the code for lockless<br /> execution in following ways:<br /> <br /> - RCUify the devcom &amp;#39;data&amp;#39; pointer. When resetting the pointer<br /> synchronously wait for RCU grace period before returning. This is fine<br /> since devcom is currently only used for synchronization of<br /> pairing/unpairing of eswitches which is rare and already expensive as-is.<br /> <br /> - Wrap all usages of &amp;#39;paired&amp;#39; boolean in {READ|WRITE}_ONCE(). The flag has<br /> already been used in some unlocked contexts without proper<br /> annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn&amp;#39;t<br /> an issue since all relevant code paths checked it again after obtaining the<br /> devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as<br /> "best effort" check to return NULL when devcom is being unpaired. Note that<br /> while RCU read lock doesn&amp;#39;t prevent the unpaired flag from being changed<br /> concurrently it still guarantees that reader can continue to use &amp;#39;data&amp;#39;.<br /> <br /> - Refactor mlx5e_tc_query_route_vport() function to use new<br /> mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.<br /> <br /> [0]:<br /> <br /> [ 164.599612] ======================================================<br /> [ 164.600142] WARNING: possible circular locking dependency detected<br /> [ 164.600667] 6.3.0-rc3+ #1 Not tainted<br /> [ 164.601021] ------------------------------------------------------<br /> [ 164.601557] handler1/3456 is trying to acquire lock:<br /> [ 164.601998] ffff88811f1714b0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.603078]<br /> but task is already holding lock:<br /> [ 164.603617] ffff88810137fc98 (&amp;comp-&gt;sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.604459]<br /> which lock already depends on the new lock.<br /> <br /> [ 164.605190]<br /> the existing dependency chain (in reverse order) is:<br /> [ 164.605848]<br /> -&gt; #1 (&amp;comp-&gt;sem){++++}-{3:3}:<br /> [ 164.606380] down_read+0x39/0x50<br /> [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]<br /> [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]<br /> [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]<br /> [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]<br /> [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]<br /> [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]<br /> [ 164.610741] tc_setup_cb_add+0xd4/0x200<br /> [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]<br /> [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower]<br /> [ 164.612116] tc_new_tfilter+0x3fc/0xd20<br /> [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0<br /> [ 164.612936] netlink_rcv_skb+0x54/0x100<br /> [ 164.613339] netlink_unicast+0x190/0x250<br /> [ 164.613746] netlink_sendmsg+0x245/0x4a0<br /> [ 164.614150] sock_sendmsg+0x38/0x60<br /> [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0<br /> [ 164.614934] ___sys_sendmsg+0x80/0xc0<br /> [ 164.615320] __sys_sendmsg+0x51/0x90<br /> [ 164.615701] do_syscall_64+0x3d/0x90<br /> [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 164.616568]<br /> -&gt; #0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}:<br /> [ 164.617210] __lock_acquire+0x159e/0x26e0<br /> [ 164.617638] lock_acquire+0xc2/0x2a0<br /> [ 164.618018] __mutex_lock+0x92/0xcd0<br /> [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.618943] post_process_attr+0x153/0x2d0 [<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Release folio lock on fscache read hit.<br /> <br /> Under the current code, when cifs_readpage_worker is called, the call<br /> contract is that the callee should unlock the page. This is documented<br /> in the read_folio section of Documentation/filesystems/vfs.rst as:<br /> <br /> &gt; The filesystem should unlock the folio once the read has completed,<br /> &gt; whether it was successful or not.<br /> <br /> Without this change, when fscache is in use and cache hit occurs during<br /> a read, the page lock is leaked, producing the following stack on<br /> subsequent reads (via mmap) to the page:<br /> <br /> $ cat /proc/3890/task/12864/stack<br /> [] folio_wait_bit_common+0x124/0x350<br /> [] filemap_read_folio+0xad/0xf0<br /> [] filemap_fault+0x8b1/0xab0<br /> [] __do_fault+0x39/0x150<br /> [] do_fault+0x25c/0x3e0<br /> [] __handle_mm_fault+0x6ca/0xc70<br /> [] handle_mm_fault+0xe9/0x350<br /> [] do_user_addr_fault+0x225/0x6c0<br /> [] exc_page_fault+0x84/0x1b0<br /> [] asm_exc_page_fault+0x27/0x30<br /> <br /> This requires a reboot to resolve; it is a deadlock.<br /> <br /> Note however that the call to cifs_readpage_from_fscache does mark the<br /> page clean, but does not free the folio lock. This happens in<br /> __cifs_readpage_from_fscache on success. Releasing the lock at that<br /> point however is not appropriate as cifs_readahead also calls<br /> cifs_readpage_from_fscache and *does* unconditionally release the lock<br /> after its return. This change therefore effectively makes<br /> cifs_readpage_worker work like cifs_readahead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix resource leak in device_add()<br /> <br /> When calling kobject_add() failed in device_add(), it will call<br /> cleanup_glue_dir() to free resource. But in kobject_add(),<br /> dev-&gt;kobj.parent has been set to NULL. This will cause resource leak.<br /> <br /> The process is as follows:<br /> device_add()<br /> get_device_parent()<br /> class_dir_create_and_add()<br /> kobject_add() //kobject_get()<br /> ...<br /> dev-&gt;kobj.parent = kobj;<br /> ...<br /> kobject_add() //failed, but set dev-&gt;kobj.parent = NULL<br /> ...<br /> glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto<br /> //"Error" label<br /> ...<br /> cleanup_glue_dir() //becaues glue_dir is NULL, not call<br /> //kobject_put()<br /> <br /> The preceding problem may cause insmod mac80211_hwsim.ko to failed.<br /> sysfs: cannot create duplicate filename &amp;#39;/devices/virtual/mac80211_hwsim&amp;#39;<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8e/0xd1<br /> sysfs_warn_dup.cold+0x1c/0x29<br /> sysfs_create_dir_ns+0x224/0x280<br /> kobject_add_internal+0x2aa/0x880<br /> kobject_add+0x135/0x1a0<br /> get_device_parent+0x3d7/0x590<br /> device_add+0x2aa/0x1cb0<br /> device_create_groups_vargs+0x1eb/0x260<br /> device_create+0xdc/0x110<br /> mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]<br /> init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]<br /> do_one_initcall+0x10f/0x630<br /> do_init_module+0x19f/0x5e0<br /> load_module+0x64b7/0x6eb0<br /> __do_sys_finit_module+0x140/0x200<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> kobject_add_internal failed for mac80211_hwsim with -EEXIST, don&amp;#39;t try to<br /> register things with the same name in the same directory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: check for station first in client probe<br /> <br /> When probing a client, first check if we have it, and then<br /> check for the channel context, otherwise you can trigger<br /> the warning there easily by probing when the AP isn&amp;#39;t even<br /> started yet. Since a client existing means the AP is also<br /> operating, we can then keep the warning.<br /> <br /> Also simplify the moved code a bit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Sync IRQ works before buffer destruction<br /> <br /> If something was written to the buffer just before destruction,<br /> it may be possible (maybe not in a real system, but it did<br /> happen in ARCH=um with time-travel) to destroy the ringbuffer<br /> before the IRQ work ran, leading this KASAN report (or a crash<br /> without KASAN):<br /> <br /> BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a<br /> Read of size 8 at addr 000000006d640a48 by task swapper/0<br /> <br /> CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7<br /> Stack:<br /> 60c4f20f 0c203d48 41b58ab3 60f224fc<br /> 600477fa 60f35687 60c4f20f 601273dd<br /> 00000008 6101eb00 6101eab0 615be548<br /> Call Trace:<br /> [] show_stack+0x25e/0x282<br /> [] dump_stack_lvl+0x96/0xfd<br /> [] print_report+0x1a7/0x5a8<br /> [] kasan_report+0xc1/0xe9<br /> [] __asan_report_load8_noabort+0x1b/0x1d<br /> [] irq_work_run_list+0x11a/0x13a<br /> [] irq_work_tick+0x24/0x34<br /> [] update_process_times+0x162/0x196<br /> [] tick_sched_handle+0x1a4/0x1c3<br /> [] tick_sched_timer+0x79/0x10c<br /> [] __hrtimer_run_queues.constprop.0+0x425/0x695<br /> [] hrtimer_interrupt+0x16c/0x2c4<br /> [] um_timer+0x164/0x183<br /> [...]<br /> <br /> Allocated by task 411:<br /> save_stack_trace+0x99/0xb5<br /> stack_trace_save+0x81/0x9b<br /> kasan_save_stack+0x2d/0x54<br /> kasan_set_track+0x34/0x3e<br /> kasan_save_alloc_info+0x25/0x28<br /> ____kasan_kmalloc+0x8b/0x97<br /> __kasan_kmalloc+0x10/0x12<br /> __kmalloc+0xb2/0xe8<br /> load_elf_phdrs+0xee/0x182<br /> [...]<br /> <br /> The buggy address belongs to the object at 000000006d640800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 584 bytes inside of<br /> freed 1024-byte region [000000006d640800, 000000006d640c00)<br /> <br /> Add the appropriate irq_work_sync() so the work finishes before<br /> the buffers are destroyed.<br /> <br /> Prior to the commit in the Fixes tag below, there was only a<br /> single global IRQ work, so this issue didn&amp;#39;t exist.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()<br /> <br /> Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the<br /> perf_sample_event_took() function was added to report time spent in<br /> overflow interrupts. If the interrupt takes too long, the perf framework<br /> will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.<br /> When hwc-&gt;interrupts is larger than max_samples_per_tick, the<br /> hwc-&gt;interrupts will be set to MAX_INTERRUPTS, and events will be<br /> throttled within the __perf_event_account_interrupt() function.<br /> <br /> However, the RISC-V PMU driver doesn&amp;#39;t call riscv_pmu_stop() to update the<br /> PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()<br /> function to avoid throttling. When the perf framework unthrottled the event<br /> in the timer interrupt handler, it triggers riscv_pmu_start() function<br /> and causes a WARN_ON_ONCE() warning, as shown below:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e<br /> Modules linked in:<br /> CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1<br /> Hardware name: SiFive (DT)<br /> epc : riscv_pmu_start+0x7c/0x8e<br /> ra : riscv_pmu_start+0x28/0x8e<br /> epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0<br /> gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0<br /> t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720<br /> s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000<br /> a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000<br /> a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030<br /> s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00<br /> s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000<br /> s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340<br /> s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796<br /> t5 : 0000000700000000 t6 : ffffaf8005269870<br /> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [] riscv_pmu_start+0x7c/0x8e<br /> [] perf_adjust_freq_unthr_context+0x15e/0x174<br /> [] perf_event_task_tick+0x88/0x9c<br /> [] scheduler_tick+0xfe/0x27c<br /> [] update_process_times+0x9a/0xba<br /> [] tick_sched_handle+0x32/0x66<br /> [] tick_sched_timer+0x64/0xb0<br /> [] __hrtimer_run_queues+0x156/0x2f4<br /> [] hrtimer_interrupt+0xe2/0x1fe<br /> [] riscv_timer_interrupt+0x38/0x42<br /> [] handle_percpu_devid_irq+0x90/0x1d2<br /> [] generic_handle_domain_irq+0x28/0x36<br /> <br /> After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,<br /> they don&amp;#39;t call *_pmu_stop() to update with PERF_HES_STOPPED flag<br /> after perf_event_overflow() function nor do they add PERF_HES_STOPPED<br /> flag checking in *_pmu_start() which don&amp;#39;t cause this warning.<br /> <br /> Thus, it&amp;#39;s recommended to remove this unnecessary check in<br /> riscv_pmu_start() function to prevent this warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process<br /> <br /> There are two states for ubifs writing pages:<br /> 1. Dirty, Private<br /> 2. Not Dirty, Not Private<br /> <br /> The normal process cannot go to ubifs_releasepage() which means there<br /> exists pages being private but not dirty. Reproducer[1] shows that it<br /> could occur (which maybe related to [2]) with following process:<br /> <br /> PA PB PC<br /> lock(page)[PA]<br /> ubifs_write_end<br /> attach_page_private // set Private<br /> __set_page_dirty_nobuffers // set Dirty<br /> unlock(page)<br /> <br /> write_cache_pages[PA]<br /> lock(page)<br /> clear_page_dirty_for_io(page) // clear Dirty<br /> ubifs_writepage<br /> <br /> do_truncation[PB]<br /> truncate_setsize<br /> i_size_write(inode, newsize) // newsize = 0<br /> <br /> i_size = i_size_read(inode) // i_size = 0<br /> end_index = i_size &gt;&gt; PAGE_SHIFT<br /> if (page-&gt;index &gt; end_index)<br /> goto out // jump<br /> out:<br /> unlock(page) // Private, Not Dirty<br /> <br /> generic_fadvise[PC]<br /> lock(page)<br /> invalidate_inode_page<br /> try_to_release_page<br /> ubifs_releasepage<br /> ubifs_assert(c, 0)<br /> // bad assertion!<br /> unlock(page)<br /> truncate_pagecache[PB]<br /> <br /> Then we may get following assertion failed:<br /> UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:<br /> UBIFS assert failed: 0, in fs/ubifs/file.c:1513<br /> UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:<br /> switched to read-only mode, error -22<br /> CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308<br /> Call Trace:<br /> dump_stack+0x13/0x1b<br /> ubifs_ro_mode+0x54/0x60 [ubifs]<br /> ubifs_assert_failed+0x4b/0x80 [ubifs]<br /> ubifs_releasepage+0x67/0x1d0 [ubifs]<br /> try_to_release_page+0x57/0xe0<br /> invalidate_inode_page+0xfb/0x130<br /> __invalidate_mapping_pages+0xb9/0x280<br /> invalidate_mapping_pagevec+0x12/0x20<br /> generic_fadvise+0x303/0x3c0<br /> ksys_fadvise64_64+0x4c/0xb0<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=215373<br /> [2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: reject unhashed sockets in bpf_sk_assign<br /> <br /> The semantics for bpf_sk_assign are as follows:<br /> <br /> sk = some_lookup_func()<br /> bpf_sk_assign(skb, sk)<br /> bpf_sk_release(sk)<br /> <br /> That is, the sk is not consumed by bpf_sk_assign. The function<br /> therefore needs to make sure that sk lives long enough to be<br /> consumed from __inet_lookup_skb. The path through the stack for a<br /> TCPv4 packet is roughly:<br /> <br /> netif_receive_skb_core: takes RCU read lock<br /> __netif_receive_skb_core:<br /> sch_handle_ingress:<br /> tcf_classify:<br /> bpf_sk_assign()<br /> deliver_ptype_list_skb:<br /> deliver_skb:<br /> ip_packet_type-&gt;func == ip_rcv:<br /> ip_rcv_core:<br /> ip_rcv_finish_core:<br /> dst_input:<br /> ip_local_deliver:<br /> ip_local_deliver_finish:<br /> ip_protocol_deliver_rcu:<br /> tcp_v4_rcv:<br /> __inet_lookup_skb:<br /> skb_steal_sock<br /> <br /> The existing helper takes advantage of the fact that everything<br /> happens in the same RCU critical section: for sockets with<br /> SOCK_RCU_FREE set bpf_sk_assign never takes a reference.<br /> skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put<br /> if necessary.<br /> <br /> This approach assumes that SOCK_RCU_FREE is never set on a sk<br /> between bpf_sk_assign and skb_steal_sock, but this invariant is<br /> violated by unhashed UDP sockets. A new UDP socket is created<br /> in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only<br /> added in udp_lib_get_port() which happens when a socket is bound.<br /> <br /> When bpf_sk_assign was added it wasn&amp;#39;t possible to access unhashed<br /> UDP sockets from BPF, so this wasn&amp;#39;t a problem. This changed<br /> in commit 0c48eefae712 ("sock_map: Lift socket state restriction<br /> for datagram sockets"), but the helper wasn&amp;#39;t adjusted accordingly.<br /> The following sequence of events will therefore lead to a refcount<br /> leak:<br /> <br /> 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.<br /> 2. Pull socket out of sockmap and bpf_sk_assign it. Since<br /> SOCK_RCU_FREE is not set we increment the refcount.<br /> 3. bind() or connect() the socket, setting SOCK_RCU_FREE.<br /> 4. skb_steal_sock will now set refcounted = false due to<br /> SOCK_RCU_FREE.<br /> 5. tcp_v4_rcv() skips sock_put().<br /> <br /> Fix the problem by rejecting unhashed sockets in bpf_sk_assign().<br /> This matches the behaviour of __inet_lookup_skb which is ultimately<br /> the goal of bpf_sk_assign().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix multiple LUN_RESET handling<br /> <br /> This fixes a bug where an initiator thinks a LUN_RESET has cleaned up<br /> running commands when it hasn&amp;#39;t. The bug was added in commit 51ec502a3266<br /> ("target: Delete tmr from list before processing").<br /> <br /> The problem occurs when:<br /> <br /> 1. We have N I/O cmds running in the target layer spread over 2 sessions.<br /> <br /> 2. The initiator sends a LUN_RESET for each session.<br /> <br /> 3. session1&amp;#39;s LUN_RESET loops over all the running commands from both<br /> sessions and moves them to its local drain_task_list.<br /> <br /> 4. session2&amp;#39;s LUN_RESET does not see the LUN_RESET from session1 because<br /> the commit above has it remove itself. session2 also does not see any<br /> commands since the other reset moved them off the state lists.<br /> <br /> 5. sessions2&amp;#39;s LUN_RESET will then complete with a successful response.<br /> <br /> 6. sessions2&amp;#39;s inititor believes the running commands on its session are<br /> now cleaned up due to the successful response and cleans up the running<br /> commands from its side. It then restarts them.<br /> <br /> 7. The commands do eventually complete on the backend and the target<br /> starts to return aborted task statuses for them. The initiator will<br /> either throw a invalid ITT error or might accidentally lookup a new<br /> task if the ITT has been reallocated already.<br /> <br /> Fix the bug by reverting the patch, and serialize the execution of<br /> LUN_RESETs and Preempt and Aborts.<br /> <br /> Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,<br /> because it turns out the original patch fixed a bug that was not<br /> mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second<br /> LUN_RESET and wait on it. Then the second reset will run<br /> core_tmr_drain_tmr_list and see the first reset and wait on it resulting in<br /> a deadlock.