xamxte/cve-to-cwe huggingface dataset:
CVE-2023-54069: In the Linux kernel, the following vulnerability has been resolved:  ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow  When we calculate the end position of ext4_free_extent, this position may be exactly where ext4_lblk_t (i.e. uint) overflows. For example, if ac_g_ex.fe_logical is 4294965248 and ac_orig_goal_len is 2048, then the computed end is 0x100000000, which is 0. If ac->ac_o_ex.fe_logical is not the first case of adjusting the best extent, that is, new_bex_end > 0, the following BUG_ON will be triggered:  ========================================================= kernel BUG at fs/ext4/mballoc.c:5116! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279 RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430 Call Trace:  <TASK>  ext4_mb_use_best_found+0x203/0x2f0  ext4_mb_try_best_found+0x163/0x240  ext4_mb_regular_allocator+0x158/0x1550  ext4_mb_new_blocks+0x86a/0xe10  ext4_ext_map_blocks+0xb0c/0x13a0  ext4_map_blocks+0x2cd/0x8f0  ext4_iomap_begin+0x27b/0x400  iomap_iter+0x222/0x3d0  __iomap_dio_rw+0x243/0xcb0  iomap_dio_rw+0x16/0x80 =========================================================  A simple reproducer demonstrating the problem:   mkfs.ext4 -F /dev/sda -b 4096 100M  mount /dev/sda /tmp/test  fallocate -l1M /tmp/test/tmp  fallocate -l10M /tmp/test/file  fallocate -i -o 1M -l16777203M /tmp/test/file  fsstress -d /tmp/test -l 0 -n 100000 -p 8 &  sleep 10 && killall -9 fsstress  rm -f /tmp/test/tmp  xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192"  We simply refactor the logic for adjusting the best extent by adding a temporary ext4_free_extent ex and use extent_logical_end() to avoid overflow, which also simplifies the code.
CVE-2023-54072: In the Linux kernel, the following vulnerability has been resolved:  ALSA: pcm: Fix potential data race at PCM memory allocation helpers  The PCM memory allocation helpers have a sanity check against too many buffer allocations.  However, the check is performed without a proper lock and the allocation isn't serialized; this allows user to allocate more memories than predefined max size.  Practically seen, this isn't really a big problem, as it's more or less some "soft limit" as a sanity check, and it's not possible to allocate unlimitedly.  But it's still better to address this for more consistent behavior.  The patch covers the size check in do_alloc_pages() with the card->memory_mutex, and increases the allocated size there for preventing the further overflow.  When the actual allocation fails, the size is decreased accordingly.
CVE-2023-54075: In the Linux kernel, the following vulnerability has been resolved:  ASoC: mediatek: common: Fix refcount leak in parse_dai_link_info  Add missing of_node_put()s before the returns to balance of_node_get()s and of_node_put()s, which may get unbalanced in case the for loop 'for_each_available_child_of_node' returns early.
CVE-2023-54076: In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix missed ses refcounting  Use new cifs_smb_ses_inc_refcount() helper to get an active reference of @ses and @ses->dfs_root_ses (if set).  This will prevent @ses->dfs_root_ses of being put in the next call to cifs_put_smb_ses() and thus potentially causing an use-after-free bug.
CVE-2023-54077: In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Fix memory leak if ntfs_read_mft failed  Label ATTR_ROOT in ntfs_read_mft() sets is_root = true and ni->ni_flags |= NI_FLAG_DIR, then next attr will goto label ATTR_ALLOC and alloc ni->dir.alloc_run. However two states are not always consistent and can make memory leak.   1) attr_name in ATTR_ROOT does not fit the condition it will set  is_root = true but NI_FLAG_DIR is not set.  2) next attr_name in ATTR_ALLOC fits the condition and alloc  ni->dir.alloc_run  3) in cleanup function ni_clear(), when NI_FLAG_DIR is set, it frees  ni->dir.alloc_run, otherwise it frees ni->file.run  4) because NI_FLAG_DIR is not set in this case, ni->dir.alloc_run is  leaked as kmemleak reported:  unreferenced object 0xffff888003bc5480 (size 64):   backtrace:     [<000000003d42e6b0>] __kmalloc_node+0x4e/0x1c0     [<00000000d8e19b8a>] kvmalloc_node+0x39/0x1f0     [<00000000fc3eb5b8>] run_add_entry+0x18a/0xa40 [ntfs3]     [<0000000011c9f978>] run_unpack+0x75d/0x8e0 [ntfs3]     [<00000000e7cf1819>] run_unpack_ex+0xbc/0x500 [ntfs3]     [<00000000bbf0a43d>] ntfs_iget5+0xb25/0x2dd0 [ntfs3]     [<00000000a6e50693>] ntfs_fill_super+0x218d/0x3580 [ntfs3]     [<00000000b9170608>] get_tree_bdev+0x3fb/0x710     [<000000004833798a>] vfs_get_tree+0x8e/0x280     [<000000006e20b8e6>] path_mount+0xf3c/0x1930     [<000000007bf15a5f>] do_mount+0xf3/0x110     ...  Fix this by always setting is_root and NI_FLAG_DIR together.
CVE-2023-54078: In the Linux kernel, the following vulnerability has been resolved:  media: max9286: Free control handler  The control handler is leaked in some probe-time error paths, as well as in the remove path. Fix it.
CVE-2023-54079: In the Linux kernel, the following vulnerability has been resolved:  power: supply: bq27xxx: Fix poll_interval handling and races on remove  Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item.  There are 2 problems with this:  1. If the driver is unbound through sysfs, rather then the module being    rmmod-ed, this changes poll_interval unexpectedly  2. This is racy, after it being set poll_interval could be changed    before bq27xxx_battery_update() checks it through    /sys/module/bq27xxx_battery/parameters/poll_interval  Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0.  There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item.  Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item.
CVE-2023-54083: In the Linux kernel, the following vulnerability has been resolved:  phy: tegra: xusb: Clear the driver reference in usb-phy dev  For the dual-role port, it will assign the phy dev to usb-phy dev and use the port dev driver as the dev driver of usb-phy.  When we try to destroy the port dev, it will destroy its dev driver as well. But we did not remove the reference from usb-phy dev. This might cause the use-after-free issue in KASAN.
CVE-2023-54084: In the Linux kernel, the following vulnerability has been resolved:  ALSA: firewire-digi00x: prevent potential use after free  This code was supposed to return an error code if init_stream() failed, but it instead freed dg00x->rx_stream and returned success. This potentially leads to a use after free.
CVE-2023-54085: In the Linux kernel, the following vulnerability has been resolved:  mptcp: fix NULL pointer dereference on fastopen early fallback  In case of early fallback to TCP, subflow_syn_recv_sock() deletes the subflow context before returning the newly allocated sock to the caller.  The fastopen path does not cope with the above unconditionally dereferencing the subflow context.
CVE-2023-54087: In the Linux kernel, the following vulnerability has been resolved:  ubi: Fix possible null-ptr-deref in ubi_free_volume()  It willl cause null-ptr-deref in the following case:  uif_init()   ubi_add_volume()     cdev_add() -> if it fails, call kill_volumes()     device_register()  kill_volumes() -> if ubi_add_volume() fails call this function   ubi_free_volume()     cdev_del()     device_unregister() -> trying to delete a not added device,       it causes null-ptr-deref  So in ubi_free_volume(), it delete devices whether they are added or not, it will causes null-ptr-deref.  Handle the error case whlie calling ubi_add_volume() to fix this problem. If add volume fails, set the corresponding vol to null, so it can not be accessed in kill_volumes() and release the resource in ubi_add_volume() error path.
CVE-2023-54091: In the Linux kernel, the following vulnerability has been resolved:  drm/client: Fix memory leak in drm_client_target_cloned  dmt_mode is allocated and never freed in this function. It was found with the ast driver, but most drivers using generic fbdev setup are probably affected.  This fixes the following kmemleak report:   backtrace:     [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm]     [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]     [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm]     [<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]     [<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]     [<00000000063a69aa>] drm_client_register+0x169/0x240 [drm]     [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast]     [<00000000987f19bb>] local_pci_probe+0xdc/0x180     [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0     [<0000000000b85301>] process_one_work+0x8b7/0x1540     [<000000003375b17c>] worker_thread+0x70a/0xed0     [<00000000b0d43cd9>] kthread+0x29f/0x340     [<000000008d770833>] ret_from_fork+0x1f/0x30 unreferenced object 0xff11000333089a00 (size 128):
CVE-2023-54093: In the Linux kernel, the following vulnerability has been resolved:  media: anysee: fix null-ptr-deref in anysee_master_xfer  In anysee_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 anysee_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()")  [hverkuil: add spaces around +]
CVE-2023-54097: In the Linux kernel, the following vulnerability has been resolved:  regulator: stm32-pwr: fix of_iomap leak  Smatch reports: drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn: 'base' from of_iomap() not released on lines: 151,166.  In stm32_pwr_regulator_probe(), base is not released when devm_kzalloc() fails to allocate memory or devm_regulator_register() fails to register a new regulator device, which may cause a leak.  To fix this issue, replace of_iomap() with devm_platform_ioremap_resource(). devm_platform_ioremap_resource() is a specialized function for platform devices. It allows 'base' to be automatically released whether the probe function succeeds or fails.  Besides, use IS_ERR(base) instead of !base as the return value of devm_platform_ioremap_resource() can either be a pointer to the remapped memory or an ERR_PTR() encoded error code if the operation fails.
CVE-2023-54098: In the Linux kernel, the following vulnerability has been resolved:  drm/i915/gvt: fix gvt debugfs destroy  When gvt debug fs is destroyed, need to have a sane check if drm minor's debugfs root is still available or not, otherwise in case like device remove through unbinding, drm minor's debugfs directory has already been removed, then intel_gvt_debugfs_clean() would act upon dangling pointer like below oops.  i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x1926_rid_0x0a.golden_hw_state failed with error -2 i915 0000:00:02.0: MDEV: Registered Console: switching to colour dummy device 80x25 i915 0000:00:02.0: MDEV: Unregistering BUG: kernel NULL pointer dereference, address: 00000000000000a0 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 2486 Comm: gfx-unbind.sh Tainted: G          I        6.1.0-rc8+ #15 Hardware name: Dell Inc. XPS 13 9350/0JXC1H, BIOS 1.13.0 02/10/2020 RIP: 0010:down_write+0x1f/0x90 Code: 1d ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89 fb e8 62 c0 ff ff bf 01 00 00 00 e8 28 5e 31 ff 31 c0 ba 01 00 00 00 <f0> 48 0f b1 13 75 33 65 48 8b 04 25 c0 bd 01 00 48 89 43 08 bf 01 RSP: 0018:ffff9eb3036ffcc8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000000a0 RCX: ffffff8100000000 RDX: 0000000000000001 RSI: 0000000000000064 RDI: ffffffffa48787a8 RBP: ffff9eb3036ffd30 R08: ffffeb1fc45a0608 R09: ffffeb1fc45a05c0 R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 R13: ffff91acc33fa328 R14: ffff91acc033f080 R15: ffff91acced533e0 FS:  00007f6947bba740(0000) GS:ffff91ae36d00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000a0 CR3: 00000001133a2002 CR4: 00000000003706e0 Call Trace:  <TASK>  simple_recursive_removal+0x9f/0x2a0  ? start_creating.part.0+0x120/0x120  ? _raw_spin_lock+0x13/0x40  debugfs_remove+0x40/0x60  intel_gvt_debugfs_clean+0x15/0x30 [kvmgt]  intel_gvt_clean_device+0x49/0xe0 [kvmgt]  intel_gvt_driver_remove+0x2f/0xb0  i915_driver_remove+0xa4/0xf0  i915_pci_remove+0x1a/0x30  pci_device_remove+0x33/0xa0  device_release_driver_internal+0x1b2/0x230  unbind_store+0xe0/0x110  kernfs_fop_write_iter+0x11b/0x1f0  vfs_write+0x203/0x3d0  ksys_write+0x63/0xe0  do_syscall_64+0x37/0x90  entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f6947cb5190 Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89 RSP: 002b:00007ffcbac45a28 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f6947cb5190 RDX: 000000000000000d RSI: 0000555e35c866a0 RDI: 0000000000000001 RBP: 0000555e35c866a0 R08: 0000000000000002 R09: 0000555e358cb97c R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001 R13: 000000000000000d R14: 0000000000000000 R15: 0000555e358cb8e0  </TASK> Modules linked in: kvmgt CR2: 00000000000000a0 ---[ end trace 0000000000000000 ]---
CVE-2023-54099: In the Linux kernel, the following vulnerability has been resolved:  fs: Protect reconfiguration of sb read-write from racing writes  The reconfigure / remount code takes a lot of effort to protect filesystem's reconfiguration code from racing writes on remounting read-only. However during remounting read-only filesystem to read-write mode userspace writes can start immediately once we clear SB_RDONLY flag. This is inconvenient for example for ext4 because we need to do some writes to the filesystem (such as preparation of quota files) before we can take userspace writes so we are clearing SB_RDONLY flag before we are fully ready to accept userpace writes and syzbot has found a way to exploit this [1]. Also as far as I'm reading the code the filesystem remount code was protected from racing writes in the legacy mount path by the mount's MNT_READONLY flag so this is relatively new problem. It is actually fairly easy to protect remount read-write from racing writes using sb->s_readonly_remount flag so let's just do that instead of having to workaround these races in the filesystem code.  [1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/
CVE-2023-54100: In the Linux kernel, the following vulnerability has been resolved:  scsi: qedi: Fix use after free bug in qedi_remove()  In qedi_probe() we call __qedi_probe() which initializes &qedi->recovery_work with qedi_recovery_handler() and &qedi->board_disable_work with qedi_board_disable_work().  When qedi_schedule_recovery_handler() is called, schedule_delayed_work() will finally start the work.  In qedi_remove(), which is called to remove the driver, the following sequence may be observed:  Fix this by finishing the work before cleanup in qedi_remove().  CPU0                  CPU1                       |qedi_recovery_handler qedi_remove          |   __qedi_remove      | iscsi_host_free      | scsi_host_put        | //free shost         |                      |iscsi_host_for_each_session                      |//use qedi->shost  Cancel recovery_work and board_disable_work in __qedi_remove().
CVE-2023-54101: In the Linux kernel, the following vulnerability has been resolved:  driver: soc: xilinx: use _safe loop iterator to avoid a use after free  The hash_for_each_possible() loop dereferences "eve_data" to get the next item on the list.  However the loop frees eve_data so it leads to a use after free.  Use hash_for_each_possible_safe() instead.
CVE-2023-54102: In the Linux kernel, the following vulnerability has been resolved:  scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow  A static code analysis tool flagged the possibility of buffer overflow when using copy_from_user() for a debugfs entry.  Currently, it is possible that copy_from_user() copies more bytes than what would fit in the mybuf char array.  Add a min() restriction check between sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect against buffer overflow.
CVE-2023-54104: In the Linux kernel, the following vulnerability has been resolved:  mtd: rawnand: fsl_upm: Fix an off-by one test in fun_exec_op()  'op-cs' is copied in 'fun->mchip_number' which is used to access the 'mchip_offsets' and the 'rnb_gpio' arrays. These arrays have NAND_MAX_CHIPS elements, so the index must be below this limit.  Fix the sanity check in order to avoid the NAND_MAX_CHIPS value. This would lead to out-of-bound accesses.
CVE-2023-54105: In the Linux kernel, the following vulnerability has been resolved:  can: isotp: check CAN address family in isotp_bind()  Add missing check to block non-AF_CAN binds.  Syzbot created some code which matched the right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:  bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10)                                 ^^^^ This has no funtional impact but the userspace should be notified about the wrong address family field content.
CVE-2023-54106: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: fix potential memory leak in mlx5e_init_rep_rx  The memory pointed to by the priv->rx_res pointer is not freed in the error path of mlx5e_init_rep_rx, which can lead to a memory leak. Fix by freeing the memory in the error path, thereby making the error path identical to mlx5e_cleanup_rep_rx().
CVE-2023-54107: In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: dropping parent refcount after pd_free_fn() is done  Some cgroup policies will access parent pd through child pd even after pd_offline_fn() is done. If pd_free_fn() for parent is called before child, then UAF can be triggered. Hence it's better to guarantee the order of pd_free_fn().  Currently refcount of parent blkg is dropped in __blkg_release(), which is before pd_free_fn() is called in blkg_free_work_fn() while blkg_free_work_fn() is called asynchronously.  This patch make sure pd_free_fn() called from removing cgroup is ordered by delaying dropping parent refcount after calling pd_free_fn() for child.  BTW, pd_free_fn() will also be called from blkcg_deactivate_policy() from deleting device, and following patches will guarantee the order.
CVE-2023-54109: In the Linux kernel, the following vulnerability has been resolved:  media: rcar_fdp1: Fix refcount leak in probe and remove function  rcar_fcp_get() take reference, which should be balanced with rcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove and the error paths of fdp1_probe() to fix this.  [hverkuil: resolve merge conflict, remove() is now void]
CVE-2023-54110: In the Linux kernel, the following vulnerability has been resolved:  usb: rndis_host: Secure rndis_query check against int overflow  Variables off and len typed as uint32 in rndis_query function are controlled by incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently the response pointer will be referring to a location past the expected buffer boundaries allowing information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID.
CVE-2023-54111: In the Linux kernel, the following vulnerability has been resolved:  pinctrl: rockchip: Fix refcount leak in rockchip_pinctrl_parse_groups  of_find_node_by_phandle() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2023-54112: In the Linux kernel, the following vulnerability has been resolved:  kcm: Fix memory leak in error path of kcm_sendmsg()  syzbot reported a memory leak like below:  BUG: memory leak unreferenced object 0xffff88810b088c00 (size 240):   comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s)   hex dump (first 32 bytes):     00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00  ................     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................   backtrace:     [<ffffffff83e5d5ff>] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634     [<ffffffff84606e59>] alloc_skb include/linux/skbuff.h:1289 [inline]     [<ffffffff84606e59>] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815     [<ffffffff83e479c6>] sock_sendmsg_nosec net/socket.c:725 [inline]     [<ffffffff83e479c6>] sock_sendmsg+0x56/0xb0 net/socket.c:748     [<ffffffff83e47f55>] ____sys_sendmsg+0x365/0x470 net/socket.c:2494     [<ffffffff83e4c389>] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548     [<ffffffff83e4c536>] __sys_sendmsg+0xa6/0x120 net/socket.c:2577     [<ffffffff84ad7bb8>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]     [<ffffffff84ad7bb8>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80     [<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd  In kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to append newly allocated skbs to 'head'. If some bytes are copied, an error occurred, and jumped to out_error label, 'last_skb' is left unmodified. A later kcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the 'head' frag_list and causing the leak.  This patch fixes this issue by properly updating the last allocated skb in 'last_skb'.