deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-39902
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/slub: avoid accessing metadata when pointer is invalid in object_err()

object_err() reports details of an object for further debugging, such as
the freelist pointer, redzone, etc. However, if the pointer is invalid,
attempting to access object metadata can lead to a crash since it does
not point to a valid object.

One known path to the crash is when alloc_consistency_checks()
determines the pointer to the allocated object is invalid because of a
freelist corruption, and calls object_err() to report it. The debug code
should report and handle the corruption gracefully and not crash in the
process.

In case the pointer is NULL or check_valid_pointer() returns false for
the pointer, only print the pointer value and skip accessing metadata.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ef7058b4dc6fcef622ac23b45225db57f17b83f; https://git.kernel.org/stable/c/1f0797f17927b5cad0fb7eced422f9a7c30a3191; https://git.kernel.org/stable/c/3baa1da473e6e50281324ff1d332d1a07a3bb02e
CVE: CVE-2025-39904
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: kexec: initialize kexec_buf struct in load_other_segments()

Patch series "kexec: Fix invalid field access".

The kexec_buf structure was previously declared without initialization. 
commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")
added a field that is always read but not consistently populated by all
architectures.  This un-initialized field will contain garbage.

This is also triggering a UBSAN warning when the uninitialized data was
accessed:

	------------[ cut here ]------------
	UBSAN: invalid-load in ./include/linux/kexec.h:210:10
	load of value 252 is not a valid value for type '_Bool'

Zero-initializing kexec_buf at declaration ensures all fields are cleanly
set, preventing future instances of uninitialized memory being used.

An initial fix was already landed for arm64[0], and this patchset fixes
the problem on the remaining arm64 code and on riscv, as raised by Mark.

Discussions about this problem could be found at[1][2].


This patch (of 3):

The kexec_buf structure was previously declared without initialization.
commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")
added a field that is always read but not consistently populated by all
architectures. This un-initialized field will contain garbage.

This is also triggering a UBSAN warning when the uninitialized data was
accessed:

	------------[ cut here ]------------
	UBSAN: invalid-load in ./include/linux/kexec.h:210:10
	load of value 252 is not a valid value for type '_Bool'

Zero-initializing kexec_buf at declaration ensures all fields are
cleanly set, preventing future instances of uninitialized memory being
used.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/04d3cd43700a2d0fe4bfb1012a8ec7f2e34a3507; https://git.kernel.org/stable/c/340cc9a3bd30b25edaf6a9708d41b5f2c10a054a
CVE: CVE-2025-39905
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phylink: add lock for serializing concurrent pl->phydev writes with resolver

Currently phylink_resolve() protects itself against concurrent
phylink_bringup_phy() or phylink_disconnect_phy() calls which modify
pl->phydev by relying on pl->state_mutex.

The problem is that in phylink_resolve(), pl->state_mutex is in a lock
inversion state with pl->phydev->lock. So pl->phydev->lock needs to be
acquired prior to pl->state_mutex. But that requires dereferencing
pl->phydev in the first place, and without pl->state_mutex, that is
racy.

Hence the reason for the extra lock. Currently it is redundant, but it
will serve a functional purpose once mutex_lock(&phy->lock) will be
moved outside of the mutex_lock(&pl->state_mutex) section.

Another alternative considered would have been to let phylink_resolve()
acquire the rtnl_mutex, which is also held when phylink_bringup_phy()
and phylink_disconnect_phy() are called. But since phylink_disconnect_phy()
runs under rtnl_lock(), it would deadlock with phylink_resolve() when
calling flush_work(&pl->resolve). Additionally, it would have been
undesirable because it would have unnecessarily blocked many other call
paths as well in the entire kernel, so the smaller-scoped lock was
preferred.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3; https://git.kernel.org/stable/c/56fe63b05ec84ae6674269d78397cec43a7a295a
CVE: CVE-2025-39906
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: remove oem i2c adapter on finish

Fixes a bug where unbinding of the GPU would leave the oem i2c adapter
registered resulting in a null pointer dereference when applications try
to access the invalid device.

(cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1dfd2864a1c[PII_REDACTED]e5a27c055f50f7c2796; https://git.kernel.org/stable/c/c686124bcf[PII_REDACTED]0857ff462f00f3f7a4ab
CVE: CVE-2025-39907
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer

Avoid below overlapping mappings by using a contiguous
non-cacheable buffer.

[    4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,
overlapping mappings aren't supported
[    4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300
[    4.097071] Modules linked in:
[    4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1
[    4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)
[    4.118824] Workqueue: events_unbound deferred_probe_work_func
[    4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    4.131624] pc : add_dma_entry+0x23c/0x300
[    4.135658] lr : add_dma_entry+0x23c/0x300
[    4.139792] sp : ffff800009dbb490
[    4.143016] x29: ffff800009dbb4a0 x28: [PII_REDACTED] x27: ffff8000098a6000
[    4.150174] x26: [PII_REDACTED] x25: ffff8000099e7000 x24: ffff8000099e7de8
[    4.157231] x23: 00000000ffffffff x22: [PII_REDACTED] x21: ffff8000098a6a20
[    4.164388] x20: ffff[PII_REDACTED]80 x19: ffff800009819ba0 x18: [PII_REDACTED]
[    4.171545] x17:[PII_REDACTED]656e69 x16: 6c[PII_REDACTED]203a x15: 72656c6c6f72746e
[    4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12:[PII_REDACTED]0004ec
[    4.185759] x11:[PII_REDACTED]0001a4 x10: ffff80000988af58 x9 : ffff800009832f58
[    4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000
[    4.199972] x5 :[PII_REDACTED]00bff4 x4 : [PII_REDACTED] x3 : [PII_REDACTED]
[    4.207128] x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffff0000812d2c40
[    4.214185] Call trace:
[    4.216605]  add_dma_entry+0x23c/0x300
[    4.220338]  debug_dma_map_sg+0x198/0x350
[    4.224373]  __dma_map_sg_attrs+0xa0/0x110
[    4.228411]  dma_map_sg_attrs+0x10/0x2c
[    4.232247]  stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc
[    4.237088]  stm32_fmc2_nfc_seq_read_page+0xc8/0x174
[    4.242127]  nand_read_oob+0x1d4/0x8e0
[    4.245861]  mtd_read_oob_std+0x58/0x84
[    4.249596]  mtd_read_oob+0x90/0x150
[    4.253231]  mtd_read+0x68/0xac
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/06d8ef8f853752fea88c8d5bb093a40e71b330cf; https://git.kernel.org/stable/c/26adba1e7d7924174e15a3ba4b[PII_REDACTED]00b; https://git.kernel.org/stable/c/513c40e59d5a414ab763a9c84797534b5e8c208d
CVE: CVE-2025-39908
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dev_ioctl: take ops lock in hwtstamp lower paths

ndo hwtstamp callbacks are expected to run under the per-device ops
lock. Make the lower get/set paths consistent with the rest of ndo
invocations.

Kernel log:
WARNING: CPU: 13 PID: 51364 at ./include/net/netdev_lock.h:70 __netdev_update_features+0x4bd/0xe60
...
RIP: 0010:__netdev_update_features+0x4bd/0xe60
...
Call Trace:
<TASK>
netdev_update_features+0x1f/0x60
mlx5_hwtstamp_set+0x181/0x290 [mlx5_core]
mlx5e_hwtstamp_set+0x19/0x30 [mlx5_core]
dev_set_hwtstamp_phylib+0x9f/0x220
dev_set_hwtstamp_phylib+0x9f/0x220
dev_set_hwtstamp+0x13d/0x240
dev_ioctl+0x12f/0x4b0
sock_ioctl+0x171/0x370
__x64_sys_ioctl+0x3f7/0x900
? __sys_setsockopt+0x69/0xb0
do_syscall_64+0x6f/0x2e0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
...
</TASK>
....
---[ end trace [PII_REDACTED] ]---

Note that the mlx5_hwtstamp_set and mlx5e_hwtstamp_set functions shown
in the trace come from an in progress patch converting the legacy ioctl
to ndo_hwtstamp_get/set and are not present in mainline.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2d92fa0cdc02291de57f72170e8b60cef0cf5372; https://git.kernel.org/stable/c/686cab5a18e443e1d5f2abb17bed[PII_REDACTED]5f
CVE: CVE-2025-39909
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()

Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters
application".

DAMON's RECLAIM and LRU_SORT modules perform no validation on
user-configured parameters during application, which may lead to
division-by-zero errors.

Avoid the divide-by-zero by adding validation checks when DAMON modules
attempt to apply the parameters.


This patch (of 2):

During the calculation of 'hot_thres' and 'cold_thres', either
'sample_interval' or 'aggr_interval' is used as the divisor, which may
lead to division-by-zero errors.  Fix it by directly returning -EINVAL
when such a case occurs.  Additionally, since 'aggr_interval' is already
required to be set no smaller than 'sample_interval' in damon_set_attrs(),
only the case where 'sample_interval' is zero needs to be checked.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/326a4b3750c71af3f3c52399ec4dbe33b6da4c26; https://git.kernel.org/stable/c/711f19dfd783ffb37ca4324388b9c4cb87e71363; https://git.kernel.org/stable/c/74e391f7da7d9d5235a3cca88ee9fc18f720c75b
CVE: CVE-2025-39910
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()

kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask and
always allocate memory using the hardcoded GFP_KERNEL flag.  This makes
them inconsistent with vmalloc(), which was recently extended to support
GFP_NOFS and GFP_NOIO allocations.

Page table allocations performed during shadow population also ignore the
external gfp_mask.  To preserve the intended semantics of GFP_NOFS and
GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate
memalloc scope.

xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.

There was a report here
https://lkml.kernel.org/r/686ea951.050a0220[PII_REDACTED].GAE@google.com

This patch:
 - Extends kasan_populate_vmalloc() and helpers to take gfp_mask;
 - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page();
 - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore()
   around apply_to_page_range();
 - Updates vmalloc.c and percpu allocator call sites accordingly.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/33b95d90427cb4babf32059e323a6d0c027610fe; https://git.kernel.org/stable/c/79357cd06d41d0f5a11b17d7c86176e395d10ef2
CVE: CVE-2025-39911
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path

If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration
later than the first, the error path wants to free the IRQs requested
so far. However, it uses the wrong dev_id argument for free_irq(), so
it does not free the IRQs correctly and instead triggers the warning:

 Trying to free already-free IRQ 173
 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0
 Modules linked in: i40e(+) [...]
 CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
 Hardware name: [...]
 RIP: 0010:__free_irq+0x192/0x2c0
 [...]
 Call Trace:
  <TASK>
  free_irq+0x32/0x70
  i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]
  i40e_vsi_request_irq+0x79/0x80 [i40e]
  i40e_vsi_open+0x21f/0x2f0 [i40e]
  i40e_open+0x63/0x130 [i40e]
  __dev_open+0xfc/0x210
  __dev_change_flags+0x1fc/0x240
  netif_change_flags+0x27/0x70
  do_setlink.isra.0+0x341/0xc70
  rtnl_newlink+0x468/0x860
  rtnetlink_rcv_msg+0x375/0x450
  netlink_rcv_skb+0x5c/0x110
  netlink_unicast+0x288/0x3c0
  netlink_sendmsg+0x20d/0x430
  ____sys_sendmsg+0x3a2/0x3d0
  ___sys_sendmsg+0x99/0xe0
  __sys_sendmsg+0x8a/0xf0
  do_syscall_64+0x82/0x2c0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
  [...]
  </TASK>
 ---[ end trace [PII_REDACTED] ]---

Use the same dev_id for free_irq() as for request_irq().

I tested this with inserting code to fail intentionally.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/13ab9adef3cd386511c930a9660ae06595007f89; https://git.kernel.org/stable/c/23431998a37764c464737b855c71a81d50992e98; https://git.kernel.org/stable/c/6e4016c0dca53afc71e3b99e24252b63417395df
CVE: CVE-2025-39912
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nfs/localio: restore creds before releasing pageio data

Otherwise if the nfsd filecache code releases the nfsd_file
immediately, it can trigger the BUG_ON(cred == current->cred) in
__put_cred() when it puts the nfsd_file->nf_file->f-cred.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/57c1bb02b4fc8eec6eb01736e7fad26dffacf18c; https://git.kernel.org/stable/c/992203a1fba51b025c60ec0c8b0d9223343dea95; https://git.kernel.org/stable/c/c250be1d75bf80dc5ab46f0b434b746c1868a1ea
CVE: CVE-2025-39913
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.

syzbot reported the splat below. [0]

The repro does the following:

  1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
  2. Attach the prog to a SOCKMAP
  3. Add a socket to the SOCKMAP
  4. Activate fault injection
  5. Send data less than cork_bytes

At 5., the data is carried over to the next sendmsg() as it is
smaller than the cork_bytes specified by bpf_msg_cork_bytes().

Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold
the data, but this fails silently due to fault injection + __GFP_NOWARN.

If the allocation fails, we need to revert the sk->sk_forward_alloc
change done by sk_msg_alloc().

Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate
psock->cork.

The "*copied" also needs to be updated such that a proper error can
be returned to the caller, sendmsg. It fails to allocate psock->cork.
Nothing has been corked so far, so this patch simply sets "*copied"
to 0.

[0]:
WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983
Modules linked in:
CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156
Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc
RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246
RAX: ffffffff8a09d0b2 RBX: dffffc[PII_REDACTED] RCX: ffff888024a23c80
RDX: [PII_REDACTED] RSI:[PII_REDACTED]000fff RDI: [PII_REDACTED]
RBP:[PII_REDACTED]000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4
R10: dffffc[PII_REDACTED] R11: ffffed100fc0f8c5 R12: ffff88807e07c380
R13: dffffc[PII_REDACTED] R14: ffff88807e07c60c R15: 1ffff1100fc0f872
FS: [PII_REDACTED]4c4500(0000) GS:ffff888125af1000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2:[PII_REDACTED]4df5c8 CR3:[PII_REDACTED]b06000 CR4:[PII_REDACTED]3526f0
Call Trace:
 <IRQ>
 __sk_destruct+0x86/0x660 net/core/sock.c:2339
 rcu_do_batch kernel/rcu/tree.c:2605 [inline]
 rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861
 handle_softirqs+0x286/0x870 kernel/softirq.c:579
 __do_softirq kernel/softirq.c:613 [inline]
 invoke_softirq kernel/softirq.c:453 [inline]
 __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052
 </IRQ>
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/05366527f44cf4b884f3d9462ae8009be9665856; https://git.kernel.org/stable/c/08f58d10f5abf11d297cc[PII_REDACTED]98c921f91; https://git.kernel.org/stable/c/539920180c55f5e13a2488a2339f94e6b8cb69e0
CVE: CVE-2025-39914
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Silence warning when chunk allocation fails in trace_pid_write

Syzkaller trigger a fault injection warning:

WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0
Modules linked in:
CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0
Tainted: [U]=USER
Hardware name: Google Compute Engine/Google Compute Engine
RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294
Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff
RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283
RAX:[PII_REDACTED]0012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000
RDX: [PII_REDACTED] RSI: ffffffff81bbd78b RDI: [PII_REDACTED]
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffffffffffffffef
R13: [PII_REDACTED] R14: dffffc[PII_REDACTED] R15: ffffffff81c264f0
FS:  00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 0000001b2e80dff8 CR3:[PII_REDACTED]8f8000 CR4:[PII_REDACTED]3526f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464
 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]
 register_pid_events kernel/trace/trace_events.c:2354 [inline]
 event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425
 vfs_write+0x24c/0x1150 fs/read_write.c:677
 ksys_write+0x12b/0x250 fs/read_write.c:731
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

We can reproduce the warning by following the steps below:
1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid
   and register sched_switch tracepoint.
2. echo ' ' >> set_event_pid, and perform fault injection during chunk
   allocation of trace_pid_list_alloc. Let pid_list with no pid and
assign to tr->filtered_pids.
3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to
   tr->filtered_pids.
4. echo 9 >> set_event_pid, will trigger the double register
   sched_switch tracepoint warning.

The reason is that syzkaller injects a fault into the chunk allocation
in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which
may trigger double register of the same tracepoint. This only occurs
when the system is about to crash, but to suppress this warning, let's
add failure handling logic to trace_pid_list_set.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-415
References: https://git.kernel.org/stable/c/1262bda871dace8c6efae25f3b6a2d34f6f06d54; https://git.kernel.org/stable/c/7583a73c53f1d1ae7a39b130eb7190a11f0a902f; https://git.kernel.org/stable/c/793338906ff57d8c683f44fe48ca99d49c8782a7
CVE: CVE-2025-39916
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()

When creating a new scheme of DAMON_RECLAIM, the calculation of
'min_age_region' uses 'aggr_interval' as the divisor, which may lead to
division-by-zero errors.  Fix it by directly returning -EINVAL when such a
case occurs.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/40cb9b38b645126fdd1d6aa3d6811a8ad50ddfa1; https://git.kernel.org/stable/c/5d6eeb3c683c777ed4538eb3a650bb7da17a7cff; https://git.kernel.org/stable/c/64dc351e58271c1e9005e42f5216b4f3d7a39b66
CVE: CVE-2025-39917
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix out-of-bounds dynptr write in bpf_crypto_crypt

Stanislav reported that in bpf_crypto_crypt() the destination dynptr's
size is not validated to be at least as large as the source dynptr's
size before calling into the crypto backend with 'len = src_len'. This
can result in an OOB write when the destination is smaller than the
source.

Concretely, in mentioned function, psrc and pdst are both linear
buffers fetched from each dynptr:

  psrc = __bpf_dynptr_data(src, src_len);
  [...]
  pdst = __bpf_dynptr_data_rw(dst, dst_len);
  [...]
  err = decrypt ?
        ctx->type->decrypt(ctx->tfm, psrc, pdst, src_len, piv) :
        ctx->type->encrypt(ctx->tfm, psrc, pdst, src_len, piv);

The crypto backend expects pdst to be large enough with a src_len length
that can be written. Add an additional src_len > dst_len check and bail
out if it's the case. Note that these kfuncs are accessible under root
privileges only.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/0126358df12d6f476f79251d9c398ac5c1b3062d; https://git.kernel.org/stable/c/c4be24ef0510c146dca4671effb127e97631534b; https://git.kernel.org/stable/c/f9bb6ffa7f5ad0f8ee0f53fc4a10655872ee4a14
CVE: CVE-2025-39918
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: fix linked list corruption

Never leave scheduled wcid entries on the temporary on-stack list
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/49fba87205bec14a0f6bd997635bf[PII_REDACTED]e; https://git.kernel.org/stable/c/c91a59b04f928cb4a1436b0e0a27650883d0388a; https://git.kernel.org/stable/c/e4d5a5fc61fdc65220a1ce078d24c1d20bbb0835
CVE: CVE-2025-39919
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: add missing check for rx wcid entries

Non-station wcid entries must not be passed to the rx functions.
In case of the global wcid entry, it could even lead to corruption in the wcid
array due to pointer being casted to struct mt7996_sta_link using container_of.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4a522b01e368eec58d182ecc47d24f49a39e440d; https://git.kernel.org/stable/c/69dcc19048fcdc3fb166fd25b805470ee8fc0eb1
CVE: CVE-2025-39920
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

pcmcia: Add error handling for add_interval() in do_validate_mem()

In the do_validate_mem(), the call to add_interval() does not
handle errors. If kmalloc() fails in add_interval(), it could
result in a null pointer being inserted into the linked list,
leading to illegal memory access when sub_interval() is called
next.

This patch adds an error handling for the add_interval(). If
add_interval() returns an error, the function will return early
with the error code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/06b26e3099207c94b3d1be8565aedc6edc4f0a60; https://git.kernel.org/stable/c/289b58f8ff3198d091074a751d6b8f6827726f3e; https://git.kernel.org/stable/c/369bf6e241506583f4ee7593c53b92e5a9f271b4