xamxte/cve-to-cwe huggingface dataset:
CVE-2022-50627: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix monitor mode bringup crash  When the interface is brought up in monitor mode, it leads to NULL pointer dereference crash. This crash happens when the packet type is extracted for a SKB. This extraction which is present in the received msdu delivery path,is not needed for the monitor ring packets since they are all RAW packets. Hence appending the flags with "RX_FLAG_ONLY_MONITOR" to skip that extraction.  Observed calltrace:  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000064 Mem abort info:   ESR = 0x0000000096000004   EC = 0x25: DABT (current EL), IL = 32 bits   SET = 0, FnV = 0   EA = 0, S1PTW = 0   FSC = 0x04: level 0 translation fault Data abort info:   ISV = 0, ISS = 0x00000004   CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048517000 [0000000000000064] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ath11k_pci ath11k qmi_helpers CPU: 2 PID: 1781 Comm: napi/-271 Not tainted 6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6 Hardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k] lr : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k] sp : ffff80000ef5bb10 x29: ffff80000ef5bb10 x28: 0000000000000000 x27: ffff000007baafa0 x26: ffff000014a91ed0 x25: 0000000000000000 x24: 0000000000000000 x23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600 x20: 0000000000000000 x19: ffff800002b77740 x18: 0000000000000006 x17: 736564203634343a x16: 656e694c20657079 x15: 0000000000000143 x14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8 x11: ffff80000a591d30 x10: ffff80000a579d40 x9 : c0000000ffffefff x8 : 0000000000000003 x7 : 0000000000017fe8 x6 : ffff80000a579ce8 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 3a35ec12ed7f8900 x1 : 0000000000000000 x0 : 0000000000000052 Call trace:  ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]  ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k]  ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k]  ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k]  ath11k_dp_service_srng+0x234/0x338 [ath11k]  ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]  __napi_poll+0x5c/0x190  napi_threaded_poll+0xf0/0x118  kthread+0xf4/0x110  ret_from_fork+0x10/0x20  Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
CVE-2022-50629: In the Linux kernel, the following vulnerability has been resolved:  wifi: rsi: Fix memory leak in rsi_coex_attach()  The coex_cb needs to be freed when rsi_create_kthread() failed in rsi_coex_attach().
CVE-2022-50630: In the Linux kernel, the following vulnerability has been resolved:  mm: hugetlb: fix UAF in hugetlb_handle_userfault  The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to the following race,  hugetlb_fault   hugetlb_no_page     /*unlock vma_lock */     hugetlb_handle_userfault       handle_userfault         /* unlock mm->mmap_lock*/                                            vm_mmap_pgoff                                              do_mmap                                                mmap_region                                                  munmap_vma_range                                                    /* clean old vma */         /* lock vma_lock again  <--- UAF */     /* unlock vma_lock */  Since the vma_lock will unlock immediately after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix the issue.  [1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/ [2] https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/
CVE-2023-53743: In the Linux kernel, the following vulnerability has been resolved:  PCI: Free released resource after coalescing  release_resource() doesn't actually free the resource or resource list entry so free the resource list entry to avoid a leak.
CVE-2023-53744: In the Linux kernel, the following vulnerability has been resolved:  soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe  wkup_m3_ipc_get() takes refcount, which should be freed by wkup_m3_ipc_put(). Add missing refcount release in the error paths.
CVE-2023-53745: In the Linux kernel, the following vulnerability has been resolved:  um: vector: Fix memory leak in vector_config  If the return value of the uml_parse_vector_ifspec function is NULL, we should call kfree(params) to prevent memory leak.
CVE-2023-53746: In the Linux kernel, the following vulnerability has been resolved:  s390/vfio-ap: fix memory leak in vfio_ap device driver  The device release callback function invoked to release the matrix device uses the dev_get_drvdata(device *dev) function to retrieve the pointer to the vfio_matrix_dev object in order to free its storage. The problem is, this object is not stored as drvdata with the device; since the kfree function will accept a NULL pointer, the memory for the vfio_matrix_dev object is never freed.  Since the device being released is contained within the vfio_matrix_dev object, the container_of macro will be used to retrieve its pointer.
CVE-2023-53747: In the Linux kernel, the following vulnerability has been resolved:  vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF  After a call to console_unlock() in vcs_write() the vc_data struct can be freed by vc_port_destruct(). Because of that, the struct vc_data pointer must be reloaded in the while loop in vcs_write() after console_lock() to avoid a UAF when vcs_size() is called.  Syzkaller reported a UAF in vcs_size().  BUG: KASAN: slab-use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215) Read of size 4 at addr ffff8880beab89a8 by task repro_vcs_size/4119  Call Trace:  <TASK> __asan_report_load4_noabort (mm/kasan/report_generic.c:380) vcs_size (drivers/tty/vt/vc_screen.c:215) vcs_write (drivers/tty/vt/vc_screen.c:664) vfs_write (fs/read_write.c:582 fs/read_write.c:564) ...  <TASK>  Allocated by task 1213: kmalloc_trace (mm/slab_common.c:1064) vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680     drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058) con_install (drivers/tty/vt/vt.c:3334) tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415     drivers/tty/tty_io.c:1392) tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128) chrdev_open (fs/char_dev.c:415) do_dentry_open (fs/open.c:921) vfs_open (fs/open.c:1052) ...  Freed by task 4116: kfree (mm/slab_common.c:1016) vc_port_destruct (drivers/tty/vt/vt.c:1044) tty_port_destructor (drivers/tty/tty_port.c:296) tty_port_put (drivers/tty/tty_port.c:312) vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2)) vt_ioctl (drivers/tty/vt/vt_ioctl.c:903) tty_ioctl (drivers/tty/tty_io.c:2778) ...  The buggy address belongs to the object at ffff8880beab8800  which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 424 bytes inside of  freed 1024-byte region [ffff8880beab8800, ffff8880beab8c00)  The buggy address belongs to the physical page: page:00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000     index:0x0 pfn:0xbeab8 head:00000000afc77580 order:3 entire_mapcount:0 nr_pages_mapped:0     pincount:0 flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected  Memory state around the buggy address:  ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb                                   ^  ffff8880beab8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  ffff8880beab8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Disabling lock debugging due to kernel taint
CVE-2023-53748: In the Linux kernel, the following vulnerability has been resolved:  media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setup  variable *nplanes is provided by user via system call argument. The possible value of q_data->fmt->num_planes is 1-3, while the value of *nplanes can be 1-8. The array access by index i can cause array out-of-bounds.  Fix this bug by checking *nplanes against the array size.
CVE-2023-53750: In the Linux kernel, the following vulnerability has been resolved:  pinctrl: freescale: Fix a memory out of bounds when num_configs is 1  The config passed in by pad wakeup is 1, when num_configs is 1, Configuration [1] should not be fetched, which will be detected by KASAN as a memory out of bounds condition. Modify to get configs[1] when num_configs is 2.
CVE-2023-53751: In the Linux kernel, the following vulnerability has been resolved:  cifs: fix potential use-after-free bugs in TCP_Server_Info::hostname  TCP_Server_Info::hostname may be updated once or many times during reconnect, so protect its access outside reconnect path as well and then prevent any potential use-after-free bugs.
CVE-2023-53752: In the Linux kernel, the following vulnerability has been resolved:  net: deal with integer overflows in kmalloc_reserve()  Blamed commit changed:     ptr = kmalloc(size);     if (ptr)       size = ksize(ptr);      size = kmalloc_size_roundup(size);     ptr = kmalloc(size);  This allowed various crash as reported by syzbot [1] and Kyle Zeng.  Problem is that if @size is bigger than 0x80000001, kmalloc_size_roundup(size) returns 2^32.  kmalloc_reserve() uses a 32bit variable (obj_size), so 2^32 is truncated to 0.  kmalloc(0) returns ZERO_SIZE_PTR which is not handled by skb allocations.  Following trace can be triggered if a netdev->mtu is set close to 0x7fffffff  We might in the future limit netdev->mtu to more sensible limit (like KMALLOC_MAX_SIZE).  This patch is based on a syzbot report, and also a report and tentative fix from Kyle Zeng.  [1] BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline] BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554  CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023 Call trace: dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106 print_report+0xe4/0x4b4 mm/kasan/report.c:398 kasan_report+0x150/0x1ac mm/kasan/report.c:495 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 memset+0x40/0x70 mm/kasan/shadow.c:44 __build_skb_around net/core/skbuff.c:294 [inline] __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 alloc_skb include/linux/skbuff.h:1316 [inline] igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359 add_grec+0x81c/0x1124 net/ipv4/igmp.c:534 igmpv3_send_cr net/ipv4/igmp.c:667 [inline] igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810 call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x54c/0x710 kernel/time/timer.c:1790 run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803 _stext+0x380/0xfbc ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79 call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891 do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84 invoke_softirq kernel/softirq.c:437 [inline] __irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683 irq_exit_rcu+0x14/0x78 kernel/softirq.c:695 el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717 __el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724 el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729 el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584
CVE-2023-53754: In the Linux kernel, the following vulnerability has been resolved:  scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()  When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4) returns false, drbl_regs_memmap_p is not remapped. This passes a NULL pointer to iounmap(), which can trigger a WARN() on certain arches.  When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4) returns true, drbl_regs_memmap_p may has been remapped and ctrl_regs_memmap_p is not remapped. This is a resource leak and passes a NULL pointer to iounmap().  To fix these issues, we need to add null checks before iounmap(), and change some goto labels.
CVE-2023-53755: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: ptdma: check for null desc before calling pt_cmd_callback  Resolves a panic that can occur on AMD systems, typically during host shutdown, after the PTDMA driver had been exercised. The issue was the pt_issue_pending() function is mistakenly assuming that there will be at least one descriptor in the Submitted queue when the function is called. However, it is possible that both the Submitted and Issued queues could be empty, which could result in pt_cmd_callback() being mistakenly called with a NULL pointer. Ref: Bugzilla Bug 216856.
CVE-2023-53756: In the Linux kernel, the following vulnerability has been resolved:  KVM: VMX: Fix crash due to uninitialized current_vmcs  KVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running as a nested hypervisor on top of Hyper-V. When MSR bitmap is updated, evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to mark that the msr bitmap was changed.  vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr -> vmx_msr_bitmap_l01_changed which in the end calls this function. The function checks for current_vmcs if it is null but the check is insufficient because current_vmcs is not initialized. Because of this, the code might incorrectly write to the structure pointed by current_vmcs value left by another task. Preemption is not disabled, the current task can be preempted and moved to another CPU while current_vmcs is accessed multiple times from evmcs_touch_msr_bitmap() which leads to crash.  The manipulation of MSR bitmaps by callers happens only for vmcs01 so the solution is to use vmx->vmcs01.vmcs instead of current_vmcs.    BUG: kernel NULL pointer dereference, address: 0000000000000338   PGD 4e1775067 P4D 0   Oops: 0002 [#1] PREEMPT SMP NOPTI   ...   RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel]   ...   Call Trace:    vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel]    vmx_vcpu_create+0xe6/0x540 [kvm_intel]    kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm]    kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm]    kvm_vm_ioctl+0x53f/0x790 [kvm]    __x64_sys_ioctl+0x8a/0xc0    do_syscall_64+0x5c/0x90    entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVE-2023-53757: In the Linux kernel, the following vulnerability has been resolved:  irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probe  of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2023-53759: In the Linux kernel, the following vulnerability has been resolved:  HID: hidraw: fix data race on device refcount  The hidraw_open() function increments the hidraw device reference counter. The counter has no dedicated synchronization mechanism, resulting in a potential data race when concurrently opening a device.  The race is a regression introduced by commit 8590222e4b02 ("HID: hidraw: Replace hidraw device table mutex with a rwsem"). While minors_rwsem is intended to protect the hidraw_table itself, by instead acquiring the lock for writing, the reference counter is also protected. This is symmetrical to hidraw_release().
CVE-2023-53760: In the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: core: mcq: Fix &hwq->cq_lock deadlock issue  When ufshcd_err_handler() is executed, CQ event interrupt can enter waiting for the same lock. This can happen in ufshcd_handle_mcq_cq_events() and also in ufs_mtk_mcq_intr(). The following warning message will be generated when &hwq->cq_lock is used in IRQ context with IRQ enabled. Use ufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave instead of spin_lock to resolve the deadlock issue.  [name:lockdep&]WARNING: inconsistent lock state [name:lockdep&]-------------------------------- [name:lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] takes:   ffffff8028444600 (&hwq->cq_lock){?.-.}-{2:2}, at: ufshcd_mcq_poll_cqe_lock+0x30/0xe0 [name:lockdep&]{IN-HARDIRQ-W} state was registered at:   lock_acquire+0x17c/0x33c   _raw_spin_lock+0x5c/0x7c   ufshcd_mcq_poll_cqe_lock+0x30/0xe0   ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod]   __handle_irq_event_percpu+0x140/0x3ec   handle_irq_event+0x50/0xd8   handle_fasteoi_irq+0x148/0x2b0   generic_handle_domain_irq+0x4c/0x6c   gic_handle_irq+0x58/0x134   call_on_irq_stack+0x40/0x74   do_interrupt_handler+0x84/0xe4   el1_interrupt+0x3c/0x78 <snip>  Possible unsafe locking scenario:        CPU0        ----   lock(&hwq->cq_lock);   <Interrupt>     lock(&hwq->cq_lock);   *** DEADLOCK *** 2 locks held by kworker/u16:4/260:  [name:lockdep&]  stack backtrace: CPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S      W  OE 6.1.17-mainline-android14-2-g277223301adb #1 Workqueue: ufs_eh_wq_0 ufshcd_err_handler   Call trace:   dump_backtrace+0x10c/0x160   show_stack+0x20/0x30   dump_stack_lvl+0x98/0xd8   dump_stack+0x20/0x60   print_usage_bug+0x584/0x76c   mark_lock_irq+0x488/0x510   mark_lock+0x1ec/0x25c   __lock_acquire+0x4d8/0xffc   lock_acquire+0x17c/0x33c   _raw_spin_lock+0x5c/0x7c   ufshcd_mcq_poll_cqe_lock+0x30/0xe0   ufshcd_poll+0x68/0x1b0   ufshcd_transfer_req_compl+0x9c/0xc8   ufshcd_err_handler+0x3bc/0xea0   process_one_work+0x2f4/0x7e8   worker_thread+0x234/0x450   kthread+0x110/0x134   ret_from_fork+0x10/0x20
CVE-2023-53761: In the Linux kernel, the following vulnerability has been resolved:  USB: usbtmc: Fix direction for 0-length ioctl control messages  The syzbot fuzzer found a problem in the usbtmc driver: When a user submits an ioctl for a 0-length control transfer, the driver does not check that the direction is set to OUT:  ------------[ cut here ]------------ usb 3-1: BOGUS control dir, pipe 80000b80 doesn't match bRequestType fd WARNING: CPU: 0 PID: 5100 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 0 PID: 5100 Comm: syz-executor428 Not tainted 6.3.0-syzkaller-12049-g58390c8ce1bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Code: 7c 24 40 e8 1b 13 5c fb 48 8b 7c 24 40 e8 21 1d f0 fe 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 e0 b5 fc 8a e8 19 c8 23 fb <0f> 0b e9 9f ee ff ff e8 ed 12 5c fb 0f b6 1d 12 8a 3c 08 31 ff 41 RSP: 0018:ffffc90003d2fb00 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8880789e9058 RCX: 0000000000000000 RDX: ffff888029593b80 RSI: ffffffff814c1447 RDI: 0000000000000001 RBP: ffff88801ea742f8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88802915e528 R13: 00000000000000fd R14: 0000000080000b80 R15: ffff8880222b3100 FS:  0000555556ca63c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9ef4d18150 CR3: 0000000073e5b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>  usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58  usb_internal_control_msg drivers/usb/core/message.c:102 [inline]  usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153  usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1954 [inline]  usbtmc_ioctl+0x1b3d/0x2840 drivers/usb/class/usbtmc.c:2097  To fix this, we must override the direction in the bRequestType field of the control request structure when the length is 0.
CVE-2023-53762: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync  Use-after-free can occur in hci_disconnect_all_sync if a connection is deleted by concurrent processing of a controller event.  To prevent this the code now tries to iterate over the list backwards to ensure the links are cleanup before its parents, also it no longer relies on a cursor, instead it always uses the last element since hci_abort_conn_sync is guaranteed to call hci_conn_del.  UAF crash log: ================================================================== BUG: KASAN: slab-use-after-free in hci_set_powered_sync (net/bluetooth/hci_sync.c:5424) [bluetooth] Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124  CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G        W 6.5.0-rc1+ #10 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace:  <TASK>  dump_stack_lvl+0x5b/0x90  print_report+0xcf/0x670  ? __virt_addr_valid+0xdd/0x160  ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]  kasan_report+0xa6/0xe0  ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]  ? __pfx_set_powered_sync+0x10/0x10 [bluetooth]  hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]  ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth]  ? __pfx_lock_release+0x10/0x10  ? __pfx_set_powered_sync+0x10/0x10 [bluetooth]  hci_cmd_sync_work+0x137/0x220 [bluetooth]  process_one_work+0x526/0x9d0  ? __pfx_process_one_work+0x10/0x10  ? __pfx_do_raw_spin_lock+0x10/0x10  ? mark_held_locks+0x1a/0x90  worker_thread+0x92/0x630  ? __pfx_worker_thread+0x10/0x10  kthread+0x196/0x1e0  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2c/0x50  </TASK>  Allocated by task 1782:  kasan_save_stack+0x33/0x60  kasan_set_track+0x25/0x30  __kasan_kmalloc+0x8f/0xa0  hci_conn_add+0xa5/0xa80 [bluetooth]  hci_bind_cis+0x881/0x9b0 [bluetooth]  iso_connect_cis+0x121/0x520 [bluetooth]  iso_sock_connect+0x3f6/0x790 [bluetooth]  __sys_connect+0x109/0x130  __x64_sys_connect+0x40/0x50  do_syscall_64+0x60/0x90  entry_SYSCALL_64_after_hwframe+0x6e/0xd8  Freed by task 695:  kasan_save_stack+0x33/0x60  kasan_set_track+0x25/0x30  kasan_save_free_info+0x2b/0x50  __kasan_slab_free+0x10a/0x180  __kmem_cache_free+0x14d/0x2e0  device_release+0x5d/0xf0  kobject_put+0xdf/0x270  hci_disconn_complete_evt+0x274/0x3a0 [bluetooth]  hci_event_packet+0x579/0x7e0 [bluetooth]  hci_rx_work+0x287/0xaa0 [bluetooth]  process_one_work+0x526/0x9d0  worker_thread+0x92/0x630  kthread+0x196/0x1e0  ret_from_fork+0x2c/0x50 ==================================================================