xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40138: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency()  syzbot reported a f2fs bug as below:  Oops: gen[  107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G        W           6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT_{RT,(full)} RIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284 Call Trace:  <TASK>  f2fs_check_quota_consistency fs/f2fs/super.c:1188 [inline]  f2fs_check_opt_consistency+0x1378/0x2c10 fs/f2fs/super.c:1436  __f2fs_remount fs/f2fs/super.c:2653 [inline]  f2fs_reconfigure+0x482/0x1770 fs/f2fs/super.c:5297  reconfigure_super+0x224/0x890 fs/super.c:1077  do_remount fs/namespace.c:3314 [inline]  path_mount+0xd18/0xfe0 fs/namespace.c:4112  do_mount fs/namespace.c:4133 [inline]  __do_sys_mount fs/namespace.c:4344 [inline]  __se_sys_mount+0x317/0x410 fs/namespace.c:4321  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The direct reason is f2fs_check_quota_consistency() may suffer null-ptr-deref issue in strcmp().  The bug can be reproduced w/ below scripts: mkfs.f2fs -f /dev/vdb mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs quotacheck -uc /mnt/f2fs/ umount /mnt/f2fs mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs umount /mnt/f2fs  So, before old_qname and new_qname comparison, we need to check whether they are all valid pointers, fix it.
CVE-2025-40139: In the Linux kernel, the following vulnerability has been resolved:  smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().  smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.  Using sk_dst_get(sk)->dev could trigger UAF.  Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().  Note that the returned value of smc_clc_prfx_set() is not used in the caller.  While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.
CVE-2025-40141: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: ISO: Fix possible UAF on iso_conn_free  This attempt to fix similar issue to sco_conn_free where if the conn->sk is not set to NULL may lead to UAF on iso_conn_free.
CVE-2025-40145: In the Linux kernel, the following vulnerability has been resolved:  PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure  When devm_add_action_or_reset() fails, it calls the passed cleanup function.  Hence the caller must not repeat that cleanup.  Replace the "goto err_regulator_free" by the actual freeing, as there will never be a need again for a second user of this label.
CVE-2025-40147: In the Linux kernel, the following vulnerability has been resolved:  blk-throttle: fix access race during throttle policy activation  On repeated cold boots we occasionally hit a NULL pointer crash in blk_should_throtl() when throttling is consulted before the throttle policy is fully enabled for the queue. Checking only q->td != NULL is insufficient during early initialization, so blkg_to_pd() for the throttle policy can still return NULL and blkg_to_tg() becomes NULL, which later gets dereferenced.   Unable to handle kernel NULL pointer dereference  at virtual address 0000000000000156  ...  pc : submit_bio_noacct+0x14c/0x4c8  lr : submit_bio_noacct+0x48/0x4c8  sp : ffff800087f0b690  x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0  x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70  x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000  x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff  x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff  x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c  x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60  x8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002  x5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500  x2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a  Call trace:   submit_bio_noacct+0x14c/0x4c8   verity_map+0x178/0x2c8   __map_bio+0x228/0x250   dm_submit_bio+0x1c4/0x678   __submit_bio+0x170/0x230   submit_bio_noacct_nocheck+0x16c/0x388   submit_bio_noacct+0x16c/0x4c8   submit_bio+0xb4/0x210   f2fs_submit_read_bio+0x4c/0xf0   f2fs_mpage_readpages+0x3b0/0x5f0   f2fs_readahead+0x90/0xe8  Tighten blk_throtl_activated() to also require that the throttle policy bit is set on the queue:    return q->td != NULL &&          test_bit(blkcg_policy_throtl.plid, q->blkcg_pols);  This prevents blk_should_throtl() from accessing throttle group state until policy data has been attached to blkgs.
CVE-2025-40148: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions  The function dc_stream_set_cursor_attributes() currently dereferences the `stream` pointer and nested members `stream->ctx->dc->current_state` without checking for NULL.  All callers of these functions, such as in `dcn30_apply_idle_power_optimizations()` and `amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks before calling these functions.  Fixes below: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes() error: we previously assumed 'stream' could be null (see line 334)  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c     327 bool dc_stream_program_cursor_attributes(     328         struct dc_stream_state *stream,     329         const struct dc_cursor_attributes *attributes)     330 {     331         struct dc  *dc;     332         bool reset_idle_optimizations = false;     333     334         dc = stream ? stream->ctx->dc : NULL;                      ^^^^^^ The old code assumed stream could be NULL.      335 --> 336         if (dc_stream_set_cursor_attributes(stream, attributes)) {                                                     ^^^^^^ The refactor added an unchecked dereference.  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c    313  bool dc_stream_set_cursor_attributes(    314          struct dc_stream_state *stream,    315          const struct dc_cursor_attributes *attributes)    316  {    317          bool result = false;    318    319          if (dc_stream_check_cursor_attributes(stream, stream->ctx->dc->current_state, attributes)) {                                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here. This function used to check for if stream as NULL and return false at the start. Probably we should add that back.
CVE-2025-40150: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid migrating empty section  It reports a bug from device w/ zufs:  F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT F2FS-fs (dm-64): Stopped filesystem due to reason: 4  Thread A    Thread B - f2fs_expand_inode_data  - f2fs_allocate_pinning_section   - f2fs_gc_range    - do_garbage_collect w/ segno #x      - writepage       - f2fs_allocate_data_block        - new_curseg         - allocate segno #x  The root cause is: fallocate on pinning file may race w/ block allocation as above, result in do_garbage_collect() from fallocate() may migrate segment which is just allocated by a log, the log will update segment type in its in-memory structure, however GC will get segment type from on-disk SSA block, once segment type changes by log, we can detect such inconsistency, then shutdown filesystem.  In this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE), however segno #173822 was just allocated as data type segment, so in-memory SIT shows type of segno #173822 is 0 (SUM_TYPE_DATA).  Change as below to fix this issue: - check whether current section is empty before gc - add sanity checks on do_garbage_collect() to avoid any race case, result in migrating segment used by log. - btw, it fixes misc issue in printed logs: "SSA and SIT" -> "SIT and SSA".
CVE-2025-40153: In the Linux kernel, the following vulnerability has been resolved:  mm: hugetlb: avoid soft lockup when mprotect to large memory area  When calling mprotect() to a large hugetlb memory area in our customer's workload (~300GB hugetlb memory), soft lockup was observed:  watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]  CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7 Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mte_clear_page_tags+0x14/0x24 lr : mte_sync_tags+0x1c0/0x240 sp : ffff80003150bb80 x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000 x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458 x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000 x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000 x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000  Call trace:   mte_clear_page_tags+0x14/0x24   set_huge_pte_at+0x25c/0x280   hugetlb_change_protection+0x220/0x430   change_protection+0x5c/0x8c   mprotect_fixup+0x10c/0x294   do_mprotect_pkey.constprop.0+0x2e0/0x3d4   __arm64_sys_mprotect+0x24/0x44   invoke_syscall+0x50/0x160   el0_svc_common+0x48/0x144   do_el0_svc+0x30/0xe0   el0_svc+0x30/0xf0   el0t_64_sync_handler+0xc4/0x148   el0t_64_sync+0x1a4/0x1a8  Soft lockup is not triggered with THP or base page because there is cond_resched() called for each PMD size.  Although the soft lockup was triggered by MTE, it should be not MTE specific.  The other processing which takes long time in the loop may trigger soft lockup too.  So add cond_resched() for hugetlb to avoid soft lockup.
CVE-2025-40155: In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: debugfs: Fix legacy mode page table dump logic  In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like:   Oops: general protection fault, probably for non-canonical address        0xf00087d3f000f000: 0000 [#1] SMP NOPTI  CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014  RIP: 0010:pgtable_walk_level+0x98/0x150  RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206  RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e  RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000  RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002  R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000  R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98  FS:  0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0  PKRU: 55555554  Call Trace:   <TASK>   pgtable_walk_level+0x88/0x150   domain_translation_struct_show.isra.0+0x2d9/0x300   dev_domain_translation_struct_show+0x20/0x40   seq_read_iter+0x12d/0x490 ...  Avoid walking the page table if TT is not 00b or 01b.
CVE-2025-40158: In the Linux kernel, the following vulnerability has been resolved:  ipv6: use RCU in ip6_output()  Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF.  We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2().
CVE-2025-40159: In the Linux kernel, the following vulnerability has been resolved:  xsk: Harden userspace-supplied xdp_desc validation  Turned out certain clearly invalid values passed in xdp_desc from userspace can pass xp_{,un}aligned_validate_desc() and then lead to UBs or just invalid frames to be queued for xmit.  desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len can cause positive integer overflow and wraparound, the same way low enough desc->addr with a non-zero pool->tx_metadata_len can cause negative integer overflow. Both scenarios can then pass the validation successfully. This doesn't happen with valid XSk applications, but can be used to perform attacks.  Always promote desc->len to ``u64`` first to exclude positive overflows of it. Use explicit check_{add,sub}_overflow() when validating desc->addr (which is ``u64`` already).  bloat-o-meter reports a little growth of the code size:  add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44) Function                                     old     new   delta xskq_cons_peek_desc                          299     330     +31 xsk_tx_peek_release_desc_batch               973    1002     +29 xsk_generic_xmit                            3148    3132     -16  but hopefully this doesn't hurt the performance much.
CVE-2025-40162: In the Linux kernel, the following vulnerability has been resolved:  ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails  devm_kasprintf() may return NULL on memory allocation failure, but the debug message prints cpus->dai_name before checking it. Move the dev_dbg() call after the NULL check to prevent potential NULL pointer dereference.
CVE-2025-40166: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/guc: Check GuC running state before deregistering exec queue  In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call exec_destroy() after the GuC has already been stopped and CT communication disabled.  In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running.  Here is the failure dmesg log: " [  468.089581] ---[ end trace 0000000000000000 ]--- [  468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) [  468.090558] pci 0000:03:00.0: [drm] GT0:     total 65535 [  468.090562] pci 0000:03:00.0: [drm] GT0:     used 1 [  468.090564] pci 0000:03:00.0: [drm] GT0:     range 1..1 (1) [  468.092716] ------------[ cut here ]------------ [  468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] "  v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().     As CT may go down and come back during VF migration.  (cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)
CVE-2025-40167: In the Linux kernel, the following vulnerability has been resolved:  ext4: detect invalid INLINE_DATA + EXTENTS flag combination  syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal.  The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set:      EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15:     comm syz.0.17: corrupted extent tree: lblk 0 < prev 66  Investigation revealed that the inode has both flags set:     DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1  This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks  Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes.  Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode.
CVE-2025-40168: In the Linux kernel, the following vulnerability has been resolved:  smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().  smc_clc_prfx_match() is called from smc_listen_work() and not under RCU nor RTNL.  Using sk_dst_get(sk)->dev could trigger UAF.  Let's use __sk_dst_get() and dst_dev_rcu().  Note that the returned value of smc_clc_prfx_match() is not used in the caller.
CVE-2025-40169: In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject negative offsets for ALU ops  When verifying BPF programs, the check_alu_op() function validates instructions with ALU operations. The 'offset' field in these instructions is a signed 16-bit integer.  The existing check 'insn->off > 1' was intended to ensure the offset is either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1).  This commit tightens the validation by changing the condition to '(insn->off != 0 && insn->off != 1)'. This ensures that any value other than the explicitly permitted 0 and 1 is rejected, hardening the verifier against malformed BPF programs.
CVE-2025-40173: In the Linux kernel, the following vulnerability has been resolved:  net/ip6_tunnel: Prevent perpetual tunnel growth  Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"), ipv6 tunnel yet increases the headroom without any ceiling.  Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.  Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer.
CVE-2025-40176: In the Linux kernel, the following vulnerability has been resolved:  tls: wait for pending async decryptions if tls_strp_msg_hold fails  Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned).  In this case, wait for all pending decryption requests.
CVE-2025-40177: In the Linux kernel, the following vulnerability has been resolved:  accel/qaic: Fix bootlog initialization ordering  As soon as we queue MHI buffers to receive the bootlog from the device, we could be receiving data. Therefore all the resources needed to process that data need to be setup prior to queuing the buffers.  We currently initialize some of the resources after queuing the buffers which creates a race between the probe() and any data that comes back from the device. If the uninitialized resources are accessed, we could see page faults.  Fix the init ordering to close the race.
CVE-2025-40178: In the Linux kernel, the following vulnerability has been resolved:  pid: Add a judgment for ns null in pid_nr_ns  __task_pid_nr_ns         ns = task_active_pid_ns(current);         pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);                 if (pid && ns->level <= pid->level) {  Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.  For example:  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058  Mem abort info:  ESR = 0x0000000096000007  EC = 0x25: DABT (current EL), IL = 32 bits  SET = 0, FnV = 0  EA = 0, S1PTW = 0  FSC = 0x07: level 3 translation fault  Data abort info:  ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000  CM = 0, WnR = 0, TnD = 0, TagAccess = 0  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0  user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000  [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000  pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)  pc : __task_pid_nr_ns+0x74/0xd0  lr : __task_pid_nr_ns+0x24/0xd0  sp : ffffffc08001bd10  x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001  x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31  x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0  x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000  x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc  x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800  x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001  x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449  x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc  x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0  Call trace:  __task_pid_nr_ns+0x74/0xd0  ...  __handle_irq_event_percpu+0xd4/0x284  handle_irq_event+0x48/0xb0  handle_fasteoi_irq+0x160/0x2d8  generic_handle_domain_irq+0x44/0x60  gic_handle_irq+0x4c/0x114  call_on_irq_stack+0x3c/0x74  do_interrupt_handler+0x4c/0x84  el1_interrupt+0x34/0x58  el1h_64_irq_handler+0x18/0x24  el1h_64_irq+0x68/0x6c  account_kernel_stack+0x60/0x144  exit_task_stack_account+0x1c/0x80  do_exit+0x7e4/0xaf8  ...  get_signal+0x7bc/0x8d8  do_notify_resume+0x128/0x828  el0_svc+0x6c/0x70  el0t_64_sync_handler+0x68/0xbc  el0t_64_sync+0x1a8/0x1ac  Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)  ---[ end trace 0000000000000000 ]---  Kernel panic - not syncing: Oops: Fatal exception in interrupt
CVE-2025-40179: In the Linux kernel, the following vulnerability has been resolved:  ext4: verify orphan file size is not too big  In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files.
CVE-2025-40180: In the Linux kernel, the following vulnerability has been resolved:  mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop  The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds.
CVE-2025-40182: In the Linux kernel, the following vulnerability has been resolved:  crypto: skcipher - Fix reqsize handling  Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks.  However, this is being recommended for use in all crypto algs [1] instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in skcipher algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [2]  Add proper set_reqsize calls in the skcipher init function to properly initialize reqsize for these algorithms in the framework.  [1]: https://lore.kernel.org/linux-crypto/aCL8BxpHr5OpT04k@gondor.apana.org.au/ [2]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b