xamxte/cve-to-cwe huggingface dataset:
CVE-2023-54012: In the Linux kernel, the following vulnerability has been resolved:  net: fix stack overflow when LRO is disabled for virtual interfaces  When the virtual interface's feature is updated, it synchronizes the updated feature for its own lower interface. This propagation logic should be worked as the iteration, not recursively. But it works recursively due to the netdev notification unexpectedly. This problem occurs when it disables LRO only for the team and bonding interface type.         team0          |   +------+------+-----+-----+   |      |      |     |     | team1  team2  team3  ...  team200  If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGE event to its own lower interfaces(team1 ~ team200). It is worked by netdev_sync_lower_features(). So, the NETDEV_FEAT_CHANGE notification logic of each lower interface work iteratively. But generated NETDEV_FEAT_CHANGE event is also sent to the upper interface too. upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own lower interfaces again. lower and upper interfaces receive this event and generate this event again and again. So, the stack overflow occurs.  But it is not the infinite loop issue. Because the netdev_sync_lower_features() updates features before generating the NETDEV_FEAT_CHANGE event. Already synchronized lower interfaces skip notification logic. So, it is just the problem that iteration logic is changed to the recursive unexpectedly due to the notification mechanism.  Reproducer:  ip link add team0 type team ethtool -K team0 lro on for i in {1..200} do         ip link add team$i master team0 type team         ethtool -K team$i lro on done  ethtool -K team0 lro off  In order to fix it, the notifier_ctx member of bonding/team is introduced.
CVE-2023-54014: In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()  Klocwork reported warning of rport maybe NULL and will be dereferenced. rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.  Check valid rport returned by fc_bsg_to_rport().
CVE-2023-54015: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device  In case devcom allocation is failed, mlx5 is always freeing the priv. However, this priv might have been allocated by a different thread, and freeing it might lead to use-after-free bugs. Fix it by freeing the priv only in case it was allocated by the running thread.
CVE-2023-54016: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath12k: Fix memory leak in rx_desc and tx_desc  Currently when ath12k_dp_cc_desc_init() is called we allocate memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during descriptor cleanup rx_descs and tx_descs memory is not freed.  This is cause of memory leak. These allocated memory should be freed in ath12k_dp_cc_cleanup.  In ath12k_dp_cc_desc_init(), we can save base address of rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and tx_descs memory using their base address.  Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
CVE-2023-54017: In the Linux kernel, the following vulnerability has been resolved:  powerpc/pseries: fix possible memory leak in ibmebus_bus_init()  If device_register() returns error in ibmebus_bus_init(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked.  As comment of device_add() says, it should call put_device() to drop the reference count that was set in device_initialize() when it fails, so the name can be freed in kobject_cleanup().
CVE-2023-54018: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/hdmi: Add missing check for alloc_ordered_workqueue  Add check for the return value of alloc_ordered_workqueue as it may return NULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and `hdmi_hpd.c`.  Patchwork: https://patchwork.freedesktop.org/patch/517211/
CVE-2023-54019: In the Linux kernel, the following vulnerability has been resolved:  sched/psi: use kernfs polling functions for PSI trigger polling  Destroying psi trigger in cgroup_file_release causes UAF issues when a cgroup is removed from under a polling process. This is happening because cgroup removal causes a call to cgroup_file_release while the actual file is still alive. Destroying the trigger at this point would also destroy its waitqueue head and if there is still a polling process on that file accessing the waitqueue, it will step on the freed pointer:  do_select   vfs_poll                            do_rmdir                              cgroup_rmdir                                kernfs_drain_open_files                                  cgroup_file_release                                    cgroup_pressure_release                                      psi_trigger_destroy                                        wake_up_pollfree(&t->event_wait) // vfs_poll is unblocked                                        synchronize_rcu                                        kfree(t)   poll_freewait -> UAF access to the trigger's waitqueue head  Patch [1] fixed this issue for epoll() case using wake_up_pollfree(), however the same issue exists for synchronous poll() case. The root cause of this issue is that the lifecycles of the psi trigger's waitqueue and of the file associated with the trigger are different. Fix this by using kernfs_generic_poll function when polling on cgroup-specific psi triggers. It internally uses kernfs_open_node->poll waitqueue head with its lifecycle tied to the file's lifecycle. This also renders the fix in [1] obsolete, so revert it.  [1] commit c2dbe32d5db5 ("sched/psi: Fix use-after-free in ep_remove_wait_queue()")
CVE-2023-54020: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: sf-pdma: pdma_desc memory leak fix  Commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread support for a DMA channel") changed sf_pdma_prep_dma_memcpy() to unconditionally allocate a new sf_pdma_desc each time it is called.  The driver previously recycled descs, by checking the in_use flag, only allocating additional descs if the existing one was in use. This logic was removed in commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread support for a DMA channel"), but sf_pdma_free_desc() was not changed to handle the new behaviour.  As a result, each time sf_pdma_prep_dma_memcpy() is called, the previous descriptor is leaked, over time leading to memory starvation:    unreferenced object 0xffffffe008447300 (size 192):   comm "irq/39-mchp_dsc", pid 343, jiffies 4294906910 (age 981.200s)   hex dump (first 32 bytes):     00 00 00 ff 00 00 00 00 b8 c1 00 00 00 00 00 00  ................     00 00 70 08 10 00 00 00 00 00 00 c0 00 00 00 00  ..p.............   backtrace:     [<00000000064a04f4>] kmemleak_alloc+0x1e/0x28     [<00000000018927a7>] kmem_cache_alloc+0x11e/0x178     [<000000002aea8d16>] sf_pdma_prep_dma_memcpy+0x40/0x112  Add the missing kfree() to sf_pdma_free_desc(), and remove the redundant in_use flag.
CVE-2023-54022: In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix potential memory leaks at error path for UMP open  The allocation and initialization errors at alloc_midi_urbs() that is called at MIDI 2.0 / UMP device are supposed to be handled at the caller side by invoking free_midi_urbs().  However, free_midi_urbs() loops only for ep->num_urbs entries, and since ep->num_entries wasn't updated yet at the allocation / init error in alloc_midi_urbs(), this entry won't be released.  The intention of free_midi_urbs() is to release the whole elements, so change the loop size to NUM_URBS to scan over all elements for fixing the missed releases.  Also, the call of free_midi_urbs() is missing at snd_usb_midi_v2_open().  Although it'll be released later at reopen/close or disconnection, it's better to release immediately at the error path.
CVE-2023-54023: In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix race between balance and cancel/pause  Syzbot reported a panic that looks like this:    assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465   ------------[ cut here ]------------   kernel BUG at fs/btrfs/messages.c:259!   RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259   Call Trace:    <TASK>    btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline]    btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline]    btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:870 [inline]    __se_sys_ioctl fs/ioctl.c:856 [inline]    __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856    do_syscall_x64 arch/x86/entry/common.c:50 [inline]    do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80    entry_SYSCALL_64_after_hwframe+0x63/0xcd  The reproducer is running a balance and a cancel or pause in parallel. The way balance finishes is a bit wonky, if we were paused we need to save the balance_ctl in the fs_info, but clear it otherwise and cleanup. However we rely on the return values being specific errors, or having a cancel request or no pause request.  If balance completes and returns 0, but we have a pause or cancel request we won't do the appropriate cleanup, and then the next time we try to start a balance we'll trip this ASSERT.  The error handling is just wrong here, we always want to clean up, unless we got -ECANCELLED and we set the appropriate pause flag in the exclusive op.  With this patch the reproducer ran for an hour without tripping, previously it would trip in less than a few minutes.
CVE-2023-54024: In the Linux kernel, the following vulnerability has been resolved:  KVM: Destroy target device if coalesced MMIO unregistration fails  Destroy and free the target coalesced MMIO device if unregistering said device fails.  As clearly noted in the code, kvm_io_bus_unregister_dev() does not destroy the target device.    BUG: memory leak   unreferenced object 0xffff888112a54880 (size 64):     comm "syz-executor.2", pid 5258, jiffies 4297861402 (age 14.129s)     hex dump (first 32 bytes):       38 c7 67 15 00 c9 ff ff 38 c7 67 15 00 c9 ff ff  8.g.....8.g.....       e0 c7 e1 83 ff ff ff ff 00 30 67 15 00 c9 ff ff  .........0g.....     backtrace:       [<0000000006995a8a>] kmalloc include/linux/slab.h:556 [inline]       [<0000000006995a8a>] kzalloc include/linux/slab.h:690 [inline]       [<0000000006995a8a>] kvm_vm_ioctl_register_coalesced_mmio+0x8e/0x3d0 arch/x86/kvm/../../../virt/kvm/coalesced_mmio.c:150       [<00000000022550c2>] kvm_vm_ioctl+0x47d/0x1600 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3323       [<000000008a75102f>] vfs_ioctl fs/ioctl.c:46 [inline]       [<000000008a75102f>] file_ioctl fs/ioctl.c:509 [inline]       [<000000008a75102f>] do_vfs_ioctl+0xbab/0x1160 fs/ioctl.c:696       [<0000000080e3f669>] ksys_ioctl+0x76/0xa0 fs/ioctl.c:713       [<0000000059ef4888>] __do_sys_ioctl fs/ioctl.c:720 [inline]       [<0000000059ef4888>] __se_sys_ioctl fs/ioctl.c:718 [inline]       [<0000000059ef4888>] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718       [<000000006444fa05>] do_syscall_64+0x9f/0x4e0 arch/x86/entry/common.c:290       [<000000009a4ed50b>] entry_SYSCALL_64_after_hwframe+0x49/0xbe    BUG: leak checking failed
CVE-2023-54025: In the Linux kernel, the following vulnerability has been resolved:  wifi: rsi: Do not configure WoWlan in shutdown hook if not enabled  In case WoWlan was never configured during the operation of the system, the hw->wiphy->wowlan_config will be NULL. rsi_config_wowlan() checks whether wowlan_config is non-NULL and if it is not, then WARNs about it. The warning is valid, as during normal operation the rsi_config_wowlan() should only ever be called with non-NULL wowlan_config. In shutdown this rsi_config_wowlan() should only ever be called if WoWlan was configured before by the user.  Add checks for non-NULL wowlan_config into the shutdown hook. While at it, check whether the wiphy is also non-NULL before accessing wowlan_config . Drop the single-use wowlan_config variable, just inline it into function call.
CVE-2023-54026: In the Linux kernel, the following vulnerability has been resolved:  opp: Fix use-after-free in lazy_opp_tables after probe deferral  When dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns -EPROBE_DEFER, the opp_table is freed again, to wait until all the interconnect paths are available.  However, if the OPP table is using required-opps then it may already have been added to the global lazy_opp_tables list. The error path does not remove the opp_table from the list again.  This can cause crashes later when the provider of the required-opps is added, since we will iterate over OPP tables that have already been freed. E.g.:    Unable to handle kernel NULL pointer dereference when read   CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3   PC is at _of_add_opp_table_v2 (include/linux/of.h:949   drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404   drivers/opp/of.c:1032) -> lazy_link_required_opp_table()  Fix this by calling _of_clear_opp_table() to remove the opp_table from the list and clear other allocated resources. While at it, also add the missing mutex_destroy() calls in the error path.
CVE-2023-54027: In the Linux kernel, the following vulnerability has been resolved:  iio: core: Prevent invalid memory access when there is no parent  Commit 813665564b3d ("iio: core: Convert to use firmware node handle instead of OF node") switched the kind of nodes to use for label retrieval in device registration.  Probably an unwanted change in that commit was that if the device has no parent then NULL pointer is accessed.  This is what happens in the stock IIO dummy driver when a new entry is created in configfs:    # mkdir /sys/kernel/config/iio/devices/dummy/foo   BUG: kernel NULL pointer dereference, address: ...   ...   Call Trace:   __iio_device_register   iio_dummy_probe  Since there seems to be no reason to make a parent device of an IIO dummy device mandatory, let’s prevent the invalid memory access in __iio_device_register when the parent device is NULL.  With this change, the IIO dummy driver works fine with configfs.
CVE-2023-54030: In the Linux kernel, the following vulnerability has been resolved:  io_uring/net: don't overflow multishot recv  Don't allow overflowing multishot recv CQEs, it might get out of hand, hurt performance, and in the worst case scenario OOM the task.
CVE-2023-54031: In the Linux kernel, the following vulnerability has been resolved:  vdpa: Add queue index attr to vdpa_nl_policy for nlattr length check  The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops.  That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.  This patch adds the missing nla_policy for vdpa queue index attr to avoid such bugs.
CVE-2023-54033: In the Linux kernel, the following vulnerability has been resolved:  bpf: fix a memory leak in the LRU and LRU_PERCPU hash maps  The LRU and LRU_PERCPU maps allocate a new element on update before locking the target hash table bucket. Right after that the maps try to lock the bucket. If this fails, then maps return -EBUSY to the caller without releasing the allocated element. This makes the element untracked: it doesn't belong to either of free lists, and it doesn't belong to the hash table, so can't be re-used; this eventually leads to the permanent -ENOMEM on LRU map updates, which is unexpected. Fix this by returning the element to the local free list if bucket locking fails.
CVE-2023-54034: In the Linux kernel, the following vulnerability has been resolved:  iommufd: Make sure to zero vfio_iommu_type1_info before copying to user  Missed a zero initialization here. Most of the struct is filled with a copy_from_user(), however minsz for that copy is smaller than the actual struct by 8 bytes, thus we don't fill the padding.
CVE-2023-54036: In the Linux kernel, the following vulnerability has been resolved:  wifi: rtl8xxxu: Fix memory leaks with RTL8723BU, RTL8192EU  The wifi + bluetooth combo chip RTL8723BU can leak memory (especially?) when it's connected to a bluetooth audio device. The busy bluetooth traffic generates lots of C2H (card to host) messages, which are not freed correctly.  To fix this, move the dev_kfree_skb() call in rtl8xxxu_c2hcmd_callback() inside the loop where skb_dequeue() is called.  The RTL8192EU leaks memory because the C2H messages are added to the queue and left there forever. (This was fine in the past because it probably wasn't sending any C2H messages until commit e542e66b7c2e ("wifi: rtl8xxxu: gen2: Turn on the rate control"). Since that commit it sends a C2H message when the TX rate changes.)  To fix this, delete the check for rf_paths > 1 and the goto. Let the function process the C2H messages from RTL8192EU like the ones from the other chips.  Theoretically the RTL8188FU could also leak like RTL8723BU, but it most likely doesn't send C2H messages frequently enough.  This change was tested with RTL8723BU by Erhard F. I tested it with RTL8188FU and RTL8192EU.
CVE-2023-54038: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no link  hci_connect_sco currently returns NULL when there is no link (i.e. when hci_conn_link() returns NULL).  sco_connect() expects an ERR_PTR in case of any error (see line 266 in sco.c). Thus, hcon set as NULL passes through to sco_conn_add(), which tries to get hcon->hdev, resulting in dereferencing a NULL pointer as reported by syzkaller.  The same issue exists for iso_connect_cis() calling hci_connect_cis().  Thus, make hci_connect_sco() and hci_connect_cis() return ERR_PTR instead of NULL.
CVE-2023-54039: In the Linux kernel, the following vulnerability has been resolved:  can: j1939: j1939_tp_tx_dat_new(): fix out-of-bounds memory access  In the j1939_tp_tx_dat_new() function, an out-of-bounds memory access could occur during the memcpy() operation if the size of skb->cb is larger than the size of struct j1939_sk_buff_cb. This is because the memcpy() operation uses the size of skb->cb, leading to a read beyond the struct j1939_sk_buff_cb.  Updated the memcpy() operation to use the size of struct j1939_sk_buff_cb instead of the size of skb->cb. This ensures that the memcpy() operation only reads the memory within the bounds of struct j1939_sk_buff_cb, preventing out-of-bounds memory access.  Additionally, add a BUILD_BUG_ON() to check that the size of skb->cb is greater than or equal to the size of struct j1939_sk_buff_cb. This ensures that the skb->cb buffer is large enough to hold the j1939_sk_buff_cb structure.  [mkl: rephrase commit message]
CVE-2023-54041: In the Linux kernel, the following vulnerability has been resolved:  io_uring: fix memory leak when removing provided buffers  When removing provided buffers, io_buffer structs are not being disposed of, leading to a memory leak. They can't be freed individually, because they are allocated in page-sized groups. They need to be added to some free list instead, such as io_buffers_cache. All callers already hold the lock protecting it, apart from when destroying buffers, so had to extend the lock there.
CVE-2023-54042: In the Linux kernel, the following vulnerability has been resolved:  powerpc/64s: Fix VAS mm use after free  The refcount on mm is dropped before the coprocessor is detached.
CVE-2025-68344: In the Linux kernel, the following vulnerability has been resolved:  ALSA: wavefront: Fix integer overflow in sample size validation  The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem  Fix by using unsigned comparison to avoid integer overflow.
CVE-2025-68345: In the Linux kernel, the following vulnerability has been resolved:  ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi()  The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-68346: In the Linux kernel, the following vulnerability has been resolved:  ALSA: dice: fix buffer overflow in detect_stream_formats()  The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS.  Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().
CVE-2025-68347: In the Linux kernel, the following vulnerability has been resolved:  ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events  The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes).  Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.
CVE-2025-68348: In the Linux kernel, the following vulnerability has been resolved:  block: fix memory leak in __blkdev_issue_zero_pages  Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending.  Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak.  This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.
CVE-2025-68349: In the Linux kernel, the following vulnerability has been resolved:  NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid  Fixes a crash when layout is null during this call stack:  write_inode     -> nfs4_write_inode         -> pnfs_layoutcommit_inode  pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.
CVE-2025-68350: In the Linux kernel, the following vulnerability has been resolved:  exfat: fix divide-by-zero in exfat_allocate_bitmap  The variable max_ra_count can be 0 in exfat_allocate_bitmap(), which causes a divide-by-zero error in the subsequent modulo operation (i % max_ra_count), leading to a system crash. When max_ra_count is 0, it means that readahead is not used. This patch load the bitmap without readahead.
CVE-2025-68351: In the Linux kernel, the following vulnerability has been resolved:  exfat: fix refcount leak in exfat_find  Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.  Function `exfat_get_dentry_set` would increase the reference counter of `es->bh` on success. Therefore, `exfat_put_dentry_set` must be called after `exfat_get_dentry_set` to ensure refcount consistency. This patch relocate two checks to avoid possible leaks.
CVE-2025-68352: In the Linux kernel, the following vulnerability has been resolved:  spi: ch341: fix out-of-bounds memory access in ch341_transfer_one  Discovered by Atuin - Automated Vulnerability Discovery Engine.  The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header.  When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because:  1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size    'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is    CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1    overflows the buffer.  Fix this by copying 'len - 1' bytes.