xamxte/cve-to-cwe huggingface dataset:
CVE-2023-53764: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath12k: Handle lock during peer_id find  ath12k_peer_find_by_id() requires that the caller hold the ab->base_lock. Currently the WBM error path does not hold the lock and calling that function, leads to the following lockdep_assert()in QCN9274:  [105162.160893] ------------[ cut here ]------------ [105162.160916] WARNING: CPU: 3 PID: 0 at drivers/net/wireless/ath/ath12k/peer.c:71 ath12k_peer_find_by_id+0x52/0x60 [ath12k] [105162.160933] Modules linked in: ath12k(O) qrtr_mhi qrtr mac80211 cfg80211 mhi qmi_helpers libarc4 nvme nvme_core [last unloaded: ath12k(O)] [105162.160967] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G        W  O       6.1.0-rc2+ #3 [105162.160972] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0056.2019.0506.1527 05/06/2019 [105162.160977] RIP: 0010:ath12k_peer_find_by_id+0x52/0x60 [ath12k] [105162.160990] Code: 07 eb 0f 39 68 24 74 0a 48 8b 00 48 39 f8 75 f3 31 c0 5b 5d c3 48 8d bf b0 f2 00 00 be ff ff ff ff e8 22 20 c4 e2 85 c0 75 bf <0f> 0b eb bb 66 2e 0f 1f 84 00 00 00 00 00 41 54 4c 8d a7 98 f2 00 [105162.160996] RSP: 0018:ffffa223001acc60 EFLAGS: 00010246 [105162.161003] RAX: 0000000000000000 RBX: ffff9f0573940000 RCX: 0000000000000000 [105162.161008] RDX: 0000000000000001 RSI: ffffffffa3951c8e RDI: ffffffffa39a96d7 [105162.161013] RBP: 000000000000000a R08: 0000000000000000 R09: 0000000000000000 [105162.161017] R10: ffffa223001acb40 R11: ffffffffa3d57c60 R12: ffff9f057394f2e0 [105162.161022] R13: ffff9f0573940000 R14: ffff9f04ecd659c0 R15: ffff9f04d5a9b040 [105162.161026] FS:  0000000000000000(0000) GS:ffff9f0575600000(0000) knlGS:0000000000000000 [105162.161031] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105162.161036] CR2: 00001d5c8277a008 CR3: 00000001e6224006 CR4: 00000000003706e0 [105162.161041] Call Trace: [105162.161046]  <IRQ> [105162.161051]  ath12k_dp_rx_process_wbm_err+0x6da/0xaf0 [ath12k] [105162.161072]  ? ath12k_dp_rx_process_err+0x80e/0x15a0 [ath12k] [105162.161084]  ? __lock_acquire+0x4ca/0x1a60 [105162.161104]  ath12k_dp_service_srng+0x263/0x310 [ath12k] [105162.161120]  ath12k_pci_ext_grp_napi_poll+0x1c/0x70 [ath12k] [105162.161133]  __napi_poll+0x22/0x260 [105162.161141]  net_rx_action+0x2f8/0x380 [105162.161153]  __do_softirq+0xd0/0x4c9 [105162.161162]  irq_exit_rcu+0x88/0xe0 [105162.161169]  common_interrupt+0xa5/0xc0 [105162.161174]  </IRQ> [105162.161179]  <TASK> [105162.161184]  asm_common_interrupt+0x22/0x40  Handle spin lock/unlock in WBM error path to hold the necessary lock expected by ath12k_peer_find_by_id().  Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0-03171-QCAHKSWPL_SILICONZ-1
CVE-2023-53765: In the Linux kernel, the following vulnerability has been resolved:  dm cache: free background tracker's queued work in btracker_destroy  Otherwise the kernel can BUG with:  [ 2245.426978] ============================================================================= [ 2245.435155] BUG bt_work (Tainted: G    B   W         ): Objects remaining in bt_work on __kmem_cache_shutdown() [ 2245.445233] ----------------------------------------------------------------------------- [ 2245.445233] [ 2245.454879] Slab 0x00000000b0ce2b30 objects=64 used=2 fp=0x000000000a3c6a4e flags=0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) [ 2245.467300] CPU: 7 PID: 10805 Comm: lvm Kdump: loaded Tainted: G    B   W          6.0.0-rc2 #19 [ 2245.476078] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.5.6 10/06/2021 [ 2245.483646] Call Trace: [ 2245.486100]  <TASK> [ 2245.488206]  dump_stack_lvl+0x34/0x48 [ 2245.491878]  slab_err+0x95/0xcd [ 2245.495028]  __kmem_cache_shutdown.cold+0x31/0x136 [ 2245.499821]  kmem_cache_destroy+0x49/0x130 [ 2245.503928]  btracker_destroy+0x12/0x20 [dm_cache] [ 2245.508728]  smq_destroy+0x15/0x60 [dm_cache_smq] [ 2245.513435]  dm_cache_policy_destroy+0x12/0x20 [dm_cache] [ 2245.518834]  destroy+0xc0/0x110 [dm_cache] [ 2245.522933]  dm_table_destroy+0x5c/0x120 [dm_mod] [ 2245.527649]  __dm_destroy+0x10e/0x1c0 [dm_mod] [ 2245.532102]  dev_remove+0x117/0x190 [dm_mod] [ 2245.536384]  ctl_ioctl+0x1a2/0x290 [dm_mod] [ 2245.540579]  dm_ctl_ioctl+0xa/0x20 [dm_mod] [ 2245.544773]  __x64_sys_ioctl+0x8a/0xc0 [ 2245.548524]  do_syscall_64+0x5c/0x90 [ 2245.552104]  ? syscall_exit_to_user_mode+0x12/0x30 [ 2245.556897]  ? do_syscall_64+0x69/0x90 [ 2245.560648]  ? do_syscall_64+0x69/0x90 [ 2245.564394]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 2245.569447] RIP: 0033:0x7fe52583ec6b ... [ 2245.646771] ------------[ cut here ]------------ [ 2245.651395] kmem_cache_destroy bt_work: Slab cache still has objects when called from btracker_destroy+0x12/0x20 [dm_cache] [ 2245.651408] WARNING: CPU: 7 PID: 10805 at mm/slab_common.c:478 kmem_cache_destroy+0x128/0x130  Found using: lvm2-testsuite --only "cache-single-split.sh"  Ben bisected and found that commit 0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock") first exposed dm-cache's incomplete cleanup of its background tracker work objects.
CVE-2023-53766: In the Linux kernel, the following vulnerability has been resolved:  FS: JFS: Check for read-only mounted filesystem in txBegin   This patch adds a check for read-only mounted filesystem  in txBegin before starting a transaction potentially saving  from NULL pointer deref.
CVE-2023-53767: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath12k: fix memory leak in ath12k_qmi_driver_event_work()  Currently the buffer pointed by event is not freed in case ATH12K_FLAG_UNREGISTERING bit is set, this causes memory leak.  Add a goto skip instead of return, to ensure event and all the list entries are freed properly.  Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
CVE-2023-53768: In the Linux kernel, the following vulnerability has been resolved:  regmap-irq: Fix out-of-bounds access when allocating config buffers  When allocating the 2D array for handling IRQ type registers in regmap_add_irq_chip_fwnode(), the intent is to allocate a matrix with num_config_bases rows and num_config_regs columns.  This is currently handled by allocating a buffer to hold a pointer for each row (i.e. num_config_bases). After that, the logic attempts to allocate the memory required to hold the register configuration for each row. However, instead of doing this allocation for each row (i.e. num_config_bases allocations), the logic erroneously does this allocation num_config_regs number of times.  This scenario can lead to out-of-bounds accesses when num_config_regs is greater than num_config_bases. Fix this by updating the terminating condition of the loop that allocates the memory for holding the register configuration to allocate memory only for each row in the matrix.  Amit Pundir reported a crash that was occurring on his db845c device due to memory corruption (see "Closes" tag for Amit's report). The KASAN report below helped narrow it down to this issue:  [   14.033877][    T1] ================================================================== [   14.042507][    T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364 [   14.050796][    T1] Write of size 8 at addr 06ffff8081021850 by task init/1  [   14.242004][    T1] The buggy address belongs to the object at ffffff8081021850 [   14.242004][    T1]  which belongs to the cache kmalloc-8 of size 8 [   14.255669][    T1] The buggy address is located 0 bytes inside of [   14.255669][    T1]  8-byte region [ffffff8081021850, ffffff8081021858)
CVE-2025-48565: In multiple locations, there is a possible way to bypass the cross profile intent filter due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
CVE-2025-48589: In multiple functions of HeaderPrivacyIconsController.kt, there is a possible way to grand permissions across user  due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
CVE-2025-48607: In multiple locations, there is a possible way to create a large amount of app ops due to a logic error in the code. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.
CVE-2025-48610: In __pkvm_guest_relinquish_to_host of mem_protect.c, there is a possible configuration data leak due to a logic error in the code. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
CVE-2022-50631: In the Linux kernel, the following vulnerability has been resolved:  RISC-V: kexec: Fix memory leak of fdt buffer  This is reported by kmemleak detector:  unreferenced object 0xff60000082864000 (size 9588):   comm "kexec", pid 146, jiffies 4294900634 (age 64.788s)   hex dump (first 32 bytes):     d0 0d fe ed 00 00 12 ed 00 00 00 48 00 00 11 40  ...........H...@     00 00 00 28 00 00 00 11 00 00 00 02 00 00 00 00  ...(............   backtrace:     [<00000000f95b17c4>] kmemleak_alloc+0x34/0x3e     [<00000000b9ec8e3e>] kmalloc_order+0x9c/0xc4     [<00000000a95cf02e>] kmalloc_order_trace+0x34/0xb6     [<00000000f01e68b4>] __kmalloc+0x5c2/0x62a     [<000000002bd497b2>] kvmalloc_node+0x66/0xd6     [<00000000906542fa>] of_kexec_alloc_and_setup_fdt+0xa6/0x6ea     [<00000000e1166bde>] elf_kexec_load+0x206/0x4ec     [<0000000036548e09>] kexec_image_load_default+0x40/0x4c     [<0000000079fbe1b4>] sys_kexec_file_load+0x1c4/0x322     [<0000000040c62c03>] ret_from_syscall+0x0/0x2  In elf_kexec_load(), a buffer is allocated via kvmalloc() to store fdt. While it's not freed back to system when kexec kernel is reloaded or unloaded.  Then memory leak is caused.  Fix it by introducing riscv specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there.
CVE-2022-50632: In the Linux kernel, the following vulnerability has been resolved:  drivers: perf: marvell_cn10k: Fix hotplug callback leak in tad_pmu_init()  tad_pmu_init() won't remove the callback added by cpuhp_setup_state_multi() when platform_driver_register() failed. Remove the callback by cpuhp_remove_multi_state() in fail path.  Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus: arm-ccn: Prevent hotplug callback leak")
CVE-2022-50633: In the Linux kernel, the following vulnerability has been resolved:  usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init  of_icc_get() alloc resources for path handle, we should release it when not need anymore. Like the release in dwc3_qcom_interconnect_exit() function. Add icc_put() in error handling to fix this.
CVE-2022-50634: In the Linux kernel, the following vulnerability has been resolved:  power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()  cw_bat_probe() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen:  cw_bat_probe()     create_singlethread_workqueue() # failed, cw_bat->wq is NULL     queue_delayed_work()         queue_delayed_work_on()             __queue_delayed_work()  # warning here, but continue                 __queue_work()      # access wq->flags, null-ptr-deref  Check the ret value and return -ENOMEM if it is NULL.
CVE-2022-50635: In the Linux kernel, the following vulnerability has been resolved:  powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()  I found a null pointer reference in arch_prepare_kprobe():    # echo 'p cmdline_proc_show' > kprobe_events   # echo 'p cmdline_proc_show+16' >> kprobe_events   Kernel attempted to read user page (0) - exploit attempt? (uid: 0)   BUG: Kernel NULL pointer dereference on read at 0x00000000   Faulting instruction address: 0xc000000000050bfc   Oops: Kernel access of bad area, sig: 11 [#1]   LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV   Modules linked in:   CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10   NIP:  c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc   REGS: c0000000348475b0 TRAP: 0300   Not tainted  (6.0.0-rc3-00007-gdcf8e5633e2e)   MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 88002444  XER: 20040006   CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0   ...   NIP arch_prepare_kprobe+0x10c/0x2d0   LR  arch_prepare_kprobe+0xfc/0x2d0   Call Trace:     0xc0000000012f77a0 (unreliable)     register_kprobe+0x3c0/0x7a0     __register_trace_kprobe+0x140/0x1a0     __trace_kprobe_create+0x794/0x1040     trace_probe_create+0xc4/0xe0     create_or_delete_trace_kprobe+0x2c/0x80     trace_parse_run_command+0xf0/0x210     probes_write+0x20/0x40     vfs_write+0xfc/0x450     ksys_write+0x84/0x140     system_call_exception+0x17c/0x3a0     system_call_vectored_common+0xe8/0x278   --- interrupt: 3000 at 0x7fffa5682de0   NIP:  00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000   REGS: c000000034847e80 TRAP: 3000   Not tainted  (6.0.0-rc3-00007-gdcf8e5633e2e)   MSR:  900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE>  CR: 44002408  XER: 00000000  The address being probed has some special:    cmdline_proc_show: Probe based on ftrace   cmdline_proc_show+16: Probe for the next instruction at the ftrace location  The ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets set to NULL. In arch_prepare_kprobe() it will check for:    ...   prev = get_kprobe(p->addr - 1);   preempt_enable_no_resched();   if (prev && ppc_inst_prefixed(ppc_inst_read(prev->ainsn.insn))) {   ...  If prev is based on ftrace, 'ppc_inst_read(prev->ainsn.insn)' will occur with a null pointer reference. At this point prev->addr will not be a prefixed instruction, so the check can be skipped.  Check if prev is ftrace-based kprobe before reading 'prev->ainsn.insn' to fix this problem.  [mpe: Trim oops]
CVE-2022-50637: In the Linux kernel, the following vulnerability has been resolved:  cpufreq: qcom-hw: Fix memory leak in qcom_cpufreq_hw_read_lut()  If "cpu_dev" fails to get opp table in qcom_cpufreq_hw_read_lut(), the program will return, resulting in "table" resource is not released.
CVE-2022-50639: In the Linux kernel, the following vulnerability has been resolved:  io-wq: Fix memory leak in worker creation  If the CPU mask allocation for a node fails, then the memory allocated for the 'io_wqe' struct of the current node doesn't get freed on the error handling path, since it has not yet been added to the 'wqes' array.  This was spotted when fuzzing v6.1-rc1 with Syzkaller: BUG: memory leak unreferenced object 0xffff8880093d5000 (size 1024):   comm "syz-executor.2", pid 7701, jiffies 4295048595 (age 13.900s)   hex dump (first 32 bytes):     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................   backtrace:     [<00000000cb463369>] __kmem_cache_alloc_node+0x18e/0x720     [<00000000147a3f9c>] kmalloc_node_trace+0x2a/0x130     [<000000004e107011>] io_wq_create+0x7b9/0xdc0     [<00000000c38b2018>] io_uring_alloc_task_context+0x31e/0x59d     [<00000000867399da>] __io_uring_add_tctx_node.cold+0x19/0x1ba     [<000000007e0e7a79>] io_uring_setup.cold+0x1b80/0x1dce     [<00000000b545e9f6>] __x64_sys_io_uring_setup+0x5d/0x80     [<000000008a8a7508>] do_syscall_64+0x5d/0x90     [<000000004ac08bec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVE-2022-50641: In the Linux kernel, the following vulnerability has been resolved:  HSI: omap_ssi: Fix refcount leak in ssi_probe  When returning or breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node to possibly release the node.
CVE-2022-50642: In the Linux kernel, the following vulnerability has been resolved:  platform/chrome: cros_ec_typec: zero out stale pointers  `cros_typec_get_switch_handles` allocates four pointers when obtaining type-c switch handles. These pointers are all freed if failing to obtain any of them; therefore, pointers in `port` become stale. The stale pointers eventually cause use-after-free or double free in later code paths. Zeroing out all pointer fields after freeing to eliminate these stale pointers.
CVE-2022-50643: In the Linux kernel, the following vulnerability has been resolved:  cifs: Fix xid leak in cifs_copy_file_range()  If the file is used by swap, before return -EOPNOTSUPP, should free the xid, otherwise, the xid will be leaked.
CVE-2022-50644: In the Linux kernel, the following vulnerability has been resolved:  clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe  pm_runtime_get_sync() will increment pm usage counter. Forgetting to putting operation will result in reference leak. Add missing pm_runtime_put_sync in some error paths.
CVE-2022-50645: In the Linux kernel, the following vulnerability has been resolved:  EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()  As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, so it doesn't need to call an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCI device needs to be put in the error path.
CVE-2022-50646: In the Linux kernel, the following vulnerability has been resolved:  scsi: hpsa: Fix possible memory leak in hpsa_init_one()  The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, in hpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps to clean1 directly, which frees h and leaks the h->reply_map.  Fix by calling hpda_free_ctlr_info() to release h->replay_map and h instead free h directly.
CVE-2022-50649: In the Linux kernel, the following vulnerability has been resolved:  power: supply: adp5061: fix out-of-bounds read in adp5061_get_chg_type()  ADP5061_CHG_STATUS_1_CHG_STATUS is masked with 0x07, which means a length of 8, but adp5061_chg_type array size is 4, may end up reading 4 elements beyond the end of the adp5061_chg_type[] array.
CVE-2022-50651: In the Linux kernel, the following vulnerability has been resolved:  ethtool: eeprom: fix null-deref on genl_info in dump  The similar fix as commit 46cdedf2a0fa ("ethtool: pse-pd: fix null-deref on genl_info in dump") is also needed for ethtool eeprom.
CVE-2022-50653: In the Linux kernel, the following vulnerability has been resolved:  mmc: atmel-mci: fix return value check of mmc_add_host()  mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to    delete device, but it's not added yet, it will lead a kernel    crash because of null-ptr-deref in device_del().  So fix this by checking the return value and calling mmc_free_host() in the error path.
CVE-2022-50654: In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix panic due to wrong pageattr of im->image  In the scenario where livepatch and kretfunc coexist, the pageattr of im->image is rox after arch_prepare_bpf_trampoline in bpf_trampoline_update, and then modify_fentry or register_fentry returns -EAGAIN from bpf_tramp_ftrace_ops_func, the BPF_TRAMP_F_ORIG_STACK flag will be configured, and arch_prepare_bpf_trampoline will be re-executed.  At this time, because the pageattr of im->image is rox, arch_prepare_bpf_trampoline will read and write im->image, which causes a fault. as follows:    insmod livepatch-sample.ko    # samples/livepatch/livepatch-sample.c   bpftrace -e 'kretfunc:cmdline_proc_show {}'  BUG: unable to handle page fault for address: ffffffffa0206000 PGD 322d067 P4D 322d067 PUD 322e063 PMD 1297e067 PTE d428061 Oops: 0003 [#1] PREEMPT SMP PTI CPU: 2 PID: 270 Comm: bpftrace Tainted: G            E K    6.1.0 #5 RIP: 0010:arch_prepare_bpf_trampoline+0xed/0x8c0 RSP: 0018:ffffc90001083ad8 EFLAGS: 00010202 RAX: ffffffffa0206000 RBX: 0000000000000020 RCX: 0000000000000000 RDX: ffffffffa0206001 RSI: ffffffffa0206000 RDI: 0000000000000030 RBP: ffffc90001083b70 R08: 0000000000000066 R09: ffff88800f51b400 R10: 000000002e72c6e5 R11: 00000000d0a15080 R12: ffff8880110a68c8 R13: 0000000000000000 R14: ffff88800f51b400 R15: ffffffff814fec10 FS:  00007f87bc0dc780(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa0206000 CR3: 0000000010b70000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>  bpf_trampoline_update+0x25a/0x6b0  __bpf_trampoline_link_prog+0x101/0x240  bpf_trampoline_link_prog+0x2d/0x50  bpf_tracing_prog_attach+0x24c/0x530  bpf_raw_tp_link_attach+0x73/0x1d0  __sys_bpf+0x100e/0x2570  __x64_sys_bpf+0x1c/0x30  do_syscall_64+0x5b/0x80  entry_SYSCALL_64_after_hwframe+0x63/0xcd  With this patch, when modify_fentry or register_fentry returns -EAGAIN from bpf_tramp_ftrace_ops_func, the pageattr of im->image will be reset to nx+rw.
CVE-2022-50656: In the Linux kernel, the following vulnerability has been resolved:  nfc: pn533: Clear nfc_target before being used  Fix a slab-out-of-bounds read that occurs in nla_put() called from nfc_genl_send_target() when target->sensb_res_len, which is duplicated from an nfc_target in pn533, is too large as the nfc_target is not properly initialized and retains garbage values. Clear nfc_targets with memset() before they are used.  Found by a modified version of syzkaller.  BUG: KASAN: slab-out-of-bounds in nla_put Call Trace:  memcpy  nla_put  nfc_genl_dump_targets  genl_lock_dumpit  netlink_dump  __netlink_dump_start  genl_family_rcv_msg_dumpit  genl_rcv_msg  netlink_rcv_skb  genl_rcv  netlink_unicast  netlink_sendmsg  sock_sendmsg  ____sys_sendmsg  ___sys_sendmsg  __sys_sendmsg  do_syscall_64
CVE-2023-53778: In the Linux kernel, the following vulnerability has been resolved:  accel/qaic: Clean up integer overflow checking in map_user_pages()  The encode_dma() function has some validation on in_trans->size but it would be more clear to move those checks to find_and_map_user_pages().  The encode_dma() had two checks:   if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size)   return -EINVAL;  The in_trans->addr variable is the starting address.  The in_trans->size variable is the total size of the transfer.  The transfer can occur in parts and the resources->xferred_dma_size tracks how many bytes we have already transferred.  This patch introduces a new variable "remaining" which represents the amount we want to transfer (in_trans->size) minus the amount we have already transferred (resources->xferred_dma_size).  I have modified the check for if in_trans->size is zero to instead check if in_trans->size is less than resources->xferred_dma_size.  If we have already transferred more bytes than in_trans->size then there are negative bytes remaining which doesn't make sense.  If there are zero bytes remaining to be copied, just return success.  The check in encode_dma() checked that "addr + size" could not overflow and barring a driver bug that should work, but it's easier to check if we do this in parts.  First check that "in_trans->addr + resources->xferred_dma_size" is safe.  Then check that "xfer_start_addr + remaining" is safe.  My final concern was that we are dealing with u64 values but on 32bit systems the kmalloc() function will truncate the sizes to 32 bits.  So I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);" and returned -EINVAL if it were >= SIZE_MAX.  This will not affect 64bit systems.