xamxte/cve-to-cwe huggingface dataset:
CVE-2022-50701: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7921s: fix slab-out-of-bounds access in sdio host  SDIO may need addtional 511 bytes to align bus operation. If the tailroom of this skb is not big enough, we would access invalid memory region. For low level operation, increase skb size to keep valid memory access in SDIO host.  Error message: [69.951] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0xe9/0x1a0 [69.951] Read of size 64 at addr ffff88811c9cf000 by task kworker/u16:7/451 [69.951] CPU: 4 PID: 451 Comm: kworker/u16:7 Tainted: G W  OE  6.1.0-rc5 #1 [69.951] Workqueue: kvub300c vub300_cmndwork_thread [vub300] [69.951] Call Trace: [69.951]  <TASK> [69.952]  dump_stack_lvl+0x49/0x63 [69.952]  print_report+0x171/0x4a8 [69.952]  kasan_report+0xb4/0x130 [69.952]  kasan_check_range+0x149/0x1e0 [69.952]  memcpy+0x24/0x70 [69.952]  sg_copy_buffer+0xe9/0x1a0 [69.952]  sg_copy_to_buffer+0x12/0x20 [69.952]  __command_write_data.isra.0+0x23c/0xbf0 [vub300] [69.952]  vub300_cmndwork_thread+0x17f3/0x58b0 [vub300] [69.952]  process_one_work+0x7ee/0x1320 [69.952]  worker_thread+0x53c/0x1240 [69.952]  kthread+0x2b8/0x370 [69.952]  ret_from_fork+0x1f/0x30 [69.952]  </TASK>  [69.952] Allocated by task 854: [69.952]  kasan_save_stack+0x26/0x50 [69.952]  kasan_set_track+0x25/0x30 [69.952]  kasan_save_alloc_info+0x1b/0x30 [69.952]  __kasan_kmalloc+0x87/0xa0 [69.952]  __kmalloc_node_track_caller+0x63/0x150 [69.952]  kmalloc_reserve+0x31/0xd0 [69.952]  __alloc_skb+0xfc/0x2b0 [69.952]  __mt76_mcu_msg_alloc+0xbf/0x230 [mt76] [69.952]  mt76_mcu_send_and_get_msg+0xab/0x110 [mt76] [69.952]  __mt76_mcu_send_firmware.cold+0x94/0x15d [mt76] [69.952]  mt76_connac_mcu_send_ram_firmware+0x415/0x54d [mt76_connac_lib] [69.952]  mt76_connac2_load_ram.cold+0x118/0x4bc [mt76_connac_lib] [69.952]  mt7921_run_firmware.cold+0x2e9/0x405 [mt7921_common] [69.952]  mt7921s_mcu_init+0x45/0x80 [mt7921s] [69.953]  mt7921_init_work+0xe1/0x2a0 [mt7921_common] [69.953]  process_one_work+0x7ee/0x1320 [69.953]  worker_thread+0x53c/0x1240 [69.953]  kthread+0x2b8/0x370 [69.953]  ret_from_fork+0x1f/0x30 [69.953] The buggy address belongs to the object at ffff88811c9ce800              which belongs to the cache kmalloc-2k of size 2048 [69.953] The buggy address is located 0 bytes to the right of              2048-byte region [ffff88811c9ce800, ffff88811c9cf000)  [69.953] Memory state around the buggy address: [69.953]  ffff88811c9cef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953]  ffff88811c9cef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953] >ffff88811c9cf000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [69.953]                    ^ [69.953]  ffff88811c9cf080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [69.953]  ffff88811c9cf100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
CVE-2022-50702: In the Linux kernel, the following vulnerability has been resolved:  vdpa_sim: fix possible memory leak in vdpasim_net_init() and vdpasim_blk_init()  Inject fault while probing module, if device_register() fails in vdpasim_net_init() or vdpasim_blk_init(), but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup().  (vdpa_sim_net) unreferenced object 0xffff88807eebc370 (size 16):   comm "modprobe", pid 3848, jiffies 4362982860 (age 18.153s)   hex dump (first 16 bytes):     76 64 70 61 73 69 6d 5f 6e 65 74 00 6b 6b 6b a5  vdpasim_net.kkk.   backtrace:     [<ffffffff8174f19e>] __kmalloc_node_track_caller+0x4e/0x150     [<ffffffff81731d53>] kstrdup+0x33/0x60     [<ffffffff83a5d421>] kobject_set_name_vargs+0x41/0x110     [<ffffffff82d87aab>] dev_set_name+0xab/0xe0     [<ffffffff82d91a23>] device_add+0xe3/0x1a80     [<ffffffffa0270013>] 0xffffffffa0270013     [<ffffffff81001c27>] do_one_initcall+0x87/0x2e0     [<ffffffff813739cb>] do_init_module+0x1ab/0x640     [<ffffffff81379d20>] load_module+0x5d00/0x77f0     [<ffffffff8137bc40>] __do_sys_finit_module+0x110/0x1b0     [<ffffffff83c4d505>] do_syscall_64+0x35/0x80     [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0  (vdpa_sim_blk) unreferenced object 0xffff8881070c1250 (size 16):   comm "modprobe", pid 6844, jiffies 4364069319 (age 17.572s)   hex dump (first 16 bytes):     76 64 70 61 73 69 6d 5f 62 6c 6b 00 6b 6b 6b a5  vdpasim_blk.kkk.   backtrace:     [<ffffffff8174f19e>] __kmalloc_node_track_caller+0x4e/0x150     [<ffffffff81731d53>] kstrdup+0x33/0x60     [<ffffffff83a5d421>] kobject_set_name_vargs+0x41/0x110     [<ffffffff82d87aab>] dev_set_name+0xab/0xe0     [<ffffffff82d91a23>] device_add+0xe3/0x1a80     [<ffffffffa0220013>] 0xffffffffa0220013     [<ffffffff81001c27>] do_one_initcall+0x87/0x2e0     [<ffffffff813739cb>] do_init_module+0x1ab/0x640     [<ffffffff81379d20>] load_module+0x5d00/0x77f0     [<ffffffff8137bc40>] __do_sys_finit_module+0x110/0x1b0     [<ffffffff83c4d505>] do_syscall_64+0x35/0x80     [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2022-50703: In the Linux kernel, the following vulnerability has been resolved:  soc: qcom: smsm: Fix refcount leak bugs in qcom_smsm_probe()  There are two refcount leak bugs in qcom_smsm_probe():  (1) The 'local_node' is escaped out from for_each_child_of_node() as the break of iteration, we should call of_node_put() for it in error path or when it is not used anymore. (2) The 'node' is escaped out from for_each_available_child_of_node() as the 'goto', we should call of_node_put() for it in goto target.
CVE-2022-50704: In the Linux kernel, the following vulnerability has been resolved:  USB: gadget: Fix use-after-free during usb config switch  In the process of switching USB config from rndis to other config, if the hardware does not support the ->pullup callback, or the hardware encounters a low probability fault, both of them may cause the ->pullup callback to fail, which will then cause a system panic (use after free).  The gadget drivers sometimes need to be unloaded regardless of the hardware's behavior.  Analysis as follows: ======================================================================= (1) write /config/usb_gadget/g1/UDC "none"  gether_disconnect+0x2c/0x1f8 rndis_disable+0x4c/0x74 composite_disconnect+0x74/0xb0 configfs_composite_disconnect+0x60/0x7c usb_gadget_disconnect+0x70/0x124 usb_gadget_unregister_driver+0xc8/0x1d8 gadget_dev_desc_UDC_store+0xec/0x1e4  (2) rm /config/usb_gadget/g1/configs/b.1/f1  rndis_deregister+0x28/0x54 rndis_free+0x44/0x7c usb_put_function+0x14/0x1c config_usb_cfg_unlink+0xc4/0xe0 configfs_unlink+0x124/0x1c8 vfs_unlink+0x114/0x1dc  (3) rmdir /config/usb_gadget/g1/functions/rndis.gs4  panic+0x1fc/0x3d0 do_page_fault+0xa8/0x46c do_mem_abort+0x3c/0xac el1_sync_handler+0x40/0x78 0xffffff801138f880 rndis_close+0x28/0x34 eth_stop+0x74/0x110 dev_close_many+0x48/0x194 rollback_registered_many+0x118/0x814 unregister_netdev+0x20/0x30 gether_cleanup+0x1c/0x38 rndis_attr_release+0xc/0x14 kref_put+0x74/0xb8 configfs_rmdir+0x314/0x374  If gadget->ops->pullup() return an error, function rndis_close() will be called, then it will causes a use-after-free problem. =======================================================================
CVE-2022-50707: In the Linux kernel, the following vulnerability has been resolved:  virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()  'vc_ctrl_req' is alloced in virtio_crypto_alg_skcipher_close_session(), and should be freed in the invalid ctrl_status->status error handling case. Otherwise there is a memory leak.
CVE-2022-50708: In the Linux kernel, the following vulnerability has been resolved:  HSI: ssi_protocol: fix potential resource leak in ssip_pn_open()  ssip_pn_open() claims the HSI client's port with hsi_claim_port(). When hsi_register_port_event() gets some error and returns a negetive value, the HSI client's port should be released with hsi_release_port().  Fix it by calling hsi_release_port() when hsi_register_port_event() fails.
CVE-2022-50709: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()  syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory.  Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line in ath9k_hif_usb_rx_stream().  We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter.  Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol.
CVE-2022-50710: In the Linux kernel, the following vulnerability has been resolved:  ice: set tx_tstamps when creating new Tx rings via ethtool  When the user changes the number of queues via ethtool, the driver allocates new rings. This allocation did not initialize tx_tstamps. This results in the tx_tstamps field being zero (due to kcalloc allocation), and would result in a NULL pointer dereference when attempting a transmit timestamp on the new ring.
CVE-2022-50711: In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: mtk_eth_soc: fix possible memory leak in mtk_probe()  If mtk_wed_add_hw() has been called, mtk_wed_exit() needs be called in error path or removing module to free the memory allocated in mtk_wed_add_hw().
CVE-2023-53867: In the Linux kernel, the following vulnerability has been resolved:  ceph: fix potential use-after-free bug when trimming caps  When trimming the caps and just after the 'session->s_cap_lock' is released in ceph_iterate_session_caps() the cap maybe removed by another thread, and when using the stale cap memory in the callbacks it will trigger use-after-free crash.  We need to check the existence of the cap just after the 'ci->i_ceph_lock' being acquired. And do nothing if it's already removed.
CVE-2023-53988: In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Fix slab-out-of-bounds read in hdr_delete_de()  Here is a BUG report from syzbot:  BUG: KASAN: slab-out-of-bounds in hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806 Read of size 16842960 at addr ffff888079cc0600 by task syz-executor934/3631  Call Trace:  memmove+0x25/0x60 mm/kasan/shadow.c:54  hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806  indx_delete_entry+0x74f/0x3670 fs/ntfs3/index.c:2193  ni_remove_name+0x27a/0x980 fs/ntfs3/frecord.c:2910  ntfs_unlink_inode+0x3d4/0x720 fs/ntfs3/inode.c:1712  ntfs_rename+0x41a/0xcb0 fs/ntfs3/namei.c:276  Before using the meta-data in struct INDEX_HDR, we need to check index header valid or not. Otherwise, the corruptedi (or malicious) fs image can cause out-of-bounds access which could make kernel panic.
CVE-2023-53990: In the Linux kernel, the following vulnerability has been resolved:  SMB3: Add missing locks to protect deferred close file list  cifs_del_deferred_close function has a critical section which modifies the deferred close file list. We must acquire deferred_lock before calling cifs_del_deferred_close function.
CVE-2023-53991: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dpu: Disallow unallocated resources to be returned  In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in "drm/msm/dpu: Reject topologies for which no DSC blocks are available") remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs).  To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn't increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform.  ^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context.  Patchwork: https://patchwork.freedesktop.org/patch/517636/
CVE-2023-53993: In the Linux kernel, the following vulnerability has been resolved:  PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y  After a pci_doe_task completes, its work_struct needs to be destroyed to avoid a memory leak with CONFIG_DEBUG_OBJECTS=y.
CVE-2023-53995: In the Linux kernel, the following vulnerability has been resolved:  net: ipv4: fix one memleak in __inet_del_ifa()  I got the below warning when do fuzzing test: unregister_netdevice: waiting for bond0 to become free. Usage count = 2  It can be repoduced via:  ip link add bond0 type bond sysctl -w net.ipv4.conf.bond0.promote_secondaries=1 ip addr add 4.117.174.103/0 scope 0x40 dev bond0 ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0 ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0 ip addr del 4.117.174.103/0 scope 0x40 dev bond0 ip link delete bond0 type bond  In this reproduction test case, an incorrect 'last_prim' is found in __inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40) is lost. The memory of the secondary address is leaked and the reference of in_device and net_device is leaked.  Fix this problem: Look for 'last_prim' starting at location of the deleted IP and inserting the promoted IP into the location of 'last_prim'.
CVE-2023-53997: In the Linux kernel, the following vulnerability has been resolved:  thermal: of: fix double-free on unregistration  Since commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone parameters structure"), thermal_zone_device_register() allocates a copy of the tzp argument and frees it when unregistering, so thermal_of_zone_register() now ends up leaking its original tzp and double-freeing the tzp copy. Fix this by locating tzp on stack instead.
CVE-2023-53998: In the Linux kernel, the following vulnerability has been resolved:  hwrng: virtio - Fix race on data_avail and actual data  The virtio rng device kicks off a new entropy request whenever the data available reaches zero.  When a new request occurs at the end of a read operation, that is, when the result of that request is only needed by the next reader, then there is a race between the writing of the new data and the next reader.  This is because there is no synchronisation whatsoever between the writer and the reader.  Fix this by writing data_avail with smp_store_release and reading it with smp_load_acquire when we first enter read.  The subsequent reads are safe because they're either protected by the first load acquire, or by the completion mechanism.  Also remove the redundant zeroing of data_idx in random_recv_done (data_idx must already be zero at this point) and data_avail in request_entropy (ditto).
CVE-2023-53999: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: TC, Fix internal port memory leak  The flow rule can be splited, and the extra post_act rules are added to post_act table. It's possible to trigger memleak when the rule forwards packets from internal port and over tunnel, in the case that, for example, CT 'new' state offload is allowed. As int_port object is assigned to the flow attribute of post_act rule, and its refcnt is incremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() is not called, the refcnt is never decremented, then int_port is never freed.  The kmemleak reports the following error: unreferenced object 0xffff888128204b80 (size 64):   comm "handler20", pid 50121, jiffies 4296973009 (age 642.932s)   hex dump (first 32 bytes):     01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00  ................     98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff  .wgA.....wgA....   backtrace:     [<00000000e992680d>] kmalloc_trace+0x27/0x120     [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core]     [<0000000035a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core]     [<0000000070c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core]     [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core]     [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core]     [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core]     [<0000000016c15cc3>] tc_setup_cb_add+0x1cf/0x410     [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower]     [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower]     [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010     [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0     [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360     [<0000000082dd6c8b>] netlink_unicast+0x438/0x710     [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50     [<0000000016e92590>] sock_sendmsg+0xc5/0x190  So fix this by moving int_port cleanup code to the flow attribute free helper, which is used by all the attribute free cases.
CVE-2023-54001: In the Linux kernel, the following vulnerability has been resolved:  staging: r8712: Fix memory leak in _r8712_init_xmit_priv()  In the above mentioned routine, memory is allocated in several places. If the first succeeds and a later one fails, the routine will leak memory. This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel"). A potential memory leak in r8712_xmit_resource_alloc() is also addressed.
CVE-2023-54003: In the Linux kernel, the following vulnerability has been resolved:  RDMA/core: Fix GID entry ref leak when create_ah fails  If AH create request fails, release sgid_attr to avoid GID entry referrence leak reported while releasing GID table
CVE-2023-54005: In the Linux kernel, the following vulnerability has been resolved:  binder: fix memory leak in binder_init()  In binder_init(), the destruction of binder_alloc_shrinker_init() is not performed in the wrong path, which will cause memory leaks. So this commit introduces binder_alloc_shrinker_exit() and calls it in the wrong path to fix that.
CVE-2023-54006: In the Linux kernel, the following vulnerability has been resolved:  af_unix: Fix data-race around unix_tot_inflight.  unix_tot_inflight is changed under spin_lock(unix_gc_lock), but unix_release_sock() reads it locklessly.  Let's use READ_ONCE() for unix_tot_inflight.  Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix: annote lockless accesses to unix_tot_inflight & gc_in_progress")  BUG: KCSAN: data-race in unix_inflight / unix_release_sock  write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:  unix_inflight+0x130/0x180 net/unix/scm.c:64  unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123  unix_scm_to_skb net/unix/af_unix.c:1832 [inline]  unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955  sock_sendmsg_nosec net/socket.c:724 [inline]  sock_sendmsg+0x148/0x160 net/socket.c:747  ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493  ___sys_sendmsg+0xc6/0x140 net/socket.c:2547  __sys_sendmsg+0x94/0x140 net/socket.c:2576  __do_sys_sendmsg net/socket.c:2585 [inline]  __se_sys_sendmsg net/socket.c:2583 [inline]  __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x72/0xdc  read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:  unix_release_sock+0x608/0x910 net/unix/af_unix.c:671  unix_release+0x59/0x80 net/unix/af_unix.c:1058  __sock_release+0x7d/0x170 net/socket.c:653  sock_close+0x19/0x30 net/socket.c:1385  __fput+0x179/0x5e0 fs/file_table.c:321  ____fput+0x15/0x20 fs/file_table.c:349  task_work_run+0x116/0x1a0 kernel/task_work.c:179  resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]  exit_to_user_mode_loop kernel/entry/common.c:171 [inline]  exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204  __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]  syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297  do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86  entry_SYSCALL_64_after_hwframe+0x72/0xdc  value changed: 0x00000000 -> 0x00000001  Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
CVE-2023-54007: In the Linux kernel, the following vulnerability has been resolved:  vmci_host: fix a race condition in vmci_host_poll() causing GPF  During fuzzing, a general protection fault is observed in vmci_host_poll().  general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf] RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926 <- omitting registers -> Call Trace:  <TASK>  lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]  _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162  add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22  poll_wait include/linux/poll.h:49 [inline]  vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174  vfs_poll include/linux/poll.h:88 [inline]  do_pollfd fs/select.c:873 [inline]  do_poll fs/select.c:921 [inline]  do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015  __do_sys_ppoll fs/select.c:1121 [inline]  __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101  do_syscall_x64 arch/x86/entry/common.c:51 [inline]  do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82  entry_SYSCALL_64_after_hwframe+0x46/0xb0  Example thread interleaving that causes the general protection fault is as follows:  CPU1 (vmci_host_poll)               CPU2 (vmci_host_do_init_context) -----                               ----- // Read uninitialized context context = vmci_host_dev->context;                                     // Initialize context                                     vmci_host_dev->context = vmci_ctx_create();                                     vmci_host_dev->ct_type = VMCIOBJ_CONTEXT;  if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) {     // Dereferencing the wrong pointer     poll_wait(..., &context->host_context); }  In this scenario, vmci_host_poll() reads vmci_host_dev->context first, and then reads vmci_host_dev->ct_type to check that vmci_host_dev->context is initialized. However, since these two reads are not atomically executed, there is a chance of a race condition as described above.  To fix this race condition, read vmci_host_dev->context after checking the value of vmci_host_dev->ct_type so that vmci_host_poll() always reads an initialized context.
CVE-2023-54009: In the Linux kernel, the following vulnerability has been resolved:  i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error path  The cdns_i2c_master_xfer() function gets a runtime PM reference when the function is entered. This reference is released when the function is exited. There is currently one error path where the function exits directly, which leads to a leak of the runtime PM reference.  Make sure that this error path also releases the runtime PM reference.
CVE-2023-54010: In the Linux kernel, the following vulnerability has been resolved:  ACPICA: ACPICA: check null return of ACPI_ALLOCATE_ZEROED in acpi_db_display_objects  ACPICA commit 0d5f467d6a0ba852ea3aad68663cbcbd43300fd4  ACPI_ALLOCATE_ZEROED may fails, object_info might be null and will cause null pointer dereference later.
CVE-2023-54011: In the Linux kernel, the following vulnerability has been resolved:  scsi: mpi3mr: Fix an issue found by KASAN  Write only correct size (32 instead of 64 bytes).