Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() will check NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix hang during unmount when block group reclaim task is running<br /> <br /> When we start an unmount, at close_ctree(), if we have the reclaim task<br /> running and in the middle of a data block group relocation, we can trigger<br /> a deadlock when stopping an async reclaim task, producing a trace like the<br /> following:<br /> <br /> [629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000<br /> [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]<br /> [629724.501267] Call Trace:<br /> [629724.501759] <br /> [629724.502174] __schedule+0x3cb/0xed0<br /> [629724.502842] schedule+0x4e/0xb0<br /> [629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]<br /> [629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0<br /> [629724.505442] flush_space+0x423/0x630 [btrfs]<br /> [629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50<br /> [629724.507259] ? lock_release+0x220/0x4a0<br /> [629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]<br /> [629724.508940] ? do_raw_spin_unlock+0x4b/0xa0<br /> [629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]<br /> [629724.510922] process_one_work+0x252/0x5a0<br /> [629724.511694] ? process_one_work+0x5a0/0x5a0<br /> [629724.512508] worker_thread+0x52/0x3b0<br /> [629724.513220] ? process_one_work+0x5a0/0x5a0<br /> [629724.514021] kthread+0xf2/0x120<br /> [629724.514627] ? kthread_complete_and_exit+0x20/0x20<br /> [629724.515526] ret_from_fork+0x22/0x30<br /> [629724.516236] <br /> [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000<br /> [629724.518269] Call Trace:<br /> [629724.518746] <br /> [629724.519160] __schedule+0x3cb/0xed0<br /> [629724.519835] schedule+0x4e/0xb0<br /> [629724.520467] schedule_timeout+0xed/0x130<br /> [629724.521221] ? lock_release+0x220/0x4a0<br /> [629724.521946] ? lock_acquired+0x19c/0x420<br /> [629724.522662] ? trace_hardirqs_on+0x1b/0xe0<br /> [629724.523411] __wait_for_common+0xaf/0x1f0<br /> [629724.524189] ? usleep_range_state+0xb0/0xb0<br /> [629724.524997] __flush_work+0x26d/0x530<br /> [629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140<br /> [629724.526580] ? lock_acquire+0x1a0/0x310<br /> [629724.527324] __cancel_work_timer+0x137/0x1c0<br /> [629724.528190] close_ctree+0xfd/0x531 [btrfs]<br /> [629724.529000] ? evict_inodes+0x166/0x1c0<br /> [629724.529510] generic_shutdown_super+0x74/0x120<br /> [629724.530103] kill_anon_super+0x14/0x30<br /> [629724.530611] btrfs_kill_super+0x12/0x20 [btrfs]<br /> [629724.531246] deactivate_locked_super+0x31/0xa0<br /> [629724.531817] cleanup_mnt+0x147/0x1c0<br /> [629724.532319] task_work_run+0x5c/0xa0<br /> [629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0<br /> [629724.533598] syscall_exit_to_user_mode+0x16/0x40<br /> [629724.534200] do_syscall_64+0x48/0x90<br /> [629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [629724.535318] RIP: 0033:0x7fa2b90437a7<br /> [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6<br /> [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7<br /> [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0<br /> [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200<br /> [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000<br /> [629724.541796] <br /> <br /> This happens because:<br /> <br /> 1) Before entering close_ctree() we have the async block group reclaim<br /> task running and relocating a data block group;<br /> <br /> 2) There&amp;#39;s an async metadata (or data) space reclaim task running;<br /> <br /> 3) We enter close_ctree() and park the cleaner kthread;<br /> <br /> 4) The async space reclaim task is at flush_space() and runs all the<br /> existing delayed iputs;<br /> <br /> 5) Before the async space reclaim task calls<br /> btrfs_wait_on_delayed_iputs(), the block group reclaim task which is<br /> doing the data block group relocation, creates a delayed iput at<br /> replace_file_extents() (called when COWing leaves that have file extent<br /> items pointing to relocated data exten<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Store vhost pointer during subcrq allocation<br /> <br /> Currently the back pointer from a queue to the vhost adapter isn&amp;#39;t set<br /> until after subcrq interrupt registration. The value is available when a<br /> queue is first allocated and can/should be also set for primary and async<br /> queues as well as subcrqs.<br /> <br /> This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS<br /> interrupt controller where a pending subcrq interrupt from the previous<br /> kernel can be replayed immediately upon IRQ registration resulting in<br /> dereference of a garbage backpointer in ibmvfc_interrupt_scsi().<br /> <br /> Kernel attempted to read user page (58) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000058<br /> Faulting instruction address: 0xc008000003216a08<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc]<br /> LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270<br /> Call Trace:<br /> [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable)<br /> [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270<br /> [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188<br /> [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310<br /> [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80<br /> [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0<br /> [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130<br /> [c000000014622f60] [0000000020000000] 0x20000000<br /> [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0<br /> [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0<br /> [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170<br /> [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0<br /> [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0<br /> [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230<br /> [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc]<br /> [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc]<br /> [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc]<br /> [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc]<br /> [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf<br /> <br /> of_graph_get_remote_node() returns remote device node pointer with<br /> refcount incremented, we should use of_node_put() on it<br /> when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/488473/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: disable the elevator int del_gendisk<br /> <br /> The elevator is only used for file system requests, which are stopped in<br /> del_gendisk. Move disabling the elevator and freeing the scheduler tags<br /> to the end of del_gendisk instead of doing that work in disk_release and<br /> blk_cleanup_queue to avoid a use after free on q-&gt;tag_set from<br /> disk_release as the tag_set might not be alive at that point.<br /> <br /> Move the blk_qos_exit call as well, as it just depends on the elevator<br /> exit and would be the only reason to keep the not exactly cheap queue<br /> freeze in disk_release.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: fix a use-after-free issue in igb_clean_tx_ring<br /> <br /> Fix the following use-after-free bug in igb_clean_tx_ring routine when<br /> the NIC is running in XDP mode. The issue can be triggered redirecting<br /> traffic into the igb NIC and then closing the device while the traffic<br /> is flowing.<br /> <br /> [ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9<br /> [ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017<br /> [ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0<br /> [ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282<br /> [ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000<br /> [ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0<br /> [ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058<br /> [ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090<br /> [ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000<br /> [ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000<br /> [ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0<br /> [ 73.426565] Call Trace:<br /> [ 73.429087] <br /> [ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb]<br /> [ 73.436002] igb_down+0x1d7/0x220 [igb]<br /> [ 73.439974] __igb_close+0x3c/0x120 [igb]<br /> [ 73.444118] igb_xdp+0x10c/0x150 [igb]<br /> [ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb]<br /> [ 73.453362] dev_xdp_install+0xda/0x110<br /> [ 73.457371] dev_xdp_attach+0x1da/0x550<br /> [ 73.461369] do_setlink+0xfd0/0x10f0<br /> [ 73.465166] ? __nla_validate_parse+0x89/0xc70<br /> [ 73.469714] rtnl_setlink+0x11a/0x1e0<br /> [ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0<br /> [ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130<br /> [ 73.482258] netlink_rcv_skb+0x8d/0x110<br /> [ 73.486229] netlink_unicast+0x230/0x340<br /> [ 73.490317] netlink_sendmsg+0x215/0x470<br /> [ 73.494395] __sys_sendto+0x179/0x190<br /> [ 73.498268] ? move_addr_to_user+0x37/0x70<br /> [ 73.502547] ? __sys_getsockname+0x84/0xe0<br /> [ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0<br /> [ 73.511349] ? __sys_setsockopt+0xc8/0x1d0<br /> [ 73.515636] __x64_sys_sendto+0x20/0x30<br /> [ 73.519603] do_syscall_64+0x3b/0x80<br /> [ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 73.528712] RIP: 0033:0x7ff38d41f20c<br /> [ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> [ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c<br /> [ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003<br /> [ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000<br /> [ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0<br /> [ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30<br /> [ 73.596545] <br /> [ 73.598842] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix use-after-free Read in tipc_named_reinit<br /> <br /> syzbot found the following issue on:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0<br /> net/tipc/name_distr.c:413<br /> Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764<br /> <br /> CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted<br /> 5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0<br /> Hardware name: Google Compute Engine/Google Compute Engine,<br /> BIOS Google 01/01/2011<br /> Workqueue: events tipc_net_finalize_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0xeb/0x495<br /> mm/kasan/report.c:313<br /> print_report mm/kasan/report.c:429 [inline]<br /> kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491<br /> tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413<br /> tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138<br /> process_one_work+0x996/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298<br /> <br /> [...]<br /> ==================================================================<br /> <br /> In the commit<br /> d966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"),<br /> the cancel_work_sync() function just to make sure ONLY the work<br /> tipc_net_finalize_work() is executing/pending on any CPU completed before<br /> tipc namespace is destroyed through tipc_exit_net(). But this function<br /> is not guaranteed the work is the last queued. So, the destroyed instance<br /> may be accessed in the work which will try to enqueue later.<br /> <br /> In order to completely fix, we re-order the calling of cancel_work_sync()<br /> to make sure the work tipc_net_finalize_work() was last queued and it<br /> must be completed by calling cancel_work_sync().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix request_sock leak in sk lookup helpers<br /> <br /> A customer reported a request_socket leak in a Calico cloud environment. We<br /> found that a BPF program was doing a socket lookup with takes a refcnt on<br /> the socket and that it was finding the request_socket but returning the parent<br /> LISTEN socket via sk_to_full_sk() without decrementing the child request socket<br /> 1st, resulting in request_sock slab object leak. This patch retains the<br /> existing behaviour of returning full socks to the caller but it also decrements<br /> the child request_socket if one is present before doing so to prevent the leak.<br /> <br /> Thanks to Curtis Taylor for all the help in diagnosing and testing this. And<br /> thanks to Antoine Tenart for the reproducer and patch input.<br /> <br /> v2 of this patch contains, refactor as per Daniel Borkmann&amp;#39;s suggestions to<br /> validate RCU flags on the listen socket so that it balances with bpf_sk_release()<br /> and update comments as per Martin KaFai Lau&amp;#39;s suggestion. One small change to<br /> Daniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extra<br /> instruction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: use get_random_u32 instead of prandom<br /> <br /> bh might occur while updating per-cpu rnd_state from user context,<br /> ie. local_out path.<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: nginx/2725<br /> caller is nft_ng_random_eval+0x24/0x54 [nft_numgen]<br /> Call Trace:<br /> check_preemption_disabled+0xde/0xe0<br /> nft_ng_random_eval+0x24/0x54 [nft_numgen]<br /> <br /> Use the random driver instead, this also avoids need for local prandom<br /> state. Moreover, prandom now uses the random driver since d4150779e60f<br /> ("random32: use real rng for non-deterministic randomness").<br /> <br /> Based on earlier patch from Pablo Neira.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filemap: Handle sibling entries in filemap_get_read_batch()<br /> <br /> If a read races with an invalidation followed by another read, it is<br /> possible for a folio to be replaced with a higher-order folio. If that<br /> happens, we&amp;#39;ll see a sibling entry for the new folio in the next iteration<br /> of the loop. This manifests as a NULL pointer dereference while holding<br /> the RCU read lock.<br /> <br /> Handle this by simply returning. The next call will find the new folio<br /> and handle it correctly. The other ways of handling this rare race are<br /> more complex and it&amp;#39;s just not worth it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: add missing TID updates on slab deactivation<br /> <br /> The fastpath in slab_alloc_node() assumes that c-&gt;slab is stable as long as<br /> the TID stays the same. However, two places in __slab_alloc() currently<br /> don&amp;#39;t update the TID when deactivating the CPU slab.<br /> <br /> If multiple operations race the right way, this could lead to an object<br /> getting lost; or, in an even more unlikely situation, it could even lead to<br /> an object being freed onto the wrong slab&amp;#39;s freelist, messing up the<br /> `inuse` counter and eventually causing a page to be freed to the page<br /> allocator while it still contains slab objects.<br /> <br /> (I haven&amp;#39;t actually tested these cases though, this is just based on<br /> looking at the code. Writing testcases for this stuff seems like it&amp;#39;d be<br /> a pain...)<br /> <br /> The race leading to state inconsistency is (all operations on the same CPU<br /> and kmem_cache):<br /> <br /> - task A: begin do_slab_free():<br /> - read TID<br /> - read pcpu freelist (==NULL)<br /> - check `slab == c-&gt;slab` (true)<br /> - [PREEMPT A-&gt;B]<br /> - task B: begin slab_alloc_node():<br /> - fastpath fails (`c-&gt;freelist` is NULL)<br /> - enter __slab_alloc()<br /> - slub_get_cpu_ptr() (disables preemption)<br /> - enter ___slab_alloc()<br /> - take local_lock_irqsave()<br /> - read c-&gt;freelist as NULL<br /> - get_freelist() returns NULL<br /> - write `c-&gt;slab = NULL`<br /> - drop local_unlock_irqrestore()<br /> - goto new_slab<br /> - slub_percpu_partial() is NULL<br /> - get_partial() returns NULL<br /> - slub_put_cpu_ptr() (enables preemption)<br /> - [PREEMPT B-&gt;A]<br /> - task A: finish do_slab_free():<br /> - this_cpu_cmpxchg_double() succeeds()<br /> - [CORRUPT STATE: c-&gt;slab==NULL, c-&gt;freelist!=NULL]<br /> <br /> From there, the object on c-&gt;freelist will get lost if task B is allowed to<br /> continue from here: It will proceed to the retry_load_slab label,<br /> set c-&gt;slab, then jump to load_freelist, which clobbers c-&gt;freelist.<br /> <br /> But if we instead continue as follows, we get worse corruption:<br /> <br /> - task A: run __slab_free() on object from other struct slab:<br /> - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial)<br /> - task A: run slab_alloc_node() with NUMA node constraint:<br /> - fastpath fails (c-&gt;slab is NULL)<br /> - call __slab_alloc()<br /> - slub_get_cpu_ptr() (disables preemption)<br /> - enter ___slab_alloc()<br /> - c-&gt;slab is NULL: goto new_slab<br /> - slub_percpu_partial() is non-NULL<br /> - set c-&gt;slab to slub_percpu_partial(c)<br /> - [CORRUPT STATE: c-&gt;slab points to slab-1, c-&gt;freelist has objects<br /> from slab-2]<br /> - goto redo<br /> - node_match() fails<br /> - goto deactivate_slab<br /> - existing c-&gt;freelist is passed into deactivate_slab()<br /> - inuse count of slab-1 is decremented to account for object from<br /> slab-2<br /> <br /> At this point, the inuse count of slab-1 is 1 lower than it should be.<br /> This means that if we free all allocated objects in slab-1 except for one,<br /> SLUB will think that slab-1 is completely unused, and may free its page,<br /> leading to use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Allocate/free queue resource only during probe/remove<br /> <br /> Currently, the sub-queues and event pool resources are allocated/freed for<br /> every CRQ connection event such as reset and LPM. This exposes the driver<br /> to a couple issues. First the inefficiency of freeing and reallocating<br /> memory that can simply be resued after being sanitized. Further, a system<br /> under memory pressue runs the risk of allocation failures that could result<br /> in a crippled driver. Finally, there is a race window where command<br /> submission/compeletion can try to pull/return elements from/to an event<br /> pool that is being deleted or already has been deleted due to the lack of<br /> host state around freeing/allocating resources. The following is an example<br /> of list corruption following a live partition migration (LPM):<br /> <br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nft_counter nft_compat nf_tables nfnetlink rpadlpar_io rpaphp xsk_diag nfsv3 nfs_acl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth vmx_crypto dm_multipath dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse<br /> CPU: 0 PID: 2108 Comm: ibmvfc_0 Kdump: loaded Not tainted 5.14.0-70.9.1.el9_0.ppc64le #1<br /> NIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10<br /> REGS: c00000025c10b760 TRAP: 0700 Not tainted (5.14.0-70.9.1.el9_0.ppc64le)<br /> MSR: 800000000282b033 CR: 2800028f XER: 0000000f<br /> CFAR: c0000000001f55bc IRQMASK: 0<br /> GPR00: c0000000007c4bac c00000025c10ba00 c000000002a47c00 000000000000004e<br /> GPR04: c0000031e3006f88 c0000031e308bd00 c00000025c10b768 0000000000000027<br /> GPR08: 0000000000000000 c0000031e3009dc0 00000031e0eb0000 0000000000000000<br /> GPR12: c0000031e2ffffa8 c000000002dd0000 c000000000187108 c00000020fcee2c0<br /> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> GPR20: 0000000000000000 0000000000000000 0000000000000000 c008000002f81300<br /> GPR24: 5deadbeef0000100 5deadbeef0000122 c000000263ba6910 c00000024cc88000<br /> GPR28: 000000000000003c c0000002430a0000 c0000002430ac300 000000000000c300<br /> NIP [c0000000007c4bb0] __list_del_entry_valid+0x90/0x100<br /> LR [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100<br /> Call Trace:<br /> [c00000025c10ba00] [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 (unreliable)<br /> [c00000025c10ba60] [c008000002f42284] ibmvfc_free_queue+0xec/0x210 [ibmvfc]<br /> [c00000025c10bb10] [c008000002f4246c] ibmvfc_deregister_scsi_channel+0xc4/0x160 [ibmvfc]<br /> [c00000025c10bba0] [c008000002f42580] ibmvfc_release_sub_crqs+0x78/0x130 [ibmvfc]<br /> [c00000025c10bc20] [c008000002f4f6cc] ibmvfc_do_work+0x5c4/0xc70 [ibmvfc]<br /> [c00000025c10bce0] [c008000002f4fdec] ibmvfc_work+0x74/0x1e8 [ibmvfc]<br /> [c00000025c10bda0] [c0000000001872b8] kthread+0x1b8/0x1c0<br /> [c00000025c10be10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64<br /> Instruction dump:<br /> 40820034 38600001 38210060 4e800020 7c0802a6 7c641b78 3c62fe7a 7d254b78<br /> 3863b590 f8010070 4ba309cd 60000000 7c0802a6 3c62fe7a 3863b640<br /> ---[ end trace 11a2b65a92f8b66c ]---<br /> ibmvfc 30000003: Send warning. Receive queue closed, will retry.<br /> <br /> Add registration/deregistration helpers that are called instead during<br /> connection resets to sanitize and reconfigure the queues.