xamxte/cve-to-cwe huggingface dataset:
CVE-2025-39946: In the Linux kernel, the following vulnerability has been resolved:  tls: make sure to abort the stream if headers are bogus  Normally we wait for the socket to buffer up the whole record before we service it. If the socket has a tiny buffer, however, we read out the data sooner, to prevent connection stalls. Make sure that we abort the connection when we find out late that the record is actually invalid. Retrying the parsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb space.  Constructing a scenario in which we're under pressure without enough data in the socket to parse the length upfront is quite hard. syzbot figured out a way to do this by serving us the header in small OOB sends, and then filling in the recvbuf with a large normal send.  Make sure that tls_rx_msg_size() aborts strp, if we reach an invalid record there's really no way to recover.
CVE-2025-39949: In the Linux kernel, the following vulnerability has been resolved:  qed: Don't collect too many protection override GRC elements  In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.  This will result in a kernel panic with reason:   BUG: unable to handle kernel paging request at ADDRESS  where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is:  p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure.  The panic can be arrived at from either the qede Ethernet driver path:      [exception RIP: qed_grc_dump_addr_range+0x108]  qed_protection_override_dump at ffffffffc02662ed [qed]  qed_dbg_protection_override_dump at ffffffffc0267792 [qed]  qed_dbg_feature at ffffffffc026aa8f [qed]  qed_dbg_all_data at ffffffffc026b211 [qed]  qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]  devlink_health_do_dump at ffffffff82497f61  devlink_health_report at ffffffff8249cf29  qed_report_fatal_error at ffffffffc0272baf [qed]  qede_sp_task at ffffffffc045ed32 [qede]  process_one_work at ffffffff81d19783  or the qedf storage driver path:      [exception RIP: qed_grc_dump_addr_range+0x108]  qed_protection_override_dump at ffffffffc068b2ed [qed]  qed_dbg_protection_override_dump at ffffffffc068c792 [qed]  qed_dbg_feature at ffffffffc068fa8f [qed]  qed_dbg_all_data at ffffffffc0690211 [qed]  qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]  devlink_health_do_dump at ffffffff8aa95e51  devlink_health_report at ffffffff8aa9ae19  qed_report_fatal_error at ffffffffc0697baf [qed]  qed_hw_err_notify at ffffffffc06d32d7 [qed]  qed_spq_post at ffffffffc06b1011 [qed]  qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]  qedf_cleanup_fcport at ffffffffc05e7597 [qedf]  qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]  fc_rport_work at ffffffffc02da715 [libfc]  process_one_work at ffffffff8a319663  Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.
CVE-2025-39953: In the Linux kernel, the following vulnerability has been resolved:  cgroup: split cgroup_destroy_wq into 3 workqueues  A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.  Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio  Call Trace:  cgroup_lock_and_drain_offline+0x14c/0x1e8  cgroup_destroy_root+0x3c/0x2c0  css_free_rwork_fn+0x248/0x338  process_one_work+0x16c/0x3b8  worker_thread+0x22c/0x3b0  kthread+0xec/0x100  ret_from_fork+0x10/0x20  Root Cause:  CPU0                            CPU1 mount perf_event                umount net_prio cgroup1_get_tree                cgroup_kill_sb rebind_subsystems               // root destruction enqueues     // cgroup_destroy_wq // kill all perf_event css                                 // one perf_event css A is dying                                 // css A offline enqueues cgroup_destroy_wq                                 // root destruction will be executed first                                 css_free_rwork_fn                                 cgroup_destroy_root                                 cgroup_lock_and_drain_offline                                 // some perf descendants are dying                                 // cgroup_destroy_wq max_active = 1                                 // waiting for css A to die  Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is    blocked behind root destruction in cgroup_destroy_wq (max_active=1)  Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation  This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.  [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
CVE-2022-50480: In the Linux kernel, the following vulnerability has been resolved:  memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe()  The break of for_each_available_child_of_node() needs a corresponding of_node_put() when the reference 'child' is not used anymore. Here we do not need to call of_node_put() in fail path as '!match' means no break.  While the of_platform_device_create() will created a new reference by 'child' but it has considered the refcounting.
CVE-2022-50486: In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: ti: Fix return type of netcp_ndo_start_xmit()  With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals:    drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]           .ndo_start_xmit         = netcp_ndo_start_xmit,                                     ^~~~~~~~~~~~~~~~~~~~   1 error generated.  ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netcp_ndo_start_xmit() to match the prototype's to resolve the warning and CFI failure.
CVE-2022-50505: In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: Fix pci device refcount leak in ppr_notifier()  As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak.
CVE-2023-53533: In the Linux kernel, the following vulnerability has been resolved:  Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe  rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put().
CVE-2023-53547: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix sdma v4 sw fini error  Fix sdma v4 sw fini error for sdma 4.2.2 to solve the following general protection fault  [  +0.108196] general protection fault, probably for non-canonical address 0xd5e5a4ae79d24a32: 0000 [#1] PREEMPT SMP PTI [  +0.000018] RIP: 0010:free_fw_priv+0xd/0x70 [  +0.000022] Call Trace: [  +0.000012]  <TASK> [  +0.000011]  release_firmware+0x55/0x80 [  +0.000021]  amdgpu_ucode_release+0x11/0x20 [amdgpu] [  +0.000415]  amdgpu_sdma_destroy_inst_ctx+0x4f/0x90 [amdgpu] [  +0.000360]  sdma_v4_0_sw_fini+0xce/0x110 [amdgpu]
CVE-2023-53548: In the Linux kernel, the following vulnerability has been resolved:  net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb  The syzbot fuzzer identified a problem in the usbnet driver:  usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc9000463f568 EFLAGS: 00010086 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001 RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003 R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500 FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0 Call Trace:  <TASK>  usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453  __netdev_start_xmit include/linux/netdevice.h:4918 [inline]  netdev_start_xmit include/linux/netdevice.h:4932 [inline]  xmit_one net/core/dev.c:3578 [inline]  dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594 ...  This bug is caused by the fact that usbnet trusts the bulk endpoint addresses its probe routine receives in the driver_info structure, and it does not check to see that these endpoints actually exist and have the expected type and directions.  The fix is simply to add such a check.
CVE-2023-53557: In the Linux kernel, the following vulnerability has been resolved:  fprobe: Release rethook after the ftrace_ops is unregistered  While running bpf selftests it's possible to get following fault:    general protection fault, probably for non-canonical address \   0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI   ...   Call Trace:    <TASK>    fprobe_handler+0xc1/0x270    ? __pfx_bpf_testmod_init+0x10/0x10    ? __pfx_bpf_testmod_init+0x10/0x10    ? bpf_fentry_test1+0x5/0x10    ? bpf_fentry_test1+0x5/0x10    ? bpf_testmod_init+0x22/0x80    ? do_one_initcall+0x63/0x2e0    ? rcu_is_watching+0xd/0x40    ? kmalloc_trace+0xaf/0xc0    ? do_init_module+0x60/0x250    ? __do_sys_finit_module+0xac/0x120    ? do_syscall_64+0x37/0x90    ? entry_SYSCALL_64_after_hwframe+0x72/0xdc    </TASK>  In unregister_fprobe function we can't release fp->rethook while it's possible there are some of its users still running on another cpu.  Moving rethook_free call after fp->ops is unregistered with unregister_ftrace_function call.
CVE-2023-53558: In the Linux kernel, the following vulnerability has been resolved:  rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()  pr_info() is called with rtp->cbs_gbl_lock spin lock locked.  Because pr_info() calls printk() that might sleep, this will result in BUG like below:  [    0.206455] cblist_init_generic: Setting adjustable number of callback queues. [    0.206463] [    0.206464] ============================= [    0.206464] [ BUG: Invalid wait context ] [    0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted [    0.206466] ----------------------------- [    0.206466] swapper/0/1 is trying to lock: [    0.206467] ffffffffa0167a58 (&port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0 [    0.206473] other info that might help us debug this: [    0.206473] context-{5:5} [    0.206474] 3 locks held by swapper/0/1: [    0.206474]  #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0 [    0.206478]  #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e [    0.206482]  #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330 [    0.206485] stack backtrace: [    0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5 [    0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 [    0.206489] Call Trace: [    0.206490]  <TASK> [    0.206491]  dump_stack_lvl+0x6a/0x9f [    0.206493]  __lock_acquire.cold+0x2d7/0x2fe [    0.206496]  ? stack_trace_save+0x46/0x70 [    0.206497]  lock_acquire+0xd1/0x2f0 [    0.206499]  ? serial8250_console_write+0x327/0x4a0 [    0.206500]  ? __lock_acquire+0x5c7/0x2720 [    0.206502]  _raw_spin_lock_irqsave+0x3d/0x90 [    0.206504]  ? serial8250_console_write+0x327/0x4a0 [    0.206506]  serial8250_console_write+0x327/0x4a0 [    0.206508]  console_emit_next_record.constprop.0+0x180/0x330 [    0.206511]  console_unlock+0xf7/0x1f0 [    0.206512]  vprintk_emit+0xf7/0x330 [    0.206514]  _printk+0x63/0x7e [    0.206516]  cblist_init_generic.constprop.0.cold+0x24/0x32 [    0.206518]  rcu_init_tasks_generic+0x5/0xd9 [    0.206522]  kernel_init_freeable+0x15b/0x2a2 [    0.206523]  ? rest_init+0x160/0x160 [    0.206526]  kernel_init+0x11/0x120 [    0.206527]  ret_from_fork+0x1f/0x30 [    0.206530]  </TASK> [    0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.  This patch moves pr_info() so that it is called without rtp->cbs_gbl_lock locked.
CVE-2023-53563: In the Linux kernel, the following vulnerability has been resolved:  cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver  After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf() and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy of the CPU and mark it as busy.  In these functions, cpufreq_cpu_put() should be used to release the policy, but it is not, so any other entity trying to access the policy is blocked indefinitely.  One such scenario is when amd_pstate mode is changed, leading to the following splat:  [ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds. [ 1332.110001]       Not tainted 6.5.0-rc2-amd-pstate-ut #5 [ 1332.115315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1332.123140] task:bash            state:D stack:0     pid:2929  ppid:2873   flags:0x00004006 [ 1332.123143] Call Trace: [ 1332.123145]  <TASK> [ 1332.123148]  __schedule+0x3c1/0x16a0 [ 1332.123154]  ? _raw_read_lock_irqsave+0x2d/0x70 [ 1332.123157]  schedule+0x6f/0x110 [ 1332.123160]  schedule_timeout+0x14f/0x160 [ 1332.123162]  ? preempt_count_add+0x86/0xd0 [ 1332.123165]  __wait_for_common+0x92/0x190 [ 1332.123168]  ? __pfx_schedule_timeout+0x10/0x10 [ 1332.123170]  wait_for_completion+0x28/0x30 [ 1332.123173]  cpufreq_policy_put_kobj+0x4d/0x90 [ 1332.123177]  cpufreq_policy_free+0x157/0x1d0 [ 1332.123178]  ? preempt_count_add+0x58/0xd0 [ 1332.123180]  cpufreq_remove_dev+0xb6/0x100 [ 1332.123182]  subsys_interface_unregister+0x114/0x120 [ 1332.123185]  ? preempt_count_add+0x58/0xd0 [ 1332.123187]  ? __pfx_amd_pstate_change_driver_mode+0x10/0x10 [ 1332.123190]  cpufreq_unregister_driver+0x3b/0xd0 [ 1332.123192]  amd_pstate_change_driver_mode+0x1e/0x50 [ 1332.123194]  store_status+0xe9/0x180 [ 1332.123197]  dev_attr_store+0x1b/0x30 [ 1332.123199]  sysfs_kf_write+0x42/0x50 [ 1332.123202]  kernfs_fop_write_iter+0x143/0x1d0 [ 1332.123204]  vfs_write+0x2df/0x400 [ 1332.123208]  ksys_write+0x6b/0xf0 [ 1332.123210]  __x64_sys_write+0x1d/0x30 [ 1332.123213]  do_syscall_64+0x60/0x90 [ 1332.123216]  ? fpregs_assert_state_consistent+0x2e/0x50 [ 1332.123219]  ? exit_to_user_mode_prepare+0x49/0x1a0 [ 1332.123223]  ? irqentry_exit_to_user_mode+0xd/0x20 [ 1332.123225]  ? irqentry_exit+0x3f/0x50 [ 1332.123226]  ? exc_page_fault+0x8e/0x190 [ 1332.123228]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 1332.123232] RIP: 0033:0x7fa74c514a37 [ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37 [ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001 [ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff [ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008 [ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00 [ 1332.123247]  </TASK>  Fix this by calling cpufreq_cpu_put() wherever necessary.  [ rjw: Subject and changelog edits ]
CVE-2023-53569: In the Linux kernel, the following vulnerability has been resolved:  ext2: Check block size validity during mount  Check that log of block size stored in the superblock has sensible value. Otherwise the shift computing the block size can overflow leading to undefined behavior.
CVE-2023-53571: In the Linux kernel, the following vulnerability has been resolved:  drm/i915: Make intel_get_crtc_new_encoder() less oopsy  The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that.  (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)
CVE-2023-53583: In the Linux kernel, the following vulnerability has been resolved:  perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()  Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the perf_sample_event_took() function was added to report time spent in overflow interrupts. If the interrupt takes too long, the perf framework will lower the sysctl_perf_event_sample_rate and max_samples_per_tick. When hwc->interrupts is larger than max_samples_per_tick, the hwc->interrupts will be set to MAX_INTERRUPTS, and events will be throttled within the __perf_event_account_interrupt() function.  However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler() function to avoid throttling. When the perf framework unthrottled the event in the timer interrupt handler, it triggers riscv_pmu_start() function and causes a WARN_ON_ONCE() warning, as shown below:   ------------[ cut here ]------------  WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e  Modules linked in:  CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1  Hardware name: SiFive (DT)  epc : riscv_pmu_start+0x7c/0x8e   ra : riscv_pmu_start+0x28/0x8e  epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0   gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0   t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720   s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000   a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000   a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030   s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00   s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000   s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340   s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796   t5 : 0000000700000000 t6 : ffffaf8005269870  status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003  [<ffffffff80aef864>] riscv_pmu_start+0x7c/0x8e  [<ffffffff80185b56>] perf_adjust_freq_unthr_context+0x15e/0x174  [<ffffffff80188642>] perf_event_task_tick+0x88/0x9c  [<ffffffff800626a8>] scheduler_tick+0xfe/0x27c  [<ffffffff800b5640>] update_process_times+0x9a/0xba  [<ffffffff800c5bd4>] tick_sched_handle+0x32/0x66  [<ffffffff800c5e0c>] tick_sched_timer+0x64/0xb0  [<ffffffff800b5e50>] __hrtimer_run_queues+0x156/0x2f4  [<ffffffff800b6bdc>] hrtimer_interrupt+0xe2/0x1fe  [<ffffffff80acc9e8>] riscv_timer_interrupt+0x38/0x42  [<ffffffff80090a16>] handle_percpu_devid_irq+0x90/0x1d2  [<ffffffff8008a9f4>] generic_handle_domain_irq+0x28/0x36  After referring other PMU drivers like Arm, Loongarch, Csky, and Mips, they don't call *_pmu_stop() to update with PERF_HES_STOPPED flag after perf_event_overflow() function nor do they add PERF_HES_STOPPED flag checking in *_pmu_start() which don't cause this warning.  Thus, it's recommended to remove this unnecessary check in riscv_pmu_start() function to prevent this warning.
CVE-2023-53589: In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: don't trust firmware n_channels  If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response.  Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly.
CVE-2023-53592: In the Linux kernel, the following vulnerability has been resolved:  gpio: sifive: Fix refcount leak in sifive_gpio_probe  of_irq_find_parent() 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-53593: In the Linux kernel, the following vulnerability has been resolved:  cifs: Release folio lock on fscache read hit.  Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as:  > The filesystem should unlock the folio once the read has completed, > whether it was successful or not.  Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page:  $ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault+0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30  This requires a reboot to resolve; it is a deadlock.  Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead.
CVE-2023-53598: In the Linux kernel, the following vulnerability has been resolved:  bus: mhi: host: Range check CHDBOFF and ERDBOFF  If the value read from the CHDBOFF and ERDBOFF registers is outside the range of the MHI register space then an invalid address might be computed which later causes a kernel panic.  Range check the read value to prevent a crash due to bad data from the device.
CVE-2023-53604: In the Linux kernel, the following vulnerability has been resolved:  dm integrity: call kmem_cache_destroy() in dm_integrity_init() error path  Otherwise the journal_io_cache will leak if dm_register_target() fails.