deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-40246
Published: 2025-12-04
Description: 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[PII_REDACTED]92s[PII_REDACTED]86s 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.
References: https://git.kernel.org/stable/c/678e1cc2f482e0985a0613ab4a5bf89c497e5acc; https://git.kernel.org/stable/c/7c2d68e091584149fe89bcbaf9b99b3162d46ee7; https://git.kernel.org/stable/c/81a8685cac4bf081c93a7df591644f4f80240bb9
CVE: CVE-2025-40247
Published: 2025-12-04
Description: 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 [PII_REDACTED]
    Mem abort info:
      ESR = 0x[PII_REDACTED]000004
      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
    [[PII_REDACTED]] pgd=[PII_REDACTED], p4d=[PII_REDACTED]
    Internal error: Oops: [PII_REDACTED] [#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: [PII_REDACTED] x25: 00000000fffffffc x24: [PII_REDACTED]
    x23: ffff00098c4e1450 x22: 00000000fffffffc x21: [PII_REDACTED]
    x20: ffff000a508c7af8 x19: [PII_REDACTED] x18:[PII_REDACTED]0003e8
    x17: ffff[PII_REDACTED]50 x16: ffff[PII_REDACTED]20 x15: [PII_REDACTED]
    x14: ffff[PII_REDACTED]40 x13: [PII_REDACTED] x12: ffff0008b5711e30
    x11:[PII_REDACTED]1058fa x10:[PII_REDACTED]000a80 x9 : ffff000a508c7940
    x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : [PII_REDACTED]
    x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8
    x2 : fffffdffc0000000 x1 : [PII_REDACTED] 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 [PII_REDACTED] ]---

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/
References: https://git.kernel.org/stable/c/830d68f2cb8ab6fb798bb[PII_REDACTED]a9e012af0; https://git.kernel.org/stable/c/b865da18b6cb878f33b5920693d03f23b9c4d1a3
CVE: CVE-2025-40248
Published: 2025-12-04
Description: 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/
References: https://git.kernel.org/stable/c/002541ef650b742a198e4be363881439bb9d86b4; https://git.kernel.org/stable/c/3f71753935d648082a8279a97d30efe6b85be680; https://git.kernel.org/stable/c/5998da5a8208ae9ad7838ba322bccb2bdcd95e81
CVE: CVE-2025-40249
Published: 2025-12-04
Description: 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.
References: https://git.kernel.org/stable/c/d4cd0902c156b2ca60fdda8cd8b5bcb4b0e9ed64; https://git.kernel.org/stable/c/dccc6daa8afa0f64c432e4c867f275747e3415e1
CVE: CVE-2025-40252
Published: 2025-12-04
Description: 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.
References: https://git.kernel.org/stable/c/896f1a2493b59beb2b5ccdf990503dbb16cb2256; https://git.kernel.org/stable/c/917a9d02182ac8b4f25eb47dc02f3ec679608c24; https://git.kernel.org/stable/c/a778912b4a53587ea07d85526d152f85d109cbfe
CVE: CVE-2025-40253
Published: 2025-12-04
Description: 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.
References: https://git.kernel.org/stable/c/06f1dd1de0d33dbfbd2e1fc9fc57d8895f730de2; https://git.kernel.org/stable/c/3b177b2ded563df16f6d5920671ffcfe5915d472; https://git.kernel.org/stable/c/43096dab8cc60fc39133205fd149a54d3acebea8
CVE: CVE-2025-40255
Published: 2025-12-04
Description: 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.
References: https://git.kernel.org/stable/c/8817f816ae41908e9625c0770c4af0dcdcc01238; https://git.kernel.org/stable/c/f796a8dec9beafcc0f6f0d3478ed685a15c5e062
CVE: CVE-2025-40256
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added

In commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), I
missed the case where state creation fails between full
initialization (->init_state has been called) and being inserted on
the lists.

In this situation, ->init_state has been called, so for IPcomp
tunnels, the fallback tunnel has been created and added onto the
lists, but the user state never gets added, because we fail before
that. The user state doesn't go through __xfrm_state_delete, so we
don't call xfrm_state_delete_tunnel for those states, and we end up
leaking the FB tunnel.

There are several codepaths affected by this: the add/update paths, in
both net/key and xfrm, and the migrate code (xfrm_migrate,
xfrm_state_migrate). A "proper" rollback of the init_state work would
probably be doable in the add/update code, but for migrate it gets
more complicated as multiple states may be involved.

At some point, the new (not-inserted) state will be destroyed, so call
xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states
will have their fallback tunnel cleaned up during __xfrm_state_delete,
which solves the issue that b441cf3f8c4b (and other patches before it)
aimed at. All states (including FB tunnels) will be removed from the
lists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).
References: https://git.kernel.org/stable/c/10deb69864840ccf96b00ac2ab3a2055c0c04721; https://git.kernel.org/stable/c/1dad653643f28ccc89be93f9440b8804cded85b2; https://git.kernel.org/stable/c/57b72d74d4651dc19d046308a8304eb9abfe66ac
CVE: CVE-2025-40258
Published: 2025-12-04
Description: 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
References: https://git.kernel.org/stable/c/035bca3f017ee9dea3a5a756e77a6f7138cc6eea; https://git.kernel.org/stable/c/3fc7723ed01d1130d4bf7063c50e0af60ecccbb4; https://git.kernel.org/stable/c/8f9ba1a99a89feef9b5867c15a0141a97e893309
CVE: CVE-2025-40259
Published: 2025-12-04
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: sg: Do not sleep in atomic context

sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may
sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead
of disabled.
References: https://git.kernel.org/stable/c/109afbd88ecc46b6cc[PII_REDACTED]387e97999765; https://git.kernel.org/stable/c/11eeee00c94d770d4e45364060b5f1526dfe567b; https://git.kernel.org/stable/c/3dfd520c3b4ffe69e0630c580717d40447ab842f
CVE: CVE-2025-40260
Published: 2025-12-04
Description: 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 [c[PII_REDACTED]8fa58] scx_enable.constprop.0+0x358/0x12b0
LR [c[PII_REDACTED]8fa2c] 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.
References: https://git.kernel.org/stable/c/625e173e2a59b6cf6cbfb51c0a6bea47f3861eab; https://git.kernel.org/stable/c/7b6216baae751369195fa3c83d434d23bcda406a
CVE: CVE-2025-40262
Published: 2025-12-04
Description: 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 &.
References: https://git.kernel.org/stable/c/3e96803b169dc948847f0fc2bae729a80914eb7b; https://git.kernel.org/stable/c/4ce5218b101205b3425099fe3df88a61b58f9cc2; https://git.kernel.org/stable/c/[PII_REDACTED]5a6e866d31a46f9bcb5e19167cfbaa
CVE: CVE-2025-40263
Published: 2025-12-04
Description: 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 [PII_REDACTED]
  ...
  x3 : [PII_REDACTED] x2 : [PII_REDACTED]
  x1 : [PII_REDACTED] x0 : [PII_REDACTED]
  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.
References: https://git.kernel.org/stable/c/2d251c15c27e2dd16d6318425d2f7260cbd47d39; https://git.kernel.org/stable/c/6d[PII_REDACTED]4535af06163eb585d6d9663ec7ec; https://git.kernel.org/stable/c/9cf59f4724a9ee06ebb06c76b8678ac322e850b7
CVE: CVE-2025-40264
Published: 2025-12-04
Description: 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().
References: https://git.kernel.org/stable/c/012ee5882b1830db469194466a210768ed207388; https://git.kernel.org/stable/c/1ecd86ec6efddb59a10c927e8e679f183bb9113e; https://git.kernel.org/stable/c/48d59b60dd5d7e4c48c077a2008c9dcd7b59bdfe
CVE: CVE-2025-40266
Published: 2025-12-04
Description: 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.
References: https://git.kernel.org/stable/c/103e17aac09cdd358133f9e00998b75d6c1f1518; https://git.kernel.org/stable/c/bc1909ef38788f2ee3d8011d70bf[PII_REDACTED]51; https://git.kernel.org/stable/c/f9f1aed6c8a3427900da3121e[PII_REDACTED]69c3
CVE: CVE-2025-54158
Published: 2025-12-04
Description: Missing authentication for critical function vulnerability in BeeDrive in Synology BeeDrive for desktop before 1.4.2-13960 allows local users to execute arbitrary code via unspecified vectors.
CVSS Score: 7.8 (HIGH)
CWE: CWE-306
References: https://www.synology.com/en-global/security/advisory/Synology_SA_25_08
CVE: CVE-2025-54159
Published: 2025-12-04
Description: Missing authorization vulnerability in BeeDrive in Synology BeeDrive for desktop before 1.4.2-13960 allows remote attackers to delete arbitrary files via unspecified vectors.
CVSS Score: 7.5 (HIGH)
CWE: CWE-862
References: https://www.synology.com/en-global/security/advisory/Synology_SA_25_08
CVE: CVE-2025-54160
Published: 2025-12-04
Description: Improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability in BeeDrive in Synology BeeDrive for desktop before 1.4.2-13960 allows local users to execute arbitrary code via unspecified vectors.
CVSS Score: 7.8 (HIGH)
CWE: CWE-22
References: https://www.synology.com/en-global/security/advisory/Synology_SA_25_08
CVE: CVE-2025-56427
Published: 2025-12-04
Description: Directory Traversal vulnerability in ComposioHQ v.0.7.20 allows a remote attacker to obtain sensitive information via the _download_file_or_dir function.
CVSS Score: 7.5 (HIGH)
CWE: CWE-200
References: https://github.com/ComposioHQ/composio/blob/master/python/composio/server/api.py#L278; https://github.com/TOAST-Research/pocs/blob/main/composio/composio_1.md; https://github.com/TOAST-Research/pocs/blob/main/composio/composio_1.md
CVE: CVE-2025-57210
Published: 2025-12-04
Description: Incorrect access control in the component ApiPayController.java of platform v1.0.0 allows attackers to access sensitive information via unspecified vectors.
CVSS Score: 7.5 (HIGH)
CWE: CWE-284
References: https://gist.github.com/xueye0629/[PII_REDACTED]fa3bbba628d3044dc50451; https://gitee.com/fuyang_lipengjun/platform
CVE: CVE-2025-57212
Published: 2025-12-04
Description: Incorrect access control in the component ApiOrderService.java of platform v1.0.0 allows attackers to access sensitive information via a crafted request.
CVSS Score: 7.5 (HIGH)
CWE: CWE-284
References: https://gist.github.com/xueye0629/85730f2317cfac2796fe5e23da3ae399; https://gitee.com/fuyang_lipengjun/platform
CVE: CVE-2025-57213
Published: 2025-12-04
Description: Incorrect access control in the component orderService.queryObject of platform v1.0.0 allows attackers to access sensitive information via a crafted request.
CVSS Score: 7.5 (HIGH)
CWE: CWE-284
References: https://gist.github.com/xueye0629/620e4e0cc0f23c903736971e6375f00e; https://gitee.com/fuyang_lipengjun/platform
CVE: CVE-2025-61148
Published: 2025-12-04
Description: An Insecure Direct Object Reference (IDOR) vulnerability in the EduplusCampus 3.0.1 Student Payment API allows authenticated users to access other students personal and financial records by modifying the 'rec_no' parameter in the /student/get-receipt endpoint.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-639
References: https://drive.google.com/file/d/1BRZRurbl7TY6KU4uaelAUn7L9Cn6XfjC/view?usp=sharing; https://github.com/sharma19d/CVE-2025-61148; https://medium.com/@Charon19d/how-i-hacked-all-universities-in-my-city-d6b8e320455c
CVE: CVE-2025-63681
Published: 2025-12-04
Description: open-webui v0.6.33 is vulnerable to Incorrect Access Control. The API /api/tasks/stop/ directly accesses and cancels tasks without verifying user ownership, enabling attackers (a normal user) to stop arbitrary LLM response tasks.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-284
References: https://github.com/TOAST-Research/pocs/blob/main/openwebui/arbitirary_task_stop/report.md; https://github.com/open-webui/open-webui/blob/46ae3f4f5d7d4d706041bdae4ad2d802e568712b/backend/open_webui/main.py#L1652; https://github.com/TOAST-Research/pocs/blob/main/openwebui/arbitirary_task_stop/report.md