ALT-BU-2025-6912-6
Branch c10f2 update bulletin.
Package kernel-image-un-def updated to version 6.1.136-alt0.c10f.2 for branch c10f2 in task 383025.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2024-10603
Уязвимость функции of_modalias() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-06-09
BDU:2025-05411
Уязвимость компонента net_sched модуля net/sched/sch_sfq.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-11
BDU:2025-06312
Уязвимость функции krb_authenticate() модуля fs/smb/server/smb2pdu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-07485
Уязвимость функции tcf_mirred_to_dev() модуля net/sched/act_mirred.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-07500
Уязвимость функции iocg_pay_debt() модуля block/blk-iocost.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-03
BDU:2025-09837
Уязвимость функции spi_imx_transfer_one операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-10599
Уязвимость функции dwc3_check_event_buf операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2026-03-03
BDU:2025-10603
Уязвимость функции virtsnd_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10604
Уязвимость функции size_limit_mb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-10606
Уязвимость компонента ci_hdrc_imx операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-10608
Уязвимость компонента cdns3 операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-10758
Уязвимость функции af_alg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11798
Уязвимость компонента microchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11811
Уязвимость ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-11836
Уязвимость компонента qcom/lpass.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11867
Уязвимость компонента st.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-11868
Уязвимость компонента isofs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11870
Уязвимость компонента drivers/net/ppp/ppp_synctty.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11888
Уязвимость компонента hfi_parser ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11893
Уязвимость компонента hfi_parser ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11896
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11906
Уязвимость компонента sclp_con.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11932
Уязвимость компонента jfs_dmap.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-11933
Уязвимость компонента sch_codel.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-11934
Уязвимость компонента openvswitch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11935
Уязвимость компонента tls_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-11960
Уязвимость компонента fs/read_write.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11973
Уязвимость компонента inftlcore.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-11978
Уязвимость компонента virtiofs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11982
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11997
Уязвимость ядра операционной системы Linux, связанная с ошибками синхронизации при использовании общего ресурса, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12002
Уязвимость компонента pwm-mediatek.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12003
Уязвимость компонента drm/amd/pm/smu11 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12004
Уязвимость компонента jfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12008
Уязвимость компонента drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12009
Уязвимость компонента drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищемой информации и вызвать отказ в обслуживании(DoS)
Modified: 2026-03-11
BDU:2025-12010
Уязвимость компонента drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищемой информации и вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12011
Уязвимость компонента drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12012
Уязвимость компонента drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12023
Уязвимость компонента hugetlbpage.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12028
Уязвимость компонента phy_led_triggers.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12029
Уязвимость функции wl1251_tx_work компонента wl1251/tx.c модуля wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12034
Уязвимость компонента cxgb4_ethtool.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12036
Уязвимость компонента link.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12053
Уязвимость компонента backlight ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12061
Уязвимость функции pci_register_host_bridge() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12062
Уязвимость функции chameleon_parse_gdd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12069
Уязвимость компонента avic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12071
Уязвимость компонента kfd_process.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12072
Уязвимость компонента arm.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12074
Уязвимость компонента drivers/hsi/clients/ssi_protocol.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12085
Уязвимость компонента sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12087
Уязвимость компонента sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12089
Уязвимость функции ext4_xattr_inode_dec_ref_all() компонента fs/ext4/xattr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12091
Уязвимость компонента sctp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12105
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12108
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12109
Уязвимость ядра операционной системы Linux, связанная с возможностью использования памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12110
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12129
Уязвимость ядра операционной системы Linux, связанная с неправильным разыменованем нулеового указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12136
Уязвимость компонента dev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12137
Уязвимость функции p9_client_write() компонента 9p/net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12138
Уязвимость компонентов igc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12139
Уязвимость компонента hid-pidff.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12140
Уязвимость компонента amd_powerplay.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12141
Уязвимость компонента smb2misc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12142
Уязвимость компонента parse.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12144
Уязвимость функций scmi_cpufreq_get_rate() и cpufreq_cpu_get_raw() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12145
Уязвимость компонента scpi-cpufreq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12149
Уязвимость компонента monitor.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-12150
Уязвимость компонента xen-netfront.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12151
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12153
Уязвимость компонента btrtl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12154
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования нулевого указателя NULL, позволяющая нарушителю вызвать отказ в обслуживании(DoS)
Modified: 2026-03-11
BDU:2025-12156
Уязвимость модуля i2c-cros-ec-tunnel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12158
Уязвимость компонента RDMA/cma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12160
Уязвимость функции pxa_ata_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12162
Уязвимость компонента iommu/mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-12163
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования нулеового указателя NULL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12164
Уязвимость компонента i3c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12165
Уязвимость компонента ene-kb3930 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12166
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12245
Уязвимость компонента nfs4state.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12246
Уязвимость компонента dispc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12257
Уязвимость ядра операционной системы Linux, связанная с недостаточной блокировкой, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12271
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12275
Уязвимость компонента chip.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12278
Уязвимость ядра операционной системы Linux, связанная с некорректным вычислением, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12285
Уязвимость компонента umem_odp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12290
Уязвимость компонента qibfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12306
Уязвимость компонента venus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12307
Уязвимость компонента venus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12324
Уязвимость ядра операционной системы Linux, связанная с неправильным контролем идентификаторов ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12329
Уязвимость компонента brcmnand.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12330
Уязвимость компонента jfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2026-03-31
BDU:2025-12335
Уязвимость модуля USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12338
Уязвимость компонента bpf_trace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12343
Уязвимость ядра операционной системы Linux, связанная с ошибками при блокировке потоков, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-12344
Уязвимость компонента vlan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12352
Уязвимость компонента ftrace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12353
Уязвимость компонента page_pool.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12370
Уязвимость компонента drm/nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12705
Уязвимость функции l2cap_connect() модуля net/bluetooth/l2cap_core.c ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-11-25
CVE-2024-26739
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: don't override retval if we already lost the skb If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it.
- https://git.kernel.org/stable/c/0117fe0a4615a7c8d30d6ebcbf87332fbe63e6fd
- https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210
- https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d
- https://git.kernel.org/stable/c/9d3ef89b6a5e9f2e940de2cef3d543be0be8dec5
- https://git.kernel.org/stable/c/e873e8f7d03a2ee5b77fb1a305c782fed98e2754
- https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7
- https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210
- https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d
- https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-03
CVE-2024-36908
In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.
- https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6
- https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e
- https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67
- https://git.kernel.org/stable/c/56a9d07f427378eeb75b917bb49c6fbea8204126
- https://git.kernel.org/stable/c/7d215e013d097ed6fc4b0ad0272c9514214dc408
- https://git.kernel.org/stable/c/aed0aac18f039dd4af13c143063754efca358cb0
- https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6
- https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e
- https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2024-38541
In the Linux kernel, the following vulnerability has been resolved: of: module: add buffer overflow check in of_modalias() In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).
- https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6
- https://git.kernel.org/stable/c/46795440ef2b4ac919d09310a69a404c5bc90a88
- https://git.kernel.org/stable/c/5d59fd637a8af42b211a92b2edb2474325b4d488
- https://git.kernel.org/stable/c/733e62786bdf1b2b9dbb09ba2246313306503414
- https://git.kernel.org/stable/c/c7f24b7d94549ff4623e8f41ea4d9f5319bd8ac8
- https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252
- https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a
- https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e
- https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6
- https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252
- https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a
- https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-03
CVE-2024-46733
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix qgroup reserve leaks in cow_file_range
In the buffered write path, the dirty page owns the qgroup reserve until
it creates an ordered_extent.
Therefore, any errors that occur before the ordered_extent is created
must free that reservation, or else the space is leaked. The fstest
generic/475 exercises various IO error paths, and is able to trigger
errors in cow_file_range where we fail to get to allocating the ordered
extent. Note that because we *do* clear delalloc, we are likely to
remove the inode from the delalloc list, so the inodes/pages to not have
invalidate/launder called on them in the commit abort path.
This results in failures at the unmount stage of the test that look like:
BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure
BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure
BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672
------------[ cut here ]------------
WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]
Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq
CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]
RSP: 0018:ffffb4465283be00 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8
RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/159f0f61b283ea71e827dd0c18c5dce197de1fa2
- https://git.kernel.org/stable/c/30479f31d44d47ed00ae0c7453d9b253537005b2
- https://git.kernel.org/stable/c/84464db2ec2a55b9313d5f264da196a37ec80994
- https://git.kernel.org/stable/c/e42ef22bc10f0309c0c65d8d6ca8b4127a674b7f
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2024-56609
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb When removing kernel modules by: rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core Driver uses skb_queue_purge() to purge TX skb, but not report tx status causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue() to correct this. Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing between TX work and purge TX queue, flush and destroy TX work in advance. wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local choice (Reason: 3=DEAUTH_LEAVING) ------------[ cut here ]------------ Have pending ack frames! WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691 ieee80211_free_ack_frame+0x5c/0x90 [mac80211] CPU: 3 PID: 9232 Comm: rmmod Tainted: G C 6.10.1-200.fc40.aarch64 #1 Hardware name: pine64 Pine64 PinePhone Braveheart (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] sp : ffff80008c1b37b0 x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0 x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000 x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000 x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964 x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0 x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000 Call trace: ieee80211_free_ack_frame+0x5c/0x90 [mac80211] idr_for_each+0x74/0x110 ieee80211_free_hw+0x44/0xe8 [mac80211] rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio] sdio_bus_remove+0x44/0x180 device_remove+0x54/0x90 device_release_driver_internal+0x1d4/0x238 driver_detach+0x54/0xc0 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x78 sdio_unregister_driver+0x2c/0x40 rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs] __do_sys_delete_module.isra.0+0x190/0x338 __arm64_sys_delete_module+0x1c/0x30 invoke_syscall+0x74/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/3d94c4b21966b49c3e26ceeefacaa11ff7ee6d68
- https://git.kernel.org/stable/c/3e5e4a801aaf4283390cc34959c6c48f910ca5ea
- https://git.kernel.org/stable/c/4e8ce3978d704cb28678355d294e10a008b6230a
- https://git.kernel.org/stable/c/9bca6528f20325d30c22236b23116f161d418f6d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22126
In the Linux kernel, the following vulnerability has been resolved: md: fix mddev uaf while iterating all_mddevs list While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem.
- https://git.kernel.org/stable/c/5462544ccbad3fc938a71b01fa5bd3a0dc2b750a
- https://git.kernel.org/stable/c/8542870237c3a48ff049b6c5df5f50c8728284fa
- https://git.kernel.org/stable/c/ca9f84de76723b358dfc0606668efdca54afc2e5
- https://git.kernel.org/stable/c/d69a23d8e925f8052d657652a6875ec2712c7e33
- https://git.kernel.org/stable/c/e2a9f73ee408a460f4c9dfe03b4741d6b11652b8
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23140
In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released. However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq(). [kwilczynski: commit log]
- https://git.kernel.org/stable/c/0557e70e2aeba8647bf5a950820b67cfb86533db
- https://git.kernel.org/stable/c/54c9f299ad7d7c4be5d271ed12d01a59e95b8907
- https://git.kernel.org/stable/c/5a4b7181213268c9b07bef8800905528435db44a
- https://git.kernel.org/stable/c/705be96504779e4a333ea042b4779ea941f0ace9
- https://git.kernel.org/stable/c/770407f6173f4f39f4e2c1b54422b79ce6c98bdb
- https://git.kernel.org/stable/c/9d5118b107b1a2353ed0dff24404aee2e6b7ca0a
- https://git.kernel.org/stable/c/e516e187bf32d8decc7c7d0025ae4857cad13c0e
- https://git.kernel.org/stable/c/f6cb7828c8e17520d4f5afb416515d3fae1af9a9
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23141
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses
Acquire a lock on kvm->srcu when userspace is getting MP state to handle a
rather extreme edge case where "accepting" APIC events, i.e. processing
pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU
is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP
state will trigger a nested VM-Exit by way of ->check_nested_events(), and
emuating the nested VM-Exit can access guest memory.
The splat was originally hit by syzkaller on a Google-internal kernel, and
reproduced on an upstream kernel by hacking the triple_fault_event_test
selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a
memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.
=============================
WARNING: suspicious RCU usage
6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
-----------------------------
include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by triple_fault_ev/1256:
#0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]
stack backtrace:
CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:
- https://git.kernel.org/stable/c/0357c8406dfa09430dd9858ebe813feb65524b6e
- https://git.kernel.org/stable/c/592e040572f216d916f465047c8ce4a308fcca44
- https://git.kernel.org/stable/c/7bc5c360375d28ba5ef6298b0d53e735c81d66a1
- https://git.kernel.org/stable/c/8a3df0aa1087a89f5ce55f4aba816bfcb1ecf1be
- https://git.kernel.org/stable/c/ef01cac401f18647d62720cf773d7bb0541827da
- https://git.kernel.org/stable/c/f5cbe725b7477b4cd677be1b86b4e08f90572997
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23142
In the Linux kernel, the following vulnerability has been resolved: sctp: detect and prevent references to a freed transport in sendmsg sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent. There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf(). This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read. This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport"). Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process. If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send. The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).
- https://git.kernel.org/stable/c/0f7df4899299ce4662e5f95badb9dbc57cc37fa5
- https://git.kernel.org/stable/c/2e5068b7e0ae0a54f6cfd03a2f80977da657f1ee
- https://git.kernel.org/stable/c/3257386be6a7eb8a8bfc9cbfb746df4eb4fc70e8
- https://git.kernel.org/stable/c/547762250220325d350d0917a7231480e0f4142b
- https://git.kernel.org/stable/c/5bc83bdf5f5b8010d1ca5a4555537e62413ab4e2
- https://git.kernel.org/stable/c/7a63f4fb0efb4e69efd990cbb740a848679ec4b0
- https://git.kernel.org/stable/c/9e7c37fadb3be1fc33073fcf10aa96d166caa697
- https://git.kernel.org/stable/c/c6fefcb71d246baaf3bacdad1af7ff50ebcfe652
- https://git.kernel.org/stable/c/f1a69a940de58b16e8249dff26f74c8cc59b32be
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-23144
In the Linux kernel, the following vulnerability has been resolved: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable().
- https://git.kernel.org/stable/c/11d128f7eacec276c75cf4712880a6307ca9c885
- https://git.kernel.org/stable/c/1c82f5a393d8b9a5c1ea032413719862098afd4b
- https://git.kernel.org/stable/c/276822a00db3c1061382b41e72cafc09d6a0ec30
- https://git.kernel.org/stable/c/61a5c565fd2442d3128f3bab5f022658adc3a4e6
- https://git.kernel.org/stable/c/74c7d67a3c305fc1fa03c32a838e8446fb7aee14
- https://git.kernel.org/stable/c/87d947a0607be384bfe7bb0935884a711e35ca07
- https://git.kernel.org/stable/c/b447885ec9130cf86f355e011dc6b94d6ccfb5b7
- https://git.kernel.org/stable/c/b8ddf5107f53789448900f04fa220f34cd2f777e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23145
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix NULL pointer in can_accept_new_subflow When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. Call trace: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflow_req->msk' under the `own_req == true` conditional. Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to.
- https://git.kernel.org/stable/c/443041deb5ef6a1289a99ed95015ec7442f141dc
- https://git.kernel.org/stable/c/4b2649b9717678aeb097893cc49f59311a1ecab0
- https://git.kernel.org/stable/c/7f9ae060ed64aef8f174c5f1ea513825b1be9af1
- https://git.kernel.org/stable/c/855bf0aacd51fced11ea9aa0d5101ee0febaeadb
- https://git.kernel.org/stable/c/8cf7fef1bb2ffea7792bcbf71ca00216cecc725d
- https://git.kernel.org/stable/c/b3088bd2a6790c8efff139d86d7a9d0b1305977b
- https://git.kernel.org/stable/c/dc81e41a307df523072186b241fa8244fecd7803
- https://git.kernel.org/stable/c/efd58a8dd9e7a709a90ee486a4247c923d27296f
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23146
In the Linux kernel, the following vulnerability has been resolved: mfd: ene-kb3930: Fix a potential NULL pointer dereference The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference"). This was detected by our static analysis tool.
- https://git.kernel.org/stable/c/2edb5b29b197d90b4d08cd45e911c0bcf24cb895
- https://git.kernel.org/stable/c/4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199
- https://git.kernel.org/stable/c/6dc88993ee3fa8365ff6a5d6514702f70ba6863a
- https://git.kernel.org/stable/c/76d0f4199bc5b51acb7b96c6663a8953543733ad
- https://git.kernel.org/stable/c/7b47df6498f223c8956bfe0d994a0e42a520dfcd
- https://git.kernel.org/stable/c/90ee23c2514a22a9c2bb39a540cbe1c9acb27d0b
- https://git.kernel.org/stable/c/b1758417310d2cc77e52cd15103497e52e2614f6
- https://git.kernel.org/stable/c/ea07760676bba49319d553af80c239da053b5fb1
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23147
In the Linux kernel, the following vulnerability has been resolved: i3c: Add NULL pointer check in i3c_master_queue_ibi() The I3C master driver may receive an IBI from a target device that has not been probed yet. In such cases, the master calls `i3c_master_queue_ibi()` to queue an IBI work task, leading to "Unable to handle kernel read from unreadable memory" and resulting in a kernel panic. Typical IBI handling flow: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`. 3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver’s IBI handler task. However, since target device events are asynchronous to the I3C probe sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`, leading to a kernel panic. Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing an uninitialized `dev->ibi`, ensuring stability.
- https://git.kernel.org/stable/c/09359e7c8751961937cb5fc50220969b0a4e1058
- https://git.kernel.org/stable/c/1b54faa5f47fa7c642179744aeff03f0810dc62e
- https://git.kernel.org/stable/c/3ba402610843d7d15c7f3966a461deeeaff7fba4
- https://git.kernel.org/stable/c/6871a676aa534e8f218279672e0445c725f81026
- https://git.kernel.org/stable/c/bd496a44f041da9ef3afe14d1d6193d460424e91
- https://git.kernel.org/stable/c/d83b0c03ef8fbea2f03029a1cc1f5041f0e1d47f
- https://git.kernel.org/stable/c/e6bba328578feb58c614c11868c259b40484c5fa
- https://git.kernel.org/stable/c/fe4a4fc179b7898055555a11685915473588392e
- https://git.kernel.org/stable/c/ff9d61db59bb27d16d3f872bff2620d50856b80c
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23148
In the Linux kernel, the following vulnerability has been resolved: soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe() soc_dev_attr->revision could be NULL, thus, a pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool.
- https://git.kernel.org/stable/c/4129760e462f45f14e61b10408ace61aa7c2ed30
- https://git.kernel.org/stable/c/44a2572a0fdcf3e7565763690d579b998a8f0562
- https://git.kernel.org/stable/c/475b9b45dc32eba58ab794b5d47ac689fc018398
- https://git.kernel.org/stable/c/4f51d169fd0d4821bce775618db024062b09a3f7
- https://git.kernel.org/stable/c/5f80fd2ff8bfd13e41554741740e0ca8e6445ded
- https://git.kernel.org/stable/c/8ce469d23205249bb17c1135ccadea879576adfc
- https://git.kernel.org/stable/c/8ee067cf0cf82429e9b204283c7d0d8d6891d10e
- https://git.kernel.org/stable/c/c8222ef6cf29dd7cad21643228f96535cc02b327
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23150
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was
caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
Call Trace:
- https://git.kernel.org/stable/c/16d9067f00e3a7d1df7c3aa9c20d214923d27e10
- https://git.kernel.org/stable/c/17df39f455f1289319d4d09e4826aa46852ffd17
- https://git.kernel.org/stable/c/2883e9e74f73f9265e5f8d1aaaa89034b308e433
- https://git.kernel.org/stable/c/2eeb1085bf7bd5c7ba796ca4119925fa5d336a3f
- https://git.kernel.org/stable/c/35d0aa6db9d93307085871ceab8a729594a98162
- https://git.kernel.org/stable/c/515c34cff899eb5dae6aa7eee01c1295b07d81af
- https://git.kernel.org/stable/c/94824ac9a8aaf2fb3c54b4bdde842db80ffa555d
- https://git.kernel.org/stable/c/ab0cc5c25552ae0d20eae94b40a93be11b080fc5
- https://git.kernel.org/stable/c/b96bd2c3db26ad0daec5b78c85c098b53900e2e1
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23151
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Fix race between unprepare and queue_buf A client driver may use mhi_unprepare_from_transfer() to quiesce incoming data during the client driver's tear down. The client driver might also be processing data at the same time, resulting in a call to mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs after mhi_unprepare_from_transfer() has torn down the channel, a panic will occur due to an invalid dereference leading to a page fault. This occurs because mhi_gen_tre() does not verify the channel state after locking it. Fix this by having mhi_gen_tre() confirm the channel state is valid, or return error to avoid accessing deinitialized data. [mani: added stable tag]
- https://git.kernel.org/stable/c/0686a818d77a431fc3ba2fab4b46bbb04e8c9380
- https://git.kernel.org/stable/c/178e5657c8fd285125cc6743a81b513bce099760
- https://git.kernel.org/stable/c/3e7ecf181cbdde9753204ada3883ca1704d8702b
- https://git.kernel.org/stable/c/5f084993c90d9d0b4a52a349ede5120f992a7ca1
- https://git.kernel.org/stable/c/899d0353ea69681f474b6bc9de32c663b89672da
- https://git.kernel.org/stable/c/a77955f7704b2a00385e232cbcc1cb06b5c7a425
- https://git.kernel.org/stable/c/ee1fce83ed56450087309b9b74ad9bcb2b010fa6
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23156
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi_parser: refactor hfi packet parsing logic words_count denotes the number of words in total payload, while data points to payload of various property within it. When words_count reaches last word, data can access memory beyond the total payload. This can lead to OOB access. With this patch, the utility api for handling individual properties now returns the size of data consumed. Accordingly remaining bytes are calculated before parsing the payload, thereby eliminates the OOB access possibilities.
- https://git.kernel.org/stable/c/05b07e52a0d08239147ba3460045855f4fb398de
- https://git.kernel.org/stable/c/0beabe9b49190a02321b02792b29fc0f0e28b51f
- https://git.kernel.org/stable/c/0f9a4bab7d83738963365372e4745854938eab2d
- https://git.kernel.org/stable/c/6d278c5548d840c4d85d445347b2a5c31b2ab3a0
- https://git.kernel.org/stable/c/9edaaa8e3e15aab1ca413ab50556de1975bcb329
- https://git.kernel.org/stable/c/a736c72d476d1c7ca7be5018f2614ee61168ad01
- https://git.kernel.org/stable/c/bb3fd8b7906a12dc2b61389abb742bf6542d97fb
- https://git.kernel.org/stable/c/f195e94c7af921d99abd79f57026a218d191d2c7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23157
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi_parser: add check to avoid out of bound access There is a possibility that init_codecs is invoked multiple times during manipulated payload from video firmware. In such case, if codecs_count can get incremented to value more than MAX_CODEC_NUM, there can be OOB access. Reset the count so that it always starts from beginning.
- https://git.kernel.org/stable/c/172bf5a9ef70a399bb227809db78442dc01d9e48
- https://git.kernel.org/stable/c/1ad6aa1464b8a5ce5c194458315021e8d216108e
- https://git.kernel.org/stable/c/26bbedd06d85770581fda5d78e78539bb088fad1
- https://git.kernel.org/stable/c/2b8b9ea4e26a501eb220ea189e42b4527e65bdfa
- https://git.kernel.org/stable/c/53e376178ceacca3ef1795038b22fc9ef45ff1d3
- https://git.kernel.org/stable/c/b2541e29d82da8a0df728aadec3e0a8db55d517b
- https://git.kernel.org/stable/c/cb5be9039f91979f8a2fac29f529f746d7848f3e
- https://git.kernel.org/stable/c/d4d88ece4ba91df5b02f1d3f599650f9e9fc0f45
- https://git.kernel.org/stable/c/e5133a0b25463674903fdc0528e0a29b7267130e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23158
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: add check to handle incorrect queue size qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.
- https://git.kernel.org/stable/c/101a86619aab42bb61f2253bbf720121022eab86
- https://git.kernel.org/stable/c/1b86c1917e16bafbbb08ab90baaff533aa36c62d
- https://git.kernel.org/stable/c/32af5c1fdb9bc274f52ee0472d3b060b18e4aab4
- https://git.kernel.org/stable/c/40084302f639b3fe954398c5ba5ee556b7242b54
- https://git.kernel.org/stable/c/679424f8b31446f90080befd0300ea915485b096
- https://git.kernel.org/stable/c/69baf245b23e20efda0079238b27fc63ecf13de1
- https://git.kernel.org/stable/c/a45957bcde529169188929816775a575de77d84f
- https://git.kernel.org/stable/c/cf5f7bb4e0d786f4d9d50ae6b5963935eab71d75
- https://git.kernel.org/stable/c/edb89d69b1438681daaf5ca90aed3242df94cc96
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23159
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: add a check to handle OOB in sfr region sfr->buf_size is in shared memory and can be modified by malicious user. OOB write is possible when the size is made higher than actual sfr data buffer. Cap the size to allocated size for such cases.
- https://git.kernel.org/stable/c/1b8fb257234e7d2d4b3f48af07c5aa5e11c71634
- https://git.kernel.org/stable/c/4dd109038d513b92d4d33524ffc89ba32e02ba48
- https://git.kernel.org/stable/c/4e95233af57715d81830fe82b408c633edff59f4
- https://git.kernel.org/stable/c/530f623f56a6680792499a8404083e17f8ec51f4
- https://git.kernel.org/stable/c/5af611c70fb889d46d2f654b8996746e59556750
- https://git.kernel.org/stable/c/8879397c0da5e5ec1515262995e82cdfd61b282a
- https://git.kernel.org/stable/c/a062d8de0be5525ec8c52f070acf7607ec8cbfe4
- https://git.kernel.org/stable/c/d78a8388a27b265fcb2b8d064f088168ac9356b0
- https://git.kernel.org/stable/c/f4b211714bcc70effa60c34d9fa613d182e3ef1e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23161
In the Linux kernel, the following vulnerability has been resolved:
PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type
The access to the PCI config space via pci_ops::read and pci_ops::write is
a low-level hardware access. The functions can be accessed with disabled
interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this
purpose.
A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be
acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in
the same context as the pci_lock.
Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with
interrupts disabled.
This was reported as:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
Call Trace:
rt_spin_lock+0x4e/0x130
vmd_pci_read+0x8d/0x100 [vmd]
pci_user_read_config_byte+0x6f/0xe0
pci_read_config+0xfe/0x290
sysfs_kf_bin_read+0x68/0x90
[bigeasy: reword commit message]
Tested-off-by: Luis Claudio R. Goncalves
- https://git.kernel.org/stable/c/13e5148f70e81991acbe0bab5b1b50ba699116e7
- https://git.kernel.org/stable/c/18056a48669a040bef491e63b25896561ee14d90
- https://git.kernel.org/stable/c/20d0a9062c031068fa39f725a32f182b709b5525
- https://git.kernel.org/stable/c/2358046ead696ca5c7c628d6c0e2c6792619a3e5
- https://git.kernel.org/stable/c/5c3cfcf0b4bf43530788b08a8eaf7896ec567484
- https://git.kernel.org/stable/c/c250262d6485ca333e9821f85b07eb383ec546b1
- https://git.kernel.org/stable/c/c2968c812339593ac6e2bdd5cc3adabe3f05fa53
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-23163
In the Linux kernel, the following vulnerability has been resolved:
net: vlan: don't propagate flags on open
With the device instance lock, there is now a possibility of a deadlock:
[ 1.211455] ============================================
[ 1.211571] WARNING: possible recursive locking detected
[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted
[ 1.211823] --------------------------------------------
[ 1.211936] ip/184 is trying to acquire lock:
[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0
[ 1.212207]
[ 1.212207] but task is already holding lock:
[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0
[ 1.212487]
[ 1.212487] other info that might help us debug this:
[ 1.212626] Possible unsafe locking scenario:
[ 1.212626]
[ 1.212751] CPU0
[ 1.212815] ----
[ 1.212871] lock(&dev->lock);
[ 1.212944] lock(&dev->lock);
[ 1.213016]
[ 1.213016] *** DEADLOCK ***
[ 1.213016]
[ 1.213143] May be due to missing lock nesting notation
[ 1.213143]
[ 1.213294] 3 locks held by ip/184:
[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0
[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0
[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0
[ 1.213895]
[ 1.213895] stack backtrace:
[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5
[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
[ 1.213994] Call Trace:
[ 1.213995]
- https://git.kernel.org/stable/c/27b918007d96402aba10ed52a6af8015230f1793
- https://git.kernel.org/stable/c/299d7d27af6b5844cda06a0fdfa635705e1bc50f
- https://git.kernel.org/stable/c/523fa0979d842443aa14b80002e45b471cbac137
- https://git.kernel.org/stable/c/538b43aa21e3b17c110104efd218b966d2eda5f8
- https://git.kernel.org/stable/c/53fb25e90c0a503a17c639341ba5e755cb2feb5c
- https://git.kernel.org/stable/c/8980018a9806743d9b80837330d46f06ecf78516
- https://git.kernel.org/stable/c/a32f1d4f1f4c9d978698f3c718621f6198f2e7ac
- https://git.kernel.org/stable/c/b1e3eeb037256a2f1206a8d69810ec47eb152026
- https://git.kernel.org/stable/c/d537859e56bcc3091805c524484a4c85386b3cc8
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37738
In the Linux kernel, the following vulnerability has been resolved:
ext4: ignore xattrs past end
Once inside 'ext4_xattr_inode_dec_ref_all' we should
ignore xattrs entries past the 'end' entry.
This fixes the following KASAN reported issue:
==================================================================
BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90
Read of size 4 at addr ffff888012c120c4 by task repro/2065
CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/362a90cecd36e8a5c415966d0b75b04a0270e4dd
- https://git.kernel.org/stable/c/3bc6317033f365ce578eb6039445fb66162722fd
- https://git.kernel.org/stable/c/6aff941cb0f7d0c897c3698ad2e30672709135e3
- https://git.kernel.org/stable/c/76c365fa7e2a8bb85f0190cdb4b8cdc99b2fdce3
- https://git.kernel.org/stable/c/836e625b03a666cf93ff5be328c8cb30336db872
- https://git.kernel.org/stable/c/c8e008b60492cf6fd31ef127aea6d02fd3d314cd
- https://git.kernel.org/stable/c/cf9291a3449b04688b81e32621e88de8f4314b54
- https://git.kernel.org/stable/c/eb59cc31b6ea076021d14b04e7faab1636b87d0e
- https://git.kernel.org/stable/c/f737418b6de31c962c7192777ee4018906975383
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37739
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()
syzbot reports an UBSAN issue as below:
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10
index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]')
CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0
Call Trace:
- https://git.kernel.org/stable/c/67e16ccba74dd8de0a7b10062f1e02d77432f573
- https://git.kernel.org/stable/c/6ba8b41d0aa4b82f90f0c416cb53fcef9696525d
- https://git.kernel.org/stable/c/8b5e5aac44fee122947a269f9034c048e4c295de
- https://git.kernel.org/stable/c/98dbf2af63de0b551082c9bc48333910e009b09f
- https://git.kernel.org/stable/c/a67e1bf03c609a751d1740a1789af25e599966fa
- https://git.kernel.org/stable/c/d7242fd7946d4cba0411effb6b5048ca55125747
- https://git.kernel.org/stable/c/e6494977bd4a83862118a05f57a8df40256951c0
- https://git.kernel.org/stable/c/ecc461331604b07cdbdb7360dbdf78471653264c
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37740
In the Linux kernel, the following vulnerability has been resolved: jfs: add sanity check for agwidth in dbMount The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG. To avoid this issue, add a check for agwidth in dbAllocAG.
- https://git.kernel.org/stable/c/722e72f7f9c69fcb3ab7988c2471feff7a4c8de1
- https://git.kernel.org/stable/c/a065cec230aa807c18828a3eee82f1c8592c2adf
- https://git.kernel.org/stable/c/a260bf14cd347878f01f70739ba829442a474a16
- https://git.kernel.org/stable/c/a741f29ac8b6374c9904be8b7ac7cdfcd7e7e4fa
- https://git.kernel.org/stable/c/c8c96a9e7660e5e5eea445978fe8f2e432d91c1f
- https://git.kernel.org/stable/c/cc0bc4cb62ce5fa0c383e3bf0765d01f46bd49ac
- https://git.kernel.org/stable/c/ccd97c8a4f90810f228ee40d1055148fa146dd57
- https://git.kernel.org/stable/c/ddf2846f22e8575d6b4b6a66f2100f168b8cd73d
- https://git.kernel.org/stable/c/e3f85edb03183fb06539e5b50dd2c4bb42b869f0
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37741
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4,
which does not match the mounted loop device, causing the mapping of the
mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(),
read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the
metapage data it returns is corrupted, which causes the nlink value of 0 to be
assigned to the iag inode when executing copy_from_dinode(), which ultimately
causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1]
WARNING: possible recursive locking detected
6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
--------------------------------------------
syz-executor301/5309 is trying to acquire lock:
ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock:
ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index]));
lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309:
#0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515
#1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]
#1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026
#2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
#3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]
#3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
#3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669
#4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]
#4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
#4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace:
CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/5b2f26d3fba4e9aac314f8bc0963b3fc28c0e456
- https://git.kernel.org/stable/c/86bfeaa18f9e4615b97f2d613e0fcc4ced196527
- https://git.kernel.org/stable/c/8b5ce75f8bd3ddf480cc0a240d7ff5cdea0444f9
- https://git.kernel.org/stable/c/994787341358816d91b2fded288ecb7f129f2b27
- https://git.kernel.org/stable/c/a2b560815528ae8e266fca6038bb5585d13aaef4
- https://git.kernel.org/stable/c/aeb926e605f97857504bdf748f575e40617e2ef9
- https://git.kernel.org/stable/c/b3c4884b987e5d8d0ec061a4d52653c4f4b9c37e
- https://git.kernel.org/stable/c/b61e69bb1c049cf507e3c654fa3dc1568231bd07
- https://git.kernel.org/stable/c/c9541c2bd0edbdbc5c1148a84d3b48dc8d1b8af2
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37742
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of imap allocated in the diMount() function syzbot reports that hex_dump_to_buffer is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276 diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876 jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156 evict+0x723/0xd10 fs/inode.c:796 iput_final fs/inode.c:1946 [inline] iput+0x97b/0xdb0 fs/inode.c:1972 txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733 kthread+0x6b9/0xef0 kernel/kthread.c:464 ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] __kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320 kmalloc_noprof include/linux/slab.h:901 [inline] diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105 jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176 jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523 get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636 get_tree_bdev+0x37/0x50 fs/super.c:1659 jfs_get_tree+0x34/0x40 fs/jfs/super.c:635 vfs_get_tree+0xb1/0x5a0 fs/super.c:1814 do_new_mount+0x71f/0x15e0 fs/namespace.c:3560 path_mount+0x742/0x1f10 fs/namespace.c:3887 do_mount fs/namespace.c:3900 [inline] __do_sys_mount fs/namespace.c:4111 [inline] __se_sys_mount+0x71f/0x800 fs/namespace.c:4088 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4088 x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ===================================================== The reason is that imap is not properly initialized after memory allocation. It will cause the snprintf() function to write uninitialized data into linebuf within hex_dump_to_buffer(). Fix this by using kzalloc instead of kmalloc to clear its content at the beginning in diMount().
- https://git.kernel.org/stable/c/067347e00a3a7d04afed93f080c6c131e5dd15ee
- https://git.kernel.org/stable/c/4f10732712fce33e53703ffe5ed9155f23814097
- https://git.kernel.org/stable/c/63148ce4904faa668daffdd1d3c1199ae315ef2c
- https://git.kernel.org/stable/c/7057f3aab47629d38e54eae83505813cf0da1e4b
- https://git.kernel.org/stable/c/9629d7d66c621671d9a47afe27ca9336bfc8a9ea
- https://git.kernel.org/stable/c/cab1852368dd74d629ee02abdbc559218ca64dde
- https://git.kernel.org/stable/c/d0d7eca253ccd0619b3d2b683ffe32218ebca9ac
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37748
In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group Currently, mtk_iommu calls during probe iommu_device_register before the hw_list from driver data is initialized. Since iommu probing issue fix, it leads to NULL pointer dereference in mtk_iommu_device_group when hw_list is accessed with list_first_entry (not null safe). So, change the call order to ensure iommu_device_register is called after the driver data are initialized.
- https://git.kernel.org/stable/c/2f75cb27bef43c8692b0f5e471e5632f6a9beb99
- https://git.kernel.org/stable/c/38e8844005e6068f336a3ad45451a562a0040ca1
- https://git.kernel.org/stable/c/69f9d2d37d1207c5a73dac52a4ce1361ead707f5
- https://git.kernel.org/stable/c/6abd09bed43b8d83d461e0fb5b9a200a06aa8a27
- https://git.kernel.org/stable/c/a0842539e8ef9386c070156103aff888e558a60c
- https://git.kernel.org/stable/c/ce7d3b2f6f393fa35f0ea12861b83a1ca28b295c
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37749
In the Linux kernel, the following vulnerability has been resolved: net: ppp: Add bound checking for skb data on ppp_sync_txmung Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. [pabeni@redhat.com: fixed subj typo]
- https://git.kernel.org/stable/c/1f6eb9fa87a781d5370c0de7794ae242f1a95ee5
- https://git.kernel.org/stable/c/529401c8f12ecc35f9ea5d946d5a5596cf172b48
- https://git.kernel.org/stable/c/6e8a6bf43cea4347121ab21bb1ed8d7bef7e732e
- https://git.kernel.org/stable/c/99aa698dec342a07125d733e39aab4394b3b7e05
- https://git.kernel.org/stable/c/aabc6596ffb377c4c9c8f335124b92ea282c9821
- https://git.kernel.org/stable/c/b4c836d33ca888695b2f2665f948bc1b34fbd533
- https://git.kernel.org/stable/c/b78f2b458f56a5a4d976c8e01c43dbf58d3ea2ca
- https://git.kernel.org/stable/c/de5a4f0cba58625e88b7bebd88f780c8c0150997
- https://git.kernel.org/stable/c/fbaffe8bccf148ece8ad67eb5d7aa852cabf59c8
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37752
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: move the limit validation
It is not sufficient to directly validate the limit on the data that
the user passes as it can be updated based on how the other parameters
are changed.
Move the check at the end of the configuration update process to also
catch scenarios where the limit is indirectly updated, for example
with the following configurations:
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
This fixes the following syzkaller reported crash:
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6
index 65535 is out of range for type 'struct sfq_head[128]'
CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024
Call Trace:
- https://git.kernel.org/stable/c/1348214fa042a71406964097e743c87a42c85a49
- https://git.kernel.org/stable/c/5e5e1fcc1b8ed57f902c424c5d9b328a3a19073d
- https://git.kernel.org/stable/c/6c589aa318023690f1606c666a7fb5f4c1c9c219
- https://git.kernel.org/stable/c/7d62ded97db6b7c94c891f704151f372b1ba4688
- https://git.kernel.org/stable/c/8fadc871a42933aacb7f1ce9ed9a96485e2c9cf4
- https://git.kernel.org/stable/c/b36a68192037d1614317a09b0d78c7814e2eecf9
- https://git.kernel.org/stable/c/b3bf8f63e6179076b57c9de660c9f80b5abefe70
- https://git.kernel.org/stable/c/d2718324f9e329b10ddc091fba5a0ba2b9d4d96a
- https://git.kernel.org/stable/c/f86293adce0c201cfabb283ef9d6f21292089bb8
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37756
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then
run into all sort of unexpected corner cases. I have a vague
recollection of Eric pointing this out to us a long time ago.
Supporting disconnect is really hard, for one thing if offload
is enabled we'd need to wait for all packets to be _acked_.
Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp,
but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
Call Trace:
- https://git.kernel.org/stable/c/2bcad8fefcecdd5f005d8c550b25d703c063c34a
- https://git.kernel.org/stable/c/5071a1e606b30c0c11278d3c6620cd6a24724cf6
- https://git.kernel.org/stable/c/7bdcf5bc35ae59fc4a0fa23276e84b4d1534a3cf
- https://git.kernel.org/stable/c/8513411ec321942bd3cfed53d5bb700665c67d86
- https://git.kernel.org/stable/c/9fcbca0f801580cbb583e9cb274e2c7fbe766ca6
- https://git.kernel.org/stable/c/ac91c6125468be720eafde9c973994cb45b61d44
- https://git.kernel.org/stable/c/c665bef891e8972e1d3ce5bbc0d42a373346a2c3
- https://git.kernel.org/stable/c/f3ce4d3f874ab7919edca364c147ac735f9f1d04
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37757
In the Linux kernel, the following vulnerability has been resolved: tipc: fix memory leak in tipc_link_xmit In case the backlog transmit queue for system-importance messages is overloaded, tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated. This commit fixes this issue by purging the skb list before tipc_link_xmit() returns.
- https://git.kernel.org/stable/c/09c2dcda2c551bba30710c33f6ac678ae7395389
- https://git.kernel.org/stable/c/24e6280cdd7f8d01fc6b9b365fb800c2fb7ea9bb
- https://git.kernel.org/stable/c/69ae94725f4fc9e75219d2d69022029c5b24bc9a
- https://git.kernel.org/stable/c/7c5957f7905b4aede9d7a559d271438f3ca9e852
- https://git.kernel.org/stable/c/84895f5ce3829d9fc030e5ec2d8729da4c0c9d08
- https://git.kernel.org/stable/c/a40cbfbb8f95c325430f017883da669b2aa927d4
- https://git.kernel.org/stable/c/d0e02d3d27a0b4dcb13f954f537ca1dd8f282dcf
- https://git.kernel.org/stable/c/d4d40e437adb376be16b3a12dd5c63f0fa768247
- https://git.kernel.org/stable/c/ed06675d3b8cd37120b447646d53f7cd3e6fcd63
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37758
In the Linux kernel, the following vulnerability has been resolved: ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe() devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does not check for this case, which can result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue.
- https://git.kernel.org/stable/c/17d5e6e915fad5a261db3698c9c5bbe702102d7c
- https://git.kernel.org/stable/c/2ba9e4c69207777bb0775c7c091800ecd69de144
- https://git.kernel.org/stable/c/2dc53c7a0c1f57b082931facafa804a7ca32a9a6
- https://git.kernel.org/stable/c/5b09bf6243b0bc0ae58bd9efdf6f0de5546f8d06
- https://git.kernel.org/stable/c/a551f75401793ba8075d7f46ffc931ce5151f03f
- https://git.kernel.org/stable/c/ad320e408a8c95a282ab9c05cdf0c9b95e317985
- https://git.kernel.org/stable/c/c022287f6e599422511aa227dc6da37b58d9ceac
- https://git.kernel.org/stable/c/d0d720f9282839b9db625a376c02a1426a16b0ae
- https://git.kernel.org/stable/c/ee2b0301d6bfe16b35d57947687c664ecb815775
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37765
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: prime: fix ttm_bo_delayed_delete oops
Fix an oops in ttm_bo_delayed_delete which results from dererencing a
dangling pointer:
Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP
CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216
Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024
Workqueue: ttm ttm_bo_delayed_delete [ttm]
RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290
Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b
RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b
R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc
FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/12b038d521c75e3521522503becf3bc162628469
- https://git.kernel.org/stable/c/31e94c7989572f96926673614a3b958915a13ca9
- https://git.kernel.org/stable/c/47761deabb69a5df0c2c4ec400d80bb3e072bd2e
- https://git.kernel.org/stable/c/6b95947ee780f4e1fb26413a1437d05bcb99712b
- https://git.kernel.org/stable/c/6e2c805996a49998d31ac522beb1534ca417e761
- https://git.kernel.org/stable/c/706868a1a1072cffd8bd63f7e161d79141099849
- https://git.kernel.org/stable/c/8ec0fbb28d049273bfd4f1e7a5ae4c74884beed3
- https://git.kernel.org/stable/c/ada78110b2d3ec88b398a49703bd336d4cee7a08
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37766
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/068091b796480819bf70b159f17e222ad8bea900
- https://git.kernel.org/stable/c/42f7b5d12c28b2a601a98d10a80c6db1fe1a2900
- https://git.kernel.org/stable/c/4e3d9508c056d7e0a56b58d5c81253e2a0d22b6c
- https://git.kernel.org/stable/c/6b9f9b998b107c7539f148a013d789ddb860c3b9
- https://git.kernel.org/stable/c/80814924260cea431a8fc6137d11cc8cb331a10c
- https://git.kernel.org/stable/c/affd2241927a1e74c0aecd50c2d920dc4213c56d
- https://git.kernel.org/stable/c/ce773dd844ee19a605af27f11470887e0f2044a9
- https://git.kernel.org/stable/c/ffd688804425579a472fbd2525bedb58b1d28bd9
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37767
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/327107bd7f052f4ee2d0c966c7ae879822f1814f
- https://git.kernel.org/stable/c/8f7b5987e21e003cafac28f0e4d323e6496f83ba
- https://git.kernel.org/stable/c/c3ff73e3bddf1a6c30d7effe4018d12ba0cadd2e
- https://git.kernel.org/stable/c/f23e9116ebb71b63fe9cec0dcac792aa9af30b0c
- https://git.kernel.org/stable/c/f2904fa2b9da943db6bef7c0f8b3fb4fc14acbc4
- https://git.kernel.org/stable/c/fb803d4bb9ea0a61c21c4987505e4d4ae18f9fdc
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37768
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/3cdd02cb70682d7d205ca6dc02a4d1eb76758d24
- https://git.kernel.org/stable/c/5fc4fb54f6f064c25bfbbfd443aa861d3422dd4c
- https://git.kernel.org/stable/c/7c246a05df51c52fe0852ce56ba10c41e6ed1f39
- https://git.kernel.org/stable/c/8e9c4f8d197d5709c75effa5d58e80b4fa01981a
- https://git.kernel.org/stable/c/9e4f1e21fe7b93a8ef57db433071266c2590e260
- https://git.kernel.org/stable/c/b0742a709be7979c7a480772046a1f36d09dab00
- https://git.kernel.org/stable/c/be0fffc4152aac4f0291ed2d793f3cfee788449d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37769
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm/smu11: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE. (cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71)
- https://git.kernel.org/stable/c/63a150400194592206817124268ff6f43947e8c9
- https://git.kernel.org/stable/c/7ba88b5cccc1a99c1afb96e31e7eedac9907704c
- https://git.kernel.org/stable/c/de2cba068c9c648503973b57696d035cfe58a9f6
- https://git.kernel.org/stable/c/de6f8e0534cfabc528c969d453150ca90b24fb01
- https://git.kernel.org/stable/c/fc9d55377353321e78f9e108d15f72a17e8c6ee2
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37770
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/05de66de280ea1bd0459c994bfd2dd332cfbc2a9
- https://git.kernel.org/stable/c/0c02fcbe4a1393a3c02da6ae35e72493cfdb2155
- https://git.kernel.org/stable/c/4b8c3c0d17c07f301011e2908fecd2ebdcfe3d1c
- https://git.kernel.org/stable/c/587de3ca7875c06fe3c3aa4073a85c4eff46591f
- https://git.kernel.org/stable/c/836a189fb422e7efb81c51d5160e47ec7bc11500
- https://git.kernel.org/stable/c/bd4d90adbca1862d03e581e10e74ab73ec75e61b
- https://git.kernel.org/stable/c/e109528bbf460e50074c156253d9080d223ee37f
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37771
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/402964994e8ece29702383b234fabcf04791ff95
- https://git.kernel.org/stable/c/5096174074114f83c700a27869c54362cbb10f3e
- https://git.kernel.org/stable/c/6413fed016208171592c88b5df002af8a1387e24
- https://git.kernel.org/stable/c/7d641c2b83275d3b0424127b2e0d2d0f7dd82aef
- https://git.kernel.org/stable/c/b7c41df4913789ebfe73cc1e17c6401d4c5eab69
- https://git.kernel.org/stable/c/baa54adb5e0599299b8f088efb5544d876a3eb62
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37772
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix workqueue crash in cma_netevent_work_handler
struct rdma_cm_id has member "struct work_struct net_work"
that is reused for enqueuing cma_netevent_work_handler()s
onto cma_wq.
Below crash[1] can occur if more than one call to
cma_netevent_callback() occurs in quick succession,
which further enqueues cma_netevent_work_handler()s for the
same rdma_cm_id, overwriting any previously queued work-item(s)
that was just scheduled to run i.e. there is no guarantee
the queued work item may run between two successive calls
to cma_netevent_callback() and the 2nd INIT_WORK would overwrite
the 1st work item (for the same rdma_cm_id), despite grabbing
id_table_lock during enqueue.
Also drgn analysis [2] indicates the work item was likely overwritten.
Fix this by moving the INIT_WORK() to __rdma_create_id(),
so that it doesn't race with any existing queue_work() or
its worker thread.
[1] Trimmed crash stack:
=============================================
BUG: kernel NULL pointer dereference, address: 0000000000000008
kworker/u256:6 ... 6.12.0-0...
Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)
RIP: 0010:process_one_work+0xba/0x31a
Call Trace:
worker_thread+0x266/0x3a0
kthread+0xcf/0x100
ret_from_fork+0x31/0x50
ret_from_fork_asm+0x1a/0x30
=============================================
[2] drgn crash analysis:
>>> trace = prog.crashed_thread().stack_trace()
>>> trace
(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)
(1) __crash_kexec (kernel/crash_core.c:122:4)
(2) panic (kernel/panic.c:399:3)
(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)
...
(8) process_one_work (kernel/workqueue.c:3168:2)
(9) process_scheduled_works (kernel/workqueue.c:3310:3)
(10) worker_thread (kernel/workqueue.c:3391:4)
(11) kthread (kernel/kthread.c:389:9)
Line workqueue.c:3168 for this kernel version is in process_one_work():
3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
>>> trace[8]["work"]
*(struct work_struct *)0xffff92577d0a21d8 = {
.data = (atomic_long_t){
.counter = (s64)536870912, <=== Note
},
.entry = (struct list_head){
.next = (struct list_head *)0xffff924d075924c0,
.prev = (struct list_head *)0xffff924d075924c0,
},
.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,
}
Suspicion is that pwq is NULL:
>>> trace[8]["pwq"]
(struct pool_workqueue *)
- https://git.kernel.org/stable/c/45f5dcdd049719fb999393b30679605f16ebce14
- https://git.kernel.org/stable/c/51003b2c872c63d28bcf5fbcc52cf7b05615f7b7
- https://git.kernel.org/stable/c/b172a4a0de254f1fcce7591833a9a63547c2f447
- https://git.kernel.org/stable/c/c2b169fc7a12665d8a675c1ff14bca1b9c63fb9a
- https://git.kernel.org/stable/c/d23fd7a539ac078df119707110686a5b226ee3bb
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-05
CVE-2025-37773
In the Linux kernel, the following vulnerability has been resolved: virtiofs: add filesystem context source name check In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added.
- https://git.kernel.org/stable/c/599d1e2a6aecc44acf22fe7ea6f5e84a7e526abe
- https://git.kernel.org/stable/c/5ee09cdaf3414f6c92960714af46d3d90eede2f3
- https://git.kernel.org/stable/c/9d6dcf18a1b49990295ac8a05fd9bdfd27ccbf88
- https://git.kernel.org/stable/c/a648d80f8d9b208beee03a2d9aa690cfacf1d41e
- https://git.kernel.org/stable/c/a94fd938df2b1628da66b498aa0eeb89593bc7a2
- https://git.kernel.org/stable/c/b84f13fdad10a543e2e65bab7e81b3f0bceabd67
- https://git.kernel.org/stable/c/c3e31d613951c299487844c4d1686a933e8ee291
- https://git.kernel.org/stable/c/f6ec52710dc5e156b774cbef5d0f5c99b1c53a80
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-03-17
CVE-2025-37775
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix the warning from __kernel_write_iter [ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280 This patch doesn't allow writing to directory.
- https://git.kernel.org/stable/c/1ed343481ba6911178bc5ca7a51be319eafcc747
- https://git.kernel.org/stable/c/2a879da5c34a1e5d971e815d5b30f27eb6d69efc
- https://git.kernel.org/stable/c/44079e544c9f6e3e9fb43a16ddf8b08cf686d657
- https://git.kernel.org/stable/c/b37f2f332b40ad1c27f18682a495850f2f04db0a
- https://git.kernel.org/stable/c/b7ce8db490286c2e009758fa1416d66aeb333614
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-04-18
CVE-2025-37778
In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.
- https://git.kernel.org/stable/c/1db2451de23e98bc864c6a6e52aa0d82c91cb325
- https://git.kernel.org/stable/c/1e440d5b25b7efccb3defe542a73c51005799a5f
- https://git.kernel.org/stable/c/6e30c0e10210c714f3d4453dc258d4abcc70364e
- https://git.kernel.org/stable/c/b61f04d5d73c53d183019bafe22fb700a739bac5
- https://git.kernel.org/stable/c/d5b554bc8d554ed6ddf443d3db2fad9f665cec10
- https://git.kernel.org/stable/c/e83e39a5f6a01a81411a4558a59a10f87aa88dd6
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-37780
In the Linux kernel, the following vulnerability has been resolved: isofs: Prevent the use of too small fid syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1] The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block. [1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
- https://git.kernel.org/stable/c/007124c896e7d4614ac1f6bd4dedb975c35a2a8e
- https://git.kernel.org/stable/c/0405d4b63d082861f4eaff9d39c78ee9dc34f845
- https://git.kernel.org/stable/c/0fdafdaef796816a9ed0fd7ac812932d569d9beb
- https://git.kernel.org/stable/c/56dfffea9fd3be0b3795a9ca6401e133a8427e0b
- https://git.kernel.org/stable/c/5e7de55602c61c8ff28db075cc49c8dd6989d7e0
- https://git.kernel.org/stable/c/63d5a3e207bf315a32c7d16de6c89753a759f95a
- https://git.kernel.org/stable/c/952e7a7e317f126d0a2b879fc531b716932d5ffa
- https://git.kernel.org/stable/c/ee01a309ebf598be1ff8174901ed6e91619f1749
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-37781
In the Linux kernel, the following vulnerability has been resolved:
i2c: cros-ec-tunnel: defer probe if parent EC is not present
When i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent
device will not be found, leading to NULL pointer dereference.
That can also be reproduced by unbinding the controller driver and then
loading i2c-cros-ec-tunnel module (or binding the device).
[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058
[ 271.998215] #PF: supervisor read access in kernel mode
[ 272.003351] #PF: error_code(0x0000) - not-present page
[ 272.008485] PGD 0 P4D 0
[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI
[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5
[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC
[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021
[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel]
[ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9
[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282
[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000
[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00
[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000
[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000
[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10
[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000
[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0
[ 272.129155] Call Trace:
[ 272.131606]
- https://git.kernel.org/stable/c/092de5ac8cb2eaa9593a765fa92ba39d8173f984
- https://git.kernel.org/stable/c/1355b5ca4782be85a2ef7275e4c508f770d0fb27
- https://git.kernel.org/stable/c/3090cad5ccff8963b95160f4060068048a1e4c4c
- https://git.kernel.org/stable/c/424eafe65647a8d6c690284536e711977153195a
- https://git.kernel.org/stable/c/b66d4910a608427367c4e21499e149f085782df7
- https://git.kernel.org/stable/c/cd83035b6f2a102c2d5acd3bfb2a11ff967aaba6
- https://git.kernel.org/stable/c/da8edc9eb2516aface7f86be5fa6d09c0d07b9f8
- https://git.kernel.org/stable/c/e89bf1311d4497c6743f3021e9c481b16c3a41c9
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-37787
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registered Russell King reports that a system with mv88e6xxx dereferences a NULL pointer when unbinding this driver: https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/ The crash seems to be in devlink_region_destroy(), which is not NULL tolerant but is given a NULL devlink global region pointer. At least on some chips, some devlink regions are conditionally registered since the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue; These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chip does not have an STU or PVT, it should crash like this. To fix the issue, avoid unregistering those regions which are NULL, i.e. were skipped at mv88e6xxx_setup_devlink_regions_global() time.
- https://git.kernel.org/stable/c/3665695e3572239dc233216f06b41f40cc771889
- https://git.kernel.org/stable/c/5f5e95945bb1e08be7655da6acba648274db457d
- https://git.kernel.org/stable/c/8ccdf5e24b276848eefb2755e05ff0f005a0c4a1
- https://git.kernel.org/stable/c/b3c70dfe51f10df60db2646c08cebd24bcdc5247
- https://git.kernel.org/stable/c/bbb80f004f7a90c3dcaacc982c59967457254a05
- https://git.kernel.org/stable/c/c84f6ce918a9e6f4996597cbc62536bbf2247c96
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-37788
In the Linux kernel, the following vulnerability has been resolved: cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path In the for loop used to allocate the loc_array and bmap for each port, a memory leak is possible when the allocation for loc_array succeeds, but the allocation for bmap fails. This is because when the control flow goes to the label free_eth_finfo, only the allocations starting from (i-1)th iteration are freed. Fix that by freeing the loc_array in the bmap allocation error path.
- https://git.kernel.org/stable/c/00ffb3724ce743578163f5ade2884374554ca021
- https://git.kernel.org/stable/c/08aa59c0be768596467552c129e9f82166779a67
- https://git.kernel.org/stable/c/118d05b530343cd9322607b9719405ba254a4183
- https://git.kernel.org/stable/c/76deedea08899885f076aba0bb80bd1276446822
- https://git.kernel.org/stable/c/dafb6e433ab2333b67be05433dc9c6ccbc7b1284
- https://git.kernel.org/stable/c/e9de08e15aee35b96064960f95997bb6c1209c4b
- https://git.kernel.org/stable/c/fa2d7708955e4f8212fd69bab1da604e60cb0b15
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-37789
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix nested key length validation in the set() action It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first.
- https://git.kernel.org/stable/c/03d7262dd53e8c404da35cc81aaa887fd901f76b
- https://git.kernel.org/stable/c/1489c195c8eecd262aa6712761ba5288203e28ec
- https://git.kernel.org/stable/c/54c6957d1123a2032099b9eab51c314800f677ce
- https://git.kernel.org/stable/c/65d91192aa66f05710cfddf6a14b5a25ee554dba
- https://git.kernel.org/stable/c/7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd
- https://git.kernel.org/stable/c/824a7c2df5127b2402b68a21a265d413e78dcad7
- https://git.kernel.org/stable/c/a27526e6b48eee9e2d82efff502c4f272f1a91d4
- https://git.kernel.org/stable/c/be80768d4f3b6fd13f421451cc3fee8778aba8bc
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-37790
In the Linux kernel, the following vulnerability has been resolved: net: mctp: Set SOCK_RCU_FREE Bind lookup runs under RCU, so ensure that a socket doesn't go away in the middle of a lookup.
- https://git.kernel.org/stable/c/3f899bd6dd56ddc46509b526e23a8f0a97712a6d
- https://git.kernel.org/stable/c/52024cd6ec71a6ca934d0cc12452bd8d49850679
- https://git.kernel.org/stable/c/5c1313b93c8c2e3904a48aa88e2fa1db28c607ae
- https://git.kernel.org/stable/c/a8a3b61ce140e2b0a72a779e8d70f60c0cf1e47a
- https://git.kernel.org/stable/c/b9764ebebb007249fb733a131b6110ff333b6616
- https://git.kernel.org/stable/c/e3b5edbdb45924a7d4206d13868a2aac71f1e53d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2025-37792
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: Prevent potential NULL dereference The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch: drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'
- https://git.kernel.org/stable/c/2d7c60c2a38b4b461fa960ad0995136a6bfe0756
- https://git.kernel.org/stable/c/324dddea321078a6eeb535c2bff5257be74c9799
- https://git.kernel.org/stable/c/3db6605043b50c8bb768547b23e0222f67ceef3e
- https://git.kernel.org/stable/c/53ceef799dcfc22c734d600811bfc9dd32eaea0a
- https://git.kernel.org/stable/c/73dc99c0ea94abd22379b2d82cacbc73f3e18ec1
- https://git.kernel.org/stable/c/aaf356f872a60db1e96fb762a62c4607fd22741f
- https://git.kernel.org/stable/c/c3e9717276affe59fd8213706db021b493e81e34
- https://git.kernel.org/stable/c/d8441818690d795232331bd8358545c5c95b6b72
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-37794
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Purge vif txq in ieee80211_do_stop() After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point).
- https://git.kernel.org/stable/c/305741e7e63234cbcf9b5c4e6aeca25ba0834be8
- https://git.kernel.org/stable/c/378677eb8f44621ecc9ce659f7af61e5baa94d81
- https://git.kernel.org/stable/c/5f6863dc407f25fcf23fc857f9ac51756a09ea2c
- https://git.kernel.org/stable/c/8bc34db7f771a464ff8f686b6f8d4e04963fec27
- https://git.kernel.org/stable/c/929ec2c9ad34248ef625e137b6118b6e965797d9
- https://git.kernel.org/stable/c/a8df245b5b29f6de98d016dc18e2bb35ec70b0cb
- https://git.kernel.org/stable/c/a932a5ce4eee0cbad20220f950fe7bd3534bcbc9
- https://git.kernel.org/stable/c/c74b84544dee27298a71715b3ce2c40d372b5a23
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-37796
In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x: fix use after free access in at76_disconnect The memory pointed to by priv is freed at the end of at76_delete_device function (using ieee80211_free_hw). But the code then accesses the udev field of the freed object to put the USB device. This may also lead to a memory leak of the usb device. Fix this by using udev from interface.
- https://git.kernel.org/stable/c/152721cbae42713ecfbca6847e0f102ee6b19546
- https://git.kernel.org/stable/c/27c7e63b3cb1a20bb78ed4a36c561ea4579fd7da
- https://git.kernel.org/stable/c/3c619aec1f538333b56746d2f796aab1bca5c9a5
- https://git.kernel.org/stable/c/5e7df74745700f059dc117a620e566964a2e8f2c
- https://git.kernel.org/stable/c/6e4ab3e574c2a335b40fa1f70d1c54fcb58ab33f
- https://git.kernel.org/stable/c/7ca513631fa6ad3011b8b9197cdde0f351103704
- https://git.kernel.org/stable/c/a9682bfef2cf3802515a902e964d774e137be1b9
- https://git.kernel.org/stable/c/c731cdfddcf1be1590d5ba8c9b508f98e3a2b3d6
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-37797
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class handling This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel. The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied.
- https://git.kernel.org/stable/c/20d584a33e480ae80d105f43e0e7b56784da41b9
- https://git.kernel.org/stable/c/28b09a067831f7317c3841812276022d6c940677
- https://git.kernel.org/stable/c/39b9095dd3b55d9b2743df038c32138efa34a9de
- https://git.kernel.org/stable/c/3aa852e3605000d5c47035c3fc3a986d14ccfa9f
- https://git.kernel.org/stable/c/3df275ef0a6ae181e8428a6589ef5d5231e58b5c
- https://git.kernel.org/stable/c/86cd4641c713455a4f1c8e54c370c598c2b1cee0
- https://git.kernel.org/stable/c/bb583c88d23b72d8d16453d24856c99bd93dadf5
- https://git.kernel.org/stable/c/fcc8ede663569c704fb00a702973bd6c00373283
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-37798
In the Linux kernel, the following vulnerability has been resolved: codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue().
- https://git.kernel.org/stable/c/2f9761a94bae33d26e6a81b31b36e7d776d93dc1
- https://git.kernel.org/stable/c/342debc12183b51773b3345ba267e9263bdfaaef
- https://git.kernel.org/stable/c/4d55144b12e742404bb3f8fee6038bafbf45619d
- https://git.kernel.org/stable/c/7a742a9506849d1c1aa71e36c89855ceddc7d58e
- https://git.kernel.org/stable/c/829c49b6b2ff45b043739168fd1245e4e1a91a30
- https://git.kernel.org/stable/c/a57fe60ef4cf96bfbb6b58397ec28bdb5a5c6b31
- https://git.kernel.org/stable/c/cc71a757da78dd4aa1b4a9b19cb011833730ccf2
- https://git.kernel.org/stable/c/e73c838c80dccb9e4f19becc11d9f3cb4a27d483
- https://git.kernel.org/stable/c/eda741fe155ddf5ecd2dd3bfbd4fc3c0c7dbb450
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-03
CVE-2025-37801
In the Linux kernel, the following vulnerability has been resolved: spi: spi-imx: Add check for spi_imx_setupxfer() Add check for the return value of spi_imx_setupxfer(). spi_imx->rx and spi_imx->tx function pointer can be NULL when spi_imx_setupxfer() return error, and make NULL pointer dereference. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: 0x0 spi_imx_pio_transfer+0x50/0xd8 spi_imx_transfer_one+0x18c/0x858 spi_transfer_one_message+0x43c/0x790 __spi_pump_transfer_message+0x238/0x5d4 __spi_sync+0x2b0/0x454 spi_write_then_read+0x11c/0x200
- https://git.kernel.org/stable/c/055ef73bb1afc3f783a9a13b496770a781964a07
- https://git.kernel.org/stable/c/185d376875ea6fb4256b9dc97ee0b4d2b0fdd399
- https://git.kernel.org/stable/c/2b4479eb462ecb39001b38dfb331fc6028dedac8
- https://git.kernel.org/stable/c/2fea0d6d7b5d27fbf55512d51851ba0a346ede52
- https://git.kernel.org/stable/c/951a04ab3a2db4029debfa48d380ef834b93207e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-37803
In the Linux kernel, the following vulnerability has been resolved: udmabuf: fix a buf size overflow issue during udmabuf creation by casting size_limit_mb to u64 when calculate pglimit.
- https://git.kernel.org/stable/c/021ba7f1babd029e714d13a6bf2571b08af96d0f
- https://git.kernel.org/stable/c/13fe12c037b470321436deec393030c6153cfeb9
- https://git.kernel.org/stable/c/29b65a3171a49c9b69f31035146be966cec40b7a
- https://git.kernel.org/stable/c/2b8419c6ecf69007dcff54ea0b9f0b215282c55a
- https://git.kernel.org/stable/c/373512760e13fdaa726faa9502d0f5be2abb3d33
- https://git.kernel.org/stable/c/3f6c9d66e0f8eb9679b57913aa64b4d2266f6fbe
- https://git.kernel.org/stable/c/b2ff4e9c599b000833d16a917f519aa2e4a75de2
- https://git.kernel.org/stable/c/e84a08fc7e25cdad5d9a3def42cc770ff711193f
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-37805
In the Linux kernel, the following vulnerability has been resolved: sound/virtio: Fix cancel_sync warnings on uninitialized work_structs Betty reported hitting the following warning: [ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ... It seems we're hitting the error path in virtsnd_probe(), which triggers a virtsnd_remove() which iterates over the substreams calling cancel_work_sync() on the elapsed_period work_struct. Looking at the code, from earlier in: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg() We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsnd_ctl_query_info() fails, we will exit without having initialized the elapsed_period work_struct. When that error path unwinds we then call virtsnd_remove() which as long as the substreams array is allocated, will iterate through calling cancel_work_sync() on the uninitialized work struct hitting this warning. Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data. Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing. Feedback or thoughts would be appreciated!
- https://git.kernel.org/stable/c/3c7df2e27346eb40a0e86230db1ccab195c97cfe
- https://git.kernel.org/stable/c/54c7b864fbe4423a07b443a4ada0106052942116
- https://git.kernel.org/stable/c/5be9407b41eae20eef9140f5cfbfcbc3d01aaf45
- https://git.kernel.org/stable/c/66046b586c0aaa9332483bcdbd76e3305d6138e9
- https://git.kernel.org/stable/c/9908498ce929a5a052b79bb7942f9ea317312ce4
- https://git.kernel.org/stable/c/e03b10c45c7675b6098190c6e7de1b656d8bcdbe
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-10
CVE-2025-37808
In the Linux kernel, the following vulnerability has been resolved: crypto: null - Use spin lock instead of mutex As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.
- https://git.kernel.org/stable/c/0486de3c1b8223138dcc614846bd76364f758de6
- https://git.kernel.org/stable/c/1b66a5920b7fc7cc6251192a3fcad115b6d75dd5
- https://git.kernel.org/stable/c/1dd4a8561d85dea545cf93f56efc48df8176e218
- https://git.kernel.org/stable/c/8cf2945512a8c0ef74ddd5b5a4f6b6a2fb1a4efb
- https://git.kernel.org/stable/c/dcc47a028c24e793ce6d6efebfef1a1e92f80297
- https://git.kernel.org/stable/c/e27244cbe10658a66b8775be7f0acc4ad2f618d6
- https://git.kernel.org/stable/c/e307c54ac8198bf09652c72603ba6e6d97798410
- https://git.kernel.org/stable/c/f7a5a5c8e1ec16a4b2041398abe95de0e14572ef
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37810
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: check that event count does not exceed event buffer length The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34
- https://git.kernel.org/stable/c/015c39f38e69a491d2abd5e98869a500a9459b3b
- https://git.kernel.org/stable/c/52a7c9d930b95aa8b1620edaba4818040c32631f
- https://git.kernel.org/stable/c/63ccd26cd1f6600421795f6ca3e625076be06c9f
- https://git.kernel.org/stable/c/99d655119b870ee60e4dbf310aa9a1ed8d9ede3d
- https://git.kernel.org/stable/c/a44547015287a19001384fe94dbff84c92ce4ee1
- https://git.kernel.org/stable/c/b43225948b231b3f331194010f84512bee4d9f59
- https://git.kernel.org/stable/c/c0079630f268843a25ed75226169cba40e0d8880
- https://git.kernel.org/stable/c/c4d80e41cb42008dceb35e5dbf52574d93beac0d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37811
In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: ci_hdrc_imx: fix usbmisc handling usbmisc is an optional device property so it is totally valid for the corresponding data->usbmisc_data to have a NULL value. Check that before dereferencing the pointer. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.
- https://git.kernel.org/stable/c/0ee460498ced49196149197c9f6d29a10e5e0798
- https://git.kernel.org/stable/c/121e9f80ea5478bca3a8f3f26593fd66f87da649
- https://git.kernel.org/stable/c/2aa87bd825377f5073b76701780a902cd0fc725a
- https://git.kernel.org/stable/c/4e28f79e3dffa52d327b46d1a78dac16efb5810b
- https://git.kernel.org/stable/c/8060b719676e8c0e5a2222c2977ba0458d9d9535
- https://git.kernel.org/stable/c/887902ca73490f38c69fd6149ef361a041cf912f
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37812
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: Fix deadlock when using NCM gadget The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget"). Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using "iperf --bidir" over NCM ethernet link. The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler.
- https://git.kernel.org/stable/c/09e90a9689a4aac7a2f726dc2aa472b0b37937b7
- https://git.kernel.org/stable/c/48a62deb857f0694f611949015e70ad194d97159
- https://git.kernel.org/stable/c/59a760e4796a3cd88d8b9d7706e0a638de677751
- https://git.kernel.org/stable/c/74cd6e408a4c010e404832f0e4609d29bf1d0c41
- https://git.kernel.org/stable/c/a1059896f2bfdcebcdc7153c3be2307ea319501f
- https://git.kernel.org/stable/c/b96239582531775f2fdcb14de29bdb6870fd4c8c
- https://git.kernel.org/stable/c/c27db84ed44e50ff90d9e3a2a25fae2e0a0fa015
- https://git.kernel.org/stable/c/eebfb64c624fc738b669100173344fb441c5e719
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37815
In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generic_handle_irq. A previous fix patch was submitted where 'generic_handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handle_nested_irq with the mapped IRQ number, leads to a failure in locating the registered handler.
- https://git.kernel.org/stable/c/1263d5f581908602c618c6665e683c4436383a09
- https://git.kernel.org/stable/c/12cc2193f2b9548e8ea5fbce8201b44158222edf
- https://git.kernel.org/stable/c/18eb77c75ed01439f96ae5c0f33461eb5134b907
- https://git.kernel.org/stable/c/4e02059dc91068bc5017b8546f9ec3b930f6d6a6
- https://git.kernel.org/stable/c/62957f58ab3aa7fa792dc6ff3575624062539a4d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37817
In the Linux kernel, the following vulnerability has been resolved: mcb: fix a double free bug in chameleon_parse_gdd() In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev' would be released in mcb_device_register() via put_device(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcb_device_register() fails.
- https://git.kernel.org/stable/c/4ffe8c9fb561e4427dd1a3056cd5b3685b74f78d
- https://git.kernel.org/stable/c/59f993cd36b6e28a394ba3d977e8ffe5c9884e3b
- https://git.kernel.org/stable/c/7c7f1bfdb2249f854a736d9b79778c7e5a29a150
- https://git.kernel.org/stable/c/96838eb1836fd372e42be5db84f0b333b65146a6
- https://git.kernel.org/stable/c/bcc7d58ee5173e34306026bd01e1fbf75e169d37
- https://git.kernel.org/stable/c/c5b8a549ef1fcc6066b037a3962c79d60465ba0b
- https://git.kernel.org/stable/c/d70184958b0ea8c0fd52e2b456654b503e769fc8
- https://git.kernel.org/stable/c/df1a5d5c6134224f9298e5189230f9d29ae50cac
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37818
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Return NULL from huge_pte_offset() for invalid PMD LoongArch's huge_pte_offset() currently returns a pointer to a PMD slot even if the underlying entry points to invalid_pte_table (indicating no mapping). Callers like smaps_hugetlb_range() fetch this invalid entry value (the address of invalid_pte_table) via this pointer. The generic is_swap_pte() check then incorrectly identifies this address as a swap entry on LoongArch, because it satisfies the "!pte_present() && !pte_none()" conditions. This misinterpretation, combined with a coincidental match by is_migration_entry() on the address bits, leads to kernel crashes in pfn_swap_entry_to_page(). Fix this at the architecture level by modifying huge_pte_offset() to check the PMD entry's content using pmd_none() before returning. If the entry is invalid (i.e., it points to invalid_pte_table), return NULL instead of the pointer to the slot.
- https://git.kernel.org/stable/c/2ca9380b12711afe95b3589bd82b59623b3c96b3
- https://git.kernel.org/stable/c/34256805720993e37adf6127371a1265aea8376a
- https://git.kernel.org/stable/c/51424fd171cee6a33f01f7c66b8eb23ac42289d4
- https://git.kernel.org/stable/c/b49f085cd671addbda4802d6b9382513f7dd0f30
- https://git.kernel.org/stable/c/bd51834d1cf65a2c801295d230c220aeebf87a73
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37820
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: handle NULL returned by xdp_convert_buff_to_frame() The function xdp_convert_buff_to_frame() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior. On XDP redirect failure, the associated page must be released explicitly if it was previously retained via get_page(). Failing to do so may result in a memory leak, as the pages reference count is not decremented.
- https://git.kernel.org/stable/c/5b83d30c63f9964acb1bc63eb8e670b9e0d2c240
- https://git.kernel.org/stable/c/cc3628dcd851ddd8d418bf0c897024b4621ddc92
- https://git.kernel.org/stable/c/cefd8a2e2de46209ce66e6d30c237eb59b6c5bfa
- https://git.kernel.org/stable/c/d6a9c4e6f9b3ec3ad98468c950ad214af8a2efb9
- https://git.kernel.org/stable/c/eefccd889df3b49d92e7349d94c4aa7e1ba19f6c
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-10
CVE-2025-37823
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.
- https://git.kernel.org/stable/c/11bccb054c1462fb069219f8e98e97a5a730758e
- https://git.kernel.org/stable/c/2f46d14919c39528c6e540ebc43f90055993eedc
- https://git.kernel.org/stable/c/68f256305ceb426d545a0dc31f83c2ab1d211a1e
- https://git.kernel.org/stable/c/6ccbda44e2cc3d26fd22af54c650d6d5d801addf
- https://git.kernel.org/stable/c/76c4c22c2437d3d3880efc0f62eca06ef078d290
- https://git.kernel.org/stable/c/c6936266f8bf98a53f28ef9a820e6a501e946d09
- https://git.kernel.org/stable/c/c6f035044104c6ff656f4565cd22938dc892528c
- https://git.kernel.org/stable/c/da7936518996d290e2fcfcaf6cd7e15bfd87804a
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-10
CVE-2025-37824
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix NULL pointer dereference in tipc_mon_reinit_self()
syzbot reported:
tipc: Node number set to 1055423674
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: events tipc_net_finalize_work
RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719
...
RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba
RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010
RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010
FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0ceef62a328ce1288598c9242576292671f21e96
- https://git.kernel.org/stable/c/4d5e1e2d3e9d70beff7beab44fd6ce91405a405e
- https://git.kernel.org/stable/c/5fd464fd24de93d0eca377554bf0ff2548f76f30
- https://git.kernel.org/stable/c/a3df56010403b2cd26388096ebccf959d23c4dcc
- https://git.kernel.org/stable/c/d63527e109e811ef11abb1c2985048fdb528b4cb
- https://git.kernel.org/stable/c/dd6cb0a8575b00fbd503e96903184125176f4fa3
- https://git.kernel.org/stable/c/e6613b6d41f4010c4d484cbc7bfca690d8d522a2
- https://git.kernel.org/stable/c/e79e8e05aa46f90d21023f0ffe6f136ed6a20932
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37829
In the Linux kernel, the following vulnerability has been resolved: cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.
- https://git.kernel.org/stable/c/124bddf123311cd1f18bffd63a5d974468d59c67
- https://git.kernel.org/stable/c/19e0eaa62e8831f2bc0285fef3bf8faaa7f3e09b
- https://git.kernel.org/stable/c/28fbd7b13b4d3074b16db913aedc9d8d37ab41e7
- https://git.kernel.org/stable/c/73b24dc731731edf762f9454552cb3a5b7224949
- https://git.kernel.org/stable/c/8fbaa76690f67a7cbad315f89d607b46e3e06ede
- https://git.kernel.org/stable/c/ad4796f2da495b2cbbd0fccccbcbf63f2aeee613
- https://git.kernel.org/stable/c/da8ee91e532486055ecf88478d38c2f3dc234182
- https://git.kernel.org/stable/c/fdf035d9c5436536ffcfea0ac6adeb5dda3c3a23
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-01-19
CVE-2025-37830
In the Linux kernel, the following vulnerability has been resolved: cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.
- https://git.kernel.org/stable/c/484d3f15cc6cbaa52541d6259778e715b2c83c54
- https://git.kernel.org/stable/c/4e3d1c1925d8e752992cd893d03d974e6807ac16
- https://git.kernel.org/stable/c/7ccfadfb2562337b4f0462a86a9746a6eea89718
- https://git.kernel.org/stable/c/bd1dcfba72aac4159c1d5e17cd861e702e6c19ac
- https://git.kernel.org/stable/c/cfaca93b8fe317b7faa9af732e0ba8c9081fa018
- https://git.kernel.org/stable/c/ea834c90aa7cc80a1b456f7a91432734d5087d16
- https://git.kernel.org/stable/c/f9c5423855e3687262d881aeee5cfb3bc8577bff
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-14
CVE-2025-37836
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix reference leak in pci_register_host_bridge() If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register(). Found by code review. [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
- https://git.kernel.org/stable/c/3297497ad2246eb9243849bfbbc57a0dea97d76e
- https://git.kernel.org/stable/c/804443c1f27883926de94c849d91f5b7d7d696e9
- https://git.kernel.org/stable/c/9707d0c932f41006a2701afc926b232b50e356b4
- https://git.kernel.org/stable/c/b783478e0c53ffb4f04f25fb4e21ef7f482b05df
- https://git.kernel.org/stable/c/bbba4c50a2d2a1d3f3bf31cc4b8280cb492bf2c7
- https://git.kernel.org/stable/c/bd2a352a0d72575f1842d28c14c10089f0cfe1ae
- https://git.kernel.org/stable/c/f4db1b2c9ae3d013733c302ee70cac943b7070c0
- https://git.kernel.org/stable/c/f9208aec86226524ec1cb68a09ac70e974ea6536
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-37838
In the Linux kernel, the following vulnerability has been resolved: HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition In the ssi_protocol_probe() function, &ssi->work is bound with ssip_xmit_work(), In ssip_pn_setup(), the ssip_pn_xmit() function within the ssip_pn_ops structure is capable of starting the work. If we remove the module which will call ssi_protocol_remove() to make a cleanup, it will free ssi through kfree(ssi), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ssip_xmit_work ssi_protocol_remove | kfree(ssi); | | struct hsi_client *cl = ssi->cl; | // use ssi Fix it by ensuring that the work is canceled before proceeding with the cleanup in ssi_protocol_remove().
- https://git.kernel.org/stable/c/4a8c29beb8a02b5a0a9d77d608aa14b6f88a6b86
- https://git.kernel.org/stable/c/4b4194c9a7a8f92db39e8e86c85f4fb12ebbec4f
- https://git.kernel.org/stable/c/58eb29dba712ab0f13af59ca2fe545f5ce360e78
- https://git.kernel.org/stable/c/72972552d0d0bfeb2dec5daf343a19018db36ffa
- https://git.kernel.org/stable/c/834e602d0cc7c743bfce734fad4a46cefc0f9ab1
- https://git.kernel.org/stable/c/ae5a6a0b425e8f76a9f0677e50796e494e89b088
- https://git.kernel.org/stable/c/d03abc1c2b21324550fa71e12d53e7d3498e0af6
- https://git.kernel.org/stable/c/d58493832e284f066e559b8da5ab20c15a2801d3
- https://git.kernel.org/stable/c/e3f88665a78045fe35c7669d2926b8d97b892c11
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-14
CVE-2025-37839
In the Linux kernel, the following vulnerability has been resolved: jbd2: remove wrong sb->s_sequence check Journal emptiness is not determined by sb->s_sequence == 0 but rather by sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON.
- https://git.kernel.org/stable/c/3b4643ffaf72d7a5a357e9bf68b1775f8cfe7e77
- https://git.kernel.org/stable/c/9eaec071f111cd2124ce9a5b93536d3f6837d457
- https://git.kernel.org/stable/c/ad926f735b4d4f10768fec7d080cadeb6d075cac
- https://git.kernel.org/stable/c/b0cca357f85beb6144ab60c62dcc98508cc044bf
- https://git.kernel.org/stable/c/b479839525fe7906966cdc4b5b2afbca048558a1
- https://git.kernel.org/stable/c/c88f7328bb0fff66520fc9164f02b1d06e083c1b
- https://git.kernel.org/stable/c/c98eb9ffb1d9c98237b5e1668eee17654e129fb0
- https://git.kernel.org/stable/c/cf30432f5b3064ff85d85639c2f0106f89c566f6
- https://git.kernel.org/stable/c/e6eff39dd0fe4190c6146069cc16d160e71d1148
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-14
CVE-2025-37840
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: fix PM resume warning Fixed warning on PM resume as shown below caused due to uninitialized struct nand_operation that checks chip select field : WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cut here ]------------ [ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Modules linked in: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Tainted: [W]=WARN [ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree) [ 14.588598] Call trace: [ 14.588604] dump_backtrace from show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c [ 14.588653] r5:c08d40b0 r4:c1003cb0 [ 14.588656] dump_stack from __warn+0x84/0xe4 [ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194 [ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8 [ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048 [ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150 [ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040 [ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54 [ 14.588735] r5:00000010 r4:c0840a50 [ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c [ 14.588757] dpm_run_callback from device_resume+0xc0/0x324 [ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010 [ 14.588779] device_resume from dpm_resume+0x130/0x160 [ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0 [ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20 [ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414 [ 14.588826] r4:00000010 [ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8 [ 14.588848] r5:c228a414 r4:00000000 [ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc [ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000 [ 14.588871] r4:00000003 [ 14.588874] pm_suspend from state_store+0x74/0xd0 [ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003 [ 14.588892] state_store from kobj_attr_store+0x1c/0x28 [ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250 [ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c [ 14.588936] r5:c3502900 r4:c0d92a48 [ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0 [ 14.588956] r5:c3502900 r4:c3501f40 [ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420 [ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00 [ 14.588983] r4:c042a88c [ 14.588987] vfs_write from ksys_write+0x74/0xe4 [ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00 [ 14.589008] r4:c34f7f00 [ 14.589011] ksys_write from sys_write+0x10/0x14 [ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004 [ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c [ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0) [ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001 [ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78 [ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8 [ 14.589065] ---[ end trace 0000000000000000 ]--- The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when doing PM resume operation in compliance with the controller support for single die nand chip. Switching from nand_reset_op() to nan ---truncated---
- https://git.kernel.org/stable/c/659b1f29f3e2fd5d751fdf35c5526d1f1c9b3dd2
- https://git.kernel.org/stable/c/6f567c6a5250e3531cfd9c7ff254ecc2650464fa
- https://git.kernel.org/stable/c/7266066b9469f04ed1d4c0fdddaea1425835eb55
- https://git.kernel.org/stable/c/8775581e1c48e1bdd04a893d6f6bbe5128ad0ea7
- https://git.kernel.org/stable/c/9bd51723ab51580e077c91d494c37e80703b8524
- https://git.kernel.org/stable/c/9dd161f707ecb7db38e5f529e979a5b6eb565b2d
- https://git.kernel.org/stable/c/c2eb3cffb0d972c5503e4d48921971c81def0fe5
- https://git.kernel.org/stable/c/ddc210cf8b8a8be68051ad958bf3e2cef6b681c2
- https://git.kernel.org/stable/c/fbcb584efa5cd912ff8a151d67b8fe22f4162a85
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-17
CVE-2025-37841
In the Linux kernel, the following vulnerability has been resolved: pm: cpupower: bench: Prevent NULL dereference on malloc failure If malloc returns NULL due to low memory, 'config' pointer can be NULL. Add a check to prevent NULL dereference.
- https://git.kernel.org/stable/c/0e297a02e03dceb2874789ca40bd4e65c5371704
- https://git.kernel.org/stable/c/208baa3ec9043a664d9acfb8174b332e6b17fb69
- https://git.kernel.org/stable/c/34a9394794b0f97af6afedc0c9ee2012c24b28ed
- https://git.kernel.org/stable/c/5e38122aa3fd0f9788186e86a677925bfec0b2d1
- https://git.kernel.org/stable/c/79bded9d70142d2a11d931fc029afece471641db
- https://git.kernel.org/stable/c/87b9f0867c0afa7e892f4b30c36cff6bf2707f85
- https://git.kernel.org/stable/c/942a4b97fc77516678b1d8af1521ff9a94c13b3e
- https://git.kernel.org/stable/c/ceec06f464d5cfc0ba966225f7d50506ceb62242
- https://git.kernel.org/stable/c/f8d28fa305b78c5d1073b63f26db265ba8291ae1
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-17
CVE-2025-37844
In the Linux kernel, the following vulnerability has been resolved: cifs: avoid NULL pointer dereference in dbg call cifs_server_dbg() implies server to be non-NULL so move call under condition to avoid NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/20048e658652e731f5cadf4a695925e570ca0ff9
- https://git.kernel.org/stable/c/6c14ee6af8f1f188b668afd6d003f7516a507b08
- https://git.kernel.org/stable/c/864ba5c651b03830f36f0906c21af05b15c1aaa6
- https://git.kernel.org/stable/c/9c9000cb91b986eb7f75835340c67857ab97c09b
- https://git.kernel.org/stable/c/b2a1833e1c63e2585867ebeaf4dd41494dcede4b
- https://git.kernel.org/stable/c/b4885bd5935bb26f0a414ad55679a372e53f9b9b
- https://git.kernel.org/stable/c/ba3ce6c60cd5db258687dfeba9fc608f5e7cadf3
- https://git.kernel.org/stable/c/e0717385f5c51e290c2cd2ad4699a778316b5132
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-17
CVE-2025-37849
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.
- https://git.kernel.org/stable/c/07476e0d932afc53c05468076393ac35d0b4999e
- https://git.kernel.org/stable/c/2480326eba8ae9ccc5e4c3c2dc8d407db68e3c52
- https://git.kernel.org/stable/c/250f25367b58d8c65a1b060a2dda037eea09a672
- https://git.kernel.org/stable/c/5085e02362b9948f82fceca979b8f8e12acb1cc5
- https://git.kernel.org/stable/c/c322789613407647a05ff5c451a7bf545fb34e73
- https://git.kernel.org/stable/c/f1e9087abaeedec9bf2894a282ee4f0d8383f299
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-17
CVE-2025-37850
In the Linux kernel, the following vulnerability has been resolved: pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config() With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm])); due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero. This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero. Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section [ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]
- https://git.kernel.org/stable/c/4cb15042b5f3ec0474e91cf379120cc597625dbb
- https://git.kernel.org/stable/c/77fb96dbe350e8a5ae4965ff9f6e7049f3966a6b
- https://git.kernel.org/stable/c/7ca59947b5fcf94e7ea4029d1bd0f7c41500a161
- https://git.kernel.org/stable/c/8b9f60725d74b72c238e4437c957d0217746b506
- https://git.kernel.org/stable/c/8ddbec73ea2598d8414e8f7103241b55cf877010
- https://git.kernel.org/stable/c/c343856ff2689ce0afef823592732fc178ef4aac
- https://git.kernel.org/stable/c/e1206d8e1651c9f62e5640b69b14d925b1a0a00a
- https://git.kernel.org/stable/c/e3cf0c38d3ce754ad63005102fcfeb0b7ff3290b
- https://git.kernel.org/stable/c/f3e9cf266c2c103cf071e15d7a17e2c699fff3c5
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-17
CVE-2025-37851
In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: Add 'plane' value check Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB of the enum parameter plane. The value of this parameter is initialized in dss_init_overlays and in the current state of the code it cannot take this value so it's not a real problem. For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not. For example, in dispc_ovl_setup_global_alpha it may lead to buffer overflow. Add check for this value. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.
- https://git.kernel.org/stable/c/09dbf22fd68c2f1a81ab89670ffa1ec3033436c4
- https://git.kernel.org/stable/c/3e411827f31db7f938a30a3c7a7599839401ec30
- https://git.kernel.org/stable/c/4efd8ef5e40f2c7a4a91a5a9f03140bfa827da89
- https://git.kernel.org/stable/c/52eafaa56f8f6d6a0cdff9282b25b4acbde34edc
- https://git.kernel.org/stable/c/660a53a0694d1f3789802509fe729dd4656fc5e0
- https://git.kernel.org/stable/c/9b0a41589ee70529b20e1e0108d03f10c649bdc4
- https://git.kernel.org/stable/c/a570efb4d877adbf3db2dc95487f2ba6bfdd148a
- https://git.kernel.org/stable/c/cdf41d72e8b015d9ea68f5a1c0a79624e7c312aa
- https://git.kernel.org/stable/c/fda15c5b96b883d62fb2d84a3a1422aa87717897
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-17
CVE-2025-37852
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() Add error handling to propagate amdgpu_cgs_create_device() failures to the caller. When amdgpu_cgs_create_device() fails, release hwmgr and return -ENOMEM to prevent null pointer dereference. [v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.
- https://git.kernel.org/stable/c/1435e895d4fc967d64e9f5bf81e992ac32f5ac76
- https://git.kernel.org/stable/c/22ea19cc089013b55c240134dbb2797700ff5a6a
- https://git.kernel.org/stable/c/55ef52c30c3e747f145a64de96192e37a8fed670
- https://git.kernel.org/stable/c/b784734811438f11533e2fb9e0deb327844bdb56
- https://git.kernel.org/stable/c/dc4380f34613eaae997b3ed263bd1cb3d0fd0075
- https://git.kernel.org/stable/c/f8693e1bae9c08233a2f535c3f412e157df32b33
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-17
CVE-2025-37854
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix mode1 reset crash issue If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM. There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash. To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.
- https://git.kernel.org/stable/c/57c9dabda80ac167de8cd71231baae37cc2f442d
- https://git.kernel.org/stable/c/6f30a847432cae84c7428e9b684b3e3fa49b2391
- https://git.kernel.org/stable/c/89af6b39f028c130d4362f57042927f005423e6a
- https://git.kernel.org/stable/c/9c4bcdf4068aae3e17e31c144300be405cfa03ff
- https://git.kernel.org/stable/c/f0b4440cdc1807bb6ec3dce0d6de81170803569b
- https://git.kernel.org/stable/c/ffd37d7d44d7e0b6e769d4fe6590e327f8cc3951
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37857
In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix array overflow in st_setup() Change the array size to follow parms size instead of a fixed value.
- https://git.kernel.org/stable/c/574b399a7fb6ae71c97e26d122205c4a720c0e43
- https://git.kernel.org/stable/c/736ae988bfb5932c05625baff70fba224d547c08
- https://git.kernel.org/stable/c/7fe3b4deed8b93609058c37c9a11df1d2b2c0423
- https://git.kernel.org/stable/c/a018d1cf990d0c339fe0e29b762ea5dc10567d67
- https://git.kernel.org/stable/c/ad4c3037dc77739a625246a2a0fb23b8f3402c06
- https://git.kernel.org/stable/c/c6015d0f7a2236ddb3928b2dfcb1c556a1368b55
- https://git.kernel.org/stable/c/e4d1ca0a84a6650d3172eb8c07ef2fbc585b0d96
- https://git.kernel.org/stable/c/e6b585d016c47ca8a37b92ea8a3fe35c0b585256
- https://git.kernel.org/stable/c/f746fe0c51e044d1248dc67918328bfb3d86b639
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37858
In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Prevent integer overflow in AG size calculation The JFS filesystem calculates allocation group (AG) size using 1 << l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB aggregates on 32-bit systems), this 32-bit shift operation causes undefined behavior and improper AG sizing. On 32-bit architectures: - Left-shifting 1 by 32+ bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize - Subsequent block allocations would reference invalid AG structures - Could lead to: - Filesystem corruption during extend operations - Kernel crashes due to invalid memory accesses - Security vulnerabilities via malformed on-disk structures Fix by casting to s64 before shifting: bmp->db_agsize = (s64)1 << l2agsize; This ensures 64-bit arithmetic even on 32-bit architectures. The cast matches the data type of db_agsize (s64) and follows similar patterns in JFS block calculation code. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/211ed8f5e39e61f9e4d18edd64ce8005a67a1b2a
- https://git.kernel.org/stable/c/3d8a45f87010a802aa214bf39702ca9d99cbf3ba
- https://git.kernel.org/stable/c/55edbf5dbf60a8195c21e92124c4028939ae16b2
- https://git.kernel.org/stable/c/7ccf3b35274512b60ecb614e0637e76bd6f2d829
- https://git.kernel.org/stable/c/7fcbf789629cdb9fbf4e2172ce31136cfed11e5e
- https://git.kernel.org/stable/c/8bb29629a5e4090e1ef7199cb42db04a52802239
- https://git.kernel.org/stable/c/c802a6a4009f585111f903e810b3be9c6d0da329
- https://git.kernel.org/stable/c/dd07a985e2ded47b6c7d69fc93c1fe02977c8454
- https://git.kernel.org/stable/c/ec34cdf4f917cc6abd306cf091f8b8361fedac88
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37859
In the Linux kernel, the following vulnerability has been resolved: page_pool: avoid infinite loop to schedule delayed worker We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1]. Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally. This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry(). [1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker.
- https://git.kernel.org/stable/c/43130d02baa137033c25297aaae95fd0edc41654
- https://git.kernel.org/stable/c/7204335d1991c23fc615ab76f31f175748a578e1
- https://git.kernel.org/stable/c/738d1812ec2e395e953258aea912ddd867d11a13
- https://git.kernel.org/stable/c/90e089a64504982f8d62f223027cb9f903781f78
- https://git.kernel.org/stable/c/91522aba56e9fcdf64da25ffef9b27f8fad48e0f
- https://git.kernel.org/stable/c/95f17738b86fd198924d874a5639bcdc49c7e5b8
- https://git.kernel.org/stable/c/9f71db4fb82deb889e0bac4a51b34daea7d506a3
- https://git.kernel.org/stable/c/c3c7c57017ce1d4b2d3788c1fc59e7e39026e158
- https://git.kernel.org/stable/c/e74e5aa33228c5e2cb4fc80ad103541a7b7805ec
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37862
In the Linux kernel, the following vulnerability has been resolved: HID: pidff: Fix null pointer dereference in pidff_find_fields This function triggered a null pointer dereference if used to search for a report that isn't implemented on the device. This happened both for optional and required reports alike. The same logic was applied to pidff_find_special_field and although pidff_init_fields should return an error earlier if one of the required reports is missing, future modifications could change this logic and resurface this possible null pointer dereference again. LKML bug report: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com
- https://git.kernel.org/stable/c/22a05462c3d0eee15154faf8d13c49e6295270a5
- https://git.kernel.org/stable/c/3a507184f9307e19cb441b897c49e7843c94e56b
- https://git.kernel.org/stable/c/44a1b8b2027afbb37e418993fb23561bdb9efb38
- https://git.kernel.org/stable/c/6b4449e4f03326fbd2136e67bfcc1e6ffe61541d
- https://git.kernel.org/stable/c/be706a48bb7896d4130edc82811233d1d62158e7
- https://git.kernel.org/stable/c/d230becb9d38b7325c5c38d051693e4c26b1829b
- https://git.kernel.org/stable/c/ddb147885225d768025f6818df533d30edf3e102
- https://git.kernel.org/stable/c/e368698da79af821f18c099520deab1219c2044b
- https://git.kernel.org/stable/c/f8f4d77710e1c38f4a2bd26c88c4878b5b5e817a
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37865
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT: https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/ This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), which tries to find an MST entry in &chip->msts associated with the SID, but fails and returns -ENOENT as such. But we know that this chip does not support MST at all, so that is not surprising. The question is why does the guard in mv88e6xxx_mst_put() not exit early: if (!sid) return 0; And the answer seems to be simple: the sid comes from vlan.sid which supposedly was previously populated by mv88e6xxx_vtu_get(). But some chip->info->ops->vtu_getnext() implementations do not populate vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case, later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is just residual stack memory. Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge VLAN mapped to the default MSTI. For some chips, SID 0 is valid and installed by mv88e6xxx_stu_setup(). A chip which does not support the STU would implicitly only support mapping all VLANs to the default MSTI, so although SID 0 is not valid, it would be sufficient, if we were to zero-initialize the vlan structure, to fix the bug, due to the coincidence that a test for vlan.sid == 0 already exists and leads to the same (correct) behavior. Another option which would be sufficient would be to add a test for mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one which already exists in mv88e6xxx_mst_get(). But that placement means the caller will have to dereference vlan.sid, which means it will access uninitialized memory, which is not nice even if it ignores it later. So we end up making both modifications, in order to not rely just on the sid == 0 coincidence, but also to avoid having uninitialized structure fields which might get temporarily accessed.
- https://git.kernel.org/stable/c/35cde75c08a1fa1a5ac0467afe2709caceeef002
- https://git.kernel.org/stable/c/9da4acbd60664271d34a627f7f63cd5bad8eba74
- https://git.kernel.org/stable/c/9ee6d3a368ed34f2457863da3085c676e9e37a3d
- https://git.kernel.org/stable/c/afae9087301471970254a9180e5a26d3d8e8af09
- https://git.kernel.org/stable/c/ea08dfc35f83cfc73493c52f63ae4f2e29edfe8d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37867
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Silence oversized kvmalloc() warning
syzkaller triggered an oversized kvmalloc() warning.
Silence it by adding __GFP_NOWARN.
syzkaller log:
WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180
CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:__kvmalloc_node_noprof+0x175/0x180
RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246
RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b
RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002
RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000
R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000
R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0d81bb58a203ad5f4044dc18cfbc230c194f650a
- https://git.kernel.org/stable/c/6c588e9afbab240c921f936cb676dac72e2e2b66
- https://git.kernel.org/stable/c/791daf8240cedf27af8794038ae1d32ef643bce6
- https://git.kernel.org/stable/c/9a0e6f15029e1a8a21e40f06fd05aa52b7f063de
- https://git.kernel.org/stable/c/ae470d06320dea4002d441784d691f0a26b4322d
- https://git.kernel.org/stable/c/f476eba25fdf70faa7b19a3e0fb00e65c5b53106
- https://git.kernel.org/stable/c/f94ac90ce7bd6f9266ad0d99044ed86e8d1416c1
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37871
In the Linux kernel, the following vulnerability has been resolved: nfsd: decrease sc_count directly if fail to queue dl_recall A deadlock warning occurred when invoking nfs4_put_stid following a failed dl_recall queue operation: T1 T2 nfs4_laundromat nfs4_get_client_reaplist nfs4_anylock_blockers __break_lease spin_lock // ctx->flc_lock spin_lock // clp->cl_lock nfs4_lockowner_has_blockers locks_owner_has_blockers spin_lock // flctx->flc_lock nfsd_break_deleg_cb nfsd_break_one_deleg nfs4_put_stid refcount_dec_and_lock spin_lock // clp->cl_lock When a file is opened, an nfs4_delegation is allocated with sc_count initialized to 1, and the file_lease holds a reference to the delegation. The file_lease is then associated with the file through kernel_setlease. The disassociation is performed in nfsd4_delegreturn via the following call chain: nfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg --> nfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_lease The corresponding sc_count reference will be released after this disassociation. Since nfsd_break_one_deleg executes while holding the flc_lock, the disassociation process becomes blocked when attempting to acquire flc_lock in generic_delete_lease. This means: 1) sc_count in nfsd_break_one_deleg will not be decremented to 0; 2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt to acquire cl_lock; 3) Consequently, no deadlock condition is created. Given that sc_count in nfsd_break_one_deleg remains non-zero, we can safely perform refcount_dec on sc_count directly. This approach effectively avoids triggering deadlock warnings.
- https://git.kernel.org/stable/c/14985d66b9b99c12995dd99d1c6c8dec4114c2a5
- https://git.kernel.org/stable/c/7d192e27a431026c58d60edf66dc6cd98d0c01fc
- https://git.kernel.org/stable/c/a1d14d931bf700c1025db8c46d6731aa5cf440f9
- https://git.kernel.org/stable/c/a70832d3555987035fc430ccd703acd89393eadb
- https://git.kernel.org/stable/c/a7fce086f6ca84db409b9d58493ea77c1978897c
- https://git.kernel.org/stable/c/b9bbe8f9d5663311d06667ce36d6ed255ead1a26
- https://git.kernel.org/stable/c/ba903539fff745d592d893c71b30e5e268a95413
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37875
In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction. The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: "ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump. With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.
- https://git.kernel.org/stable/c/0c03e4fbe1321697d9d04587e21e416705e1b19f
- https://git.kernel.org/stable/c/16194ca3f3b4448a062650c869a7b3b206c6f5d3
- https://git.kernel.org/stable/c/31959e06143692f7e02b8eef7d7d6ac645637906
- https://git.kernel.org/stable/c/8e404ad95d2c10c261e2ef6992c7c12dde03df0e
- https://git.kernel.org/stable/c/c1f174edaccc5a00f8e218c42a0aa9156efd5f76
- https://git.kernel.org/stable/c/f3516229cd12dcd45f23ed01adab17e8772b1bd5
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37879
In the Linux kernel, the following vulnerability has been resolved: 9p/net: fix improper handling of bogus negative read/write replies In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)
- https://git.kernel.org/stable/c/374e4cd75617c8c2552f562f39dd989583f5c330
- https://git.kernel.org/stable/c/468ff4a7c61fb811c596a7c44b6a5455e40fd12b
- https://git.kernel.org/stable/c/a68768e280b7d0c967ea509e791bb9b90adc94a5
- https://git.kernel.org/stable/c/c548f95688e2b5ae0e2ae43d53cf717156c7d034
- https://git.kernel.org/stable/c/d0259a856afca31d699b706ed5e2adf11086c73b
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37881
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool
- https://git.kernel.org/stable/c/052fb65335befeae8500e88d69ea022266baaf6d
- https://git.kernel.org/stable/c/36d68151712e525450f0fbb3045e7110f0d9b610
- https://git.kernel.org/stable/c/61006ca381b4d65d2b8ca695ea8da1ce18d6dee3
- https://git.kernel.org/stable/c/8c75f3e6a433d92084ad4e78b029ae680865420f
- https://git.kernel.org/stable/c/a777ccfb9ba8d43f745e41b69ba39d4a506a081e
- https://git.kernel.org/stable/c/c8d4faf452a627f9b09c3a5c366133a19e5b7a28
- https://git.kernel.org/stable/c/cfa7984f69359761b07a7831c1258c0fde1e0389
- https://git.kernel.org/stable/c/d26a6093d52904cacdbb75424c323c19b443a890
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37883
In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Add check for get_zeroed_page() Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job.
- https://git.kernel.org/stable/c/28e5a867aa542e369e211c2baba7044228809a99
- https://git.kernel.org/stable/c/397254706eba9d8f99fd237feede7ab3169a7f9a
- https://git.kernel.org/stable/c/3b3aa72636a6205933609ec274a8747720c1ee3f
- https://git.kernel.org/stable/c/3db42c75a921854a99db0a2775814fef97415bac
- https://git.kernel.org/stable/c/e1e00dc45648125ef7cb87ebc3b581ac224e7b39
- https://git.kernel.org/stable/c/f69f8a93aacf6e99af7b1cc992d8ca2cc07b96fb
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-01-02
CVE-2025-37884
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock between rcu_tasks_trace and event_mutex. Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.
Modified: 2025-11-12
CVE-2025-37885
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn't postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.
- https://git.kernel.org/stable/c/023816bd5fa46fab94d1e7917fe131b79ed1fb41
- https://git.kernel.org/stable/c/116c7d35b8f72eac383b9fd371d7c1a8ffc2968b
- https://git.kernel.org/stable/c/3066ec21d1a33896125747f68638725f456308db
- https://git.kernel.org/stable/c/3481fd96d801715942b6f69fe251133128156f30
- https://git.kernel.org/stable/c/9bcac97dc42d2f4da8229d18feb0fe2b1ce523a2
- https://git.kernel.org/stable/c/b5de7ac74f69603ad803c524b840bffd36368fc3
- https://git.kernel.org/stable/c/e5f2dee9f7fcd2ff4b97869f3c66a0d89c167769
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-12
CVE-2025-37892
In the Linux kernel, the following vulnerability has been resolved: mtd: inftlcore: Add error check for inftl_read_oob() In INFTL_findwriteunit(), the return value of inftl_read_oob() need to be checked. A proper implementation can be found in INFTL_deleteblock(). The status will be set as SECTOR_IGNORE to break from the while-loop correctly if the inftl_read_oob() fails.
- https://git.kernel.org/stable/c/0300e751170cf80c05ca1a762a7b449e8ca6b693
- https://git.kernel.org/stable/c/114d94f095aa405fa9a51484c4be34846d7bb386
- https://git.kernel.org/stable/c/1c22356dfb041e5292835c9ff44d5f91bef8dd18
- https://git.kernel.org/stable/c/5479a6af3c96f73bec2d2819532b6d6814f52dd6
- https://git.kernel.org/stable/c/6af3b92b1c0b58ca281d0e1501bad2567f73c1a5
- https://git.kernel.org/stable/c/7772621041ee78823ccc5f1fe38f6faa22af7023
- https://git.kernel.org/stable/c/b828d394308e8e00df0a6f57e7dabae609bb8b7b
- https://git.kernel.org/stable/c/d027951dc85cb2e15924c980dc22a6754d100c7c
- https://git.kernel.org/stable/c/e7d6ceff95c55297f0ee8f9dbc4da5c558f30e9e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-19
CVE-2025-37938
In the Linux kernel, the following vulnerability has been resolved: tracing: Verify event formats that have "%*p.." The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%*p.." the verifier will ignore it, and that could be dangerous. Cover this case as well. Also add to the sample code a use case of "%*pbl".
- https://git.kernel.org/stable/c/03127354027508d076073b020d3070990fd6a958
- https://git.kernel.org/stable/c/04b80d45ecfaf780981d6582899e3ab205e4aa08
- https://git.kernel.org/stable/c/4d11fac941d83509be4e6a21038281d6d96da50c
- https://git.kernel.org/stable/c/6854c87ac823181c810f8c07489ba543260c0023
- https://git.kernel.org/stable/c/c7204fd1758c0caf1938e8a59809a1fdf28a8114
- https://git.kernel.org/stable/c/ea8d7647f9ddf1f81e2027ed305299797299aa03
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-19
CVE-2025-37940
In the Linux kernel, the following vulnerability has been resolved: ftrace: Add cond_resched() to ftrace_graph_set_hash() When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog. Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions. This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.
- https://git.kernel.org/stable/c/1fce9574b9d515bcb8a75379a8053e18602424e3
- https://git.kernel.org/stable/c/42ea22e754ba4f2b86f8760ca27f6f71da2d982c
- https://git.kernel.org/stable/c/4429535acab750d963fdc3dfcc9e0eee42f4d599
- https://git.kernel.org/stable/c/5d336ac215e5c76e43ef4bca9ba699835e53e2fd
- https://git.kernel.org/stable/c/618655d54c5f8af5d57b77491d08c0f0ff77d114
- https://git.kernel.org/stable/c/72be43ff061a889c6ee648a330a42486cafa15a6
- https://git.kernel.org/stable/c/8dd7d7280357596ba63dfdb4c1725d9dd24bd42a
- https://git.kernel.org/stable/c/dd38803c9088b848c6b56f4f6d7efc4497bfde61
- https://git.kernel.org/stable/c/e5b4ae6f01d4a510d5725eca7254519a1093920d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-16
CVE-2025-37979
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix sc7280 lpass potential buffer overflow Case values introduced in commit 5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution") cause out of bounds access in arrays of sc7280 driver data (e.g. in case of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()). Redefine LPASS_MAX_PORTS to consider the maximum possible port id for q6dsp as sc7280 driver utilizes some of those values. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/a12c14577882b1f2b4cff0f86265682f16e97b0c
- https://git.kernel.org/stable/c/a31a4934b31faea76e735bab17e63d02fcd8e029
- https://git.kernel.org/stable/c/b807b7c81a6d066757a94af7b8fa5b6a37e4d0b3
- https://git.kernel.org/stable/c/c0ce01e0ff8a0d61a7b089ab309cdc12bc527c39
- https://git.kernel.org/stable/c/d78888853eb53f47ae16cf3aa5d0444d0331b9f8
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-16
CVE-2025-37982
In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: fix memory leak in wl1251_tx_work The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.
- https://git.kernel.org/stable/c/13c9744c1bcdb5de4e7dc1a78784788ecec52add
- https://git.kernel.org/stable/c/2996144be660d930d5e394652abe08fe89dbe00e
- https://git.kernel.org/stable/c/4a43fd36710669d67dbb5c16287a58412582ca26
- https://git.kernel.org/stable/c/52f224009ce1e44805e6ff3ffc2a06af9c1c3c5b
- https://git.kernel.org/stable/c/5a90c29d0204c5ffc45b43b4eced6eef0e19a33a
- https://git.kernel.org/stable/c/8fd4b9551af214d037fbc9d8e179840b8b917841
- https://git.kernel.org/stable/c/a0f0dc96de03ffeefc2a177b7f8acde565cb77f4
- https://git.kernel.org/stable/c/f08448a885403722c5c77dae51964badfcb69495
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-16
CVE-2025-37983
In the Linux kernel, the following vulnerability has been resolved: qibfs: fix _another_ leak failure to allocate inode => leaked dentry... this one had been there since the initial merge; to be fair, if we are that far OOM, the odds of failing at that particular allocation are low...
- https://git.kernel.org/stable/c/24faa6ea274a2b96d0a78a0996c3137c2b2a65f0
- https://git.kernel.org/stable/c/3c2fde33e3e505dfd1a895d1f24bad650c655e14
- https://git.kernel.org/stable/c/47ab2caba495c1d6a899d284e541a8df656dcfe9
- https://git.kernel.org/stable/c/545defa656568c74590317cd30068f85134a8216
- https://git.kernel.org/stable/c/5d53e88d8370b9ab14dd830abb410d9a2671edb6
- https://git.kernel.org/stable/c/5e280cce3a29b7fe7b828c6ccd5aa5ba87ceb6b6
- https://git.kernel.org/stable/c/5fe708c5e3c8b2152c6caaa67243e431a5d6cca3
- https://git.kernel.org/stable/c/bdb43af4fdb39f844ede401bdb1258f67a580a27
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-16
CVE-2025-37985
In the Linux kernel, the following vulnerability has been resolved: USB: wdm: close race between wdm_open and wdm_wwan_port_stop Clearing WDM_WWAN_IN_USE must be the last action or we can open a chardev whose URBs are still poisoned
- https://git.kernel.org/stable/c/217fe1fc7d112595a793e02b306710e702eac492
- https://git.kernel.org/stable/c/52ae15c665b5fe5876655aaccc3ef70560b0e314
- https://git.kernel.org/stable/c/54f7f8978af19f899dec80bcc71c8d4855dfbd72
- https://git.kernel.org/stable/c/b02a3fef3e8c8fe5a0a266f7a14f38cc608fb167
- https://git.kernel.org/stable/c/c1846ed4eb527bdfe6b3b7dd2c78e2af4bf98f4f
- https://git.kernel.org/stable/c/e3c9adc69357fcbe6253a2bc2588ee4bbaaedbe9
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-16
CVE-2025-37989
In the Linux kernel, the following vulnerability has been resolved: net: phy: leds: fix memory leak A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code. The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound. This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer. Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.
- https://git.kernel.org/stable/c/41143e71052a00d654c15dc924fda50c1e7357d0
- https://git.kernel.org/stable/c/618541a6cc1511064dfa58c89b3445e21844092f
- https://git.kernel.org/stable/c/663c3da86e807c6c07ed48f911c7526fad6fe1ff
- https://git.kernel.org/stable/c/7f3d5880800f962c347777c4f8358f29f5fc403c
- https://git.kernel.org/stable/c/95bed65cc0eb2a610550abf849a8b94374da80a7
- https://git.kernel.org/stable/c/966d6494e2ed9be9052fcd9815afba830896aaf8
- https://git.kernel.org/stable/c/b7f0ee992adf601aa00c252418266177eb7ac2bc
- https://git.kernel.org/stable/c/f41f097f68a33d392579885426d0734a81219501
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-04-02
CVE-2025-39889
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: Check encryption key size on incoming connection This is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bit This tests the security key with size from 1 to 15 bytes while the Security Mode 4 Level 4 requests 16 bytes key size. Currently PTS fails with the following logs: - expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt), but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information available And HCI logs: < HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7 > ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64 < ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)
- https://git.kernel.org/stable/c/24b2cdfc16e9bd6ab3d03b8e01c590755bd3141f
- https://git.kernel.org/stable/c/522e9ed157e3c21b4dd623c79967f72c21e45b78
- https://git.kernel.org/stable/c/9e3114958d87ea88383cbbf38c89e04b8ea1bce5
- https://git.kernel.org/stable/c/c6d527bbd3d3896375079f5dbc8b7f96734a3ba5
- https://git.kernel.org/stable/c/d49798ecd26e0ee7995a7fc1e90ca5cd9b4402d6
- https://git.kernel.org/stable/c/d4ca2fd218caafbf50e3343ba1260c6a23b5676a
- https://git.kernel.org/stable/c/ed503d340a501e414114ddc614a3aae4f6e9eae2
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.27 updated to version 1.27.16-alt3 for branch c10f2 in task 381505.
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.31 updated to version 1.31.8-alt2 for branch c10f2 in task 381505.
Closed vulnerabilities
Modified: 2025-06-09
BDU:2025-00672
Уязвимость утилиты kubelet программного средства управления кластерами виртуальных машин Kubernetes для операционных систем Windows, позволяющая нарушителю выполнить произвольные команды
Modified: 2025-06-20
BDU:2025-06596
Уязвимость утилиты kubelet программного средства управления кластерами виртуальных машин Kubernetes, позволяющая нарушителю вызвать отказ в облуживании
Modified: 2026-04-15
CVE-2024-9042
This CVE affects only Windows worker nodes. Your worker node is vulnerable to this issue if it is running one of the affected versions listed below.
Modified: 2026-04-15
CVE-2025-0426
A security issue was discovered in Kubernetes where a large number of container checkpoint requests made to the unauthenticated kubelet read-only HTTP endpoint may cause a Node Denial of Service by filling the Node's disk.
Modified: 2025-12-20
GHSA-jgfp-53c3-624w
Node Denial of Service via kubelet Checkpoint API
- https://nvd.nist.gov/vuln/detail/CVE-2025-0426
- https://github.com/kubernetes/kubernetes/issues/130016
- https://github.com/advisories/GHSA-jgfp-53c3-624w
- https://github.com/kubernetes/kubernetes
- https://groups.google.com/g/kubernetes-security-announce/c/KiODfu8i6w8
- http://www.openwall.com/lists/oss-security/2025/02/13/1
Modified: 2025-03-14
GHSA-vv39-3w5q-974q
Kubernetes allows Command Injection affecting Windows nodes via nodes/*/logs/query API
- https://nvd.nist.gov/vuln/detail/CVE-2024-9042
- https://github.com/kubernetes/kubernetes/issues/129654
- https://github.com/kubernetes/kubernetes/commit/45f4ccc2153bbb782253704cbe24c05e22b5d60c
- https://github.com/kubernetes/kubernetes/commit/5fe148234f8ab1184f26069c4f7bef6c37efe347
- https://github.com/kubernetes/kubernetes/commit/75c83a6871dc030675288c6d63c275a43c2f0d55
- https://github.com/kubernetes/kubernetes/commit/fb0187c2bf7061258bb89891edb1237261eb7abc
- https://github.com/kubernetes/kubernetes
- https://groups.google.com/g/kubernetes-security-announce/c/9C3vn6aCSVg
- http://www.openwall.com/lists/oss-security/2025/01/16/1
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.26 updated to version 1.26.15-alt3 for branch c10f2 in task 381505.
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.29 updated to version 1.29.15-alt2 for branch c10f2 in task 381505.
Closed vulnerabilities
Modified: 2025-06-09
BDU:2025-00672
Уязвимость утилиты kubelet программного средства управления кластерами виртуальных машин Kubernetes для операционных систем Windows, позволяющая нарушителю выполнить произвольные команды
Modified: 2025-06-20
BDU:2025-06596
Уязвимость утилиты kubelet программного средства управления кластерами виртуальных машин Kubernetes, позволяющая нарушителю вызвать отказ в облуживании
Modified: 2026-04-15
CVE-2024-9042
This CVE affects only Windows worker nodes. Your worker node is vulnerable to this issue if it is running one of the affected versions listed below.
Modified: 2026-04-15
CVE-2025-0426
A security issue was discovered in Kubernetes where a large number of container checkpoint requests made to the unauthenticated kubelet read-only HTTP endpoint may cause a Node Denial of Service by filling the Node's disk.
Modified: 2025-12-20
GHSA-jgfp-53c3-624w
Node Denial of Service via kubelet Checkpoint API
- https://nvd.nist.gov/vuln/detail/CVE-2025-0426
- https://github.com/kubernetes/kubernetes/issues/130016
- https://github.com/advisories/GHSA-jgfp-53c3-624w
- https://github.com/kubernetes/kubernetes
- https://groups.google.com/g/kubernetes-security-announce/c/KiODfu8i6w8
- http://www.openwall.com/lists/oss-security/2025/02/13/1
Modified: 2025-03-14
GHSA-vv39-3w5q-974q
Kubernetes allows Command Injection affecting Windows nodes via nodes/*/logs/query API
- https://nvd.nist.gov/vuln/detail/CVE-2024-9042
- https://github.com/kubernetes/kubernetes/issues/129654
- https://github.com/kubernetes/kubernetes/commit/45f4ccc2153bbb782253704cbe24c05e22b5d60c
- https://github.com/kubernetes/kubernetes/commit/5fe148234f8ab1184f26069c4f7bef6c37efe347
- https://github.com/kubernetes/kubernetes/commit/75c83a6871dc030675288c6d63c275a43c2f0d55
- https://github.com/kubernetes/kubernetes/commit/fb0187c2bf7061258bb89891edb1237261eb7abc
- https://github.com/kubernetes/kubernetes
- https://groups.google.com/g/kubernetes-security-announce/c/9C3vn6aCSVg
- http://www.openwall.com/lists/oss-security/2025/01/16/1
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.28 updated to version 1.28.15-alt3 for branch c10f2 in task 381505.
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.24 updated to version 1.24.17-alt3 for branch c10f2 in task 381505.
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed vulnerabilities
Modified: 2026-04-15
CVE-2024-8676
A vulnerability was found in CRI-O, where it can be requested to take a checkpoint archive of a container and later be asked to restore it. When it does that restoration, it attempts to restore the mounts from the restore archive instead of the pod request. As a result, the validations run on the pod spec, verifying that the pod has access to the mounts it specifies are not applicable to a restored container. This flaw allows a malicious user to trick CRI-O into restoring a pod that doesn't have access to host mounts. The user needs access to the kubelet or cri-o socket to call the restore endpoint and trigger the restore.
- https://access.redhat.com/errata/RHBA-2024:10826
- https://access.redhat.com/errata/RHSA-2025:0648
- https://access.redhat.com/errata/RHSA-2025:1908
- https://access.redhat.com/errata/RHSA-2025:3297
- https://access.redhat.com/errata/RHSA-2025:4211
- https://access.redhat.com/errata/RHSA-2025:9765
- https://access.redhat.com/security/cve/CVE-2024-8676
- https://bugzilla.redhat.com/show_bug.cgi?id=2313842
Modified: 2025-07-02
GHSA-7p9f-6x8j-gxxp
CRI-O: Maliciously structured checkpoint file can gain arbitrary node access
- https://github.com/cri-o/cri-o/security/advisories/GHSA-7p9f-6x8j-gxxp
- https://nvd.nist.gov/vuln/detail/CVE-2024-8676
- https://github.com/cri-o/cri-o/commit/e8e7dcb7838d11b5157976bf3e31a5840bb77de7
- https://access.redhat.com/errata/RHBA-2024:10826
- https://access.redhat.com/errata/RHSA-2025:0648
- https://access.redhat.com/errata/RHSA-2025:1908
- https://access.redhat.com/errata/RHSA-2025:3297
- https://access.redhat.com/errata/RHSA-2025:4211
- https://access.redhat.com/errata/RHSA-2025:9765
- https://access.redhat.com/security/cve/CVE-2024-8676
- https://bugzilla.redhat.com/show_bug.cgi?id=2313842
- https://github.com/cri-o/cri-o
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed vulnerabilities
Modified: 2026-04-15
CVE-2024-8676
A vulnerability was found in CRI-O, where it can be requested to take a checkpoint archive of a container and later be asked to restore it. When it does that restoration, it attempts to restore the mounts from the restore archive instead of the pod request. As a result, the validations run on the pod spec, verifying that the pod has access to the mounts it specifies are not applicable to a restored container. This flaw allows a malicious user to trick CRI-O into restoring a pod that doesn't have access to host mounts. The user needs access to the kubelet or cri-o socket to call the restore endpoint and trigger the restore.
- https://access.redhat.com/errata/RHBA-2024:10826
- https://access.redhat.com/errata/RHSA-2025:0648
- https://access.redhat.com/errata/RHSA-2025:1908
- https://access.redhat.com/errata/RHSA-2025:3297
- https://access.redhat.com/errata/RHSA-2025:4211
- https://access.redhat.com/errata/RHSA-2025:9765
- https://access.redhat.com/security/cve/CVE-2024-8676
- https://bugzilla.redhat.com/show_bug.cgi?id=2313842
Modified: 2025-07-02
GHSA-7p9f-6x8j-gxxp
CRI-O: Maliciously structured checkpoint file can gain arbitrary node access
- https://github.com/cri-o/cri-o/security/advisories/GHSA-7p9f-6x8j-gxxp
- https://nvd.nist.gov/vuln/detail/CVE-2024-8676
- https://github.com/cri-o/cri-o/commit/e8e7dcb7838d11b5157976bf3e31a5840bb77de7
- https://access.redhat.com/errata/RHBA-2024:10826
- https://access.redhat.com/errata/RHSA-2025:0648
- https://access.redhat.com/errata/RHSA-2025:1908
- https://access.redhat.com/errata/RHSA-2025:3297
- https://access.redhat.com/errata/RHSA-2025:4211
- https://access.redhat.com/errata/RHSA-2025:9765
- https://access.redhat.com/security/cve/CVE-2024-8676
- https://bugzilla.redhat.com/show_bug.cgi?id=2313842
- https://github.com/cri-o/cri-o
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.30 updated to version 1.30.12-alt2 for branch c10f2 in task 381505.
Closed vulnerabilities
Modified: 2025-06-09
BDU:2025-00672
Уязвимость утилиты kubelet программного средства управления кластерами виртуальных машин Kubernetes для операционных систем Windows, позволяющая нарушителю выполнить произвольные команды
Modified: 2025-06-20
BDU:2025-06596
Уязвимость утилиты kubelet программного средства управления кластерами виртуальных машин Kubernetes, позволяющая нарушителю вызвать отказ в облуживании
Modified: 2026-04-15
CVE-2024-9042
This CVE affects only Windows worker nodes. Your worker node is vulnerable to this issue if it is running one of the affected versions listed below.
Modified: 2026-04-15
CVE-2025-0426
A security issue was discovered in Kubernetes where a large number of container checkpoint requests made to the unauthenticated kubelet read-only HTTP endpoint may cause a Node Denial of Service by filling the Node's disk.
Modified: 2025-12-20
GHSA-jgfp-53c3-624w
Node Denial of Service via kubelet Checkpoint API
- https://nvd.nist.gov/vuln/detail/CVE-2025-0426
- https://github.com/kubernetes/kubernetes/issues/130016
- https://github.com/advisories/GHSA-jgfp-53c3-624w
- https://github.com/kubernetes/kubernetes
- https://groups.google.com/g/kubernetes-security-announce/c/KiODfu8i6w8
- http://www.openwall.com/lists/oss-security/2025/02/13/1
Modified: 2025-03-14
GHSA-vv39-3w5q-974q
Kubernetes allows Command Injection affecting Windows nodes via nodes/*/logs/query API
- https://nvd.nist.gov/vuln/detail/CVE-2024-9042
- https://github.com/kubernetes/kubernetes/issues/129654
- https://github.com/kubernetes/kubernetes/commit/45f4ccc2153bbb782253704cbe24c05e22b5d60c
- https://github.com/kubernetes/kubernetes/commit/5fe148234f8ab1184f26069c4f7bef6c37efe347
- https://github.com/kubernetes/kubernetes/commit/75c83a6871dc030675288c6d63c275a43c2f0d55
- https://github.com/kubernetes/kubernetes/commit/fb0187c2bf7061258bb89891edb1237261eb7abc
- https://github.com/kubernetes/kubernetes
- https://groups.google.com/g/kubernetes-security-announce/c/9C3vn6aCSVg
- http://www.openwall.com/lists/oss-security/2025/01/16/1
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.25 updated to version 1.25.16-alt3 for branch c10f2 in task 381505.
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.23 updated to version 1.23.17-alt4 for branch c10f2 in task 381505.
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Package kubernetes1.22 updated to version 1.22.17-alt3 for branch c10f2 in task 381505.
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
Closed vulnerabilities
Modified: 2026-04-15
CVE-2024-8676
A vulnerability was found in CRI-O, where it can be requested to take a checkpoint archive of a container and later be asked to restore it. When it does that restoration, it attempts to restore the mounts from the restore archive instead of the pod request. As a result, the validations run on the pod spec, verifying that the pod has access to the mounts it specifies are not applicable to a restored container. This flaw allows a malicious user to trick CRI-O into restoring a pod that doesn't have access to host mounts. The user needs access to the kubelet or cri-o socket to call the restore endpoint and trigger the restore.
- https://access.redhat.com/errata/RHBA-2024:10826
- https://access.redhat.com/errata/RHSA-2025:0648
- https://access.redhat.com/errata/RHSA-2025:1908
- https://access.redhat.com/errata/RHSA-2025:3297
- https://access.redhat.com/errata/RHSA-2025:4211
- https://access.redhat.com/errata/RHSA-2025:9765
- https://access.redhat.com/security/cve/CVE-2024-8676
- https://bugzilla.redhat.com/show_bug.cgi?id=2313842
Modified: 2025-07-02
GHSA-7p9f-6x8j-gxxp
CRI-O: Maliciously structured checkpoint file can gain arbitrary node access
- https://github.com/cri-o/cri-o/security/advisories/GHSA-7p9f-6x8j-gxxp
- https://nvd.nist.gov/vuln/detail/CVE-2024-8676
- https://github.com/cri-o/cri-o/commit/e8e7dcb7838d11b5157976bf3e31a5840bb77de7
- https://access.redhat.com/errata/RHBA-2024:10826
- https://access.redhat.com/errata/RHSA-2025:0648
- https://access.redhat.com/errata/RHSA-2025:1908
- https://access.redhat.com/errata/RHSA-2025:3297
- https://access.redhat.com/errata/RHSA-2025:4211
- https://access.redhat.com/errata/RHSA-2025:9765
- https://access.redhat.com/security/cve/CVE-2024-8676
- https://bugzilla.redhat.com/show_bug.cgi?id=2313842
- https://github.com/cri-o/cri-o
Closed bugs
При удалении пакетов kubernetes/cri-o/etcd "ошибка чтения информации о сервисе: Нет такого файла или каталога"
