xamxte/cve-to-cwe huggingface dataset:
CVE-2022-50779: In the Linux kernel, the following vulnerability has been resolved:  orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()  When insert and remove the orangefs module, then debug_help_string will be leaked:    unreferenced object 0xffff8881652ba000 (size 4096):     comm "insmod", pid 1701, jiffies 4294893639 (age 13218.530s)     hex dump (first 32 bytes):       43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79  Client Debug Key       77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77  words are unknow     backtrace:       [<0000000004e6f8e3>] kmalloc_trace+0x27/0xa0       [<0000000006f75d85>] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs]       [<0000000091270a2a>] _sub_I_65535_1+0x57/0xf70 [crc_itu_t]       [<000000004b1ee1a3>] do_one_initcall+0x87/0x2a0       [<000000001d0614ae>] do_init_module+0xdf/0x320       [<00000000efef068c>] load_module+0x2f98/0x3330       [<000000006533b44d>] __do_sys_finit_module+0x113/0x1b0       [<00000000a0da6f99>] do_syscall_64+0x35/0x80       [<000000007790b19b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0  When remove the module, should always free debug_help_string. Should always free the allocated buffer when change the free_debug_help_string.
CVE-2022-50780: In the Linux kernel, the following vulnerability has been resolved:  net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed  When the ops_init() interface is invoked to initialize the net, but ops->init() fails, data is released. However, the ptr pointer in net->gen is invalid. In this case, when nfqnl_nf_hook_drop() is invoked to release the net, invalid address access occurs.  The process is as follows: setup_net()  ops_init()   data = kzalloc(...)   ---> alloc "data"   net_assign_generic()  ---> assign "date" to ptr in net->gen   ...   ops->init()           ---> failed   ...   kfree(data);          ---> ptr in net->gen is invalid  ...  ops_exit_list()   ...   nfqnl_nf_hook_drop()    *q = nfnl_queue_pernet(net) ---> q is invalid  The following is the Call Trace information: BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280 Read of size 8 at addr ffff88810396b240 by task ip/15855 Call Trace: <TASK> dump_stack_lvl+0x8e/0xd1 print_report+0x155/0x454 kasan_report+0xba/0x1f0 nfqnl_nf_hook_drop+0x264/0x280 nf_queue_nf_hook_drop+0x8b/0x1b0 __nf_unregister_net_hook+0x1ae/0x5a0 nf_unregister_net_hooks+0xde/0x130 ops_exit_list+0xb0/0x170 setup_net+0x7ac/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK>  Allocated by task 15855: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0xa1/0xb0 __kmalloc+0x49/0xb0 ops_init+0xe7/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0  Freed by task 15855: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x155/0x1b0 slab_free_freelist_hook+0x11b/0x220 __kmem_cache_free+0xa4/0x360 ops_init+0xb9/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2022-50781: In the Linux kernel, the following vulnerability has been resolved:  amdgpu/pm: prevent array underflow in vega20_odn_edit_dpm_table()  In the PP_OD_EDIT_VDDC_CURVE case the "input_index" variable is capped at 2 but not checked for negative values so it results in an out of bounds read.  This value comes from the user via sysfs.
CVE-2023-54044: In the Linux kernel, the following vulnerability has been resolved:  spmi: Add a check for remove callback when removing a SPMI driver  When removing a SPMI driver, there can be a crash due to NULL pointer dereference if it does not have a remove callback defined. This is one such call trace observed when removing the QCOM SPMI PMIC driver:   dump_backtrace.cfi_jt+0x0/0x8  dump_stack_lvl+0xd8/0x16c  panic+0x188/0x498  __cfi_slowpath+0x0/0x214  __cfi_slowpath+0x1dc/0x214  spmi_drv_remove+0x16c/0x1e0  device_release_driver_internal+0x468/0x79c  driver_detach+0x11c/0x1a0  bus_remove_driver+0xc4/0x124  driver_unregister+0x58/0x84  cleanup_module+0x1c/0xc24 [qcom_spmi_pmic]  __do_sys_delete_module+0x3ec/0x53c  __arm64_sys_delete_module+0x18/0x28  el0_svc_common+0xdc/0x294  el0_svc+0x38/0x9c  el0_sync_handler+0x8c/0xf0  el0_sync+0x1b4/0x1c0  If a driver has all its resources allocated through devm_() APIs and does not need any other explicit cleanup, it would not require a remove callback to be defined. Hence, add a check for remove callback presence before calling it when removing a SPMI driver.
CVE-2023-54046: In the Linux kernel, the following vulnerability has been resolved:  crypto: essiv - Handle EBUSY correctly  As it is essiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request.  However, as the caller of essiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way.  Otherwise backlogged requests will trigger a use-after-free.
CVE-2023-54047: In the Linux kernel, the following vulnerability has been resolved:  drm/rockchip: dw_hdmi: cleanup drm encoder during unbind  This fixes a use-after-free crash during rmmod.  The DRM encoder is embedded inside the larger rockchip_hdmi, which is allocated with the component. The component memory gets freed before the main drm device is destroyed. Fix it by running encoder cleanup before tearing down its container.  [moved encoder cleanup above clk_disable, similar to bind-error-path]
CVE-2023-54048: In the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Prevent handling any completions after qp destroy  HW may generate completions that indicates QP is destroyed. Driver should not be scheduling any more completion handlers for this QP, after the QP is destroyed. Since CQs are active during the QP destroy, driver may still schedule completion handlers. This can cause a race where the destroy_cq and poll_cq running simultaneously.  Snippet of kernel panic while doing bnxt_re driver load unload in loop. This indicates a poll after the CQ is freed.   [77786.481636] Call Trace: [77786.481640]  <TASK> [77786.481644]  bnxt_re_poll_cq+0x14a/0x620 [bnxt_re] [77786.481658]  ? kvm_clock_read+0x14/0x30 [77786.481693]  __ib_process_cq+0x57/0x190 [ib_core] [77786.481728]  ib_cq_poll_work+0x26/0x80 [ib_core] [77786.481761]  process_one_work+0x1e5/0x3f0 [77786.481768]  worker_thread+0x50/0x3a0 [77786.481785]  ? __pfx_worker_thread+0x10/0x10 [77786.481790]  kthread+0xe2/0x110 [77786.481794]  ? __pfx_kthread+0x10/0x10 [77786.481797]  ret_from_fork+0x2c/0x50  To avoid this, complete all completion handlers before returning the destroy QP. If free_cq is called soon after destroy_qp,  IB stack will cancel the CQ work before invoking the destroy_cq verb and this will prevent any race mentioned.
CVE-2023-54049: In the Linux kernel, the following vulnerability has been resolved:  rpmsg: glink: Add check for kstrdup  Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.
CVE-2023-54050: In the Linux kernel, the following vulnerability has been resolved:  ubifs: Fix memleak when insert_old_idx() failed  Following process will cause a memleak for copied up znode:  dirty_cow_znode   zn = copy_znode(c, znode);   err = insert_old_idx(c, zbr->lnum, zbr->offs);   if (unlikely(err))      return ERR_PTR(err);   // No one refers to zn.  Fetch a reproducer in [Link].  Function copy_znode() is split into 2 parts: resource allocation and znode replacement, insert_old_idx() is split in similar way, so resource cleanup could be done in error handling path without corrupting metadata(mem & disk). It's okay that old index inserting is put behind of add_idx_dirt(), old index is used in layout_leb_in_gaps(), so the two processes do not depend on each other.
CVE-2023-54051: In the Linux kernel, the following vulnerability has been resolved:  net: do not allow gso_size to be set to GSO_BY_FRAGS  One missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again [1]  Do not allow gso_size to be set to GSO_BY_FRAGS (0xffff), because this magic value is used by the kernel.  [1] general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 0 PID: 5039 Comm: syz-executor401 Not tainted 6.5.0-rc5-next-20230809-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:skb_segment+0x1a52/0x3ef0 net/core/skbuff.c:4500 Code: 00 00 00 e9 ab eb ff ff e8 6b 96 5d f9 48 8b 84 24 00 01 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e ea 21 00 00 48 8b 84 24 00 01 RSP: 0018:ffffc90003d3f1c8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 000000000001fffe RCX: 0000000000000000 RDX: 000000000000000e RSI: ffffffff882a3115 RDI: 0000000000000070 RBP: ffffc90003d3f378 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 5ee4a93e456187d6 R12: 000000000001ffc6 R13: dffffc0000000000 R14: 0000000000000008 R15: 000000000000ffff FS: 00005555563f2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020020000 CR3: 000000001626d000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0x9d2/0xd50 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x5c4/0x17b0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x292/0x610 net/core/gso.c:53 __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x3a5/0xf10 net/core/dev.c:3625 __dev_queue_xmit+0x8f0/0x3d60 net/core/dev.c:4329 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c7/0x5570 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:727 [inline] sock_sendmsg+0xd9/0x180 net/socket.c:750 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2496 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2550 __sys_sendmsg+0x117/0x1e0 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ff27cdb34d9
CVE-2023-54053: In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: pcie: fix possible NULL pointer dereference  It is possible that iwl_pci_probe() will fail and free the trans, then afterwards iwl_pci_remove() will be called and crash by trying to access trans which is already freed, fix it.  iwlwifi 0000:01:00.0: Detected crf-id 0xa5a5a5a2, cnv-id 0xa5a5a5a2         wfpm id 0xa5a5a5a2 iwlwifi 0000:01:00.0: Can't find a correct rfid for crf id 0x5a2 ... BUG: kernel NULL pointer dereference, address: 0000000000000028 ... RIP: 0010:iwl_pci_remove+0x12/0x30 [iwlwifi] pci_device_remove+0x3e/0xb0 device_release_driver_internal+0x103/0x1f0 driver_detach+0x4c/0x90 bus_remove_driver+0x5c/0xd0 driver_unregister+0x31/0x50 pci_unregister_driver+0x40/0x90 iwl_pci_unregister_driver+0x15/0x20 [iwlwifi] __exit_compat+0x9/0x98 [iwlwifi] __x64_sys_delete_module+0x147/0x260
CVE-2023-54055: In the Linux kernel, the following vulnerability has been resolved:  RDMA/irdma: Fix memory leak of PBLE objects  On rmmod of irdma, the PBLE object memory is not being freed. PBLE object memory are not statically pre-allocated at function initialization time unlike other HMC objects. PBLEs objects and the Segment Descriptors (SD) for it can be dynamically allocated during scale up and SD's remain allocated till function deinitialization.  Fix this leak by adding IRDMA_HMC_IW_PBLE to the iw_hmc_obj_types[] table and skip pbles in irdma_create_hmc_obj but not in irdma_del_hmc_objects().
CVE-2023-54057: In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameter  The 'acpiid' buffer in the parse_ivrs_acpihid function may overflow, because the string specifier in the format string sscanf() has no width limitation.  Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-54058: In the Linux kernel, the following vulnerability has been resolved:  firmware: arm_ffa: Check if ffa_driver remove is present before executing  Currently ffa_drv->remove() is called unconditionally from ffa_device_remove(). Since the driver registration doesn't check for it and allows it to be registered without .remove callback, we need to check for the presence of it before executing it from ffa_device_remove() to above a NULL pointer dereference like the one below:    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000   | Mem abort info:   |   ESR = 0x0000000086000004   |   EC = 0x21: IABT (current EL), IL = 32 bits   |   SET = 0, FnV = 0   |   EA = 0, S1PTW = 0   |   FSC = 0x04: level 0 translation fault   | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881cc8000   | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000   | Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP   | CPU: 3 PID: 130 Comm: rmmod Not tainted 6.3.0-rc7 #6   | Hardware name: FVP Base RevC (DT)   | pstate: 63402809 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=-c)   | pc : 0x0   | lr : ffa_device_remove+0x20/0x2c   | Call trace:   |  0x0   |  device_release_driver_internal+0x16c/0x260   |  driver_detach+0x90/0xd0   |  bus_remove_driver+0xdc/0x11c   |  driver_unregister+0x30/0x54   |  ffa_driver_unregister+0x14/0x20   |  cleanup_module+0x18/0xeec   |  __arm64_sys_delete_module+0x234/0x378   |  invoke_syscall+0x40/0x108   |  el0_svc_common+0xb4/0xf0   |  do_el0_svc+0x30/0xa4   |  el0_svc+0x2c/0x7c   |  el0t_64_sync_handler+0x84/0xf0   |  el0t_64_sync+0x190/0x194
CVE-2023-54059: In the Linux kernel, the following vulnerability has been resolved:  soc: mediatek: mtk-svs: Enable the IRQ later  If the system does not come from reset (like when is booted via kexec()), the peripheral might triger an IRQ before the data structures are initialised.   [    0.227710] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000f08 [    0.227913] Call trace: [    0.227918]  svs_isr+0x8c/0x538
CVE-2023-54060: In the Linux kernel, the following vulnerability has been resolved:  iommufd: Set end correctly when doing batch carry  Even though the test suite covers this it somehow became obscured that this wasn't working.  The test iommufd_ioas.mock_domain.access_domain_destory would blow up rarely.  end should be set to 1 because this just pushed an item, the carry, to the pfns list.  Sometimes the test would blow up with:    BUG: kernel NULL pointer dereference, address: 0000000000000000   #PF: supervisor read access in kernel mode   #PF: error_code(0x0000) - not-present page   PGD 0 P4D 0   Oops: 0000 [#1] SMP   CPU: 5 PID: 584 Comm: iommufd Not tainted 6.5.0-rc1-dirty #1236   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014   RIP: 0010:batch_unpin+0xa2/0x100 [iommufd]   Code: 17 48 81 fe ff ff 07 00 77 70 48 8b 15 b7 be 97 e2 48 85 d2 74 14 48 8b 14 fa 48 85 d2 74 0b 40 0f b6 f6 48 c1 e6 04 48 01 f2 <48> 8b 3a 48 c1 e0 06 89 ca 48 89 de 48 83 e7 f0 48 01 c7 e8 96 dc   RSP: 0018:ffffc90001677a58 EFLAGS: 00010246   RAX: 00007f7e2646f000 RBX: 0000000000000000 RCX: 0000000000000001   RDX: 0000000000000000 RSI: 00000000fefc4c8d RDI: 0000000000fefc4c   RBP: ffffc90001677a80 R08: 0000000000000048 R09: 0000000000000200   R10: 0000000000030b98 R11: ffffffff81f3bb40 R12: 0000000000000001   R13: ffff888101f75800 R14: ffffc90001677ad0 R15: 00000000000001fe   FS:  00007f9323679740(0000) GS:ffff8881ba540000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000000000000 CR3: 0000000105ede003 CR4: 00000000003706a0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   Call Trace:    <TASK>    ? show_regs+0x5c/0x70    ? __die+0x1f/0x60    ? page_fault_oops+0x15d/0x440    ? lock_release+0xbc/0x240    ? exc_page_fault+0x4a4/0x970    ? asm_exc_page_fault+0x27/0x30    ? batch_unpin+0xa2/0x100 [iommufd]    ? batch_unpin+0xba/0x100 [iommufd]    __iopt_area_unfill_domain+0x198/0x430 [iommufd]    ? __mutex_lock+0x8c/0xb80    ? __mutex_lock+0x6aa/0xb80    ? xa_erase+0x28/0x30    ? iopt_table_remove_domain+0x162/0x320 [iommufd]    ? lock_release+0xbc/0x240    iopt_area_unfill_domain+0xd/0x10 [iommufd]    iopt_table_remove_domain+0x195/0x320 [iommufd]    iommufd_hw_pagetable_destroy+0xb3/0x110 [iommufd]    iommufd_object_destroy_user+0x8e/0xf0 [iommufd]    iommufd_device_detach+0xc5/0x140 [iommufd]    iommufd_selftest_destroy+0x1f/0x70 [iommufd]    iommufd_object_destroy_user+0x8e/0xf0 [iommufd]    iommufd_destroy+0x3a/0x50 [iommufd]    iommufd_fops_ioctl+0xfb/0x170 [iommufd]    __x64_sys_ioctl+0x40d/0x9a0    do_syscall_64+0x3c/0x80    entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2023-54062: In the Linux kernel, the following vulnerability has been resolved:  ext4: fix invalid free tracking in ext4_xattr_move_to_block()  In ext4_xattr_move_to_block(), the value of the extended attribute which we need to move to an external block may be allocated by kvmalloc() if the value is stored in an external inode.  So at the end of the function the code tried to check if this was the case by testing entry->e_value_inum.  However, at this point, the pointer to the xattr entry is no longer valid, because it was removed from the original location where it had been stored.  So we could end up calling kvfree() on a pointer which was not allocated by kvmalloc(); or we could also potentially leak memory by not freeing the buffer when it should be freed.  Fix this by storing whether it should be freed in a separate variable.
CVE-2023-54063: In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Fix OOB read in indx_insert_into_buffer  Syzbot reported a OOB read bug:  BUG: KASAN: slab-out-of-bounds in indx_insert_into_buffer+0xaa3/0x13b0 fs/ntfs3/index.c:1755 Read of size 17168 at addr ffff8880255e06c0 by task syz-executor308/3630  Call Trace:  <TASK>  memmove+0x25/0x60 mm/kasan/shadow.c:54  indx_insert_into_buffer+0xaa3/0x13b0 fs/ntfs3/index.c:1755  indx_insert_entry+0x446/0x6b0 fs/ntfs3/index.c:1863  ntfs_create_inode+0x1d3f/0x35c0 fs/ntfs3/inode.c:1548  ntfs_create+0x3e/0x60 fs/ntfs3/namei.c:100  lookup_open fs/namei.c:3413 [inline]  If the member struct INDEX_BUFFER *index of struct indx_node is incorrect, that is, the value of __le32 used is greater than the value of __le32 total in struct INDEX_HDR. Therefore, OOB read occurs when memmove is called in indx_insert_into_buffer(). Fix this by adding a check in hdr_find_e().
CVE-2023-54064: In the Linux kernel, the following vulnerability has been resolved:  ipmi:ssif: Fix a memory leak when scanning for an adapter  The adapter scan ssif_info_find() sets info->adapter_name if the adapter info came from SMBIOS, as it's not set in that case.  However, this function can be called more than once, and it will leak the adapter name if it had already been set.  So check for NULL before setting it.
CVE-2023-54065: In the Linux kernel, the following vulnerability has been resolved:  net: dsa: realtek: fix out-of-bounds access  The probe function sets priv->chip_data to (void *)priv + sizeof(*priv) with the expectation that priv has enough trailing space.  However, only realtek-smi actually allocated this chip_data space. Do likewise in realtek-mdio to fix out-of-bounds accesses.  These accesses likely went unnoticed so far, because of an (unused) buf[4096] member in struct realtek_priv, which caused kmalloc to round up the allocated buffer to a big enough size, so nothing of value was overwritten. With a different allocator (like in the barebox bootloader port of the driver) or with KASAN, the memory corruption becomes quickly apparent.
CVE-2023-54066: In the Linux kernel, the following vulnerability has been resolved:  media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xfer  In gl861_i2c_master_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach gl861_i2c_master_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.  Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
CVE-2023-54068: In the Linux kernel, the following vulnerability has been resolved:  f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()  BUG_ON() will be triggered when writing files concurrently, because the same page is writtenback multiple times.  1597 void folio_end_writeback(struct folio *folio) 1598 {   ...... 1618     if (!__folio_end_writeback(folio)) 1619         BUG();   ...... 1625 }  kernel BUG at mm/filemap.c:1619! Call Trace:  <TASK>  f2fs_write_end_io+0x1a0/0x370  blk_update_request+0x6c/0x410  blk_mq_end_request+0x15/0x130  blk_complete_reqs+0x3c/0x50  __do_softirq+0xb8/0x29b  ? sort_range+0x20/0x20  run_ksoftirqd+0x19/0x20  smpboot_thread_fn+0x10b/0x1d0  kthread+0xde/0x110  ? kthread_complete_and_exit+0x20/0x20  ret_from_fork+0x22/0x30  </TASK>  Below is the concurrency scenario:  [Process A]  [Process B]  [Process C] f2fs_write_raw_pages()   - redirty_page_for_writepage()   - unlock page()    f2fs_do_write_data_page()      - lock_page()      - clear_page_dirty_for_io()      - set_page_writeback() [1st writeback]        .....        - unlock page()        generic_perform_write()         - f2fs_write_begin()           - wait_for_stable_page()          - f2fs_write_end()           - set_page_dirty()    - lock_page()     - f2fs_do_write_data_page()       - set_page_writeback() [2st writeback]  This problem was introduced by the previous commit 7377e853967b ("f2fs: compress: fix potential deadlock of compress file"). All pagelocks were released in f2fs_write_raw_pages(), but whether the page was in the writeback state was ignored in the subsequent writing process. Let's fix it by waiting for the page to writeback before writing.