xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40237: In the Linux kernel, the following vulnerability has been resolved:  fs/notify: call exportfs_encode_fid with s_umount  Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr.  This issue was found by syzkaller.  Race Condition Diagram:  Thread 1                           Thread 2 --------                           --------  generic_shutdown_super()  shrink_dcache_for_umount   sb->s_root = NULL                      |                     |             vfs_read()                     |              inotify_fdinfo()                     |               * inode get from mark *                     |               show_mark_fhandle(m, inode)                     |                exportfs_encode_fid(inode, ..)                     |                 ovl_encode_fh(inode, ..)                     |                  ovl_check_encode_origin(inode)                     |                   * deref i_sb->s_root *                     |                     |                     v  fsnotify_sb_delete(sb)  Which then leads to:  [   32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [   32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [   32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)  <snip registers, unreliable trace>  [   32.143353] Call Trace: [   32.143732]  ovl_encode_fh+0xd5/0x170 [   32.144031]  exportfs_encode_inode_fh+0x12f/0x300 [   32.144425]  show_mark_fhandle+0xbe/0x1f0 [   32.145805]  inotify_fdinfo+0x226/0x2d0 [   32.146442]  inotify_show_fdinfo+0x1c5/0x350 [   32.147168]  seq_show+0x530/0x6f0 [   32.147449]  seq_read_iter+0x503/0x12a0 [   32.148419]  seq_read+0x31f/0x410 [   32.150714]  vfs_read+0x1f0/0x9e0 [   32.152297]  ksys_read+0x125/0x240  IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path.  Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock.  This form of fix was suggested by Amir in [1].  [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/
CVE-2025-40239: In the Linux kernel, the following vulnerability has been resolved:  net: phy: micrel: always set shared->phydev for LAN8814  Currently, during the LAN8814 PTP probe shared->phydev is only set if PTP clock gets actually set, otherwise the function will return before setting it.  This is an issue as shared->phydev is unconditionally being used when IRQ is being handled, especially in lan8814_gpio_process_cap and since it was not set it will cause a NULL pointer exception and crash the kernel.  So, simply always set shared->phydev to avoid the NULL pointer exception.
CVE-2025-40240: In the Linux kernel, the following vulnerability has been resolved:  sctp: avoid NULL dereference when chunk data buffer is missing  chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only.  chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.
CVE-2025-40241: In the Linux kernel, the following vulnerability has been resolved:  erofs: fix crafted invalid cases for encoded extents  Robert recently reported two corrupted images that can cause system crashes, which are related to the new encoded extents introduced in Linux 6.15:    - The first one [1] has plen != 0 (e.g. plen == 0x2000000) but     (plen & Z_EROFS_EXTENT_PLEN_MASK) == 0. It is used to represent     special extents such as sparse extents (!EROFS_MAP_MAPPED), but     previously only plen == 0 was handled;    - The second one [2] has pa 0xffffffffffdcffed and plen 0xb4000,     then "cur [0xfffffffffffff000] += bvec.bv_len [0x1000]" in     "} while ((cur += bvec.bv_len) < end);" wraps around, causing an     out-of-bound access of pcl->compressed_bvecs[] in     z_erofs_submit_queue().  EROFS only supports 48-bit physical block     addresses (up to 1EiB for 4k blocks), so add a sanity check to     enforce this.
CVE-2025-40246: In the Linux kernel, the following vulnerability has been resolved:  xfs: fix out of bounds memory read error in symlink repair  xfs/286 produced this report on my test fleet:   ==================================================================  BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110   Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184):   memcpy_orig+0x54/0x110   xrep_symlink_salvage_inline+0xb3/0xf0 [xfs]   xrep_symlink_salvage+0x100/0x110 [xfs]   xrep_symlink+0x2e/0x80 [xfs]   xrep_attempt+0x61/0x1f0 [xfs]   xfs_scrub_metadata+0x34f/0x5c0 [xfs]   xfs_ioc_scrubv_metadata+0x387/0x560 [xfs]   xfs_file_ioctl+0xe23/0x10e0 [xfs]   __x64_sys_ioctl+0x76/0xc0   do_syscall_64+0x4e/0x1e0   entry_SYSCALL_64_after_hwframe+0x4b/0x53   kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128   allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago):   xfs_init_local_fork+0x79/0xe0 [xfs]   xfs_iformat_local+0xa4/0x170 [xfs]   xfs_iformat_data_fork+0x148/0x180 [xfs]   xfs_inode_from_disk+0x2cd/0x480 [xfs]   xfs_iget+0x450/0xd60 [xfs]   xfs_bulkstat_one_int+0x6b/0x510 [xfs]   xfs_bulkstat_iwalk+0x1e/0x30 [xfs]   xfs_iwalk_ag_recs+0xdf/0x150 [xfs]   xfs_iwalk_run_callbacks+0xb9/0x190 [xfs]   xfs_iwalk_ag+0x1dc/0x2f0 [xfs]   xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs]   xfs_iwalk+0xa4/0xd0 [xfs]   xfs_bulkstat+0xfa/0x170 [xfs]   xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs]   xfs_file_ioctl+0xbf2/0x10e0 [xfs]   __x64_sys_ioctl+0x76/0xc0   do_syscall_64+0x4e/0x1e0   entry_SYSCALL_64_after_hwframe+0x4b/0x53   CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy)  3d744dd94e92690f00a04398d2bd8631dcef1954  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014  ==================================================================  On further analysis, I realized that the second parameter to min() is not correct.  xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer.  if_bytes can be smaller than the data fork size because:  (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8.  Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long.  In other words, the logic here is wrong and we walk off the end of the incore buffer.  Fix that.
CVE-2025-40247: In the Linux kernel, the following vulnerability has been resolved:  drm/msm: Fix pgtable prealloc error path  The following splat was reported:      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010     Mem abort info:       ESR = 0x0000000096000004       EC = 0x25: DABT (current EL), IL = 32 bits       SET = 0, FnV = 0       EA = 0, S1PTW = 0       FSC = 0x04: level 0 translation fault     Data abort info:       ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000       CM = 0, WnR = 0, TnD = 0, TagAccess = 0       GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0     user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000     [0000000000000010] pgd=0000000000000000, p4d=0000000000000000     Internal error: Oops: 0000000096000004 [#1]  SMP     CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S                  6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT     Tainted: [S]=CPU_OUT_OF_SPEC     Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT)     pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)     pc : build_detached_freelist+0x28/0x224     lr : kmem_cache_free_bulk.part.0+0x38/0x244     sp : ffff000a508c7a20     x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350     x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000     x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000     x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8     x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640     x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30     x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940     x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000     x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8     x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00     Call trace:      build_detached_freelist+0x28/0x224 (P)      kmem_cache_free_bulk.part.0+0x38/0x244      kmem_cache_free_bulk+0x10/0x1c      msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0      msm_vma_job_free+0x30/0x240      msm_ioctl_vm_bind+0x1d0/0x9a0      drm_ioctl_kernel+0x84/0x104      drm_ioctl+0x358/0x4d4      __arm64_sys_ioctl+0x8c/0xe0      invoke_syscall+0x44/0x100      el0_svc_common.constprop.0+0x3c/0xe0      do_el0_svc+0x18/0x20      el0_svc+0x30/0x100      el0t_64_sync_handler+0x104/0x130      el0t_64_sync+0x170/0x174     Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6)     ---[ end trace 0000000000000000 ]---  Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue.  Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call.  So handle that case better.  Patchwork: https://patchwork.freedesktop.org/patch/678677/
CVE-2025-40248: In the Linux kernel, the following vulnerability has been resolved:  vsock: Ignore signal/timeout on connect() if already established  During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues:  1. connect() invoking vsock_transport_cancel_pkt() ->    virtio_transport_purge_skbs() may race with sendmsg() invoking    virtio_transport_get_credit(). This results in a permanently elevated    `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.  2. connect() resetting a connected socket's state may race with socket    being placed in a sockmap. A disconnected socket remaining in a sockmap    breaks sockmap's assumptions. And gives rise to WARNs.  3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a    transport change/drop after TCP_ESTABLISHED. Which poses a problem for    any simultaneous sendmsg() or connect() and may result in a    use-after-free/null-ptr-deref.  Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg().  [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
CVE-2025-40249: In the Linux kernel, the following vulnerability has been resolved:  gpio: cdev: make sure the cdev fd is still active before emitting events  With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier.  Using the regular get_file() routine in this situation triggers the following warning:    struct file::f_count incremented from zero; use-after-free condition present!  So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.
CVE-2025-40252: In the Linux kernel, the following vulnerability has been resolved:  net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()  The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array.  Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-40253: In the Linux kernel, the following vulnerability has been resolved:  s390/ctcm: Fix double-kfree  The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again.  Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.  Bug detected by the clang static analyzer.
CVE-2025-40254: In the Linux kernel, the following vulnerability has been resolved:  net: openvswitch: remove never-working support for setting nsh fields  The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action.  However, the set(nsh(...)) has a very different memory layout.  Nested attributes in there are doubled in size in case of the masked set().  That makes proper validation impossible.  There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask.  This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it:    BUG: kernel NULL pointer dereference, address: 0000000000000018   #PF: supervisor read access in kernel mode   #PF: error_code(0x0000) - not-present page   PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0   Oops: Oops: 0000 [#1] SMP NOPTI   CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary)   RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch]   Call Trace:    <TASK>    validate_nsh+0x60/0x90 [openvswitch]    validate_set.constprop.0+0x270/0x3c0 [openvswitch]    __ovs_nla_copy_actions+0x477/0x860 [openvswitch]    ovs_nla_copy_actions+0x8d/0x100 [openvswitch]    ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch]    genl_family_rcv_msg_doit+0xdb/0x130    genl_family_rcv_msg+0x14b/0x220    genl_rcv_msg+0x47/0xa0    netlink_rcv_skb+0x53/0x100    genl_rcv+0x24/0x40    netlink_unicast+0x280/0x3b0    netlink_sendmsg+0x1f7/0x430    ____sys_sendmsg+0x36b/0x3a0    ___sys_sendmsg+0x87/0xd0    __sys_sendmsg+0x6d/0xd0    do_syscall_64+0x7b/0x2c0    entry_SYSCALL_64_after_hwframe+0x76/0x7e  The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes.  It should be copying each nested attribute and doubling them in size independently.  And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump.  In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash.  And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up.  Fixing all the issues is a complex task as it requires re-writing most of the validation code.  Given that and the fact that this functionality never worked since introduction, let's just remove it altogether.  It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.
CVE-2025-40255: In the Linux kernel, the following vulnerability has been resolved:  net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()  The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as:    tsconfig_prepare_data() ->   dev_get_hwtstamp_phylib() ->   vlan_hwtstamp_get() ->   generic_hwtstamp_get_lower() ->   generic_hwtstamp_ioctl_lower()  results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL.  The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash.  Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.
CVE-2025-40258: In the Linux kernel, the following vulnerability has been resolved:  mptcp: fix race condition in mptcp_schedule_work()  syzbot reported use-after-free in mptcp_schedule_work() [1]  Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker().  [A] if (schedule_work(...)) { [B]     sock_hold(sk);         return true;     }  Problem is that mptcp_worker() can run immediately and complete before [B]  We need instead :      sock_hold(sk);     if (schedule_work(...))         return true;     sock_put(sk);  [1] refcount_t: addition on 0; use-after-free.  WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace:  <TASK>  __refcount_add include/linux/refcount.h:-1 [inline]   __refcount_inc include/linux/refcount.h:366 [inline]   refcount_inc include/linux/refcount.h:383 [inline]   sock_hold include/net/sock.h:816 [inline]   mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943   mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316   call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747   expire_timers kernel/time/timer.c:1798 [inline]   __run_timers kernel/time/timer.c:2372 [inline]   __run_timer_base+0x648/0x970 kernel/time/timer.c:2384   run_timer_base kernel/time/timer.c:2393 [inline]   run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403   handle_softirqs+0x22f/0x710 kernel/softirq.c:622   __do_softirq kernel/softirq.c:656 [inline]   run_ktimerd+0xcf/0x190 kernel/softirq.c:1138   smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160   kthread+0x711/0x8a0 kernel/kthread.c:463   ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
CVE-2025-40260: In the Linux kernel, the following vulnerability has been resolved:  sched_ext: Fix scx_enable() crash on helper kthread creation failure  A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\ while test 15 was running:  NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec  kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer.  Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.
CVE-2025-40262: In the Linux kernel, the following vulnerability has been resolved:  Input: imx_sc_key - fix memory corruption on unload  This is supposed to be "priv" but we accidentally pass "&priv" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called.  Remove the &.
CVE-2025-40263: In the Linux kernel, the following vulnerability has been resolved:  Input: cros_ec_keyb - fix an invalid memory access  If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL.  An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case.    Unable to handle kernel read from unreadable memory at virtual address 0000000000000028   ...   x3 : 0000000000000000 x2 : 0000000000000000   x1 : 0000000000000000 x0 : 0000000000000000   Call trace:   input_event   cros_ec_keyb_work   blocking_notifier_call_chain   ec_irq_thread  It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.
CVE-2025-40264: In the Linux kernel, the following vulnerability has been resolved:  be2net: pass wrb_params in case of OS2BMC  be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states.  The correct way would be to pass the wrb_params from be_xmit().
CVE-2025-40266: In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Check the untrusted offset in FF-A memory share  Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.
CVE-2025-40267: In the Linux kernel, the following vulnerability has been resolved:  io_uring/rw: ensure allocated iovec gets cleared for early failure  A previous commit reused the recyling infrastructure for early cleanup, but this is not enough for the case where our internal caches have overflowed. If this happens, then the allocated iovec can get leaked if the request is also aborted early.  Reinstate the previous forced free of the iovec for that situation.
CVE-2025-40268: In the Linux kernel, the following vulnerability has been resolved:  cifs: client: fix memory leak in smb3_fs_context_parse_param  The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation.  To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing.  syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96):   backtrace (crc 79c9c7ba):     kstrdup+0x3c/0x80 mm/util.c:84     smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444  BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96):   backtrace (crc 79c9c7ba):     smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629     smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438
CVE-2025-40269: In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix potential overflow of PCM transfer buffer  The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically.  The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor.  OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above.  This results in a buffer overflow, as reported by syzbot.  Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor.  So the best option would be just to return an error at the parameter setup time before doing any further operations.  This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize.  The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].