Security Vulnerabilities - CVEs Published In October 2025
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix memory leaks in i915 selftests
This patch fixes memory leaks on error escapes in function fake_get_pages
(cherry picked from commit 8bfbdadce85c4c51689da10f39c805a7106d4567)
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix system suspend without fbdev being initialized
If fbdev is not initialized for some reason - in practice on platforms
without display - suspending fbdev should be skipped during system
suspend, fix this up. While at it add an assert that suspending fbdev
only happens with the display present.
This fixes the following:
[ 91.227923] PM: suspend entry (s2idle)
[ 91.254598] Filesystems sync: 0.025 seconds
[ 91.270518] Freezing user space processes
[ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds)
[ 91.272686] OOM killer disabled.
[ 91.272872] Freezing remaining freezable tasks
[ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8
[ 91.659981] #PF: supervisor write access in kernel mode
[ 91.660252] #PF: error_code(0x0002) - not-present page
[ 91.660511] PGD 0 P4D 0
[ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54
[ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown
[ 91.661680] RIP: 0010:mutex_lock+0x19/0x30
[ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40
[ 91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246
[ 91.663087] RAX: 0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000
[ 91.663440] RDX: ffff8be455eb0000 RSI: 0000000000000001 RDI: 00000000000001c8
[ 91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09: ffffffff8e1432c0
[ 91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
[ 91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20
[ 91.664905] FS: 00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000
[ 91.665334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0
[ 91.665988] PKRU: 55555554
[ 91.666131] Call Trace:
[ 91.666265] <TASK>
[ 91.666381] intel_fbdev_set_suspend+0x97/0x1b0 [i915]
[ 91.666738] i915_drm_suspend+0xb9/0x100 [i915]
[ 91.667029] pci_pm_suspend+0x78/0x170
[ 91.667234] ? __pfx_pci_pm_suspend+0x10/0x10
[ 91.667461] dpm_run_callback+0x47/0x150
[ 91.667673] __device_suspend+0x10a/0x4e0
[ 91.667880] dpm_suspend+0x134/0x270
[ 91.668069] dpm_suspend_start+0x79/0x80
[ 91.668272] suspend_devices_and_enter+0x11b/0x890
[ 91.668526] pm_suspend.cold+0x270/0x2fc
[ 91.668737] state_store+0x46/0x90
[ 91.668916] kernfs_fop_write_iter+0x11b/0x200
[ 91.669153] vfs_write+0x1e1/0x3a0
[ 91.669336] ksys_write+0x53/0xd0
[ 91.669510] do_syscall_64+0x58/0xc0
[ 91.669699] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0
[ 91.669980] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0
[ 91.670278] ? syscall_exit_to_user_mode+0x17/0x40
[ 91.670524] ? do_syscall_64+0x67/0xc0
[ 91.670717] ? __irq_exit_rcu+0x3d/0x140
[ 91.670931] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 91.671202] RIP: 0033:0x7f28ffd14284
v2: CC stable. (Jani)
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
(cherry picked from commit 9542d708409a41449e99c9a464deb5e062c4bee2)
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Check instead of asserting on nested TSC scaling support
Check for nested TSC scaling support on nested SVM VMRUN instead of
asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO
has diverged from KVM's default. Userspace can trigger the WARN at will
by writing the MSR and then updating guest CPUID to hide the feature
(modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking
KVM's state_test selftest to do
vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);
after restoring state in a new VM+vCPU yields an endless supply of:
------------[ cut here ]------------
WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699
nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]
Call Trace:
<TASK>
enter_svm_guest_mode+0x114/0x560 [kvm_amd]
nested_svm_vmrun+0x260/0x330 [kvm_amd]
vmrun_interception+0x29/0x30 [kvm_amd]
svm_invoke_exit_handler+0x35/0x100 [kvm_amd]
svm_handle_exit+0xe7/0x180 [kvm_amd]
kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
__se_sys_ioctl+0x7a/0xc0
__x64_sys_ioctl+0x21/0x30
do_syscall_64+0x41/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x45ca1b
Note, the nested #VMEXIT path has the same flaw, but needs a different
fix and will be handled separately.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
OPP: Fix potential null ptr dereference in dev_pm_opp_get_required_pstate()
"opp" pointer is dereferenced before the IS_ERR_OR_NULL() check. Fix it by
removing the dereference to cache opp_table and dereference it directly
where opp_table is used.
This fixes the following smatch warning:
drivers/opp/core.c:232 dev_pm_opp_get_required_pstate() warn: variable
dereferenced before IS_ERR check 'opp' (see line 230)
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
md: don't dereference mddev after export_rdev()
Except for initial reference, mddev->kobject is referenced by
rdev->kobject, and if the last rdev is freed, there is no guarantee that
mddev is still valid. Hence mddev should not be used anymore after
export_rdev().
This problem can be triggered by following test for mdadm at very
low rate:
New file: mdadm/tests/23rdev-lifetime
devname=${dev0##*/}
devt=`cat /sys/block/$devname/dev`
pid=""
runtime=2
clean_up_test() {
pill -9 $pid
echo clear > /sys/block/md0/md/array_state
}
trap 'clean_up_test' EXIT
add_by_sysfs() {
while true; do
echo $devt > /sys/block/md0/md/new_dev
done
}
remove_by_sysfs(){
while true; do
echo remove > /sys/block/md0/md/dev-${devname}/state
done
}
echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"
add_by_sysfs &
pid="$pid $!"
remove_by_sysfs &
pid="$pid $!"
sleep $runtime
exit 0
Test cmd:
./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime
Test result:
general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP
CPU: 0 PID: 1292 Comm: test Tainted: G D W 6.5.0-rc2-00121-g01e55c376936 #562
RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]
Call Trace:
<TASK>
mddev_unlock+0x1b6/0x310 [md_mod]
rdev_attr_store+0xec/0x190 [md_mod]
sysfs_kf_write+0x52/0x70
kernfs_fop_write_iter+0x19a/0x2a0
vfs_write+0x3b5/0x770
ksys_write+0x74/0x150
__x64_sys_write+0x22/0x30
do_syscall_64+0x40/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fix this problem by don't dereference mddev after export_rdev().
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: wcd938x: fix missing mbhc init error handling
MBHC initialisation can fail so add the missing error handling to avoid
dereferencing an error pointer when later configuring the jack:
Unable to handle kernel paging request at virtual address fffffffffffffff8
pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
Call trace:
wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]
qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]
sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]
snd_soc_link_init+0x28/0x90 [snd_soc_core]
snd_soc_bind_card+0x628/0xbfc [snd_soc_core]
snd_soc_register_card+0xec/0x104 [snd_soc_core]
devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]
sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize
Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.
For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
size = SKB_DATA_ALIGN(size);
size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")
Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).
However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).
Consequently the SKB bounds checking semantics fails and panics:
skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:113!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
Workqueue: mld mld_ifc_work
RIP: 0010:skb_panic net/core/skbuff.c:113 [inline]
RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118
[snip]
Call Trace:
<TASK>
skb_put+0x151/0x210 net/core/skbuff.c:2047
skb_put_zero include/linux/skbuff.h:2422 [inline]
cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]
cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308
cdc_ncm_tx_fixup+0xa3/0x100
Deal with too low values of dwNtbOutMaxSize, clamp it in the range
[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure
enough data space is allocated to handle CDC data by making sure
dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix deadloop issue on reading trace_pipe
Soft lockup occurs when reading file 'trace_pipe':
watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
[...]
RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb
RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218
RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f
R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901
R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000
[...]
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__find_next_entry+0x1a8/0x4b0
? peek_next_entry+0x250/0x250
? down_write+0xa5/0x120
? down_write_killable+0x130/0x130
trace_find_next_entry_inc+0x3b/0x1d0
tracing_read_pipe+0x423/0xae0
? tracing_splice_read_pipe+0xcb0/0xcb0
vfs_read+0x16b/0x490
ksys_read+0x105/0x210
? __ia32_sys_pwrite64+0x200/0x200
? switch_fpu_return+0x108/0x220
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x61/0xc6
Through the vmcore, I found it's because in tracing_read_pipe(),
ring_buffer_empty_cpu() found some buffer is not empty but then it
cannot read anything due to "rb_num_of_entries() == 0" always true,
Then it infinitely loop the procedure due to user buffer not been
filled, see following code path:
tracing_read_pipe() {
... ...
waitagain:
tracing_wait_pipe() // 1. find non-empty buffer here
trace_find_next_entry_inc() // 2. loop here try to find an entry
__find_next_entry()
ring_buffer_empty_cpu(); // 3. find non-empty buffer
peek_next_entry() // 4. but peek always return NULL
ring_buffer_peek()
rb_buffer_peek()
rb_get_reader_page()
// 5. because rb_num_of_entries() == 0 always true here
// then return NULL
// 6. user buffer not been filled so goto 'waitgain'
// and eventually leads to an deadloop in kernel!!!
}
By some analyzing, I found that when resetting ringbuffer, the 'entries'
of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which
cause wrong 'overrun' count and eventually cause the deadloop issue.
To fix it, we need to clear every pages in rb_reset_cpu().
CVSS Score
7.1
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix skb_copy_ubufs() vs BIG TCP
David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy
using hugepages, and skb length bigger than ~68 KB.
skb_copy_ubufs() assumed it could copy all payload using up to
MAX_SKB_FRAGS order-0 pages.
This assumption broke when BIG TCP was able to put up to 512 KB per skb.
We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45
and limit gso_max_size to 180000.
A solution is to use higher order pages if needed.
v2: add missing __GFP_COMP, or we leak memory.
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07
In the Linux kernel, the following vulnerability has been resolved:
nvme-core: fix dev_pm_qos memleak
Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to
avoid following kmemleak:-
blktests (master) # kmemleak-clear; ./check nvme/044;
blktests (master) # kmemleak-scan ; kmemleak-show
nvme/044 (Test bi-directional authentication) [passed]
runtime 2.111s ... 2.124s
unreferenced object 0xffff888110c46240 (size 96):
comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000069ac2cec>] kmalloc_trace+0x25/0x90
[<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100
[<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core]
[<000000007df61b4b>] 0xffffffffc05e88b3
[<00000000d152b985>] 0xffffffffc05744cb
[<00000000f04a4041>] vfs_write+0xc5/0x3c0
[<00000000f9491baf>] ksys_write+0x5f/0xe0
[<000000001c46513d>] do_syscall_64+0x3b/0x90
[<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
CVSS Score
5.5
EPSS Score
0.001
Published
2025-10-07