MEDIUM4.4
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:CReferences
ALT-PU-2025-12599-7Package update kernel-image-std-def in branch c9f2
Severity:
Closed issues (38)
MEDIUM5.5
Уязвимость функции sk_msg_free() файла net/ipv4/af_inet.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функций ocfs2_extent_map_get_blocks(), ocfs2_fiemap_inline() и ocfs2_fiemap() модуля fs/ocfs2/extent_map.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.0
Уязвимость функции unpoison_memory() модуля mm/memory-failure.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции fec_enet_phy_reset_after_clk_enable() модуля drivers/net/ethernet/freescale/fec_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции edma_setup_from_hw() модуля drivers/dma/ti/edma.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM6.5
Уязвимость компонента arch/x86 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:NCVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:NReferences
MEDIUM5.5
Уязвимость компонента crypto/af_alg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции sock_lock_init_class_and_name() в модуле include/net/sock.h поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции i40e_vsi_request_irq_msix() в модуле drivers/net/ethernet/intel/i40e/i40e_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции bam_dma_probe() в модуле drivers/dma/qcom/bam_dma.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции tcp_disconnect() модуля net/ipv4/tcp.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CHIGH8.0
Уязвимость функции qed_protection_override_dump() в модуле drivers/net/ethernet/qlogic/qed/qed_debug.c драйвера сетевых адаптеров Ethernet Qlogic ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 8.0
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0HIGH 7.7
CVSS:2.0/AV:A/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH8.0
Уязвимость функции virtio_uml_probe() в модуле arch/um/drivers/virtio_uml.c 1 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 8.0
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0HIGH 7.7
CVSS:2.0/AV:A/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH8.0
Уязвимость функции cnic_cm_stop_bnx2x_hw() в модуле drivers/net/ethernet/broadcom/cnic.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 8.0
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0HIGH 7.7
CVSS:2.0/AV:A/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.7
Уязвимость функции rfkill_gpio_acpi_probe() в модуле net/rfkill/rfkill-gpio.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.7
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции fbcon_set_font() модуля drivers/video/fbdev/core/fbcon.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента stm32_fmc2_nand.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента cgroup ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline]
softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __list_del include/linux/list.h:195 [inline]
pc : __list_del_entry include/linux/list.h:218 [inline]
pc : list_move_tail include/linux/list.h:310 [inline]
pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
lr : __list_del_entry include/linux/list.h:218 [inline]
lr : list_move_tail include/linux/list.h:310 [inline]
lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
__list_del include/linux/list.h:195 [inline]
__list_del_entry include/linux/list.h:218 [inline]
list_move_tail include/linux/list.h:310 [inline]
fq_tin_dequeue include/net/fq_impl.h:112 [inline]
ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
wake_tx_push_queue net/mac80211/util.c:294 [inline]
ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
__ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
__dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
neigh_output include/net/neighbour.h:542 [inline]
ip6_fini
---truncated---
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/33ac5a4eb3d4bea2146658f1b6d1fa86d62d2b22
- https://git.kernel.org/stable/c/3fc06f6d142d2840735543216a60d0a8c345bdec
- https://git.kernel.org/stable/c/80ac0cc9c0bef984e29637b1efa93d7214b42f53
- https://git.kernel.org/stable/c/8a3ac7fb36962c34698f884bd697938054ff2afa
- https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993
- https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7
- https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993
- https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.
When I ran the repro [0] and waited a few seconds, I observed two
LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]
Reproduction Steps:
1) Mount CIFS
2) Add an iptables rule to drop incoming FIN packets for CIFS
3) Unmount CIFS
4) Unload the CIFS module
5) Remove the iptables rule
At step 3), the CIFS module calls sock_release() for the underlying
TCP socket, and it returns quickly. However, the socket remains in
FIN_WAIT_1 because incoming FIN packets are dropped.
At this point, the module's refcnt is 0 while the socket is still
alive, so the following rmmod command succeeds.
# ss -tan
State Recv-Q Send-Q Local Address:Port Peer Address:Port
FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445
# lsmod | grep cifs
cifs 1159168 0
This highlights a discrepancy between the lifetime of the CIFS module
and the underlying TCP socket. Even after CIFS calls sock_release()
and it returns, the TCP socket does not die immediately in order to
close the connection gracefully.
While this is generally fine, it causes an issue with LOCKDEP because
CIFS assigns a different lock class to the TCP socket's sk->sk_lock
using sock_lock_init_class_and_name().
Once an incoming packet is processed for the socket or a timer fires,
sk->sk_lock is acquired.
Then, LOCKDEP checks the lock context in check_wait_context(), where
hlock_class() is called to retrieve the lock class. However, since
the module has already been unloaded, hlock_class() logs a warning
and returns NULL, triggering the null-ptr-deref.
If LOCKDEP is enabled, we must ensure that a module calling
sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded
while such a socket is still alive to prevent this issue.
Let's hold the module reference in sock_lock_init_class_and_name()
and release it when the socket is freed in sk_prot_free().
Note that sock_lock_init() clears sk->sk_owner for svc_create_socket()
that calls sock_lock_init_class_and_name() for a listening socket,
which clones a socket by sk_clone_lock() without GFP_ZERO.
[0]:
CIFS_SERVER="10.0.0.137"
CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"
DEV="enp0s3"
CRED="/root/WindowsCredential.txt"
MNT=$(mktemp -d /tmp/XXXXXX)
mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1
iptables -A INPUT -s ${CIFS_SERVER} -j DROP
for i in $(seq 10);
do
umount ${MNT}
rmmod cifs
sleep 1
done
rm -r ${MNT}
iptables -D INPUT -s ${CIFS_SERVER} -j DROP
[1]:
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)
Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]
CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)
...
Call Trace:
__lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178)
lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816)
_raw_spin_lock_nested (kernel/locking/spinlock.c:379)
tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)
...
BUG: kernel NULL pointer dereference, address: 00000000000000c4
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36
Tainted: [W]=WARN
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:__lock_acquire (kernel/
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0bb2f7a1ad1f11d861f58e5ee5051c8974ff9569
- https://git.kernel.org/stable/c/2155802d3313d7b8365935c6b8d6edc0ddd7eb94
- https://git.kernel.org/stable/c/5f7f6abd92b6c8dc8f19625ef93c3a18549ede04
- https://git.kernel.org/stable/c/83083c5fc7cf9b0f136a42f26aba60da380f3601
- https://git.kernel.org/stable/c/905d43b8ad2436c240f844acb3ebcc7a99b8ebf1
- https://git.kernel.org/stable/c/b7489b753667bc9245958a4896c9419743083c27
- https://git.kernel.org/stable/c/c11247a21aab4b50a23c8b696727d7483de2f1e1
- https://git.kernel.org/stable/c/d51e47e2ab6ef10a317d576075cf625cdbf96426
- https://git.kernel.org/stable/c/feda73ad44a5cc80f6bf796bb1099a3fe71576d4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map Fix a critical memory allocation bug in edma_setup_from_hw() where queue_priority_map was allocated with insufficient memory. The code declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8), but allocated memory using sizeof(s8) instead of the correct size. This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i; The bug manifested as kernel crashes with "Oops - undefined instruction" on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the memory corruption triggered kernel hardening features on Clang. Change the allocation to use sizeof(*queue_priority_map) which automatically gets the correct size for the 2D array structure.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/069fd1688c57c0cc8a3de64d108579b31676f74b
- https://git.kernel.org/stable/c/1baed10553fc8b388351d8fc803e3ae6f1a863bc
- https://git.kernel.org/stable/c/301a96cc4dc006c9a285913d301e681cfbf7edb6
- https://git.kernel.org/stable/c/5e462fa0dfdb52b3983cf41532d3d4c7d63e2f93
- https://git.kernel.org/stable/c/7d4de60d6db02d9b01d5890d5156b04fad65d07a
- https://git.kernel.org/stable/c/d5e82f3f2c918d446df46e8d65f8083fd97cdec5
- https://git.kernel.org/stable/c/d722de80ce037dccf6931e778f4a46499d51bdf9
- https://git.kernel.org/stable/c/e63419dbf2ceb083c1651852209c7f048089ac0f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() The function of_phy_find_device may return NULL, so we need to take care before dereferencing phy_dev.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/03e79de4608bdd48ad6eec272e196124cefaf798
- https://git.kernel.org/stable/c/20a3433d31c2d2bf70ab0abec75f3136b42ae66c
- https://git.kernel.org/stable/c/4fe53aaa4271a72fe5fe3e88a45ce01646b68dc5
- https://git.kernel.org/stable/c/5f1bb554a131e59b28482abad21f691390651752
- https://git.kernel.org/stable/c/8c60d12bba14dc655d2d948b1dbf390b3ae39cb8
- https://git.kernel.org/stable/c/93a699d6e92cfdfa9eb9dbb8c653b5322542ca4f
- https://git.kernel.org/stable/c/eb148d85e126c47d65be34f2a465d69432ca5541
- https://git.kernel.org/stable/c/fe78891f296ac05bf4e5295c9829ef822f3c32e7
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory
When I did memory failure tests, below panic occurs:
page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))
kernel BUG at include/linux/page-flags.h:616!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40
RIP: 0010:unpoison_memory+0x2f3/0x590
RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246
RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8
RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0
RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb
R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000
R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe
FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0
Call Trace:
unpoison_memory+0x2f3/0x590
simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110
debugfs_attr_write+0x42/0x60
full_proxy_write+0x5b/0x80
vfs_write+0xd5/0x540
ksys_write+0x64/0xe0
do_syscall_64+0xb9/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f08f0314887
RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887
RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001
RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009
R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00
Modules linked in: hwpoison_inject
---[ end trace 0000000000000000 ]---
RIP: 0010:unpoison_memory+0x2f3/0x590
RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246
RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8
RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0
RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb
R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000
R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe
FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---
The root cause is that unpoison_memory() tries to check the PG_HWPoison
flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is
triggered. This can be reproduced by below steps:
1.Offline memory block:
echo offline > /sys/devices/system/memory/memory12/state
2.Get offlined memory pfn:
page-types -b n -rlN
3.Write pfn to unpoison-pfn
echo > /sys/kernel/debug/hwpoison/unpoison-pfn
This scenario can be identified by pfn_to_online_page() returning NULL.
And ZONE_DEVICE pages are never expected, so we can simply fail if
pfn_to_online_page() == NULL to fix the bug.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/3d278e89c2ea62b1aaa4b0d8a9766a35b3a3164a
- https://git.kernel.org/stable/c/63a327a2375a8ce7a47dec5aaa4d8a9ae0a00b96
- https://git.kernel.org/stable/c/7618fd443aa4cfa553a64cacf5721581653ee7b0
- https://git.kernel.org/stable/c/8e01ea186a52c90694c08a9ff57bea1b0e78256a
- https://git.kernel.org/stable/c/99f7048957f5ae3cee1c01189147e73a9a96de02
- https://git.kernel.org/stable/c/d613f53c83ec47089c4e25859d5e8e0359f6f8da
- https://git.kernel.org/stable/c/e4ec6def5643a1c9511115b3884eb879572294c6
- https://git.kernel.org/stable/c/fb65803ccff37cf9123c50c1c02efd1ed73c4ed5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix recursive semaphore deadlock in fiemap call
syzbot detected a OCFS2 hang due to a recursive semaphore on a
FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.
context_switch kernel/sched/core.c:5357 [inline]
__schedule+0x1798/0x4cc0 kernel/sched/core.c:6961
__schedule_loop kernel/sched/core.c:7043 [inline]
schedule+0x165/0x360 kernel/sched/core.c:7058
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115
rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185
__down_write_common kernel/locking/rwsem.c:1317 [inline]
__down_write kernel/locking/rwsem.c:1326 [inline]
down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591
ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142
do_page_mkwrite+0x14d/0x310 mm/memory.c:3361
wp_page_shared mm/memory.c:3762 [inline]
do_wp_page+0x268d/0x5800 mm/memory.c:3981
handle_pte_fault mm/memory.c:6068 [inline]
__handle_mm_fault+0x1033/0x5440 mm/memory.c:6195
handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364
do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387
handle_page_fault arch/x86/mm/fault.c:1476 [inline]
exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]
RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]
RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]
RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26
Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89
f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f
1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41
RSP: 0018:ffffc9000403f950 EFLAGS: 00050256
RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038
RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060
RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42
R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098
R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060
copy_to_user include/linux/uaccess.h:225 [inline]
fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145
ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806
ioctl_fiemap fs/ioctl.c:220 [inline]
do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532
__do_sys_ioctl fs/ioctl.c:596 [inline]
__se_sys_ioctl+0x82/0x170 fs/ioctl.c:584
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5f13850fd9
RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9
RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004
RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0
R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b
ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since
v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the
extent list of this running mmap executable. The user supplied buffer to
hold the fiemap information page faults calling ocfs2_page_mkwrite() which
will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same
semaphore. This recursive semaphore will hold filesystem locks and causes
a hang of the fileystem.
The ip_alloc_sem protects the inode extent list and size. Release the
read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()
and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock
on the last extent but simplifies the error path.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/04100f775c2ea501927f508f17ad824ad1f23c8d
- https://git.kernel.org/stable/c/0709bc11b942870fc0a7be150e42aea42321093a
- https://git.kernel.org/stable/c/16e518ca84dfe860c20a62f3615e14e8af0ace57
- https://git.kernel.org/stable/c/1d3c96547ee2ddeaddf8f19a3ef99ea06cc8115e
- https://git.kernel.org/stable/c/36054554772f95d090eb45793faf6aa3c0254b02
- https://git.kernel.org/stable/c/7e1514bd44ef68007703c752c99ff7319f35bce6
- https://git.kernel.org/stable/c/9efcb7a8b97310efed995397941a292cf89fa94f
- https://git.kernel.org/stable/c/ef30404980e4c832ef9bba1b10c08f67fa77a9ec
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
MEDIUM5.5
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: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 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 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/06d8ef8f853752fea88c8d5bb093a40e71b330cf
- https://git.kernel.org/stable/c/26adba1e7d7924174e15a3ba4b1132990786300b
- https://git.kernel.org/stable/c/513c40e59d5a414ab763a9c84797534b5e8c208d
- https://git.kernel.org/stable/c/75686c49574dd5f171ca682c18717787f1d8d55e
- https://git.kernel.org/stable/c/dc1c6e60993b93b87604eb11266ac72e1a3be9e0
- https://git.kernel.org/stable/c/dfe2ac47a6ee0ab50393694517c54ef1e276dda3
- https://git.kernel.org/stable/c/e32a2ea52b51368774d014e5bcd9b86110a2b727
- https://git.kernel.org/stable/c/f6fd98d961fa6f97347cead4f08ed862cbbb91ff
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
HIGH7.8
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:
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
[...]
---[ end trace 0000000000000000 ]---
Use the same dev_id for free_irq() as for request_irq().
I tested this with inserting code to fail intentionally.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/13ab9adef3cd386511c930a9660ae06595007f89
- https://git.kernel.org/stable/c/23431998a37764c464737b855c71a81d50992e98
- https://git.kernel.org/stable/c/6e4016c0dca53afc71e3b99e24252b63417395df
- https://git.kernel.org/stable/c/915470e1b44e71d1dd07ee067276f003c3521ee3
- https://git.kernel.org/stable/c/a30afd6617c30aaa338d1dbcb1e34e7a1890085c
- https://git.kernel.org/stable/c/b905b2acb3a0bbb08ad9be9984d8cdabdf827315
- https://git.kernel.org/stable/c/b9721a023df38cf44a88f2739b4cf51efd051f85
- https://git.kernel.org/stable/c/c62580674ce5feb1be4f90b5873ff3ce50e0a1db
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
HIGH7.8
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: dffffc0000000000 RCX: ffff888024a23c80
RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000
RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4
R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380
R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872
FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0
Call Trace:
__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
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/05366527f44cf4b884f3d9462ae8009be9665856
- https://git.kernel.org/stable/c/08f58d10f5abf11d297cc910754922498c921f91
- https://git.kernel.org/stable/c/539920180c55f5e13a2488a2339f94e6b8cb69e0
- https://git.kernel.org/stable/c/66bcb04a441fbf15d66834b7e3eefb313dd750c8
- https://git.kernel.org/stable/c/7429b8b9bfbc276fd304fbaebc405f46b421fedf
- https://git.kernel.org/stable/c/9c2a6456bdf9794474460d885c359b6c4522d6e3
- https://git.kernel.org/stable/c/a3967baad4d533dc254c31e0d221e51c8d223d58
- https://git.kernel.org/stable/c/de89e58368f8f07df005ecc1c86ad94898a999f2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0ff9df758af7022d749718fb6b8385cc5693acf3
- https://git.kernel.org/stable/c/1d98ba204d8a6db0d986c7f1aefaa0dcd1c007a2
- https://git.kernel.org/stable/c/1fc14731f0be4885e60702b9596d14d9a79cf053
- https://git.kernel.org/stable/c/2e257a6125c63350f00dc42b9674f20fd3cf4a9f
- https://git.kernel.org/stable/c/5068b5254812433e841a40886e695633148d362d
- https://git.kernel.org/stable/c/555bd16351a35c79efb029a196975a5a27f7fbc4
- https://git.kernel.org/stable/c/6ac1599d0e78036d9d08efc2f58c2d91f0a3ee4c
- https://git.kernel.org/stable/c/ebf6c7c908e5999531c3517289598f187776124f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkill_find_type() gets called with the possibly uninitialized "const char *type_name;" local variable. On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no "type" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device 2. The stack happened to contain NULL where type_name is stored
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/184f608a68f96794e8fe58cd5535014d53622cde
- https://git.kernel.org/stable/c/21a39b958b4bcf44f7674bfbbe1bbb8cad0d842d
- https://git.kernel.org/stable/c/21ba85d9d508422ca9e6698463ff9357c928c22d
- https://git.kernel.org/stable/c/47ade5f9d70b23a119ec20b1c6504864b2543a79
- https://git.kernel.org/stable/c/689aee35ce671aab752f159e5c8e66d7685e6887
- https://git.kernel.org/stable/c/8793e7a8e1b60131a825457174ed6398111daeb7
- https://git.kernel.org/stable/c/ada2282259243387e6b6e89239aeb4897e62f051
- https://git.kernel.org/stable/c/b6f56a44e4c1014b08859dcf04ed246500e310e5
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0405055930264ea8fd26f4131466fa7652e5e47d
- https://git.kernel.org/stable/c/0627e1481676669cae2df0d85b5ff13e7d24c390
- https://git.kernel.org/stable/c/6e33a7eed587062ca8161ad1f4584882a860d697
- https://git.kernel.org/stable/c/7b6a5b0a6b392263c3767fc945b311ea04b34bbd
- https://git.kernel.org/stable/c/8eeb2091e72d75df8ceaa2172638d61b4cf8929a
- https://git.kernel.org/stable/c/cfa7d9b1e3a8604afc84e9e51d789c29574fb216
- https://git.kernel.org/stable/c/e1fcd4a9c09feac0902a65615e866dbf22616125
- https://git.kernel.org/stable/c/fde6e73189f40ebcf0633aed2b68e731c25f3aa3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: qed: Don't collect too many protection override GRC elements In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer. This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESS where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure. The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783 or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663 Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/25672c620421fa2105703a94a29a03487245e6d6
- https://git.kernel.org/stable/c/56c0a2a9ddc2f5b5078c5fb0f81ab76bbc3d4c37
- https://git.kernel.org/stable/c/660b2a8f5a306a28c7efc1b4990ecc4912a68f87
- https://git.kernel.org/stable/c/70affe82e38fd3dc76b9c68b5a1989f11e7fa0f3
- https://git.kernel.org/stable/c/8141910869596b7a3a5d9b46107da2191d523f82
- https://git.kernel.org/stable/c/e0e24571a7b2f8c8f06e25d3417253ebbdbc8d5c
- https://git.kernel.org/stable/c/ea53e6a47e148b490b1c652fc65d2de5a086df76
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: um: virtio_uml: Fix use-after-free after put_device in probe When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/00e98b5a69034b251bb36dc6e7123d7648e218e4
- https://git.kernel.org/stable/c/14c231959a16ca41bfdcaede72483362a8c645d7
- https://git.kernel.org/stable/c/4f364023ddcfe83f7073b973a9cb98584b7f2a46
- https://git.kernel.org/stable/c/5e94e44c9cb30d7a383d8ac227f24a8c9326b770
- https://git.kernel.org/stable/c/7ebf70cf181651fe3f2e44e95e7e5073d594c9c0
- https://git.kernel.org/stable/c/aaf900a83508c8cd5cdf765e7749f9076196ec7f
- https://git.kernel.org/stable/c/c2ff91255e0157b356cff115d8dc3eeb5162edf2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: cgroup: split cgroup_destroy_wq into 3 workqueues A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction. Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20 Root Cause: CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1) Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation This separation eliminates blocking in the CSS free path while waiting for offline operations to complete. [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/05e0b03447cf215ec384210441b34b7a3b16e8b0
- https://git.kernel.org/stable/c/4a1e3ec28e8062cd9f339aa6a942df9c5bcb6811
- https://git.kernel.org/stable/c/79f919a89c9d06816dbdbbd168fa41d27411a7f9
- https://git.kernel.org/stable/c/993049c9b1355c78918344a6403427d53f9ee700
- https://git.kernel.org/stable/c/a0c896bda7077aa5005473e2c5b3c27173313b4c
- https://git.kernel.org/stable/c/cabadd7fd15f97090f752fd22dd7f876a0dc3dc4
- https://git.kernel.org/stable/c/ded4d207a3209a834b6831ceec7f39b934c74802
- https://git.kernel.org/stable/c/f2795d1b92506e3adf52a298f7181032a1525e04
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().
syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
in the TCP_ESTABLISHED state. [0]
syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:
1. accept()
2. connect(AF_UNSPEC)
3. connect() to another destination
As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.
Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.
Let's call reqsk_fastopen_remove() in tcp_disconnect().
[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
Call Trace:
tcp_write_timer (net/ipv4/tcp_timer.c:738)
call_timer_fn (kernel/time/timer.c:1747)
__run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
__walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
tmigr_handle_remote (kernel/time/timer_migration.c:1096)
handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/17d699727577814198d744d6afe54735c6b54c99
- https://git.kernel.org/stable/c/33a4fdf0b4a25f8ce65380c3b0136b407ca57609
- https://git.kernel.org/stable/c/45c8a6cc2bcd780e634a6ba8e46bffbdf1fc5c01
- https://git.kernel.org/stable/c/7ec092a91ff351dcde89c23e795b73a328274db6
- https://git.kernel.org/stable/c/a4378dedd6e07e62f2fccb17d78c9665718763d0
- https://git.kernel.org/stable/c/ae313d14b45eca7a6bb29cb9bf396d977e7d28fb
- https://git.kernel.org/stable/c/dfd06131107e7b699ef1e2a24ed2f7d17c917753
- https://git.kernel.org/stable/c/fa4749c065644af4db496b338452a69a3e5147d9
LOW3.3
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:LReferences
- https://git.kernel.org/stable/c/0f28c4adbc4a97437874c9b669fd7958a8c6d6ce
- https://git.kernel.org/stable/c/1b34cbbf4f011a121ef7b2d7d6e6920a036d5285
- https://git.kernel.org/stable/c/1f323a48e9b5ebfe6dc7d130fdf5c3c0e92a07c8
- https://git.kernel.org/stable/c/45bcf60fe49b37daab1acee57b27211ad1574042
- https://git.kernel.org/stable/c/7c4491b5644e3a3708f3dbd7591be0a570135b84
- https://git.kernel.org/stable/c/9aee87da5572b3a14075f501752e209801160d3d
- https://git.kernel.org/stable/c/e4c1ec11132ec466f7362a95f36a506ce4dc08c9
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fbcon: fix integer overflow in fbcon_do_set_font Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters. The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying. Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1a194e6c8e1ee745e914b0b7f50fa86c89ed13fe
- https://git.kernel.org/stable/c/4a4bac869560f943edbe3c2b032062f6673b13d3
- https://git.kernel.org/stable/c/994bdc2d23c79087fbf7dcd9544454e8ebcef877
- https://git.kernel.org/stable/c/9c8ec14075c5317edd6b242f1be8167aa1e4e333
- https://git.kernel.org/stable/c/a6eb9f423b3db000aaedf83367b8539f6b72dcfc
- https://git.kernel.org/stable/c/adac90bb1aaf45ca66f9db8ac100be16750ace78
- https://git.kernel.org/stable/c/b8a6e85328aeb9881531dbe89bcd2637a06c3c95
- https://git.kernel.org/stable/c/c0c01f9aa08c8e10e10e8c9ebb5be01a4eff6eb7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: x86/vmscape: Add conditional IBPB mitigation VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit. Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB. This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace. The intent is to integrate and optimize these cases post-embargo. [ dhansen: elaborate on suboptimal IBPB solution ]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/15006289e5c38b2a830e1fba221977a27598176c
- https://git.kernel.org/stable/c/2f4f2f8f860cb4c3336a7435ebe8dcfded0c9c6e
- https://git.kernel.org/stable/c/2f8f173413f1cbf52660d04df92d0069c4306d25
- https://git.kernel.org/stable/c/34e5667041050711a947e260fc9ebebe08bddee5
- https://git.kernel.org/stable/c/459274c77b37ac63b78c928b4b4e748d1f9d05c8
- https://git.kernel.org/stable/c/510603f504796c3535f67f55fb0b124a303b44c8
- https://git.kernel.org/stable/c/893387c18612bb452336a5881da0d015a7e8f4a2
- https://git.kernel.org/stable/c/9c23a90648e831d611152ac08dbcd1283d405e7f
- https://git.kernel.org/stable/c/ac60717f9a8d21c58617d0b34274babf24135835
- https://git.kernel.org/stable/c/c08192b5d6730a914dee6175bc71092ee6a65f14
- https://git.kernel.org/stable/c/d5490dfa35427a2967e00a4c7a1b95fdbc8ede34
- https://git.kernel.org/stable/c/d7ddc93392e4a7ffcccc86edf6ef3e64c778db52
- https://git.kernel.org/stable/c/f866eef8d1c65504d30923c3f14082ad294d0e6d
- http://www.openwall.com/lists/oss-security/2025/11/14/3
- http://www.openwall.com/lists/oss-security/2025/11/14/4
- http://www.openwall.com/lists/oss-security/2025/11/14/6
- http://www.openwall.com/lists/oss-security/2025/11/17/2
- http://www.openwall.com/lists/oss-security/2025/11/17/3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html