xamxte/cve-to-cwe huggingface dataset:
CVE-2023-53208: In the Linux kernel, the following vulnerability has been resolved:  KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state  When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired ratio doesn't match the current ratio, not if the ratio L1 is using for L2 diverges from the default.  Functionally, the end result is the same as KVM will run L2 with L1's multiplier if L2's multiplier is the default, i.e. checking that L1's multiplier is loaded is equivalent to checking if L2 has a non-default multiplier.  However, the assertion that TSC scaling is exposed to L1 is flawed, as userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVM_RUN).  E.g. hacking KVM's state_test selftest to do                  vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);                 vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);  after restoring state in a new VM+vCPU yields an endless supply of:    ------------[ cut here ]------------   WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105            nested_svm_vmexit+0x6af/0x720 [kvm_amd]   Call Trace:    nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]    svm_handle_exit+0xb9/0x180 [kvm_amd]    kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]    kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]    ? trace_hardirqs_off+0x4d/0xa0    __se_sys_ioctl+0x7a/0xc0    __x64_sys_ioctl+0x21/0x30    do_syscall_64+0x41/0x90    entry_SYSCALL_64_after_hwframe+0x63/0xcd  Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check into the if-statement is wrong as KVM needs to ensure L1's multiplier is loaded in the above scenario.   Alternatively, the WARN_ON() could simply be deleted, but that would make KVM's behavior even more subtle, e.g. it's not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when checking only tsc_ratio_msr.
CVE-2023-53217: In the Linux kernel, the following vulnerability has been resolved:  nubus: Partially revert proc_create_single_data() conversion  The conversion to proc_create_single_data() introduced a regression whereby reading a file in /proc/bus/nubus results in a seg fault:      # grep -r . /proc/bus/nubus/e/     Data read fault at 0x00000020 in Super Data (pc=0x1074c2)     BAD KERNEL BUSERR     Oops: 00000000     Modules linked in:     PC: [<001074c2>] PDE_DATA+0xc/0x16     SR: 2010  SP: 38284958  a2: 01152370     d0: 00000001    d1: 01013000    d2: 01002790    d3: 00000000     d4: 00000001    d5: 0008ce2e    a0: 00000000    a1: 00222a40     Process grep (pid: 45, task=142f8727)     Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70     baddr=001074c8 dibuf=ffffffff ver=f     Stack from 01199e48:      01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000      00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000      d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000      00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640      011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c      000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0     Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0      [<000d551a>] seq_read+0xc4/0x510      [<00018000>] fp_fcos+0x2/0x82      [<0002800d>] __sys_setreuid+0x115/0x1c6      [<00103640>] proc_reg_read+0x5c/0xb0      [<00018000>] fp_fcos+0x2/0x82      [<000b3344>] __vfs_read+0x2c/0x13c      [<00018000>] fp_fcos+0x2/0x82      [<00018000>] fp_fcos+0x2/0x82      [<000b8aa2>] sys_statx+0x60/0x7e      [<000b34b6>] vfs_read+0x62/0x12a      [<00018000>] fp_fcos+0x2/0x82      [<00018000>] fp_fcos+0x2/0x82      [<000b39c2>] ksys_read+0x48/0xbe      [<00018000>] fp_fcos+0x2/0x82      [<000b3a4e>] sys_read+0x16/0x1a      [<00018000>] fp_fcos+0x2/0x82      [<00002b84>] syscall+0x8/0xc      [<00018000>] fp_fcos+0x2/0x82      [<0000c016>] not_ext+0xa/0x18     Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8     Disabling lock debugging due to kernel taint      Segmentation fault  The proc_create_single_data() conversion does not work because single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is not equivalent to the original code.
CVE-2023-53232: In the Linux kernel, the following vulnerability has been resolved:  mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data  The MT7921 driver no longer uses eeprom.data, but the relevant code has not been removed completely since commit 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability"). This could result in potential invalid memory access.  To fix the kernel panic issue in mt7921, it is necessary to avoid accessing unallocated eeprom.data which can lead to invalid memory access.  Furthermore, it is possible to entirely eliminate the mt7921_mcu_parse_eeprom function and solely depend on mt7921_mcu_parse_response to divide the RxD header.  [2.702735] BUG: kernel NULL pointer dereference, address: 0000000000000550 [2.702740] #PF: supervisor write access in kernel mode [2.702741] #PF: error_code(0x0002) - not-present page [2.702743] PGD 0 P4D 0 [2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI [2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common] [2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286 [2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: 0000000000000000 [2.702762] RDX: 0000000000000550 RSI: 0000000000000000 RDI: ffffa367cc7bf500 [2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: 0000000000000005 [2.702764] R10: 0000000000000000 R11: ffffffffc04702e4 R12: ffffa367e8329f40 [2.702766] R13: 0000000000000000 R14: 0000000000000001 R15: ffffa367e8329f40 [2.702768] FS:  000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:0000000000000000 [2.702769] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.702775] CR2: 0000000000000550 CR3: 00000001233c6004 CR4: 0000000000770ee0 [2.702776] PKRU: 55555554 [2.702777] Call Trace: [2.702782]  mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76 <HASH:1bc4 5>] [2.702785]  mt7921_run_firmware+0x241/0x853 [mt7921_common <HASH:6a2f 6>] [2.702789]  mt7921e_mcu_init+0x2b/0x56 [mt7921e <HASH:d290 7>] [2.702792]  mt7921_register_device+0x2eb/0x5a5 [mt7921_common <HASH:6a2f 6>] [2.702795]  ? mt7921_irq_tasklet+0x1d4/0x1d4 [mt7921e <HASH:d290 7>] [2.702797]  mt7921_pci_probe+0x2d6/0x319 [mt7921e <HASH:d290 7>] [2.702799]  pci_device_probe+0x9f/0x12a
CVE-2023-53242: In the Linux kernel, the following vulnerability has been resolved:  thermal/drivers/hisi: Drop second sensor hi3660  The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm allocators") exposes a panic "BRK handler: Fatal exception" on the hi3660_thermal_probe funciton. This is because the function allocates memory for only one sensors array entry, but tries to fill up a second one.  Fix this by removing the unneeded second access.
CVE-2023-53257: In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: check S1G action frame size  Before checking the action code, check that it even exists in the frame.
CVE-2023-53268: In the Linux kernel, the following vulnerability has been resolved:  ASoC: fsl_mqs: move of_node_put() to the correct location  of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path.  To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns.
CVE-2023-53285: In the Linux kernel, the following vulnerability has been resolved:  ext4: add bounds checking in get_max_inline_xattr_value_size()  Normally the extended attributes in the inode body would have been checked when the inode is first opened, but if someone is writing to the block device while the file system is mounted, it's possible for the inode table to get corrupted.  Add bounds checking to avoid reading beyond the end of allocated memory if this happens.
CVE-2023-53291: In the Linux kernel, the following vulnerability has been resolved:  rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale  Running the 'kfree_rcu_test' test case [1] results in a splat [2]. The root cause is the kfree_scale_thread thread(s) continue running after unloading the rcuscale module.  This commit fixes that isue by invoking kfree_scale_cleanup() from rcu_scale_cleanup() when removing the rcuscale module.  [1] modprobe rcuscale kfree_rcu_test=1     // After some time     rmmod rcuscale     rmmod torture  [2] BUG: unable to handle page fault for address: ffffffffc0601a87     #PF: supervisor instruction fetch in kernel mode     #PF: error_code(0x0010) - not-present page     PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0     Oops: 0010 [#1] PREEMPT SMP NOPTI     CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015     RIP: 0010:0xffffffffc0601a87     Code: Unable to access opcode bytes at 0xffffffffc0601a5d.     RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297     RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000     RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de     RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000     R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000     R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe     FS:  0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033     CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400     Call Trace:      <TASK>      ? kvfree_call_rcu+0xf0/0x3a0      ? kthread+0xf3/0x120      ? kthread_complete_and_exit+0x20/0x20      ? ret_from_fork+0x1f/0x30      </TASK>     Modules linked in: rfkill sunrpc ... [last unloaded: torture]     CR2: ffffffffc0601a87     ---[ end trace 0000000000000000 ]---
CVE-2023-53301: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix kernel crash due to null io->bio  We should return when io->bio is null before doing anything. Otherwise, panic.  BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:__submit_merged_write_cond+0x164/0x240 [f2fs] Call Trace:  <TASK>  f2fs_submit_merged_write+0x1d/0x30 [f2fs]  commit_checkpoint+0x110/0x1e0 [f2fs]  f2fs_write_checkpoint+0x9f7/0xf00 [f2fs]  ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs]  __checkpoint_and_complete_reqs+0x84/0x190 [f2fs]  ? preempt_count_add+0x82/0xc0  ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs]  issue_checkpoint_thread+0x4c/0xf0 [f2fs]  ? __pfx_autoremove_wake_function+0x10/0x10  kthread+0xff/0x130  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2c/0x50  </TASK>
CVE-2025-39808: In the Linux kernel, the following vulnerability has been resolved:  HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()  in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58)  add null check logic to ntrig_report_version() before calling hid_to_usb_dev()
CVE-2025-39815: In the Linux kernel, the following vulnerability has been resolved:  RISC-V: KVM: fix stack overrun when loading vlenb  The userspace load can put up to 2048 bits into an xlen bit stack buffer.  We want only xlen bits, so check the size beforehand.
CVE-2025-39827: In the Linux kernel, the following vulnerability has been resolved:  net: rose: include node references in rose_neigh refcount  Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct rose_neigh tracks references from rose_node structures, while the 'use' field (now refcount_t) tracks references from rose_sock.  This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of rose_neigh->use when rose_neigh->count is incremented or decremented.  This patch also modifies rose_rt_free(), rose_rt_device_down() and rose_clear_route() to properly release references to rose_neigh objects before freeing a rose_node through rose_remove_node().  These changes ensure rose_neigh structures are properly freed only when all references, including those from rose_node structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.
CVE-2025-39835: In the Linux kernel, the following vulnerability has been resolved:  xfs: do not propagate ENODATA disk errors into xattr code  ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found.  However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as "attribute not found" when in fact it's an IO (disk) error.  At worst, we may oops in xfs_attr_leaf_get() when we do:   error = xfs_attr_leaf_hasname(args, &bp);  if (error == -ENOATTR)  {   xfs_trans_brelse(args->trans, bp);   return error;  }  because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it.  As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO.  However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later.  (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.)
CVE-2022-50341: In the Linux kernel, the following vulnerability has been resolved:  cifs: fix oops during encryption  When running xfstests against Azure the following oops occurred on an arm64 system    Unable to handle kernel write to read-only memory at virtual address   ffff0001221cf000   Mem abort info:     ESR = 0x9600004f     EC = 0x25: DABT (current EL), IL = 32 bits     SET = 0, FnV = 0     EA = 0, S1PTW = 0     FSC = 0x0f: level 3 permission fault   Data abort info:     ISV = 0, ISS = 0x0000004f     CM = 0, WnR = 1   swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000   [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,   pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787   Internal error: Oops: 9600004f [#1] PREEMPT SMP   ...   pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)   pc : __memcpy+0x40/0x230   lr : scatterwalk_copychunks+0xe0/0x200   sp : ffff800014e92de0   x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008   x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008   x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000   x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014   x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058   x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590   x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580   x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005   x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001   x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000   Call trace:    __memcpy+0x40/0x230    scatterwalk_map_and_copy+0x98/0x100    crypto_ccm_encrypt+0x150/0x180    crypto_aead_encrypt+0x2c/0x40    crypt_message+0x750/0x880    smb3_init_transform_rq+0x298/0x340    smb_send_rqst.part.11+0xd8/0x180    smb_send_rqst+0x3c/0x100    compound_send_recv+0x534/0xbc0    smb2_query_info_compound+0x32c/0x440    smb2_set_ea+0x438/0x4c0    cifs_xattr_set+0x5d4/0x7c0  This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary.  To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done.  Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov...  Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses.
CVE-2023-53321: In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211_hwsim: drop short frames  While technically some control frames like ACK are shorter and end after Address 1, such frames shouldn't be forwarded through wmediumd or similar userspace, so require the full 3-address header to avoid accessing invalid memory if shorter frames are passed in.
CVE-2023-53324: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/mdp5: Don't leak some plane state  Apparently no one noticed that mdp5 plane states leak like a sieve ever since we introduced plane_state->commit refcount a few years ago in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.")  Fix it by using the right helpers.  Patchwork: https://patchwork.freedesktop.org/patch/551236/
CVE-2023-53327: In the Linux kernel, the following vulnerability has been resolved:  iommufd/selftest: Catch overflow of uptr and length  syzkaller hits a WARN_ON when trying to have a uptr close to UINTPTR_MAX:    WARNING: CPU: 1 PID: 393 at drivers/iommu/iommufd/selftest.c:403 iommufd_test+0xb19/0x16f0   Modules linked in:   CPU: 1 PID: 393 Comm: repro Not tainted 6.2.0-c9c3395d5e3d #1   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014   RIP: 0010:iommufd_test+0xb19/0x16f0   Code: 94 c4 31 ff 44 89 e6 e8 a5 54 17 ff 45 84 e4 0f 85 bb 0b 00 00 41 be fb ff ff ff e8 31 53 17 ff e9 a0 f7 ff ff e8 27 53 17 ff <0f> 0b 41 be 8   RSP: 0018:ffffc90000eabdc0 EFLAGS: 00010246   RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8214c487   RDX: 0000000000000000 RSI: ffff88800f5c8000 RDI: 0000000000000002   RBP: ffffc90000eabe48 R08: 0000000000000000 R09: 0000000000000001   R10: 0000000000000001 R11: 0000000000000000 R12: 00000000cd2b0000   R13: 00000000cd2af000 R14: 0000000000000000 R15: ffffc90000eabe68   FS:  00007f94d76d5740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000020000043 CR3: 0000000006880006 CR4: 0000000000770ee0   PKRU: 55555554   Call Trace:    <TASK>    ? write_comp_data+0x2f/0x90    iommufd_fops_ioctl+0x1ef/0x310    __x64_sys_ioctl+0x10e/0x160    ? __pfx_iommufd_fops_ioctl+0x10/0x10    do_syscall_64+0x3b/0x90    entry_SYSCALL_64_after_hwframe+0x72/0xdc  Check that the user memory range doesn't overflow.
CVE-2022-50362: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: hisilicon: Add multi-thread support for a DMA channel  When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system.  % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual   address dead000000000108 [383493.335103] Mem abort info: [383493.335103]   ESR = 0x96000044 [383493.335105]   EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107]   SET = 0, FnV = 0 [383493.335108]   EA = 0, S1PTW = 0 [383493.335109]   FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111]   ISV = 0, ISS = 0x00000044 [383493.364739]   CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel   address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump:   loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT   -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0  This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports.  With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing.