xamxte/cve-to-cwe huggingface dataset:
CVE-2023-54113: In the Linux kernel, the following vulnerability has been resolved:  rcu: dump vmalloc memory info safely  Currently, for double invoke call_rcu(), will dump rcu_head objects memory info, if the objects is not allocated from the slab allocator, the vmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need to be held, since the call_rcu() can be invoked in interrupt context, therefore, there is a possibility of spinlock deadlock scenarios.  And in Preempt-RT kernel, the rcutorture test also trigger the following lockdep warning:  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 3 locks held by swapper/0/1:  #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0  #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370  #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70 irq event stamp: 565512 hardirqs last  enabled at (565511): [<ffffffffb379b138>] __call_rcu_common+0x218/0x940 hardirqs last disabled at (565512): [<ffffffffb5804262>] rcu_torture_init+0x20b2/0x2370 softirqs last  enabled at (399112): [<ffffffffb36b2586>] __local_bh_enable_ip+0x126/0x170 softirqs last disabled at (399106): [<ffffffffb43fef59>] inet_register_protosw+0x9/0x1d0 Preemption disabled at: [<ffffffffb58040c3>] rcu_torture_init+0x1f13/0x2370 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W          6.5.0-rc4-rt2-yocto-preempt-rt+ #15 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x68/0xb0  dump_stack+0x14/0x20  __might_resched+0x1aa/0x280  ? __pfx_rcu_torture_err_cb+0x10/0x10  rt_spin_lock+0x53/0x130  ? find_vmap_area+0x1f/0x70  find_vmap_area+0x1f/0x70  vmalloc_dump_obj+0x20/0x60  mem_dump_obj+0x22/0x90  __call_rcu_common+0x5bf/0x940  ? debug_smp_processor_id+0x1b/0x30  call_rcu_hurry+0x14/0x20  rcu_torture_init+0x1f82/0x2370  ? __pfx_rcu_torture_leak_cb+0x10/0x10  ? __pfx_rcu_torture_leak_cb+0x10/0x10  ? __pfx_rcu_torture_init+0x10/0x10  do_one_initcall+0x6c/0x300  ? debug_smp_processor_id+0x1b/0x30  kernel_init_freeable+0x2b9/0x540  ? __pfx_kernel_init+0x10/0x10  kernel_init+0x1f/0x150  ret_from_fork+0x40/0x50  ? __pfx_kernel_init+0x10/0x10  ret_from_fork_asm+0x1b/0x30  </TASK>  The previous patch fixes this by using the deadlock-safe best-effort version of find_vm_area.  However, in case of failure print the fact that the pointer was a vmalloc pointer so that we print at least something.
CVE-2023-54115: In the Linux kernel, the following vulnerability has been resolved:  pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db()  When nonstatic_release_resource_db() frees all resources associated with an PCMCIA socket, it forgets to free socket_data too, causing a memory leak observable with kmemleak:  unreferenced object 0xc28d1000 (size 64):   comm "systemd-udevd", pid 297, jiffies 4294898478 (age 194.484s)   hex dump (first 32 bytes):     00 00 00 00 00 00 00 00 f0 85 0e c3 00 00 00 00  ................     00 00 00 00 0c 10 8d c2 00 00 00 00 00 00 00 00  ................   backtrace:     [<ffda4245>] __kmem_cache_alloc_node+0x2d7/0x4a0     [<7e51f0c8>] kmalloc_trace+0x31/0xa4     [<d52b4ca0>] nonstatic_init+0x24/0x1a4 [pcmcia_rsrc]     [<a2f13e08>] pcmcia_register_socket+0x200/0x35c [pcmcia_core]     [<a728be1b>] yenta_probe+0x4d8/0xa70 [yenta_socket]     [<c48fac39>] pci_device_probe+0x99/0x194     [<84b7c690>] really_probe+0x181/0x45c     [<8060fe6e>] __driver_probe_device+0x75/0x1f4     [<b9b76f43>] driver_probe_device+0x28/0xac     [<648b766f>] __driver_attach+0xeb/0x1e4     [<6e9659eb>] bus_for_each_dev+0x61/0xb4     [<25a669f3>] driver_attach+0x1e/0x28     [<d8671d6b>] bus_add_driver+0x102/0x20c     [<df0d323c>] driver_register+0x5b/0x120     [<942cd8a4>] __pci_register_driver+0x44/0x4c     [<e536027e>] __UNIQUE_ID___addressable_cleanup_module188+0x1c/0xfffff000 [iTCO_vendor_support]  Fix this by freeing socket_data too.  Tested on a Acer Travelmate 4002WLMi by manually binding/unbinding the yenta_cardbus driver (yenta_socket).
CVE-2023-54116: In the Linux kernel, the following vulnerability has been resolved:  drm/fbdev-generic: prohibit potential out-of-bounds access  The fbdev test of IGT may write after EOF, which lead to out-of-bound access for drm drivers with fbdev-generic. For example, run fbdev test on a x86+ast2400 platform, with 1680x1050 resolution, will cause the linux kernel hang with the following call trace:    Oops: 0000 [#1] PREEMPT SMP PTI   [IGT] fbdev: starting subtest eof   Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]   [IGT] fbdev: starting subtest nullptr    RIP: 0010:memcpy_erms+0xa/0x20   RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246   RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0   RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000   RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0   R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80   R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30   FS:  0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0   Call Trace:    <TASK>    ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]    drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]    process_one_work+0x21f/0x430    worker_thread+0x4e/0x3c0    ? __pfx_worker_thread+0x10/0x10    kthread+0xf4/0x120    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x2c/0x50    </TASK>   CR2: ffffa17d40e0b000   ---[ end trace 0000000000000000 ]---  The is because damage rectangles computed by drm_fb_helper_memory_range_to_clip() function is not guaranteed to be bound in the screen's active display area. Possible reasons are:  1) Buffers are allocated in the granularity of page size, for mmap system    call support. The shadow screen buffer consumed by fbdev emulation may    also choosed be page size aligned.  2) The DIV_ROUND_UP() used in drm_fb_helper_memory_range_to_clip()    will introduce off-by-one error.  For example, on a 16KB page size system, in order to store a 1920x1080 XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size 1920*1080*4 can not be divided exactly by 16KB.   1920 * 1080 * 4 = 8294400 bytes  506 * 16 * 1024 = 8290304 bytes  507 * 16 * 1024 = 8306688 bytes   line_length = 1920*4 = 7680 bytes   507 * 16 * 1024 / 7680 = 1081.6   off / line_length = 507 * 16 * 1024 / 7680 = 1081  DIV_ROUND_UP(507 * 16 * 1024, 7680) will yeild 1082  memcpy_toio() typically issue the copy line by line, when copy the last line, out-of-bound access will be happen. Because:   1082 * line_length = 1082 * 7680 = 8309760, and 8309760 > 8306688  Note that userspace may still write to the invisiable area if a larger buffer than width x stride is exposed. But it is not a big issue as long as there still have memory resolve the access if not drafting so far.   - Also limit the y1 (Daniel)  - keep fix patch it to minimal (Daniel)  - screen_size is page size aligned because of it need mmap (Thomas)  - Adding fixes tag (Thomas)
CVE-2023-54118: In the Linux kernel, the following vulnerability has been resolved:  serial: sc16is7xx: setup GPIO controller later in probe  The GPIO controller component of the sc16is7xx driver is setup too early, which can result in a race condition where another device tries to utilise the GPIO lines before the sc16is7xx device has finished initialising.  This issue manifests itself as an Oops when the GPIO lines are configured:      Unable to handle kernel read from unreadable memory at virtual address     ...     pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx]     lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx]     ...     Call trace:     sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx]     gpiod_direction_output_raw_commit+0x64/0x318     gpiod_direction_output+0xb0/0x170     create_gpio_led+0xec/0x198     gpio_led_probe+0x16c/0x4f0     platform_drv_probe+0x5c/0xb0     really_probe+0xe8/0x448     driver_probe_device+0xe8/0x138     __device_attach_driver+0x94/0x118     bus_for_each_drv+0x8c/0xe0     __device_attach+0x100/0x1b8     device_initial_probe+0x28/0x38     bus_probe_device+0xa4/0xb0     deferred_probe_work_func+0x90/0xe0     process_one_work+0x1c4/0x480     worker_thread+0x54/0x430     kthread+0x138/0x150     ret_from_fork+0x10/0x1c  This patch moves the setup of the GPIO controller functions to later in the probe function, ensuring the sc16is7xx device has already finished initialising by the time other devices try to make use of the GPIO lines. The error handling has also been reordered to reflect the new initialisation order.
CVE-2023-54119: In the Linux kernel, the following vulnerability has been resolved:  inotify: Avoid reporting event with invalid wd  When inotify_freeing_mark() races with inotify_handle_inode_event() it can happen that inotify_handle_inode_event() sees that i_mark->wd got already reset to -1 and reports this value to userspace which can confuse the inotify listener. Avoid the problem by validating that wd is sensible (and pretend the mark got removed before the event got generated otherwise).
CVE-2023-54120: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Fix race condition in hidp_session_thread  There is a potential race condition in hidp_session_thread that may lead to use-after-free. For instance, the timer is active while hidp_del_timer is called in hidp_session_thread(). After hidp_session_put, then 'session' will be freed, causing kernel panic when hidp_idle_timeout is running.  The solution is to use del_timer_sync instead of del_timer.  Here is the call trace:  ? hidp_session_probe+0x780/0x780 call_timer_fn+0x2d/0x1e0 __run_timers.part.0+0x569/0x940 hidp_session_probe+0x780/0x780 call_timer_fn+0x1e0/0x1e0 ktime_get+0x5c/0xf0 lapic_next_deadline+0x2c/0x40 clockevents_program_event+0x205/0x320 run_timer_softirq+0xa9/0x1b0 __do_softirq+0x1b9/0x641 __irq_exit_rcu+0xdc/0x190 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0xa1/0xc0
CVE-2023-54121: In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix incorrect splitting in btrfs_drop_extent_map_range  In production we were seeing a variety of WARN_ON()'s in the extent_map code, specifically in btrfs_drop_extent_map_range() when we have to call add_extent_mapping() for our second split.  Consider the following extent map layout   PINNED  [0 16K)  [32K, 48K)  and then we call btrfs_drop_extent_map_range for [0, 36K), with skip_pinned == true.  The initial loop will have   start = 0  end = 36K  len = 36K  we will find the [0, 16k) extent, but since we are pinned we will skip it, which has this code   start = em_end;  if (end != (u64)-1)   len = start + len - em_end;  em_end here is 16K, so now the values are   start = 16K  len = 16K + 36K - 16K = 36K  len should instead be 20K.  This is a problem when we find the next extent at [32K, 48K), we need to split this extent to leave [36K, 48k), however the code for the split looks like this   split->start = start + len;  split->len = em_end - (start + len);  In this case we have   em_end = 48K  split->start = 16K + 36K       // this should be 16K + 20K  split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K  and now we have an invalid extent_map in the tree that potentially overlaps other entries in the extent map.  Even in the non-overlapping case we will have split->start set improperly, which will cause problems with any block related calculations.  We don't actually need len in this loop, we can simply use end as our end point, and only adjust start up when we find a pinned extent we need to skip.  Adjust the logic to do this, which keeps us from inserting an invalid extent map.  We only skip_pinned in the relocation case, so this is relatively rare, except in the case where you are running relocation a lot, which can happen with auto relocation on.
CVE-2023-54122: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dpu: Add check for cstate  As kzalloc may fail and return NULL pointer, it should be better to check cstate in order to avoid the NULL pointer dereference in __drm_atomic_helper_crtc_reset.  Patchwork: https://patchwork.freedesktop.org/patch/514163/
CVE-2023-54123: In the Linux kernel, the following vulnerability has been resolved:  md/raid10: fix memleak for 'conf->bio_split'  In the error path of raid10_run(), 'conf' need be freed, however, 'conf->bio_split' is missed and memory will be leaked.  Since there are 3 places to free 'conf', factor out a helper to fix the problem.
CVE-2023-54126: In the Linux kernel, the following vulnerability has been resolved:  crypto: safexcel - Cleanup ring IRQ workqueues on load failure  A failure loading the safexcel driver results in the following warning on boot, because the IRQ affinity has not been correctly cleaned up. Ensure we clean up the affinity and workqueues on a failure to load the driver.  crypto-safexcel: probe of f2800000.crypto failed with error -2 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340 Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4 CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G        W          6.1.6-00002-g9d4898824677 #3 Hardware name: MikroTik RB5009 (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : free_irq+0x300/0x340 lr : free_irq+0x2e0/0x340 sp : ffff800008fa3890 x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000 x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50 x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80 x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040 x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370 x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18 x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188 x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0 Call trace:  free_irq+0x300/0x340  devm_irq_release+0x14/0x20  devres_release_all+0xa0/0x100  device_unbind_cleanup+0x14/0x60  really_probe+0x198/0x2d4  __driver_probe_device+0x74/0xdc  driver_probe_device+0x3c/0x110  __driver_attach+0x8c/0x190  bus_for_each_dev+0x6c/0xc0  driver_attach+0x20/0x30  bus_add_driver+0x148/0x1fc  driver_register+0x74/0x120  __platform_driver_register+0x24/0x30  safexcel_init+0x48/0x1000 [crypto_safexcel]  do_one_initcall+0x4c/0x1b0  do_init_module+0x44/0x1cc  load_module+0x1724/0x1be4  __do_sys_finit_module+0xbc/0x110  __arm64_sys_finit_module+0x1c/0x24  invoke_syscall+0x44/0x110  el0_svc_common.constprop.0+0xc0/0xe0  do_el0_svc+0x20/0x80  el0_svc+0x14/0x4c  el0t_64_sync_handler+0xb0/0xb4  el0t_64_sync+0x148/0x14c ---[ end trace 0000000000000000 ]---
CVE-2023-54129: In the Linux kernel, the following vulnerability has been resolved:  octeontx2-af: Add validation for lmac type  Upon physical link change, firmware reports to the kernel about the change along with the details like speed, lmac_type_id, etc. Kernel derives lmac_type based on lmac_type_id received from firmware.  In a few scenarios, firmware returns an invalid lmac_type_id, which is resulting in below kernel panic. This patch adds the missing validation of the lmac_type_id field.  Internal error: Oops: 96000005 [#1] PREEMPT SMP [   35.321595] Modules linked in: [   35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.4.210-g2e3169d8e1bc-dirty #17 [   35.337014] Hardware name: Marvell CN103XX board (DT) [   35.344297] Workqueue: events work_for_cpu_fn [   35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO) [   35.360267] pc : strncpy+0x10/0x30 [   35.366595] lr : cgx_link_change_handler+0x90/0x180
CVE-2023-54131: In the Linux kernel, the following vulnerability has been resolved:  wifi: rt2x00: Fix memory leak when handling surveys  When removing a rt2x00 device, its associated channel surveys are not freed, causing a memory leak observable with kmemleak:  unreferenced object 0xffff9620f0881a00 (size 512):   comm "systemd-udevd", pid 2290, jiffies 4294906974 (age 33.768s)   hex dump (first 32 bytes):     70 44 12 00 00 00 00 00 92 8a 00 00 00 00 00 00  pD..............     00 00 00 00 00 00 00 00 ab 87 01 00 00 00 00 00  ................   backtrace:     [<ffffffffb0ed858b>] __kmalloc+0x4b/0x130     [<ffffffffc1b0f29b>] rt2800_probe_hw+0xc2b/0x1380 [rt2800lib]     [<ffffffffc1a9496e>] rt2800usb_probe_hw+0xe/0x60 [rt2800usb]     [<ffffffffc1ae491a>] rt2x00lib_probe_dev+0x21a/0x7d0 [rt2x00lib]     [<ffffffffc1b3b83e>] rt2x00usb_probe+0x1be/0x980 [rt2x00usb]     [<ffffffffc05981e2>] usb_probe_interface+0xe2/0x310 [usbcore]     [<ffffffffb13be2d5>] really_probe+0x1a5/0x410     [<ffffffffb13be5c8>] __driver_probe_device+0x78/0x180     [<ffffffffb13be6fe>] driver_probe_device+0x1e/0x90     [<ffffffffb13be972>] __driver_attach+0xd2/0x1c0     [<ffffffffb13bbc57>] bus_for_each_dev+0x77/0xd0     [<ffffffffb13bd2a2>] bus_add_driver+0x112/0x210     [<ffffffffb13bfc6c>] driver_register+0x5c/0x120     [<ffffffffc0596ae8>] usb_register_driver+0x88/0x150 [usbcore]     [<ffffffffb0c011c4>] do_one_initcall+0x44/0x220     [<ffffffffb0d6134c>] do_init_module+0x4c/0x220  Fix this by freeing the channel surveys on device removal.  Tested with a RT3070 based USB wireless adapter.
CVE-2023-54132: In the Linux kernel, the following vulnerability has been resolved:  erofs: stop parsing non-compact HEAD index if clusterofs is invalid  Syzbot generated a crafted image [1] with a non-compact HEAD index of clusterofs 33024 while valid numbers should be 0 ~ lclustersize-1, which causes the following unexpected behavior as below:   BUG: unable to handle page fault for address: fffff52101a3fff9  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 23ffed067 P4D 23ffed067 PUD 0  Oops: 0000 [#1] PREEMPT SMP KASAN  CPU: 1 PID: 4398 Comm: kworker/u5:1 Not tainted 6.3.0-rc6-syzkaller-g09a9639e56c0 #0  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023  Workqueue: erofs_worker z_erofs_decompressqueue_work  RIP: 0010:z_erofs_decompress_queue+0xb7e/0x2b40  ...  Call Trace:   <TASK>   z_erofs_decompressqueue_work+0x99/0xe0   process_one_work+0x8f6/0x1170   worker_thread+0xa63/0x1210   kthread+0x270/0x300   ret_from_fork+0x1f/0x30  Note that normal images or images using compact indexes are not impacted.  Let's fix this now.  [1] https://lore.kernel.org/r/000000000000ec75b005ee97fbaa@google.com
CVE-2023-54135: In the Linux kernel, the following vulnerability has been resolved:  maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()  Check the write offset end bounds before using it as the offset into the pivot array.  This avoids a possible out-of-bounds access on the pivot array if the write extends to the last slot in the node, in which case the node maximum should be used as the end pivot.  akpm: this doesn't affect any current callers, but new users of mapletree may encounter this problem if backported into earlier kernels, so let's fix it in -stable kernels in case of this.
CVE-2023-54136: In the Linux kernel, the following vulnerability has been resolved:  serial: sprd: Fix DMA buffer leak issue  Release DMA buffer when _probe() returns failure to avoid memory leak.
CVE-2023-54137: In the Linux kernel, the following vulnerability has been resolved:  vfio/type1: fix cap_migration information leak  Fix an information leak where an uninitialized hole in struct vfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.  The definition of struct vfio_iommu_type1_info_cap_migration contains a hole as shown in this pahole(1) output:    struct vfio_iommu_type1_info_cap_migration {           struct vfio_info_cap_header header;              /*     0     8 */           __u32                      flags;                /*     8     4 */            /* XXX 4 bytes hole, try to pack */            __u64                      pgsize_bitmap;        /*    16     8 */           __u64                      max_dirty_bitmap_size; /*    24     8 */            /* size: 32, cachelines: 1, members: 4 */           /* sum members: 28, holes: 1, sum holes: 4 */           /* last cacheline: 32 bytes */   };  The cap_mig variable is filled in without initializing the hole:    static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,                          struct vfio_info_cap *caps)   {       struct vfio_iommu_type1_info_cap_migration cap_mig;        cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION;       cap_mig.header.version = 1;        cap_mig.flags = 0;       /* support minimum pgsize */       cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap);       cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX;        return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig));   }  The structure is then copied to a temporary location on the heap. At this point it's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspace later:    int vfio_info_add_capability(struct vfio_info_cap *caps,                    struct vfio_info_cap_header *cap, size_t size)   {       struct vfio_info_cap_header *header;        header = vfio_info_cap_add(caps, size, cap->id, cap->version);       if (IS_ERR(header))           return PTR_ERR(header);        memcpy(header + 1, cap + 1, size - sizeof(*header));        return 0;   }  This issue was found by code inspection.
CVE-2023-54139: In the Linux kernel, the following vulnerability has been resolved:  tracing/user_events: Ensure write index cannot be negative  The write index indicates which event the data is for and accesses a per-file array. The index is passed by user processes during write() calls as the first 4 bytes. Ensure that it cannot be negative by returning -EINVAL to prevent out of bounds accesses.  Update ftrace self-test to ensure this occurs properly.