deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-10255
Published: 2025-09-11
Description: A vulnerability was determined in Ascensio System SIA OnlyOffice up to 12.7.0. Impacted is an unknown function of the file /Products/Projects/Messages.aspx of the component Comment Handler. Executing manipulation can lead to cross site scripting. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was informed early about this issue and replied: "We are already working on this case, and the issues will be resolved in one of the upcoming patches."
CVSS Score: 3.5 (LOW)
CWE: CWE-79, CWE-94
References: https://hkohi.ca/vulnerability/21; https://vuldb.com/?ctiid.323615; https://vuldb.com/?id.323615
CVE: CVE-2025-26499
Published: 2025-09-11
Description: Under heavy system utilization a random race condition can occur during authentication or token refresh operation. This flaw allows one user to be granted a token intended for another user, resulting in impersonation until the session is ended. This flaw cannot be intentionally exploited due to the required concurring action by two users. However, if the event occurs a user would be inadvertently exposed to another user’s system rights and data access.
CVSS Score: 6.0 (MEDIUM)
CWE: CWE-270
References: https://support2.windriver.com/index.php?page=cve&on=view&id=CVE-2025-26499; https://www.windriver.com/security/vulnerability-responses/CVE-2025-26499
CVE: CVE-2025-39736
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock

When netpoll is enabled, calling pr_warn_once() while holding
kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock
inversion with the netconsole subsystem.  This occurs because
pr_warn_once() may trigger netpoll, which eventually leads to
__alloc_skb() and back into kmemleak code, attempting to reacquire
kmemleak_lock.

This is the path for the deadlock.

mem_pool_alloc()
  -> raw_spin_lock_irqsave(&kmemleak_lock, flags);
      -> pr_warn_once()
          -> netconsole subsystem
	     -> netpoll
	         -> __alloc_skb
		   -> __create_object
		     -> raw_spin_lock_irqsave(&kmemleak_lock, flags);

Fix this by setting a flag and issuing the pr_warn_once() after
kmemleak_lock is released.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/08f70be5e406ce47c822f2dd11c1170ca259605b; https://git.kernel.org/stable/c/1da95d3d4b7b1d380ebd87b71a61e7e6aed3265d; https://git.kernel.org/stable/c/47b0f6d8f0d2be4d311a49e13d2fd5f152f492b2
CVE: CVE-2025-39737
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()

A soft lockup warning was observed on a relative small system x86-64
system with 16 GB of memory when running a debug kernel with kmemleak
enabled.

  watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]

The test system was running a workload with hot unplug happening in
parallel.  Then kemleak decided to disable itself due to its inability to
allocate more kmemleak objects.  The debug kernel has its
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.

The soft lockup happened in kmemleak_do_cleanup() when the existing
kmemleak objects were being removed and deleted one-by-one in a loop via a
workqueue.  In this particular case, there are at least 40,000 objects
that need to be processed and given the slowness of a debug kernel and the
fact that a raw_spinlock has to be acquired and released in
__delete_object(), it could take a while to properly handle all these
objects.

As kmemleak has been disabled in this case, the object removal and
deletion process can be further optimized as locking isn't really needed. 
However, it is probably not worth the effort to optimize for such an edge
case that should rarely happen.  So the simple solution is to call
cond_resched() at periodic interval in the iteration loop to avoid soft
lockup.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1ef72a7fedc5bca70e8cc980985790de10d407aa; https://git.kernel.org/stable/c/8d2d22a55ffe35c38e69795468a7addd1a80e9ce; https://git.kernel.org/stable/c/926092268efdf1ed7b55cf486356c74a9e7710d1
CVE: CVE-2025-39740
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/migrate: prevent potential UAF

If we hit the error path, the previous fence (if there is one) has
already been put() prior to this, so doing a fence_wait could lead to
UAF. Tweak the flow to do to the put() until after we do the wait.

(cherry picked from commit 9b7ca35ed28fe5fad86e9d9c24ebd1271e4c9c3e)
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/145832fbdd17b1d77ffd6cdd1642259e101d1b7e; https://git.kernel.org/stable/c/7e46fa64a4b94208563c3a5bf1d7f4346f94abea
CVE: CVE-2025-39741
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/migrate: don't overflow max copy size

With non-page aligned copy, we need to use 4 byte aligned pitch, however
the size itself might still be close to our maximum of ~8M, and so the
dimensions of the copy can easily exceed the S16_MAX limit of the copy
command leading to the following assert:

xe 0000:03:00.0: [drm] Assertion `size / pitch <= ((s16)(((u16)~0U) >> 1))` failed!
platform: BATTLEMAGE subplatform: 1
graphics: Xe2_HPG 20.01 step A0
media: Xe2_HPM 13.01 step A1
tile: 0 VRAM 10.0 GiB
GT: 0 type 1

WARNING: CPU: 23 PID: 10605 at drivers/gpu/drm/xe/xe_migrate.c:673 emit_copy+0x4b5/0x4e0 [xe]

To fix this account for the pitch when calculating the number of current
bytes to copy.

(cherry picked from commit 8c2d61e0e916e077fda7e7b8e67f25ffe0f361fc)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4126cb327a2e3273c81fcef1c594c5b7b645c44c; https://git.kernel.org/stable/c/7257cc6644d540130a46a61531a07a0517cace89
CVE: CVE-2025-39742
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()

The function divides number of online CPUs by num_core_siblings, and
later checks the divider by zero. This implies a possibility to get
and divide-by-zero runtime error. Fix it by moving the check prior to
division. This also helps to save one indentation level.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/1a7cf828ed861de5be1aff99e10f114b363c19d3; https://git.kernel.org/stable/c/31d0599a23efdbfe579bfbd1eb8f8c942f13744d; https://git.kernel.org/stable/c/4b4317b0d758ff92ba96f4e448a8992a6fe607bf
CVE: CVE-2025-39743
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: truncate good inode pages when hard link is 0

The fileset value of the inode copy from the disk by the reproducer is
AGGR_RESERVED_I. When executing evict, its hard link number is 0, so its
inode pages are not truncated. This causes the bugon to be triggered when
executing clear_inode() because nrpages is greater than 0.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/1bb5cdc3e39f0c2b311fcb631258b7e60d3fb0d3; https://git.kernel.org/stable/c/2b1d5ca395a5fb170c3f885cd42c16179f7f54ec; https://git.kernel.org/stable/c/2d91b3765cd05016335cd5df5e5c6a29708ec058
CVE: CVE-2025-39744
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

rcu: Fix rcu_read_unlock() deadloop due to IRQ work

During rcu_read_unlock_special(), if this happens during irq_exit(), we
can lockup if an IPI is issued. This is because the IPI itself triggers
the irq_exit() path causing a recursive lock up.

This is precisely what Xiongfeng found when invoking a BPF program on
the trace_tick_stop() tracepoint As shown in the trace below. Fix by
managing the irq_work state correctly.

irq_exit()
  __irq_exit_rcu()
    /* in_hardirq() returns false after this */
    preempt_count_sub(HARDIRQ_OFFSET)
    tick_irq_exit()
      tick_nohz_irq_exit()
	    tick_nohz_stop_sched_tick()
	      trace_tick_stop()  /* a bpf prog is hooked on this trace point */
		   __bpf_trace_tick_stop()
		      bpf_trace_run2()
			    rcu_read_unlock_special()
                              /* will send a IPI to itself */
			      irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);

A simple reproducer can also be obtained by doing the following in
tick_irq_exit(). It will hang on boot without the patch:

  static inline void tick_irq_exit(void)
  {
 +	rcu_read_lock();
 +	WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true);
 +	rcu_read_unlock();
 +

[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1cfa244f7198d325594e627574930b7b91df5bfe; https://git.kernel.org/stable/c/56c5ef194f4509df63fc0f7a91ea5973ce479b1e; https://git.kernel.org/stable/c/b41642c87716bbd09797b1e4ea7d904f06c39b7b
CVE: CVE-2025-39745
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

rcutorture: Fix rcutorture_one_extend_check() splat in RT kernels

For built with CONFIG_PREEMPT_RT=y kernels, running rcutorture
tests resulted in the following splat:

[   68.797425] rcutorture_one_extend_check during change: Current 0x1  To add 0x1  To remove 0x0  preempt_count() 0x0
[   68.797533] WARNING: CPU: 2 PID: 512 at kernel/rcu/rcutorture.c:1993 rcutorture_one_extend_check+0x419/0x560 [rcutorture]
[   68.797601] Call Trace:
[   68.797602]  <TASK>
[   68.797619]  ? lockdep_softirqs_off+0xa5/0x160
[   68.797631]  rcutorture_one_extend+0x18e/0xcc0 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]
[   68.797646]  ? local_clock+0x19/0x40
[   68.797659]  rcu_torture_one_read+0xf0/0x280 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]
[   68.797678]  ? __pfx_rcu_torture_one_read+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]
[   68.797804]  ? __pfx_rcu_torture_timer+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]
[   68.797815] rcu-torture: rcu_torture_reader task started
[   68.797824] rcu-torture: Creating rcu_torture_reader task
[   68.797824]  rcu_torture_reader+0x238/0x580 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]
[   68.797836]  ? kvm_sched_clock_read+0x15/0x30

Disable BH does not change the SOFTIRQ corresponding bits in
preempt_count() for RT kernels, this commit therefore use
softirq_count() to check the if BH is disabled.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/69c5ae0f441c2d72e8f48dc1e08464c172360c4c; https://git.kernel.org/stable/c/8d71351d88e478d3c4e945e3218e97ec677fd807; https://git.kernel.org/stable/c/a[PII_REDACTED]7cdf5e7499be00ea8e388ab014e50
CVE: CVE-2025-39746
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: shutdown driver when hardware is unreliable

In rare cases, ath10k may lose connection with the PCIe bus due to
some unknown reasons, which could further lead to system crashes during
resuming due to watchdog timeout:

ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware
ath10k_pci 0000:01:00.0: already restarting
ath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11
ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11
ieee80211 phy0: PM: **** DPM device timeout ****
Call Trace:
 panic+0x125/0x315
 dpm_watchdog_set+0x54/0x54
 dpm_watchdog_handler+0x57/0x57
 call_timer_fn+0x31/0x13c

At this point, all WMI commands will timeout and attempt to restart
device. So set a threshold for consecutive restart failures. If the
threshold is exceeded, consider the hardware is unreliable and all
ath10k operations should be skipped to avoid system crash.

fail_cont_count and pending_recovery are atomic variables, and
do not involve complex conditional logic. Therefore, even if recovery
check and reconfig complete are executed concurrently, the recovery
mechanism will not be broken.

Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/201c9b4485edc618863a60f97a2d88bddd139467; https://git.kernel.org/stable/c/84ca5632b8d05d1c2e25604d1d63434b2fb61c85; https://git.kernel.org/stable/c/c256a94d1b1b[PII_REDACTED]f7f2a7c2173e12072
CVE: CVE-2025-39747
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Add error handling for krealloc in metadata setup

Function msm_ioctl_gem_info_set_metadata() now checks for krealloc
failure and returns -ENOMEM, avoiding potential NULL pointer dereference.
Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints.

Patchwork: https://patchwork.freedesktop.org/patch/661235/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/01e3eda8edc3c4caaa49261d1a56c799b0bd6268; https://git.kernel.org/stable/c/1c8c354098ea9d4376a58c96ae6b65288a6f15d8; https://git.kernel.org/stable/c/53dc780c1e94ea782d8936b41bfaa83c663702eb
CVE: CVE-2025-39748
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Forget ranges when refining tnum after JSET

Syzbot reported a kernel warning due to a range invariant violation on
the following BPF program.

  0: call bpf_get_netns_cookie
  1: if r0 == 0 goto <exit>
  2: if r0 & Oxffffffff goto <exit>

The issue is on the path where we fall through both jumps.

That path is unreachable at runtime: after insn 1, we know r0 != 0, but
with the sign extension on the jset, we would only fallthrough insn 2
if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to
figure this out, so the verifier walks all branches. The verifier then
refines the register bounds using the second condition and we end
up with inconsistent bounds on this unreachable path:

  1: if r0 == 0 goto <exit>
    r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff)
  2: if r0 & 0xffffffff goto <exit>
    r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0)
    r0 after reg_bounds_sync:  u64=[0x1, 0] var_off=(0, 0)

Improving the range refinement for JSET to cover all cases is tricky. We
also don't expect many users to rely on JSET given LLVM doesn't generate
those instructions. So instead of improving the range refinement for
JSETs, Eduard suggested we forget the ranges whenever we're narrowing
tnums after a JSET. This patch implements that approach.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0643aa2468192a4d81326e8e[PII_REDACTED]0b1ee2; https://git.kernel.org/stable/c/22191359f8454b0be082c3b126f86bcbea0f1318; https://git.kernel.org/stable/c/2fd0c26bacd90ef26522bd3169000a4715bf151f
CVE: CVE-2025-39749
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

rcu: Protect ->defer_qs_iw_pending from data race

On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is
invoked within an interrupts-disabled region of code [1], it will invoke
rcu_read_unlock_special(), which uses an irq-work handler to force the
system to notice when the RCU read-side critical section actually ends.
That end won't happen until interrupts are enabled at the soonest.

In some kernels, such as those booted with rcutree.use_softirq=y, the
irq-work handler is used unconditionally.

The per-CPU rcu_data structure's ->defer_qs_iw_pending field is
updated by the irq-work handler and is both read and updated by
rcu_read_unlock_special().  This resulted in the following KCSAN splat:

------------------------------------------------------------------------

BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special

read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:
 rcu_read_unlock_special+0x175/0x260
 __rcu_read_unlock+0x92/0xa0
 rt_spin_unlock+0x9b/0xc0
 __local_bh_enable+0x10d/0x170
 __local_bh_enable_ip+0xfb/0x150
 rcu_do_batch+0x595/0xc40
 rcu_cpu_kthread+0x4e9/0x830
 smpboot_thread_fn+0x24d/0x3b0
 kthread+0x3bd/0x410
 ret_from_fork+0x35/0x40
 ret_from_fork_asm+0x1a/0x30

write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:
 rcu_preempt_deferred_qs_handler+0x1e/0x30
 irq_work_single+0xaf/0x160
 run_irq_workd+0x91/0xc0
 smpboot_thread_fn+0x24d/0x3b0
 kthread+0x3bd/0x410
 ret_from_fork+0x35/0x40
 ret_from_fork_asm+0x1a/0x30

no locks held by irq_work/8/88.
irq event stamp: 200272
hardirqs last  enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320
hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70
softirqs last  enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0
softirqs last disabled at (0): [<[PII_REDACTED]>] 0x0

------------------------------------------------------------------------

The problem is that irq-work handlers run with interrupts enabled, which
means that rcu_preempt_deferred_qs_handler() could be interrupted,
and that interrupt handler might contain an RCU read-side critical
section, which might invoke rcu_read_unlock_special().  In the strict
KCSAN mode of operation used by RCU, this constitutes a data race on
the ->defer_qs_iw_pending field.

This commit therefore disables interrupts across the portion of the
rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending
field.  This suffices because this handler is not a fast path.
CVSS Score: 7.0 (HIGH)
References: https://git.kernel.org/stable/c/0ad84d62217488e679ecc90e8628980dcc003de3; https://git.kernel.org/stable/c/55e11f6776798b27cf09a7aa0d718415d4fc9cf5; https://git.kernel.org/stable/c/74f58f382a7c8333f8d09701aefaa25913bdbe0e
CVE: CVE-2025-39750
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Correct tid cleanup when tid setup fails

Currently, if any error occurs during ath12k_dp_rx_peer_tid_setup(),
the tid value is already incremented, even though the corresponding
TID is not actually allocated. Proceed to
ath12k_dp_rx_peer_tid_delete() starting from unallocated tid,
which might leads to freeing unallocated TID and cause potential
crash or out-of-bounds access.

Hence, fix by correctly decrementing tid before cleanup to match only
the successfully allocated TIDs.

Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(),
as decrementing the tid before cleanup in loop will take care of this.

Compile tested only.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/2ef17d1476ab26bce89764e2f16833d7f52acc38; https://git.kernel.org/stable/c/30cad[PII_REDACTED]6c93467516bc481a3eacfd66a; https://git.kernel.org/stable/c/4a2bf707270f897ab8077baee8ed5842a5321686
CVE: CVE-2025-39751
Published: 2025-09-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-39752
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

ARM: rockchip: fix kernel hang during smp initialization

In order to bring up secondary CPUs main CPU write trampoline
code to SRAM. The trampoline code is written while secondary
CPUs are powered on (at least that true for RK3188 CPU).
Sometimes that leads to kernel hang. Probably because secondary
CPU execute trampoline code while kernel doesn't expect.

The patch moves SRAM initialization step to the point where all
secondary CPUs are powered down.

That fixes rarely hangs on RK3188:
[    0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.091996] rockchip_smp_prepare_cpus: ncores 4
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0223a3683d502b7e5eb2eb4ad7e97363fa88d531; https://git.kernel.org/stable/c/1eb67589a7e091b1e5108aab72fddbf4dc69af2c; https://git.kernel.org/stable/c/265583266d93db4ff83d088819b1f63fdf0131db
CVE: CVE-2025-39753
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: Set .migrate_folio in gfs2_{rgrp,meta}_aops

Clears up the warning added in 7ee3647243e5 ("migrate: Remove call to
->writepage") that occurs in various xfstests, causing "something found
in dmesg" failures.

[  341.136573] gfs2_meta_aops does not implement migrate_folio
[  341.136953] WARNING: CPU: 1 PID: 36 at mm/migrate.c:944 move_to_new_folio+0x2f8/0x300
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5c8f12cf1e64e0e8e6cb80b0c935389973e8be8d; https://git.kernel.org/stable/c/9d9b053f7f9c5a35049abe56af9e6ac70b6b0e4b; https://git.kernel.org/stable/c/9f745095c382b76e68407fd6f15ef27baf2a013f
CVE: CVE-2025-39754
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/smaps: fix race between smaps_hugetlb_range and migration

smaps_hugetlb_range() handles the pte without holdling ptl, and may be
concurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). 
The race is as follows.

smaps_hugetlb_range              migrate_pages
  huge_ptep_get
                                   remove_migration_ptes
				   folio_unlock
  pfn_swap_entry_folio
    BUG_ON

To fix it, hold ptl lock in smaps_hugetlb_range().
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/09fc018f48871123ad5dbd7b03c956580232ed76; https://git.kernel.org/stable/c/2a1f[PII_REDACTED]b8f1e098196f557cfc1d160138; https://git.kernel.org/stable/c/45d19b4b6c2d422771c29b83462d84afcbb33f01