xamxte/cve-to-cwe huggingface dataset:
CVE-2023-53781: In the Linux kernel, the following vulnerability has been resolved:  smc: Fix use-after-free in tcp_write_timer_handler().  With Eric's ref tracker, syzbot finally found a repro for use-after-free in tcp_write_timer_handler() by kernel TCP sockets. [0]  If SMC creates a kernel socket in __smc_create(), the kernel socket is supposed to be freed in smc_clcsock_release() by calling sock_release() when we close() the parent SMC socket.  However, at the end of smc_clcsock_release(), the kernel socket's sk_state might not be TCP_CLOSE.  This means that we have not called inet_csk_destroy_sock() in __tcp_close() and have not stopped the TCP timers.  The kernel socket's TCP timers can be fired later, so we need to hold a refcnt for net as we do for MPTCP subflows in mptcp_subflow_create_socket().  [0]: leaked reference.  sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108)  inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244)  __sock_create (net/socket.c:1546)  smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284)  __sock_create (net/socket.c:1546)  __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661)  __x64_sys_socket (net/socket.c:1672)  do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) ================================================================== BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091  CPU: 0 PID: 18091 Comm: syzrepro Tainted: G        W          6.3.0-rc4-01174-gb5d54eb5899a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014 Call Trace:  <IRQ>  dump_stack_lvl (lib/dump_stack.c:107)  print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)  kasan_report (mm/kasan/report.c:538)  tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)  tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643)  call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)  __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022)  run_timer_softirq (kernel/time/timer.c:2037)  __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572)  __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650)  irq_exit_rcu (kernel/softirq.c:664)  sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))  </IRQ>
CVE-2023-53782: In the Linux kernel, the following vulnerability has been resolved:  dccp: Fix out of bounds access in DCCP error handler  There was a previous attempt to fix an out-of-bounds access in the DCCP error handlers, but that fix assumed that the error handlers only want to access the first 8 bytes of the DCCP header. Actually, they also look at the DCCP sequence number, which is stored beyond 8 bytes, so an explicit pskb_may_pull() is required.
CVE-2023-53783: In the Linux kernel, the following vulnerability has been resolved:  blk-iocost: fix divide by 0 error in calc_lcoefs()  echo max of u64 to cost.model can cause divide by 0 error.    # echo 8:0 rbps=18446744073709551615 > /sys/fs/cgroup/io.cost.model    divide error: 0000 [#1] PREEMPT SMP   RIP: 0010:calc_lcoefs+0x4c/0xc0   Call Trace:    <TASK>    ioc_refresh_params+0x2b3/0x4f0    ioc_cost_model_write+0x3cb/0x4c0    ? _copy_from_iter+0x6d/0x6c0    ? kernfs_fop_write_iter+0xfc/0x270    cgroup_file_write+0xa0/0x200    kernfs_fop_write_iter+0x17d/0x270    vfs_write+0x414/0x620    ksys_write+0x73/0x160    __x64_sys_write+0x1e/0x30    do_syscall_64+0x35/0x80    entry_SYSCALL_64_after_hwframe+0x63/0xcd  calc_lcoefs() uses the input value of cost.model in DIV_ROUND_UP_ULL, overflow would happen if bps plus IOC_PAGE_SIZE is greater than ULLONG_MAX, it can cause divide by 0 error.  Fix the problem by setting basecost
CVE-2023-53784: In the Linux kernel, the following vulnerability has been resolved:  drm: bridge: dw_hdmi: fix connector access for scdc  Commit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdc interface to pick up an i2c adapter from a connector instead. However, in the case of dw-hdmi, the wrong connector was being used to pass i2c adapter information, since dw-hdmi's embedded connector structure is only populated when the bridge attachment callback explicitly asks for it.  drm-meson is handling connector creation, so this won't happen, leading to a NULL pointer dereference.  Fix it by having scdc functions access dw-hdmi's current connector pointer instead, which is assigned during the bridge enablement stage.  [narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag]
CVE-2023-53785: In the Linux kernel, the following vulnerability has been resolved:  mt76: mt7921: don't assume adequate headroom for SDIO headers  mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and mt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that adequate headroom will be available in the passed skb. This assumption typically is satisfied when the skb was allocated in the net core for transmission via the mt7921 netdev (although even that is only an optimization and is not strictly guaranteed), but the assumption is sometimes not satisfied when the skb originated in the receive path of another netdev and was passed through to the mt7921, such as by the bridge layer. Blindly prepending bytes to an skb is always wrong.  This commit introduces a call to skb_cow_head() before the call to mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be pushed onto the skb.  Without this fix, I can trivially cause kernel panics by bridging an MT7921AU-based USB 802.11ax interface with an Ethernet interface on an Intel Atom-based x86 system using its onboard RTL8169 PCI Ethernet adapter and also on an ARM-based Raspberry Pi 1 using its onboard SMSC9512 USB Ethernet adapter. Note that the panics do not occur in every system configuration, as they occur only if the receiving netdev leaves less headroom in its received skbs than the mt7921 needs for its SDIO headers.  Here is an example stack trace of this panic on Raspberry Pi OS Lite 2023-02-21 running kernel 6.1.24+ [1]:   skb_panic from skb_push+0x44/0x48  skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]  mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]  mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]  __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]  mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]  mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]  mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]  __mt76_worker_fn [mt76] from kthread+0xbc/0xe0  kthread from ret_from_fork+0x14/0x34  After this fix, bridging the mt7921 interface works fine on both of my previously problematic systems.  [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a
CVE-2023-53786: In the Linux kernel, the following vulnerability has been resolved:  dm flakey: fix a crash with invalid table line  This command will crash with NULL pointer dereference:  dmsetup create flakey --table \   "0 `blockdev --getsize /dev/ram0` flakey /dev/ram0 0 0 1 2 corrupt_bio_byte 512"  Fix the crash by checking if arg_name is non-NULL before comparing it.
CVE-2023-53787: In the Linux kernel, the following vulnerability has been resolved:  regulator: da9063: fix null pointer deref with partial DT config  When some of the da9063 regulators do not have corresponding DT nodes a null pointer dereference occurs on boot because such regulators have no init_data causing the pointers calculated in da9063_check_xvp_constraints() to be invalid.  Do not dereference them in this case.
CVE-2023-53788: In the Linux kernel, the following vulnerability has been resolved:  ALSA: hda/ca0132: fixup buffer overrun at tuning_ctl_set()  tuning_ctl_set() might have buffer overrun at (X) if it didn't break from loop by matching (A).   static int tuning_ctl_set(...)  {   for (i = 0; i < TUNING_CTLS_COUNT; i++) (A)   if (nid == ca0132_tuning_ctls[i].nid)     break;    snd_hda_power_up(...); (X)  dspio_set_param(..., ca0132_tuning_ctls[i].mid, ...);   snd_hda_power_down(...);                ^    return 1;  }  We will get below error by cppcheck   sound/pci/hda/patch_ca0132.c:4229:2: note: After for loop, i has value 12   for (i = 0; i < TUNING_CTLS_COUNT; i++)   ^  sound/pci/hda/patch_ca0132.c:4234:43: note: Array index out of bounds   dspio_set_param(codec, ca0132_tuning_ctls[i].mid, 0x20,                                             ^ This patch cares non match case.
CVE-2023-53789: In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: Improve page fault error reporting  If IOMMU domain for device group is not setup properly then we may hit IOMMU page fault. Current page fault handler assumes that domain is always setup and it will hit NULL pointer derefence (see below sample log).  Lets check whether domain is setup or not and log appropriate message.  Sample log: ----------  amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6  BUG: kernel NULL pointer dereference, address: 0000000000000058  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 0 P4D 0  Oops: 0000 [#1] PREEMPT SMP NOPTI  CPU: 2 PID: 56 Comm: irq/24-AMD-Vi Not tainted 6.2.0-rc2+ #89  Hardware name: xxx  RIP: 0010:report_iommu_fault+0x11/0x90  [...]  Call Trace:   <TASK>   amd_iommu_int_thread+0x60c/0x760   ? __pfx_irq_thread_fn+0x10/0x10   irq_thread_fn+0x1f/0x60   irq_thread+0xea/0x1a0   ? preempt_count_add+0x6a/0xa0   ? __pfx_irq_thread_dtor+0x10/0x10   ? __pfx_irq_thread+0x10/0x10   kthread+0xe9/0x110   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x2c/0x50   </TASK>  [joro: Edit commit message]
CVE-2023-53791: In the Linux kernel, the following vulnerability has been resolved:  md: fix warning for holder mismatch from export_rdev()  Commit a1d767191096 ("md: use mddev->external to select holder in export_rdev()") fix the problem that 'claim_rdev' is used for blkdev_get_by_dev() while 'rdev' is used for blkdev_put().  However, if mddev->external is changed from 0 to 1, then 'rdev' is used for blkdev_get_by_dev() while 'claim_rdev' is used for blkdev_put(). And this problem can be reporduced reliably by following:  New file: mdadm/tests/23rdev-lifetime  devname=${dev0##*/} devt=`cat /sys/block/$devname/dev` pid="" runtime=2  clean_up_test() {         pill -9 $pid         echo clear > /sys/block/md0/md/array_state }  trap 'clean_up_test' EXIT  add_by_sysfs() {         while true; do                 echo $devt > /sys/block/md0/md/new_dev         done }  remove_by_sysfs(){         while true; do                 echo remove > /sys/block/md0/md/dev-${devname}/state         done }  echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"  add_by_sysfs & pid="$pid $!"  remove_by_sysfs & pid="$pid $!"  sleep $runtime exit 0  Test cmd:  ./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime  Test result:  ------------[ cut here ]------------ WARNING: CPU: 0 PID: 960 at block/bdev.c:618 blkdev_put+0x27c/0x330 Modules linked in: multipath md_mod loop CPU: 0 PID: 960 Comm: test Not tainted 6.5.0-rc2-00121-g01e55c376936-dirty #50 RIP: 0010:blkdev_put+0x27c/0x330 Call Trace:  <TASK>  export_rdev.isra.23+0x50/0xa0 [md_mod]  mddev_unlock+0x19d/0x300 [md_mod]  rdev_attr_store+0xec/0x190 [md_mod]  sysfs_kf_write+0x52/0x70  kernfs_fop_write_iter+0x19a/0x2a0  vfs_write+0x3b5/0x770  ksys_write+0x74/0x150  __x64_sys_write+0x22/0x30  do_syscall_64+0x40/0x90  entry_SYSCALL_64_after_hwframe+0x63/0xcd  Fix the problem by recording if 'rdev' is used as holder.
CVE-2023-53792: In the Linux kernel, the following vulnerability has been resolved:  nvme-core: fix memory leak in dhchap_ctrl_secret  Free dhchap_secret in nvme_ctrl_dhchap_ctrl_secret_store() before we return when nvme_auth_generate_key() returns error.
CVE-2023-53793: In the Linux kernel, the following vulnerability has been resolved:  perf tool x86: Fix perf_env memory leak  Found by leak sanitizer: ``` ==1632594==ERROR: LeakSanitizer: detected memory leaks  Direct leak of 21 byte(s) in 1 object(s) allocated from:     #0 0x7f2953a7077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439     #1 0x556701d6fbbf in perf_env__read_cpuid util/env.c:369     #2 0x556701d70589 in perf_env__cpuid util/env.c:465     #3 0x55670204bba2 in x86__is_amd_cpu arch/x86/util/env.c:14     #4 0x5567020487a2 in arch__post_evsel_config arch/x86/util/evsel.c:83     #5 0x556701d8f78b in evsel__config util/evsel.c:1366     #6 0x556701ef5872 in evlist__config util/record.c:108     #7 0x556701cd6bcd in test__PERF_RECORD tests/perf-record.c:112     #8 0x556701cacd07 in run_test tests/builtin-test.c:236     #9 0x556701cacfac in test_and_print tests/builtin-test.c:265     #10 0x556701cadddb in __cmd_test tests/builtin-test.c:402     #11 0x556701caf2aa in cmd_test tests/builtin-test.c:559     #12 0x556701d3b557 in run_builtin tools/perf/perf.c:323     #13 0x556701d3bac8 in handle_internal_command tools/perf/perf.c:377     #14 0x556701d3be90 in run_argv tools/perf/perf.c:421     #15 0x556701d3c3f8 in main tools/perf/perf.c:537     #16 0x7f2952a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58  SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). ```
CVE-2023-53794: In the Linux kernel, the following vulnerability has been resolved:  cifs: fix session state check in reconnect to avoid use-after-free issue  Don't collect exiting session in smb2_reconnect_server(), because it will be released soon.  Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list.
CVE-2023-53795: In the Linux kernel, the following vulnerability has been resolved:  iommufd: IOMMUFD_DESTROY should not increase the refcount  syzkaller found a race where IOMMUFD_DESTROY increments the refcount:         obj = iommufd_get_object(ucmd->ictx, cmd->id, IOMMUFD_OBJ_ANY);        if (IS_ERR(obj))                return PTR_ERR(obj);        iommufd_ref_to_users(obj);        /* See iommufd_ref_to_users() */        if (!iommufd_object_destroy_user(ucmd->ictx, obj))  As part of the sequence to join the two existing primitives together.  Allowing the refcount the be elevated without holding the destroy_rwsem violates the assumption that all temporary refcount elevations are protected by destroy_rwsem. Racing IOMMUFD_DESTROY with iommufd_object_destroy_user() will cause spurious failures:    WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478   Modules linked in:   CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023   RIP: 0010:iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477   Code: e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 <0f> 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41   RSP: 0018:ffffc90003067e08 EFLAGS: 00010246   RAX: 0000000000000000 RBX: ffff888109ea0300 RCX: 0000000000000000   RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000ffffffff   RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88810bbb3500   R10: ffff88810bbb3e48 R11: 0000000000000000 R12: ffffc90003067e88   R13: ffffc90003067ea8 R14: ffff888101249800 R15: 00000000fffffffe   FS:  00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000555557262da8 CR3: 000000010a6fd000 CR4: 0000000000350ef0   Call Trace:    <TASK>    iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline]    iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813    iommufd_fops_ioctl+0x10f/0x1b0 drivers/iommu/iommufd/main.c:337    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+0x84/0xc0 fs/ioctl.c:856    do_syscall_x64 arch/x86/entry/common.c:50 [inline]    do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80    entry_SYSCALL_64_after_hwframe+0x63/0xcd  The solution is to not increment the refcount on the IOMMUFD_DESTROY path at all. Instead use the xa_lock to serialize everything. The refcount check == 1 and xa_erase can be done under a single critical region. This avoids the need for any refcount incrementing.  It has the downside that if userspace races destroy with other operations it will get an EBUSY instead of waiting, but this is kind of racing is already dangerous.
CVE-2023-53796: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix information leak in f2fs_move_inline_dirents()  When converting an inline directory to a regular one, f2fs is leaking uninitialized memory to disk because it doesn't initialize the entire directory block.  Fix this by zero-initializing the block.  This bug was introduced by commit 4ec17d688d74 ("f2fs: avoid unneeded initializing when converting inline dentry"), which didn't consider the security implications of leaking uninitialized memory to disk.  This was found by running xfstest generic/435 on a KMSAN-enabled kernel.
CVE-2023-53797: In the Linux kernel, the following vulnerability has been resolved:  HID: wacom: Use ktime_t rather than int when dealing with timestamps  Code which interacts with timestamps needs to use the ktime_t type returned by functions like ktime_get. The int type does not offer enough space to store these values, and attempting to use it is a recipe for problems. In this particular case, overflows would occur when calculating/storing timestamps leading to incorrect values being reported to userspace. In some cases these bad timestamps cause input handling in userspace to appear hung.
CVE-2023-53800: In the Linux kernel, the following vulnerability has been resolved:  ubi: Fix use-after-free when volume resizing failed  There is an use-after-free problem reported by KASAN:   ==================================================================   BUG: KASAN: use-after-free in ubi_eba_copy_table+0x11f/0x1c0 [ubi]   Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735    CPU: 2 PID: 4735 Comm: ubirsvol   Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),   BIOS 1.14.0-1.fc33 04/01/2014   Call Trace:    <TASK>    dump_stack_lvl+0x34/0x44    print_report+0x171/0x472    kasan_report+0xad/0x130    ubi_eba_copy_table+0x11f/0x1c0 [ubi]    ubi_resize_volume+0x4f9/0xbc0 [ubi]    ubi_cdev_ioctl+0x701/0x1850 [ubi]    __x64_sys_ioctl+0x11d/0x170    do_syscall_64+0x35/0x80    entry_SYSCALL_64_after_hwframe+0x46/0xb0    </TASK>  When ubi_change_vtbl_record() returns an error in ubi_resize_volume(), "new_eba_tbl" will be freed on error handing path, but it is holded by "vol->eba_tbl" in ubi_eba_replace_table(). It means that the liftcycle of "vol->eba_tbl" and "vol" are different, so when resizing volume in next time, it causing an use-after-free fault.  Fix it by not freeing "new_eba_tbl" after it replaced in ubi_eba_replace_table(), while will be freed in next volume resizing.
CVE-2023-53801: In the Linux kernel, the following vulnerability has been resolved:  iommu/sprd: Release dma buffer to avoid memory leak  When attaching to a domain, the driver would alloc a DMA buffer which is used to store address mapping table, and it need to be released when the IOMMU domain is freed.
CVE-2023-53802: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k: htc_hst: free skb in ath9k_htc_rx_msg() if there is no callback function  It is stated that ath9k_htc_rx_msg() either frees the provided skb or passes its management to another callback function. However, the skb is not freed in case there is no another callback function, and Syzkaller was able to cause a memory leak. Also minor comment fix.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2023-53803: In the Linux kernel, the following vulnerability has been resolved:  scsi: ses: Fix slab-out-of-bounds in ses_enclosure_data_process()  A fix for:  BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x949/0xe30 [ses] Read of size 1 at addr ffff88a1b043a451 by task systemd-udevd/3271  Checking after (and before in next loop) addl_desc_ptr[1] is sufficient, we expect the size to be sanitized before first access to addl_desc_ptr[1]. Make sure we don't walk beyond end of page.
CVE-2023-53804: In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()  During unmount process of nilfs2, nothing holds nilfs_root structure after nilfs2 detaches its writer in nilfs_detach_log_writer().  However, since nilfs_evict_inode() uses nilfs_root for some cleanup operations, it may cause use-after-free read if inodes are left in "garbage_list" and released by nilfs_dispose_list() at the end of nilfs_detach_log_writer().  Fix this issue by modifying nilfs_evict_inode() to only clear inode without additional metadata changes that use nilfs_root if the file system is degraded to read-only or the writer is detached.
CVE-2023-53806: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: populate subvp cmd info only for the top pipe  [Why] System restart observed while changing the display resolution to 8k with extended mode. Sytem restart was caused by a page fault.  [How] When the driver populates subvp info it did it for both the pipes using vblank which caused an outof bounds array access causing the page fault. added checks to allow the top pipe only to fix this issue.
CVE-2023-53808: In the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: fix memory leak in mwifiex_histogram_read()  Always free the zeroed page on return from 'mwifiex_histogram_read()'.
CVE-2023-53810: In the Linux kernel, the following vulnerability has been resolved:  blk-mq: release crypto keyslot before reporting I/O complete  Once all I/O using a blk_crypto_key has completed, filesystems can call blk_crypto_evict_key().  However, the block layer currently doesn't call blk_crypto_put_keyslot() until the request is being freed, which happens after upper layers have been told (via bio_endio()) the I/O has completed.  This causes a race condition where blk_crypto_evict_key() can see 'slot_refs != 0' without there being an actual bug.  This makes __blk_crypto_evict_key() hit the 'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return without doing anything, eventually causing a use-after-free in blk_crypto_reprogram_all_keys().  (This is a very rare bug and has only been seen when per-file keys are being used with fscrypt.)  There are two options to fix this: either release the keyslot before bio_endio() is called on the request's last bio, or make __blk_crypto_evict_key() ignore slot_refs.  Let's go with the first solution, since it preserves the ability to report bugs (via WARN_ON_ONCE) where a key is evicted while still in-use.