ALT-BU-2025-7549-4
Branch p10 update bulletin.
Package postgresql17-pgpool-II updated to version 4.6.1-alt0.p10.1 for branch p10 in task 384189.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2025-07452
Уязвимость программных средств балансировки и управления соединениями Pgpool-II, связанная с обходом аутентификации в силу исходной ошибки, позволяющая нарушителю обойти ограничения безопасности и получить доступ на чтение, изменение и удаление данных
Modified: 2026-04-15
CVE-2025-46801
Pgpool-II provided by PgPool Global Development Group contains an authentication bypass by primary weakness vulnerability. if the vulnerability is exploited, an attacker may be able to log in to the system as an arbitrary user, allowing them to read or tamper with data in the database, and/or disable the database.
Package postgresql14-pgpool-II updated to version 4.6.1-alt0.p10.1 for branch p10 in task 384189.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2025-07452
Уязвимость программных средств балансировки и управления соединениями Pgpool-II, связанная с обходом аутентификации в силу исходной ошибки, позволяющая нарушителю обойти ограничения безопасности и получить доступ на чтение, изменение и удаление данных
Modified: 2026-04-15
CVE-2025-46801
Pgpool-II provided by PgPool Global Development Group contains an authentication bypass by primary weakness vulnerability. if the vulnerability is exploited, an attacker may be able to log in to the system as an arbitrary user, allowing them to read or tamper with data in the database, and/or disable the database.
Package postgresql13-pgpool-II updated to version 4.6.1-alt0.p10.1 for branch p10 in task 384189.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2025-07452
Уязвимость программных средств балансировки и управления соединениями Pgpool-II, связанная с обходом аутентификации в силу исходной ошибки, позволяющая нарушителю обойти ограничения безопасности и получить доступ на чтение, изменение и удаление данных
Modified: 2026-04-15
CVE-2025-46801
Pgpool-II provided by PgPool Global Development Group contains an authentication bypass by primary weakness vulnerability. if the vulnerability is exploited, an attacker may be able to log in to the system as an arbitrary user, allowing them to read or tamper with data in the database, and/or disable the database.
Package postgresql15-pgpool-II updated to version 4.6.1-alt0.p10.1 for branch p10 in task 384189.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2025-07452
Уязвимость программных средств балансировки и управления соединениями Pgpool-II, связанная с обходом аутентификации в силу исходной ошибки, позволяющая нарушителю обойти ограничения безопасности и получить доступ на чтение, изменение и удаление данных
Modified: 2026-04-15
CVE-2025-46801
Pgpool-II provided by PgPool Global Development Group contains an authentication bypass by primary weakness vulnerability. if the vulnerability is exploited, an attacker may be able to log in to the system as an arbitrary user, allowing them to read or tamper with data in the database, and/or disable the database.
Package postgresql16-pgpool-II updated to version 4.6.1-alt0.p10.1 for branch p10 in task 384189.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2025-07452
Уязвимость программных средств балансировки и управления соединениями Pgpool-II, связанная с обходом аутентификации в силу исходной ошибки, позволяющая нарушителю обойти ограничения безопасности и получить доступ на чтение, изменение и удаление данных
Modified: 2026-04-15
CVE-2025-46801
Pgpool-II provided by PgPool Global Development Group contains an authentication bypass by primary weakness vulnerability. if the vulnerability is exploited, an attacker may be able to log in to the system as an arbitrary user, allowing them to read or tamper with data in the database, and/or disable the database.
Package kernel-image-un-def updated to version 6.1.140-alt1 for branch p10 in task 385010.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2024-10603
Уязвимость функции of_modalias() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-04087
Уязвимость драйвера USB (drivers/usb/typec/ucsi/ucsi.c) ядра операционных систем 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-04-13
BDU:2025-06490
Уязвимость модуля net/sched/sch_hfsc.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-02-17
BDU:2025-08099
Уязвимость компонента nft_tunnel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-13
BDU:2025-09017
Уязвимость функции macb_halt_tx() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09023
Уязвимость функции smp_store_mb() компонента dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09037
Уязвимость функции idxd_alloc() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09038
Уязвимость функции uclogic_input_configured() компонента HID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09039
Уязвимость функции mt76_dma_cleanup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-03
BDU:2025-09837
Уязвимость функции spi_imx_transfer_one операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-10257
Уязвимость модуля fs/ext4/dir.c ядра операционной системы 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-13
BDU:2025-10609
Уязвимость функции tls_strp_flush_anchor_copy операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10610
Уязвимость функции mlx5e_fix_uplink_rep_features операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10613
Уязвимость функции rxe_create_cq операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10614
Уязвимость функции nfs_get_lock_context операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-10758
Уязвимость функции af_alg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-11764
Уязвимость функции max20086_parse_regulators_dt операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11773
Уязвимость компонента memory_hotplug ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-11790
Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11793
Уязвимость компонента ip_vs_xmit.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11798
Уязвимость компонента microchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11810
Уязвимость ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11811
Уязвимость ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-11815
Уязвимость компонента bnxt_coredump.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11826
Уязвимость ядра операционной системы Linux, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11827
Уязвимость ядра операционной системы Linux, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11828
Уязвимость компонента sch_htb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в осблуживании
Modified: 2026-03-30
BDU:2025-11829
Уязвимость компонента nouveau_fence.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в осблуживании
Modified: 2026-03-25
BDU:2025-11830
Уязвимость компонента vxlan_vnifilter.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в осблуживании
Modified: 2026-03-31
BDU:2025-11836
Уязвимость компонента qcom/lpass.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11838
Уязвимость компонента dm-bufio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-11857
Уязвимость компонента sch_ets.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-11
BDU:2025-11860
Уязвимость функции ea_get() компонента fs/jfs/xattr.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11865
Уязвимость компонента vfs.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-30
BDU:2025-11866
Уязвимость компонента trace.c ядра операционной системы 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-02-16
BDU:2025-11871
Уязвимость компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11873
Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-11886
Уязвимость компонента drivers/ntb/hw/mscc/ntb_hw_switchtec.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11888
Уязвимость компонента hfi_parser ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-11892
Уязвимость ядра операционной системы Linux, связанная с чтением за допустимыми границами буфера данных, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11893
Уязвимость компонента hfi_parser ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-11895
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11896
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11900
Уязвимость компонента irq-qcom-mpm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-11901
Уязвимость функции rtnl_vfinfo_size() компонента net/core/rtnetlink.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11906
Уязвимость компонента sclp_con.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11908
Уязвимость компонента index.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-11911
Уязвимость ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11924
Уязвимость компонента init.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-04
BDU:2025-11925
Уязвимость ядра операционной системы Linux, связанная с целочисленной потерей значимости, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11928
Уязвимость компонента bpf_jit_comp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11929
Уязвимость компонентов arm64 ядра операционной системы 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-02-17
BDU:2025-11940
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11952
Уязвимость компонента platform/x86/amd/pmc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-11960
Уязвимость компонента fs/read_write.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11970
Уязвимость функции output_userspace() компонента net/openvswitch/actions.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-02-17
BDU:2025-11988
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11991
Уязвимость компонента streamzap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11997
Уязвимость ядра операционной системы Linux, связанная с ошибками синхронизации при использовании общего ресурса, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-11998
Уязвимость компонента sch_drr.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-25
BDU:2025-11999
Уязвимость компонента net/sched/sch_qfq.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-30
BDU:2025-12001
Уязвимость компонента dib8000.c ядра операционной системы 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-13
BDU:2025-12014
Уязвимость компонента drivers/dma/ti/k3-udma.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12020
Уязвимость компонента arch/x86/mm/tlb.c ядра операционной системы 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-30
BDU:2025-12032
Уязвимость компонента v3d_sched.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-12033
Уязвимость компонентов microchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12034
Уязвимость компонента cxgb4_ethtool.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12036
Уязвимость компонента link.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12038
Уязвимость функции spufs_rmdir() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12039
Уязвимость компонента spufs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12040
Уязвимость функции spufs_create_context() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12050
Уязвимость компонента drivers/media/i2c/et8ek8/et8ek8 ядра операционной системы 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-11
BDU:2025-12063
Уязвимость функции ksmbd_crypt_message() в модуле fs/smb/server/auth.c поддержки сервера SMB ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2026-03-30
BDU:2025-12068
Уязвимость компонента auth.c ядра операционной системы 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-02-16
BDU:2025-12075
Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12076
Уязвимость компонента kernel/trace ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12077
Уязвимость функции rtsx_usb_ms_drv_remove() компонента drivers/memstick/host/rtsx_usb_ms.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12085
Уязвимость компонента sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12086
Уязвимость компонента irq-gic-v2m.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-12092
Уязвимость компонента drivers/gpu/drm/vkms ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12093
Уязвимость функции erdma_accept_newconn() компонента drivers/infiniband/hw/erdma/erdma_cm.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12096
Уязвимость функции ksmbd_sessions_deregister() компонента user_session.c ядра операционной системы 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-10
BDU:2025-12111
Уязвимость компонента net/sched/sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12113
Уязвимость компонента remoteproc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12114
Уязвимость компонента com20020-pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12123
Уязвимость компонента ucsi/displayport.c ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12124
Уязвимость компонентов net/sched/ ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12126
Уязвимость функции mtk_pmic_keys_lp_reset_setup() компонента mtk-pmic-keys.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12129
Уязвимость ядра операционной системы Linux, связанная с неправильным разыменованем нулеового указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12130
Уязвимость компонента core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-12134
Уязвимость функции ice_vc_add_fdir_fltr() ядра операционной системы 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-17
BDU:2025-12167
Уязвимость компонента int3402_thermal.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12168
Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12169
Уязвимость компонента RDMA/core ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12170
Уязвимость компонента RDMA/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12173
Уязвимость компонента imx-card.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12175
Уязвимость компонента calipso.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12177
Уязвимость компонента usbnet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12178
Уязвимость компонента compat_alignment.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12180
Уязвимость компонента mpc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12236
Уязвимость компонента net/sched/sch_skbprio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-12237
Уязвимость компонента mac.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12246
Уязвимость компонента dispc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12248
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12253
Уязвимость ядра операционной системы Linux, связанная с ошибками инициализации памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12256
Уязвимость компонентов xenbus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12257
Уязвимость ядра операционной системы Linux, связанная с недостаточной блокировкой, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12271
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12272
Уязвимость компонента filter.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-12273
Уязвимость компонента mtk_star_emac.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12275
Уязвимость компонента chip.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12276
Уязвимость компонента acpi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12278
Уязвимость ядра операционной системы Linux, связанная с некорректным вычислением, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12281
Уязвимость компонента x86/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12283
Уязвимость функции btrfs_dec_ref() ядра операционной системы 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-12300
Уязвимость ядра операционной системы 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-12333
Уязвимость ядра операционной системы Linux, связанная с доступом к неинициализированному указателю, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12334
Уязвимость ядра операционной системы Linux, связанная с доступом к неинициализированному указателю, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12335
Уязвимость модуля USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12336
Уязвимость компонентов drivers/usb/typec/ucsi/ ядра операционной системы 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-31
BDU:2025-12350
Уязвимость функции st_lsm6dsx_read_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12351
Уязвимость функции st_lsm6dsx_read_tagged_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы 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-25
BDU:2025-12367
Уязвимость компонента bus.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-12368
Уязвимость компонента amdgpu_dm_hdcp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12370
Уязвимость компонента drm/nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12371
Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12705
Уязвимость функции l2cap_connect() модуля net/bluetooth/l2cap_core.c ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
BDU:2026-03461
Уязвимость функции build_prologue() модуля arch/loongarch/net/bpf_jit.c поддержки архитектуры LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-03
CVE-2023-53034
In the Linux kernel, the following vulnerability has been resolved: ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative. [ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative Ensuring xlate_pos is a positive or zero before BIT.
- https://git.kernel.org/stable/c/0df2e03e4620548b41891b4e0d1bd9d2e0d8a39a
- https://git.kernel.org/stable/c/2429bdf26a0f3950fdd996861e9c1a3873af1dbe
- https://git.kernel.org/stable/c/36d32cfb00d42e865396424bb5d340fc0a28870d
- https://git.kernel.org/stable/c/5b6857bb3bfb0dae17fab1e42c1e82c204a508b1
- https://git.kernel.org/stable/c/7ed22f8d8be26225a78cf5e85b2036421a6bf2d5
- https://git.kernel.org/stable/c/c61a3f2df162ba424be0141649a9ef5f28eaccc1
- https://git.kernel.org/stable/c/cb153bdc1812a3375639ed6ca5f147eaefb65349
- https://git.kernel.org/stable/c/de203da734fae00e75be50220ba5391e7beecdf9
- https://git.kernel.org/stable/c/f56951f211f181410a383d305e8d370993e45294
- 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-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-38611
In the Linux kernel, the following vulnerability has been resolved: media: i2c: et8ek8: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)
- https://git.kernel.org/stable/c/04d1086a62ac492ebb6bb0c94c1c8cb55f5d1f36
- https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9
- https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce
- https://git.kernel.org/stable/c/904db2ba44ae60641b6378c5013254d09acf5e80
- https://git.kernel.org/stable/c/963523600d9f1e36bc35ba774c2493d6baa4dd8f
- https://git.kernel.org/stable/c/c1a3803e5bb91c13e9ad582003e4288f67f06cd9
- https://git.kernel.org/stable/c/ece3fc1c10197052044048bea4f13cfdcf25b416
- https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9
- https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce
- https://git.kernel.org/stable/c/904db2ba44ae60641b6378c5013254d09acf5e80
- https://git.kernel.org/stable/c/c1a3803e5bb91c13e9ad582003e4288f67f06cd9
- 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-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-46753
In the Linux kernel, the following vulnerability has been resolved: btrfs: handle errors from btrfs_dec_ref() properly In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This is incorrect, we have proper error handling here, return the error.
- https://git.kernel.org/stable/c/0e4840ae09f375381167000ce47424818fcbcc7c
- https://git.kernel.org/stable/c/2c4fe45351e544da4b8f10c74b277117a4fa7869
- https://git.kernel.org/stable/c/5eb178f373b4f16f3b42d55ff88fc94dd95b93b1
- https://git.kernel.org/stable/c/67e4ca7ddc67ef949326b4dc404a9678bbe67d72
- https://git.kernel.org/stable/c/9c8237021b53d52357c0de07a768582fafb2791d
- https://git.kernel.org/stable/c/a7f16a7a709845855cb5a0e080a52bda5873f9de
- 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-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-2024-57945
In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.
- https://git.kernel.org/stable/c/92f08673d3f1893191323572f60e3c62f2e57c2f
- https://git.kernel.org/stable/c/a4a7ac3d266008018f05fae53060fcb331151a14
- https://git.kernel.org/stable/c/d2bd51954ac8377c2f1eb1813e694788998add66
- https://git.kernel.org/stable/c/f754f27e98f88428aaf6be6e00f5cbce97f62d4b
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-03
CVE-2025-21645
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wake_depth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged: kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0 The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and .poweroff handlers. i8042_pm_suspend(), however, is only set as the .suspend handler. Fix the issue by call PMC suspend handler only from the same set of dev_pm_ops handlers as i8042_pm_suspend(), which currently means just the .suspend handler. To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first. [ij: edited the commit message.]
- https://git.kernel.org/stable/c/5cc621085e2b7a9b1905a98f8e5a86bb4aea2016
- https://git.kernel.org/stable/c/ab47d72b736e78d3c2370b26e0bfc46eb0918391
- https://git.kernel.org/stable/c/b25778c87a6bce40c31e92364f08aa6240309e25
- https://git.kernel.org/stable/c/dd410d784402c5775f66faf8b624e85e41c38aaf
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-03
CVE-2025-21839
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop
Move the conditional loading of hardware DR6 with the guest's DR6 value
out of the core .vcpu_run() loop to fix a bug where KVM can load hardware
with a stale vcpu->arch.dr6.
When the guest accesses a DR and host userspace isn't debugging the guest,
KVM disables DR interception and loads the guest's values into hardware on
VM-Enter and saves them on VM-Exit. This allows the guest to access DRs
at will, e.g. so that a sequence of DR accesses to configure a breakpoint
only generates one VM-Exit.
For DR0-DR3, the logic/behavior is identical between VMX and SVM, and also
identical between KVM_DEBUGREG_BP_ENABLED (userspace debugging the guest)
and KVM_DEBUGREG_WONT_EXIT (guest using DRs), and so KVM handles loading
DR0-DR3 in common code, _outside_ of the core kvm_x86_ops.vcpu_run() loop.
But for DR6, the guest's value doesn't need to be loaded into hardware for
KVM_DEBUGREG_BP_ENABLED, and SVM provides a dedicated VMCB field whereas
VMX requires software to manually load the guest value, and so loading the
guest's value into DR6 is handled by {svm,vmx}_vcpu_run(), i.e. is done
_inside_ the core run loop.
Unfortunately, saving the guest values on VM-Exit is initiated by common
x86, again outside of the core run loop. If the guest modifies DR6 (in
hardware, when DR interception is disabled), and then the next VM-Exit is
a fastpath VM-Exit, KVM will reload hardware DR6 with vcpu->arch.dr6 and
clobber the guest's actual value.
The bug shows up primarily with nested VMX because KVM handles the VMX
preemption timer in the fastpath, and the window between hardware DR6
being modified (in guest context) and DR6 being read by guest software is
orders of magnitude larger in a nested setup. E.g. in non-nested, the
VMX preemption timer would need to fire precisely between #DB injection
and the #DB handler's read of DR6, whereas with a KVM-on-KVM setup, the
window where hardware DR6 is "dirty" extends all the way from L1 writing
DR6 to VMRESUME (in L1).
L1's view:
==========
- https://git.kernel.org/stable/c/4eb063de686bfcdfd03a8c801d1bbe87d2d5eb55
- https://git.kernel.org/stable/c/93eeb6df1605b3a24f38afdba7ab903ba6b64133
- https://git.kernel.org/stable/c/9efb2b99b96c86664bbdbdd2cdb354ac9627eb20
- https://git.kernel.org/stable/c/a1723e9c53fe6431415be19302a56543daf503f5
- https://git.kernel.org/stable/c/c2fee09fc167c74a64adb08656cb993ea475197e
- https://git.kernel.org/stable/c/d456de38d9eb753a4e9fde053c18d4ef8e485339
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-03
CVE-2025-21918
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix NULL pointer access Resources should be released only after all threads that utilize them have been destroyed. This commit ensures that resources are not released prematurely by waiting for the associated workqueue to complete before deallocating them.
- https://git.kernel.org/stable/c/079a3e52f3e751bb8f5937195bdf25c5d14fdff0
- https://git.kernel.org/stable/c/46fba7be161bb89068958138ea64ec33c0b446d4
- https://git.kernel.org/stable/c/592a0327d026a122e97e8e8bb7c60cbbe7697344
- https://git.kernel.org/stable/c/7a735a8a46f6ebf898bbefd96659ca5da798bce0
- https://git.kernel.org/stable/c/b13abcb7ddd8d38de769486db5bd917537b32ab1
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-21931
In the Linux kernel, the following vulnerability has been resolved: hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem. Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/3926b572fd073491bde13ec42ee08ac1b337bf4d
- https://git.kernel.org/stable/c/576a2f4c437c19bec7d05d05b5990f178d2b0f40
- https://git.kernel.org/stable/c/629dfc6ba5431056701d4e44830f3409b989955a
- https://git.kernel.org/stable/c/93df6da64b004f75d307ed08d3f0f1020280d339
- https://git.kernel.org/stable/c/af288a426c3e3552b62595c6138ec6371a17dbba
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-03
CVE-2025-22018
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger
Null Pointer Dereference Vulnerability if both entry and
holding_time are NULL. Because there is only for the situation
where entry is NULL and holding_time exists, it can be passed
when both entry and holding_time are NULL. If these are NULL,
the entry will be passd to eg_cache_put() as parameter and
it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725]
- https://git.kernel.org/stable/c/09691f367df44fe93255274d80a439f9bb3263fc
- https://git.kernel.org/stable/c/0ef6e49881b6b50ac454cb9d6501d009fdceb6fc
- https://git.kernel.org/stable/c/14c7aca5ba2740973de27c1bb8df77b4dcb6f775
- https://git.kernel.org/stable/c/1505f9b720656b17865e4166ab002960162bf679
- https://git.kernel.org/stable/c/3c23bb2c894e9ef2727682f98c341b20f78c9013
- https://git.kernel.org/stable/c/9da6b6340dbcf0f60ae3ec6a7d6438337c32518a
- https://git.kernel.org/stable/c/ab92f51c7f53a08f1a686bfb80690ebb3672357d
- https://git.kernel.org/stable/c/bf2986fcf82a449441f9ee4335df19be19e83970
- https://git.kernel.org/stable/c/d7f1e4a53a51cc6ba833afcb40439f18dab61c1f
- 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-22020
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
==================================================================
BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1
Tainted: [E]=UNSIGNED_MODULE
Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024
Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]
Call Trace:
- https://git.kernel.org/stable/c/0067cb7d7e7c277e91a0887a3c24e71462379469
- https://git.kernel.org/stable/c/31f0eaed6914333f42501fc7e0f6830879f5ef2d
- https://git.kernel.org/stable/c/4676741a3464b300b486e70585c3c9b692be1632
- https://git.kernel.org/stable/c/52d942a5302eefb3b7a3bfee310a5a33feeedc21
- https://git.kernel.org/stable/c/6186fb2cd36317277a8423687982140a7f3f7841
- https://git.kernel.org/stable/c/75123adf204f997e11bbddee48408c284f51c050
- https://git.kernel.org/stable/c/914c5e5bfceb9878f3056eaf4d1c88f2cbe0a185
- https://git.kernel.org/stable/c/9dfaf4d723c62bda8d9d1340e2e78acf0c190439
- https://git.kernel.org/stable/c/b094e8e3988e02e8cef7a756c8d2cea9c12509ab
- 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-22021
In the Linux kernel, the following vulnerability has been resolved: netfilter: socket: Lookup orig tuple for IPv6 SNAT nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent. However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6. IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on `-m socket --transparent` and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.
- https://git.kernel.org/stable/c/1ca2169cc19dca893c7aae6af122852097435d16
- https://git.kernel.org/stable/c/1ec43100f7123010730b7ddfc3d5c2eac19e70e7
- https://git.kernel.org/stable/c/221c27259324ec1404f028d4f5a0f2ae7f63ee23
- https://git.kernel.org/stable/c/2bb139e483f8cbe488d19d8c1135ac3615e2668c
- https://git.kernel.org/stable/c/41904cbb343d115931d6bf79aa2c815cac4ef72b
- https://git.kernel.org/stable/c/5251041573850e5020cd447374e23010be698898
- https://git.kernel.org/stable/c/58ab63d3ded2ca6141357a2b24eee8453d0f871d
- https://git.kernel.org/stable/c/6488b96a79a26e19100ad872622f04e93b638d7f
- https://git.kernel.org/stable/c/932b32ffd7604fb00b5c57e239a3cc4d901ccf6e
- 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-22025
In the Linux kernel, the following vulnerability has been resolved: nfsd: put dl_stid if fail to queue dl_recall Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid. We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release. However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented correspondingly, leading to the following nfs4_stid leak: unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. backtrace: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 unreferenced object 0xffff8881499f4d28 (size 368): comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... backtrace: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if fail to queue dl_recall.
- https://git.kernel.org/stable/c/133f5e2a37ce08c82d24e8fba65e0a81deae4609
- https://git.kernel.org/stable/c/230ca758453c63bd38e4d9f4a21db698f7abada8
- https://git.kernel.org/stable/c/63b91c8ff4589f5263873b24c052447a28e10ef7
- https://git.kernel.org/stable/c/9a81cde8c7ce65dd90fb47ceea93a45fc1a2fbd1
- https://git.kernel.org/stable/c/b874cdef4e67e5150e07eff0eae1cbb21fb92da1
- https://git.kernel.org/stable/c/cad3479b63661a399c9df1d0b759e1806e2df3c8
- https://git.kernel.org/stable/c/cdb796137c57e68ca34518d53be53b679351eb86
- https://git.kernel.org/stable/c/d96587cc93ec369031bcd7658c6adc719873c9fd
- 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-22027
In the Linux kernel, the following vulnerability has been resolved: media: streamzap: fix race between device disconnection and urb callback Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_device() is called before usb_kill_urb(). The dev->raw pointer is freed and set to NULL in rc_unregister_device(), and only after that usb_kill_urb() waits for in-progress requests to finish. If rc_unregister_device() is called while streamzap_callback() handler is not finished, this can lead to accessing freed resources. Thus rc_unregister_device() should be called after usb_kill_urb(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/15483afb930fc2f883702dc96f80efbe4055235e
- https://git.kernel.org/stable/c/30ef7cfee752ca318d5902cb67b60d9797ccd378
- https://git.kernel.org/stable/c/4db62b60af2ccdea6ac5452fd20e29587ed85f57
- https://git.kernel.org/stable/c/8760da4b9d44c36b93b6e4cf401ec7fe520015bd
- https://git.kernel.org/stable/c/adf0ddb914c9e5b3e50da4c97959e82de2df75c3
- https://git.kernel.org/stable/c/e11652a6514ec805440c1bb3739e6c6236fffcc7
- https://git.kernel.org/stable/c/f1d518c0bad01abe83c2df880274cb6a39f4a457
- https://git.kernel.org/stable/c/f656cfbc7a293a039d6a0c7100e1c846845148c1
- 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-22033
In the Linux kernel, the following vulnerability has been resolved: arm64: Don't call NULL in do_compat_alignment_fixup() do_alignment_t32_to_handler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000 [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] SMP Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa> libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1 Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : do_compat_alignment_fixup+0xd8/0x3dc sp : ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Call trace: 0x0 do_alignment_fault+0x40/0x50 do_mem_abort+0x4c/0xa0 el0_da+0x48/0xf0 el0t_32_sync_handler+0x110/0x140 el0t_32_sync+0x190/0x194 Code: bad PC value ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/2df8ee605eb6806cd41c2095306db05206633a08
- https://git.kernel.org/stable/c/617a4b0084a547917669fef2b54253cc9c064990
- https://git.kernel.org/stable/c/c28f31deeacda307acfee2f18c0ad904e5123aac
- https://git.kernel.org/stable/c/cf187601053ecaf671ae645edb898901f81d03e9
- https://git.kernel.org/stable/c/ecf798573bbe0805803f7764e12a34b4bcc65074
- https://git.kernel.org/stable/c/fa2a9f625f185c6acb4ee5be8d71359a567afac9
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22035
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free in print_graph_function_flags during tracer switching Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns. Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags. Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'. To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
- https://git.kernel.org/stable/c/099ef3385800828b74933a96c117574637c3fb3a
- https://git.kernel.org/stable/c/42561fe62c3628ea3bc9623f64f047605e98857f
- https://git.kernel.org/stable/c/70be951bc01e4a0e10d443f3510bb17426f257fb
- https://git.kernel.org/stable/c/7f81f27b1093e4895e87b74143c59c055c3b1906
- https://git.kernel.org/stable/c/81a85b12132c8ffe98f5ddbdc185481790aeaa1b
- https://git.kernel.org/stable/c/a2cce54c1748216535dda02e185d07a084be837e
- https://git.kernel.org/stable/c/c85efe6e13743cac6ba4ccf144cb91f44c86231a
- https://git.kernel.org/stable/c/de7b309139f862a44379ecd96e93c9133c69f813
- https://git.kernel.org/stable/c/f14752d66056d0c7bffe5092130409417d3baa70
- 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-22038
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate zero num_subauth before sub_auth is accessed Access psid->sub_auth[psid->num_subauth - 1] without checking if num_subauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure num_subauth != 0 before sub_auth is accessed.
- https://git.kernel.org/stable/c/0e36a3e080d6d8bd7a34e089345d043da4ac8283
- https://git.kernel.org/stable/c/3ac65de111c686c95316ade660f8ba7aea3cd3cc
- https://git.kernel.org/stable/c/56de7778a48560278c334077ace7b9ac4bfb2fd1
- https://git.kernel.org/stable/c/68c6c3142bfcdb049839d40a9a59ebe8ea865002
- https://git.kernel.org/stable/c/bf21e29d78cd2c2371023953d9c82dfef82ebb36
- https://git.kernel.org/stable/c/c8bfe1954a0b89e7b29b3a3e7f4c5e0ebd295e20
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-04-06
CVE-2025-22040
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix session use-after-free in multichannel connection There is a race condition between session setup and ksmbd_sessions_deregister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it.
- https://git.kernel.org/stable/c/3980770cb1470054e6400fd97668665975726737
- https://git.kernel.org/stable/c/596407adb9af1ee75fe7c7529607783d31b66e7f
- https://git.kernel.org/stable/c/7dfbd4c43eed91dd2548a95236908025707a8dfd
- https://git.kernel.org/stable/c/9069939d762138e232a6f79e3e1462682ed6a17d
- https://git.kernel.org/stable/c/94c281721d4ed2d972232414b91d98a6f5bdb16b
- https://git.kernel.org/stable/c/fa4cdb8cbca7d6cb6aa13e4d8d83d1103f6345db
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-04-02
CVE-2025-22041
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_sessions_deregister() In multichannel mode, UAF issue can occur in session_deregister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection.
- https://git.kernel.org/stable/c/15a9605f8d69dc85005b1a00c31a050b8625e1aa
- https://git.kernel.org/stable/c/33cc29e221df7a3085ae413e8c26c4e81a151153
- https://git.kernel.org/stable/c/8ed0e9d2f410f63525afb8351181eea36c80bcf1
- https://git.kernel.org/stable/c/a8a8ae303a8395cbac270b5b404d85df6ec788f8
- https://git.kernel.org/stable/c/ca042cc0e4f9e0d2c8f86dd67e4b22f30a516a9b
- https://git.kernel.org/stable/c/f0eb3f575138b816da74697bd506682574742fcd
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2026-04-06
CVE-2025-22042
In the Linux kernel, the following vulnerability has been resolved: ksmbd: add bounds check for create lease context Add missing bounds check for create lease context.
- https://git.kernel.org/stable/c/60b7207893a8a06c78441934931a08fdad63f18e
- https://git.kernel.org/stable/c/629dd37acc336ad778979361c351e782053ea284
- https://git.kernel.org/stable/c/800c482c9ef5910f05e3a713943c67cc6c1d4939
- https://git.kernel.org/stable/c/9a1b6ea955e6c7b29939a6d98701202f9d9644ec
- https://git.kernel.org/stable/c/a41cd52f00907a040ca22c73d4805bb79b0d0972
- https://git.kernel.org/stable/c/bab703ed8472aa9d109c5f8c1863921533363dae
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22044
In the Linux kernel, the following vulnerability has been resolved: acpi: nfit: fix narrowing conversion in acpi_nfit_ctl Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary bus families can be translated". This warning is emited if the argument is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first verifies that a user-provided value call_pkg->nd_family of type u64 is not equal to 0. Then the value is converted to int, and only after that is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while the lower 32 bits are zero. Furthermore, it is best to return EINVAL immediately upon seeing the invalid user input. The WARNING is insufficient to prevent further undefined behavior based on other invalid user input. All checks of the input value should be applied to the original variable call_pkg->nd_family. [iweiny: update commit message]
- https://git.kernel.org/stable/c/2ff0e408db36c21ed3fa5e3c1e0e687c82cf132f
- https://git.kernel.org/stable/c/4b65cff06a004ac54f6ea8886060f0d07b1ca055
- https://git.kernel.org/stable/c/73851cfceb00cc77d7a0851bc10f2263394c3e87
- https://git.kernel.org/stable/c/85f11291658ab907c4294319c8102450cc75bb96
- https://git.kernel.org/stable/c/92ba06aef65522483784dcbd6697629ddbd4c4f9
- https://git.kernel.org/stable/c/bae5b55e0f327102e78f6a66fb127275e9bc91b6
- https://git.kernel.org/stable/c/c90402d2a226ff7afbe1d0650bee8ecc15a91049
- https://git.kernel.org/stable/c/e71a57c5aaa389d4c3c82f920761262efdd18d38
- 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-22045
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs
On the following path, flush_tlb_range() can be used for zapping normal
PMD entries (PMD entries that point to page tables) together with the PTE
entries in the pointed-to page table:
collapse_pte_mapped_thp
pmdp_collapse_flush
flush_tlb_range
The arm64 version of flush_tlb_range() has a comment describing that it can
be used for page table removal, and does not use any last-level
invalidation optimizations. Fix the X86 version by making it behave the
same way.
Currently, X86 only uses this information for the following two purposes,
which I think means the issue doesn't have much impact:
- In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be
IPI'd to avoid issues with speculative page table walks.
- In Hyper-V TLB paravirtualization, again for lazy TLB stuff.
The patch "x86/mm: only invalidate final translations with INVLPGB" which
is currently under review (see
- https://git.kernel.org/stable/c/0708fd6bd8161871bfbadced2ca4319b84ab44fe
- https://git.kernel.org/stable/c/0a8f806ea6b5dd64b3d1f05ff774817d5f7ddbd1
- https://git.kernel.org/stable/c/320ac1af4c0bdb92c864dc9250d1329234820edf
- https://git.kernel.org/stable/c/3ef938c3503563bfc2ac15083557f880d29c2e64
- https://git.kernel.org/stable/c/556d446068f90981e5d71ca686bdaccdd545d491
- https://git.kernel.org/stable/c/618d5612ecb7bfc1c85342daafeb2b47e29e77a3
- https://git.kernel.org/stable/c/7085895c59e4057ffae17f58990ccb630087d0d2
- https://git.kernel.org/stable/c/78d6f9a9eb2a5da6fcbd76d6191d24b0dcc321be
- https://git.kernel.org/stable/c/93224deb50a8d20df3884f3672ce9f982129aa50
- 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-22049
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Increase ARCH_DMA_MINALIGN up to 16 ARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices (such as APBDMA) require 16 bytes alignment. When the data buffer length is too small, the hardware may make an error writing cacheline. Thus, it is dangerous to allocate a small memory buffer for DMA. It's always safe to define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16.
- https://git.kernel.org/stable/c/1d0def2d1658666ec1f32c9495df60e7411e3c82
- https://git.kernel.org/stable/c/279ec25c2df49fba1cd9488f2ddd045d9cb2112e
- https://git.kernel.org/stable/c/4103cfe9dcb88010ae4911d3ff417457d1b6a720
- https://git.kernel.org/stable/c/8b82aea3666f8f2c78f86148d78aea99c46e0f82
- https://git.kernel.org/stable/c/bfff341cac7c650e6ca8d10503725992f5564d0f
- https://git.kernel.org/stable/c/f39af67f03b564b763b06e44cb960c10a382d54a
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22050
In the Linux kernel, the following vulnerability has been resolved: usbnet:fix NPE during rx_complete Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check. This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued. Subsequent processes: (e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
- https://git.kernel.org/stable/c/0c30988588b28393e3e8873d5654f910e86391ba
- https://git.kernel.org/stable/c/0f10f83acfd619e13c64d6705908dfd792f19544
- https://git.kernel.org/stable/c/51de3600093429e3b712e5f091d767babc5dd6df
- https://git.kernel.org/stable/c/95789c2f94fd29dce8759f9766baa333f749287c
- https://git.kernel.org/stable/c/acacd48a37b52fc95f621765762c04152b58d642
- https://git.kernel.org/stable/c/d689645cd1594ea1d13cb0c404f8ad1011353e0e
- https://git.kernel.org/stable/c/fd9ee3f0d6a53844f65efde581c91bbb0ff749ac
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22054
In the Linux kernel, the following vulnerability has been resolved: arcnet: Add NULL check in com20020pci_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, com20020pci_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated.
- https://git.kernel.org/stable/c/661cf5d102949898c931e81fd4e1c773afcdeafa
- https://git.kernel.org/stable/c/887226163504494ea7e58033a97c2d2ab12e05d4
- https://git.kernel.org/stable/c/905a34dc1ad9a53a8aaaf8a759ea5dbaaa30418d
- https://git.kernel.org/stable/c/a654f31b33515d39bb56c75fd8b26bef025ced7e
- https://git.kernel.org/stable/c/be8a0decd0b59a52a07276f9ef3b33ef820b2179
- https://git.kernel.org/stable/c/ebebeb58d48e25525fa654f2c53a24713fe141c3
- https://git.kernel.org/stable/c/ececf8eff6c25acc239fa8f0fd837c76bc770547
- https://git.kernel.org/stable/c/ef8b29398ea6061ac8257f3e45c9be45cc004ce2
- https://git.kernel.org/stable/c/fda8c491db2a90ff3e6fbbae58e495b4ddddeca3
- 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-22055
In the Linux kernel, the following vulnerability has been resolved:
net: fix geneve_opt length integer overflow
struct geneve_opt uses 5 bit length for each single option, which
means every vary size option should be smaller than 128 bytes.
However, all current related Netlink policies cannot promise this
length condition and the attacker can exploit a exact 128-byte size
option to *fake* a zero length option and confuse the parsing logic,
further achieve heap out-of-bounds read.
One example crash log is like below:
[ 3.905425] ==================================================================
[ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0
[ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177
[ 3.906646]
[ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1
[ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[ 3.907784] Call Trace:
[ 3.907925]
- https://git.kernel.org/stable/c/21748669c5825761cbbf47cbeeb01387ddccc8cb
- https://git.kernel.org/stable/c/2952776c69a1a551649ed770bf22e3f691f6ec65
- https://git.kernel.org/stable/c/4d606069bdd3c76f8ab1f06796c97ef7f4746807
- https://git.kernel.org/stable/c/5a2976cc4d9c36ff58a0f10e35ce4283cbaa9c0e
- https://git.kernel.org/stable/c/738ae5712215fe9181587d582b23333f02c62ca6
- https://git.kernel.org/stable/c/a2cb85f989e2074e2f392e00188c438cab3de088
- https://git.kernel.org/stable/c/b27055a08ad4b415dcf15b63034f9cb236f7fb40
- https://git.kernel.org/stable/c/b4513ad0f391871d3feee8ddf535609a3aabeeac
- 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-22056
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_tunnel: fix geneve_opt type confusion addition
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the
parsing logic should place every geneve_opt structure one by one
compactly. Hence, when deciding the next geneve_opt position, the
pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion
before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ==================================================================
[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70
[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178
[ 6.991162]
[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1
[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[ 6.992281] Call Trace:
[ 6.992423]
- https://git.kernel.org/stable/c/0a93a710d6df334b828ea064c6d39fda34f901dc
- https://git.kernel.org/stable/c/1b755d8eb1ace3870789d48fbd94f386ad6e30be
- https://git.kernel.org/stable/c/28d88ee1e1cc8ac2d79aeb112717b97c5c833d43
- https://git.kernel.org/stable/c/31d49eb436f2da61280508d7adf8c9b473b967aa
- https://git.kernel.org/stable/c/446d94898c560ed2f61e26ae445858a4c4830762
- https://git.kernel.org/stable/c/708e268acb3a446ad2a8a3d2e9bd41cc23660cd6
- https://git.kernel.org/stable/c/a263d31c8c92e5919d41af57d9479cfb66323782
- https://git.kernel.org/stable/c/ca2adfc03cd6273f0b589fe65afc6f75e0fe116e
- 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-22058
In the Linux kernel, the following vulnerability has been resolved: udp: Fix memory accounting leak. Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops. We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release(). When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable. The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow. Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated(). When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release(). At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4). Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double. This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops. To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta. Note that first_packet_length() also potentially has the same problem. [0]: from socket import * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) data = b'a' * 100 while True: c.send(data)
- https://git.kernel.org/stable/c/13550273171f5108b1ac572d8f72f4256ab92854
- https://git.kernel.org/stable/c/3836029448e76c1e6f77cc5fe0adc09b018b5fa8
- https://git.kernel.org/stable/c/9122fec396950cc866137af7154b1d0d989be52e
- https://git.kernel.org/stable/c/a116b271bf3cb72c8155b6b7f39083c1b80dcd00
- https://git.kernel.org/stable/c/aeef6456692c6f11ae53d278df64f1316a2a405a
- https://git.kernel.org/stable/c/c3ad8c30b6b109283d2643e925f8e65f2e7ab34e
- https://git.kernel.org/stable/c/c4bac6c398118fba79e32b1cd01db22dbfe29fbf
- https://git.kernel.org/stable/c/d9c8266ce536e8314d84370e983afcaa36fb19cf
- https://git.kernel.org/stable/c/df207de9d9e7a4d92f8567e2c539d9c8c12fd99d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22060
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: Prevent parser TCAM memory corruption Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications. Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row. This issue was detected in a situation where `mvpp2_set_rx_mode()` ran concurrently on two CPUs. In this particular case the MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the `rx_classifier_drops` counter.
- https://git.kernel.org/stable/c/46c1e23e34c9d1eaadf37f88216d9d8ce0d0bcee
- https://git.kernel.org/stable/c/5b0ae1723a7d9574ae1aee7d9cf9757a30069865
- https://git.kernel.org/stable/c/96844075226b49af25a69a1d084b648ec2d9b08d
- https://git.kernel.org/stable/c/b3f48a41a00d6d8d9c6fe09ae47dd21c8c1c8b03
- https://git.kernel.org/stable/c/e3711163d14d02af9005e4cdad30899c565f13fb
- https://git.kernel.org/stable/c/e64e9b6e86b39db3baa576fd73da73533b54cb2d
- https://git.kernel.org/stable/c/fcbfb54a0269875cf3cd6a2bff4f85a2e0a0b552
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22063
In the Linux kernel, the following vulnerability has been resolved: netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference. This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.
- https://git.kernel.org/stable/c/078aabd567de3d63d37d7673f714e309d369e6e2
- https://git.kernel.org/stable/c/172a8a996a337206970467e871dd995ac07640b1
- https://git.kernel.org/stable/c/1927d0bcd5b81e80971bf6b8eba267508bd1c78b
- https://git.kernel.org/stable/c/1ad9166cab6a0f5c0b10344a97bdf749ae11dcbf
- https://git.kernel.org/stable/c/1e38f7a6cdd68377f8a4189b2fbaec14a6dd5152
- https://git.kernel.org/stable/c/3ba9cf69de50e8abed32b448616c313baa4c5712
- https://git.kernel.org/stable/c/797e5371cf55463b4530bab3fef5f27f7c6657a8
- https://git.kernel.org/stable/c/9fe3839588db7519030377b7dee3f165e654f6c5
- https://git.kernel.org/stable/c/a7e89541d05b98c79a51c0f95df020f8e82b62ed
- 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-22066
In the Linux kernel, the following vulnerability has been resolved: ASoC: imx-card: Add NULL check in imx_card_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, imx_card_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.
- https://git.kernel.org/stable/c/018e6cf2503e60087747b0ebc190e18b3640766f
- https://git.kernel.org/stable/c/38253922a89a742e7e622f626b41c64388367361
- https://git.kernel.org/stable/c/4d8458e48ff135bddc402ad79821dc058ea163d0
- https://git.kernel.org/stable/c/93d34608fd162f725172e780b1c60cc93a920719
- https://git.kernel.org/stable/c/b01700e08be99e3842570142ec5973ccd7e73eaf
- https://git.kernel.org/stable/c/dd2bbb9564d0d24a2643ad90008a79840368c4b4
- https://git.kernel.org/stable/c/e283a5bf4337a7300ac5e6ae363cc8b242a0b4b7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22071
In the Linux kernel, the following vulnerability has been resolved: spufs: fix a leak in spufs_create_context() Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor.
- https://git.kernel.org/stable/c/0f5cce3fc55b08ee4da3372baccf4bcd36a98396
- https://git.kernel.org/stable/c/239ea3c34673b3244a499fd65771c47e5bffcbb0
- https://git.kernel.org/stable/c/410c787d89c92df4215d7b1a338e2c1a8aba6b9b
- https://git.kernel.org/stable/c/4a7448c83e117ed68597952ecaede1cebc4427a7
- https://git.kernel.org/stable/c/5a90b699844a5bb96961e5892e51cc59255444a3
- https://git.kernel.org/stable/c/829bd6139968e2e759f3928cf65ad0db1e302fe3
- https://git.kernel.org/stable/c/a333f223e555d27609f8b45d75a08e8e1d36c432
- https://git.kernel.org/stable/c/c4e72a0d75442237b6f3bcca10a7d81b89376d16
- https://git.kernel.org/stable/c/d04600f43569d48262e1328eaa1592fcefa2c19c
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22072
In the Linux kernel, the following vulnerability has been resolved: spufs: fix gang directory lifetimes prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak. Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed. Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gang directory out when counter reaches zero.
- https://git.kernel.org/stable/c/029d8c711f5e5fe8cf63e8a4a1a140a06e224e45
- https://git.kernel.org/stable/c/324f280806aab28ef757aecc18df419676c10ef8
- https://git.kernel.org/stable/c/880e7b3da2e765c1f90c94c0539be039e96c7062
- https://git.kernel.org/stable/c/903733782f3ae28a2f7fe4dfb47c7fe3e079a528
- https://git.kernel.org/stable/c/c134deabf4784e155d360744d4a6a835b9de4dd4
- https://git.kernel.org/stable/c/fc646a6c6d14b5d581f162a7e32999f789e3a3ac
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22073
In the Linux kernel, the following vulnerability has been resolved: spufs: fix a leak on spufs_new_file() failure It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.
- https://git.kernel.org/stable/c/0bd56e4e72c354b65c0a7e5ac1c09eca81949d5b
- https://git.kernel.org/stable/c/132925bd6772d7614340fb755ac5415462ac8edd
- https://git.kernel.org/stable/c/35f789ccebd69f6f9a1e0a9b85435003b2450065
- https://git.kernel.org/stable/c/53b189651c33b5f1fb3b755e6a37a8206978514e
- https://git.kernel.org/stable/c/90d1b276d1b1379d20ad27d1f6349ba9f44a2e00
- https://git.kernel.org/stable/c/96de7fbdc2dcadeebc17c3cb89e7cdab487bfce0
- https://git.kernel.org/stable/c/b1eef06d10c1a9848e3a762919bbbe315a0a7cb4
- https://git.kernel.org/stable/c/d1ca8698ca1332625d83ea0d753747be66f9906d
- https://git.kernel.org/stable/c/d791985ceeb081155b4e96d314ca54c7605dcbe0
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22075
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")
added support for getting VF port and node GUIDs in netlink ifinfo
messages, but their size was not taken into consideration in the
function that allocates the netlink message, causing the following
warning when a netlink message is filled with many VF port and node
GUIDs:
# echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs
# ip link show dev ib0
RTNETLINK answers: Message too long
Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0
Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core
CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:rtnl_getlink+0x586/0x5a0
Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00
RSP: 0018:ffff888113557348 EFLAGS: 00010246
RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000
RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8
RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000
R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00
R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff
FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/0f5489707cf528f9df2f39a3045c1ee713ec90e7
- https://git.kernel.org/stable/c/15f150771e0ec97f8ab1657e7d2568e593c7fa04
- https://git.kernel.org/stable/c/23f00807619d15063d676218f36c5dfeda1eb420
- https://git.kernel.org/stable/c/28b21ee8e8fb326ba961a4bbce04ec04c65e705a
- https://git.kernel.org/stable/c/365c1ae819455561d4746aafabad673e4bcb0163
- https://git.kernel.org/stable/c/5f39454468329bb7fc7fc4895a6ba6ae3b95027e
- https://git.kernel.org/stable/c/5fed5f6de3cf734b231a11775748a6871ee3020f
- https://git.kernel.org/stable/c/bb7bdf636cef74cdd7a7d548bdc7457ae161f617
- 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-22079
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate l_tree_depth to avoid out-of-bounds access The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH. Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1].
- https://git.kernel.org/stable/c/11e24802e73362aa2948ee16b8fb4e32635d5b2a
- https://git.kernel.org/stable/c/17c99ab3db2ba74096d36c69daa6e784e98fc0b8
- https://git.kernel.org/stable/c/3d012ba4404a0bb517658699ba85e6abda386dc3
- https://git.kernel.org/stable/c/49d2a2ea9d30991bae82107f9523915b91637683
- https://git.kernel.org/stable/c/538ed8b049ef801a86c543433e5061a91cc106e3
- https://git.kernel.org/stable/c/a406aff8c05115119127c962cbbbbd202e1973ef
- https://git.kernel.org/stable/c/b942f88fe7d2d789e51c5c30a675fa1c126f5a6d
- https://git.kernel.org/stable/c/e95d97c9c8cd0c239b7b59c79be0f6a9dcf7905c
- https://git.kernel.org/stable/c/ef34840bda333fe99bafbd2d73b70ceaaf9eba66
- 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-22081
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix a couple integer overflows on 32bit systems On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().
- https://git.kernel.org/stable/c/0538f52410b619737e663167b6a2b2d0bc1a589d
- https://git.kernel.org/stable/c/0922d86a7a6032cb1694eab0b44b861bd33ba8d5
- https://git.kernel.org/stable/c/0dfe700fbd3525f30a36ffbe390a5b9319bd009a
- https://git.kernel.org/stable/c/1a14e9718a19d2e88de004a1360bfd7a86ed1395
- https://git.kernel.org/stable/c/284c9549386e9883855fb82b730303bb2edea9de
- https://git.kernel.org/stable/c/4d0f4f42922a832388a0c2fe5204c0a1037ff786
- https://git.kernel.org/stable/c/5ad414f4df2294b28836b5b7b69787659d6aa708
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22086
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from
the radix tree again we check if the next cqe QP is identical to
the one we already have.
The bug however is that we are checking if the QP is identical by
checking the QP number inside the CQE against the QP number inside the
mlx5_ib_qp, but that's wrong since the QP number from the CQE is from
FW so it should be matched against mlx5_core_qp which is our FW QP
number.
Otherwise we could use the wrong QP when handling a CQE which could
cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are
the only QPs in our driver whereas the QP number inside mlx5_ib_qp
doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP
CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21
RSP: 0018:ffff88810511bd60 EFLAGS: 00010046
RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a
RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10
R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000
R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0
FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0
Call Trace:
- https://git.kernel.org/stable/c/3b97d77049856865ac5ce8ffbc6e716928310f7f
- https://git.kernel.org/stable/c/55c65a64aefa6267b964d90e9a4039cb68ec73a5
- https://git.kernel.org/stable/c/5ed3b0cb3f827072e93b4c5b6e2b8106fd7cccbd
- https://git.kernel.org/stable/c/7c51a6964b45b6d40027abd77e89cef30d26dc5a
- https://git.kernel.org/stable/c/856d9e5d72dc44eca6d5a153581c58fbd84e92e1
- https://git.kernel.org/stable/c/cad677085274ecf9c7565b5bfc5d2e49acbf174c
- https://git.kernel.org/stable/c/d52636eb13ccba448a752964cc6fc49970912874
- https://git.kernel.org/stable/c/dc7139b7031d877acd73d7eff55670f22f48cd5e
- https://git.kernel.org/stable/c/f0447ceb8a31d79bee7144f98f9a13f765531e1a
- 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-22088
In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Prevent use-after-free in erdma_accept_newconn() After the erdma_cep_put(new_cep) being called, new_cep will be freed, and the following dereference will cause a UAF problem. Fix this issue.
- https://git.kernel.org/stable/c/667a628ab67d359166799fad89b3c6909599558a
- https://git.kernel.org/stable/c/78411a133312ce7d8a3239c76a8fd85bca1cc10f
- https://git.kernel.org/stable/c/7aa6bb5276d9fec98deb05615a086eeb893854ad
- https://git.kernel.org/stable/c/83437689249e6a17b25e27712fbee292e42e7855
- https://git.kernel.org/stable/c/a114d25d584c14019d31dbf2163780c47415a187
- https://git.kernel.org/stable/c/bc1db4d8f1b0dc480d7d745a60a8cc94ce2badd4
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22089
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Don't expose hw_counters outside of init net namespace
Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs
attributes") accidentally almost exposed hw counters to non-init net
namespaces. It didn't expose them fully, as an attempt to read any of
those counters leads to a crash like this one:
[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028
[42021.814463] #PF: supervisor read access in kernel mode
[42021.819549] #PF: error_code(0x0000) - not-present page
[42021.824636] PGD 0 P4D 0
[42021.827145] Oops: 0000 [#1] SMP PTI
[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX
[42021.841697] Hardware name: XXX
[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]
[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48
[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287
[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000
[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0
[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000
[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530
[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000
[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000
[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0
[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[42021.949324] Call Trace:
[42021.951756]
- https://git.kernel.org/stable/c/0cf80f924aecb5b2bebd4f4ad11b2efc676a0b78
- https://git.kernel.org/stable/c/6682da5d8fd578a5068531d01633c9d2e4c8f12b
- https://git.kernel.org/stable/c/9a5b7f8842a90a5e6eeff37f9f6d814e61ea3529
- https://git.kernel.org/stable/c/a1ecb30f90856b0be4168ad51b8875148e285c1f
- https://git.kernel.org/stable/c/c14d9704f5d77a7c7fa46e2114b64a4f75b64e17
- https://git.kernel.org/stable/c/d5212b99649c5740154f307e9e3d7fee9bf62773
- https://git.kernel.org/stable/c/df45ae2a4f1cdfda00c032839e12092e1f32c05e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22093
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: avoid NPD when ASIC does not support DMUB
ctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is
tested in dm_dmub_sw_init.
However, it will be dereferenced in dmub_hw_lock_mgr_cmd if
should_use_dmub_lock returns true.
This has been the case since dmub support has been added for PSR1.
Fix this by checking for dmub_srv in should_use_dmub_lock.
[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058
[ 37.447808] #PF: supervisor read access in kernel mode
[ 37.452959] #PF: error_code(0x0000) - not-present page
[ 37.458112] PGD 0 P4D 0
[ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88
[ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023
[ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0
[ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5
[ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202
[ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358
[ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000
[ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5
[ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000
[ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000
[ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000
[ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0
[ 37.572697] Call Trace:
[ 37.575152]
- https://git.kernel.org/stable/c/3453bcaf2ca92659346bf8504c2b52b3993fbd79
- https://git.kernel.org/stable/c/35ad39afd007eddf34b3307bebb715c26891cc96
- https://git.kernel.org/stable/c/42d9d7bed270247f134190ba0cb05bbd072f58c2
- https://git.kernel.org/stable/c/5e4b1e04740cdb28de189285007366d99a92f1ce
- https://git.kernel.org/stable/c/b3a93a2407ad23c8d5bacabaf7cecbb4c6cdd461
- https://git.kernel.org/stable/c/d953e2cd59ab466569c6f9da460e01caf1c83559
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22095
In the Linux kernel, the following vulnerability has been resolved: PCI: brcmstb: Fix error path after a call to regulator_bulk_get() If the regulator_bulk_get() returns an error and no regulators are created, we need to set their number to zero. If we don't do this and the PCIe link up fails, a call to the regulator_bulk_free() will result in a kernel panic. While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from add_bus(). [kwilczynski: commit log, use comma in the message to match style with other similar messages]
- https://git.kernel.org/stable/c/3651ad5249c51cf7eee078e12612557040a6bdb4
- https://git.kernel.org/stable/c/6f44e1fdb006db61394aa4d4c25728ada00842e7
- https://git.kernel.org/stable/c/7842e842a9bf6bd5866c84f588353711d131ab1a
- https://git.kernel.org/stable/c/99a0efba9f903acbdece548862b6b4cbe7d999e1
- https://git.kernel.org/stable/c/df63321a40cc98e52313cffbff376b8ae9ceffa7
- https://git.kernel.org/stable/c/eedd054834930b8d678f0776cd4b091b8fffbb4a
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2025-22097
In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix use after free and double free on init error If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded.
- https://git.kernel.org/stable/c/1f68f1cf09d06061eb549726ff8339e064eddebd
- https://git.kernel.org/stable/c/49a69f67f53518bdd9b7eeebf019a2da6cc0e954
- https://git.kernel.org/stable/c/561fc0c5cf41f646f3e9e61784cbc0fc832fb936
- https://git.kernel.org/stable/c/79d138d137b80eeb0a83244d1cff29e64cf91067
- https://git.kernel.org/stable/c/b8a18bb53e06d6d3c1fd03d12533d6e333ba8853
- https://git.kernel.org/stable/c/d5eb8e347905ab17788a7903fa1d3d06747355f5
- https://git.kernel.org/stable/c/ed15511a773df86205bda66c37193569575ae828
- 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-03
CVE-2025-23136
In the Linux kernel, the following vulnerability has been resolved: thermal: int340x: Add NULL check for adev Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. [ rjw: Subject edit, added Fixes: ]
- https://git.kernel.org/stable/c/0c49f12c77b77a706fd41370c11910635e491845
- https://git.kernel.org/stable/c/2542a3f70e563a9e70e7ded314286535a3321bdb
- https://git.kernel.org/stable/c/3155d5261b518776d1b807d9d922669991bbee56
- https://git.kernel.org/stable/c/6a810c462f099353e908c70619638884cb82229c
- https://git.kernel.org/stable/c/8e8f1ddf4186731649df8bc9646017369eb19186
- https://git.kernel.org/stable/c/953d28a4f459fcbde2d08f51aeca19d6b0f179f3
- https://git.kernel.org/stable/c/ac2eb7378319e3836cdf3a2c15a0bdf04c50e81d
- https://git.kernel.org/stable/c/bc7b5f782d28942dbdfda70df30ce132694a06de
- https://git.kernel.org/stable/c/d0d21c8e44216fa9afdb3809edf213f3c0a8c060
- 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-23138
In the Linux kernel, the following vulnerability has been resolved: watch_queue: fix pipe accounting mismatch Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM. To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers() (It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?)
- https://git.kernel.org/stable/c/205028ebba838938d3b264dda1d0708fa7fe1ade
- https://git.kernel.org/stable/c/2d680b988656bb556c863d8b46d9b9096842bf3d
- https://git.kernel.org/stable/c/471c89b7d4f58bd6082f7c1fe14d4ca15c7f1284
- https://git.kernel.org/stable/c/56ec918e6c86c1536870e4373e91eddd0c44245f
- https://git.kernel.org/stable/c/6dafa27764183738dc5368b669b71e3d0d154f12
- https://git.kernel.org/stable/c/8658c75343ed00e5e154ebbe24335f51ba8db547
- https://git.kernel.org/stable/c/d40e3537265dea9e3c33021874437ff26dc18787
- https://git.kernel.org/stable/c/f13abc1e8e1a3b7455511c4e122750127f6bc9b0
- 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-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-37785
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir
entry with rec_len == block size results in out-of-bounds read (later
on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.'
and '..' as directory entries in the first data block. It first loads
the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry()
and then uses its rec_len member to compute the location of '..' dir
entry (in ext4_next_entry). It assumes the '..' dir entry fits into the
same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the
sanity checks (it is considered the last directory entry in the data
block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the
memory slot allocated to the data block. The following call to
ext4_check_dir_entry() on new value of de then dereferences this pointer
which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir
entries that reach the end of data block. Make sure to ignore the phony
dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another
structure was recently freed from the slot past the bound, but it is
really an OOB read.
This issue was found by syzkaller tool.
Call Trace:
[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710
[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375
[ 38.595158]
[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1
[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 38.595304] Call Trace:
[ 38.595308]
- https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351
- https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842
- https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00
- https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93
- https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b
- https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78
- https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b
- https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353
- https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4
- 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-37819
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode() With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use.
- https://git.kernel.org/stable/c/0c241dedc43a036599757cd08f356253fa3e5014
- https://git.kernel.org/stable/c/2f2803e4b5e4df2b08d378deaab78b1681ef9b30
- https://git.kernel.org/stable/c/3318dc299b072a0511d6dfd8367f3304fb6d9827
- https://git.kernel.org/stable/c/3939d6f29d34cdb60e3f68b76e39e00a964a1d51
- https://git.kernel.org/stable/c/47bee0081b483b077c7560bc5358ad101f89c8ef
- https://git.kernel.org/stable/c/b63de43af8d215b0499eac28b2caa4439183efc1
- https://git.kernel.org/stable/c/dc0d654eb4179b06d3206e4396d072108b9ba082
- https://git.kernel.org/stable/c/f95659affee301464f0d058d528d96b35b452da8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-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-17
CVE-2025-37890
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case). This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/141d34391abbb315d68556b7c67ad97885407547
- https://git.kernel.org/stable/c/273bbcfa53541cde38b2003ad88a59b770306421
- https://git.kernel.org/stable/c/2e7093c7a8aba5d4f8809f271488e5babe75e202
- https://git.kernel.org/stable/c/6082a87af4c52f58150d40dec1716011d871ac21
- https://git.kernel.org/stable/c/8df7d37d626430035b413b97cee18396b3450bef
- https://git.kernel.org/stable/c/ac39fd4a757584d78ed062d4f6fd913f83bd98b5
- https://git.kernel.org/stable/c/e0cf8ee23e1915431f262a7b2dee0c7a7d699af0
- https://git.kernel.org/stable/c/e3e949a39a91d1f829a4890e7dfe9417ac72e4d0
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-10-01
CVE-2025-37893
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Fix off-by-one error in build_prologue() Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue. There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogue_offset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn.
- https://git.kernel.org/stable/c/205a2182c51ffebaef54d643e3745e720cded08b
- https://git.kernel.org/stable/c/48b904de2408af5f936f0e03f48dfcddeab58aa0
- https://git.kernel.org/stable/c/7e2586991e36663c9bc48c828b83eab180ad30a9
- https://git.kernel.org/stable/c/b3ffad2f02db4aace6799fe0049508b8925eae45
- https://git.kernel.org/stable/c/c74d95a5679741ef428974ab788f5b0758dc78ae
Modified: 2025-11-19
CVE-2025-37897
In the Linux kernel, the following vulnerability has been resolved:
wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release
plfxlc_mac_release() asserts that mac->lock is held. This assertion is
incorrect, because even if it was possible, it would not be the valid
behaviour. The function is used when probe fails or after the device is
disconnected. In both cases mac->lock can not be held as the driver is
not working with the device at the moment. All functions that use mac->lock
unlock it just after it was held. There is also no need to hold mac->lock
for plfxlc_mac_release() itself, as mac data is not affected, except for
mac->flags, which is modified atomically.
This bug leads to the following warning:
================================================================
WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0
Modules linked in:
CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: usb_hub_wq hub_event
RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106
Call Trace:
- https://git.kernel.org/stable/c/0fb15ae3b0a9221be01715dac0335647c79f3362
- https://git.kernel.org/stable/c/36a9a2647810e57e704dde59abdf831380ca9102
- https://git.kernel.org/stable/c/791a2d9e87c411aec0b9b2fb735fd15e48af9de9
- https://git.kernel.org/stable/c/93d646911be1e5be20d4f5d6c48359464cef0097
- https://git.kernel.org/stable/c/9ecb4af39f80cdda3e57825923243ec11e48be6b
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37901
In the Linux kernel, the following vulnerability has been resolved: irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not have a corresponding MPM pin and should not be handled inside the MPM driver. The IRQ domain hierarchy is always applied, so it's required to explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. This is causing crashes when setting up interrupts for non-wake GPIOs: root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1 Unable to handle kernel paging request at virtual address ffff8000a1dc3820 Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc : mpm_set_type+0x80/0xcc lr : mpm_set_type+0x5c/0xcc Call trace: mpm_set_type+0x80/0xcc (P) qcom_mpm_set_type+0x64/0x158 irq_chip_set_type_parent+0x20/0x38 msm_gpio_irq_set_type+0x50/0x530 __irq_set_trigger+0x60/0x184 __setup_irq+0x304/0x6bc request_threaded_irq+0xc8/0x19c edge_detector_setup+0x260/0x364 linereq_create+0x420/0x5a8 gpio_ioctl+0x2d4/0x6c0 Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that MPM is removed entirely from the hierarchy for non-wake GPIOs.
- https://git.kernel.org/stable/c/38a05c0b87833f5b188ae43b428b1f792df2b384
- https://git.kernel.org/stable/c/45aced97f01d5ab14c8a2a60f6748f18c501c3f5
- https://git.kernel.org/stable/c/d5c10448f411a925dd59005785cb971f0626e032
- https://git.kernel.org/stable/c/dfbaecf7e38f5e9bfa5e47a1e525ffbb58bab8cf
- https://git.kernel.org/stable/c/f102342360950b56959e5fff4a874ea88ae13758
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37903
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix slab-use-after-free in hdcp
The HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector
objects without incrementing the kref reference counts. When using a
USB-C dock, and the dock is unplugged, the corresponding
amdgpu_dm_connector objects are freed, creating dangling pointers in the
HDCP code. When the dock is plugged back, the dangling pointers are
dereferenced, resulting in a slab-use-after-free:
[ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu]
[ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10
[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233
[ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024
[ 66.776186] Workqueue: events event_property_validate [amdgpu]
[ 66.776494] Call Trace:
[ 66.776496]
- https://git.kernel.org/stable/c/3a782a83d130ceac6c98a87639ddd89640bff486
- https://git.kernel.org/stable/c/bbc66abcd297be67e3d835276e21e6fdc65205a6
- https://git.kernel.org/stable/c/be593d9d91c5a3a363d456b9aceb71029aeb3f1d
- https://git.kernel.org/stable/c/dd329f04dda35a66e0c9ed462ba91bd5f2c8be70
- https://git.kernel.org/stable/c/e25139c4aa5621f2db8e86688c33546cdd885e42
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37905
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Balance device refcount when destroying devices Using device_find_child() to lookup the proper SCMI device to destroy causes an unbalance in device refcount, since device_find_child() calls an implicit get_device(): this, in turns, inhibits the call of the provided release methods upon devices destruction. As a consequence, one of the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the drivers subsystem core. KMemleak detects this situation since loading/unloding some SCMI driver causes related devices to be created/destroyed without calling any device_release method. unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158 $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof at include/linux/slab.h:901 (inlined by) kzalloc_noprof at include/linux/slab.h:1037 (inlined by) device_private_init at drivers/base/core.c:3510 (inlined by) device_add at drivers/base/core.c:3561 Balance device refcount by issuing a put_device() on devices found via device_find_child().
- https://git.kernel.org/stable/c/2fbf6c9695ad9f05e7e5c166bf43fac7cb3276b3
- https://git.kernel.org/stable/c/8a8a3547d5c4960da053df49c75bf623827a25da
- https://git.kernel.org/stable/c/91ff1e9652fb9beb0174267d6bb38243dff211bb
- https://git.kernel.org/stable/c/969d8beaa2e374387bf9aa5602ef84fc50bb48d8
- https://git.kernel.org/stable/c/9ca67840c0ddf3f39407339624cef824a4f27599
- https://git.kernel.org/stable/c/ff4273d47da81b95ed9396110bcbd1b7b7470fe8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37909
In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Fix memleak issue when GSO enabled Always map the `skb` to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak
- https://git.kernel.org/stable/c/093855ce90177488eac772de4eefbb909033ce5f
- https://git.kernel.org/stable/c/189b05f189cac9fd233ef04d31cb5078c4d09c39
- https://git.kernel.org/stable/c/2d52e2e38b85c8b7bc00dca55c2499f46f8c8198
- https://git.kernel.org/stable/c/6c65ee5ad632eb8dcd3a91cf5dc99b22535f44d9
- https://git.kernel.org/stable/c/a0e0efbabbbe6a1859bc31bf65237ce91e124b9b
- https://git.kernel.org/stable/c/dae1ce27ceaea7e1522025b15252e3cc52802622
- https://git.kernel.org/stable/c/df993daa4c968b4b23078eacc248f6502ede8664
- https://git.kernel.org/stable/c/f42c18e2f14c1b1fdd2a5250069a84bc854c398c
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37911
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix out-of-bound memcpy() during ethtool -w When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption: BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80 ... This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf. In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information. This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.
- https://git.kernel.org/stable/c/43292b83424158fa6ec458799f3cb9c54d18c484
- https://git.kernel.org/stable/c/44807af79efd0d78fa36383dd865ddfe7992c0a6
- https://git.kernel.org/stable/c/44d81a9ebf0cad92512e0ffdf7412bfe20db66ec
- https://git.kernel.org/stable/c/4d69864915a3a052538e4ba76cd6fd77cfc64ebe
- https://git.kernel.org/stable/c/69b10dd23ab826d0c7f2d9ab311842251978d0c1
- https://git.kernel.org/stable/c/6b87bd94f34370bbf1dfa59352bed8efab5bf419
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37912
In the Linux kernel, the following vulnerability has been resolved: ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr() As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI pointer values"), we need to perform a null pointer check on the return value of ice_get_vf_vsi() before using it.
- https://git.kernel.org/stable/c/0561f2e374c3732b90e50f0a244791a4308ec67e
- https://git.kernel.org/stable/c/073791e9cfe6e4a11a6d85816ba87b1aa207493e
- https://git.kernel.org/stable/c/425c5f266b2edeee0ce16fedd8466410cdcfcfe3
- https://git.kernel.org/stable/c/a32dcc3b8293600ddc4024731b4d027d4de061a4
- https://git.kernel.org/stable/c/eae60cfe25d022d7f0321dba4cc23ad8e87ade48
- https://git.kernel.org/stable/c/f68237982dc012230550f4ecf7ce286a9c37ddc9
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37913
In the Linux kernel, the following vulnerability has been resolved: net_sched: qfq: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of qfq, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. This patch checks whether the class was already added to the agg->active list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/005a479540478a820c52de098e5e767e63e36f0a
- https://git.kernel.org/stable/c/041f410aec2c1751ee22b8b73ba05d38c3a6a602
- https://git.kernel.org/stable/c/0aa23e0856b7cedb3c88d8e3d281c212c7e4fbeb
- https://git.kernel.org/stable/c/0bf32d6fb1fcbf841bb9945570e0e2a70072c00f
- https://git.kernel.org/stable/c/370218e8ce711684acc4cdd3cc3c6dd7956bc165
- https://git.kernel.org/stable/c/53bc0b55178bd59bdd4bcd16349505cabf54b1a2
- https://git.kernel.org/stable/c/a43783119e01849fbf2fe8855634e8989b240cb4
- https://git.kernel.org/stable/c/f139f37dcdf34b67f5bf92bc8e0f7f6b3ac63aa4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37914
In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/1a6d0c00fa07972384b0c308c72db091d49988b6
- https://git.kernel.org/stable/c/1f01e9f961605eb397c6ecd1d7b0233dfbf9077c
- https://git.kernel.org/stable/c/24388ba0a1b1b6d4af1b205927ac7f7b119ee4ea
- https://git.kernel.org/stable/c/554acc5a2ea9703e08023eb9a003f9e5a830a502
- https://git.kernel.org/stable/c/72c3da7e6ceb74e74ddbb5a305a35c9fdfcac6e3
- https://git.kernel.org/stable/c/9efb6a0fa88e0910d079fdfeb4f7ce4d4ac6c990
- https://git.kernel.org/stable/c/bc321f714de693aae06e3786f88df2975376d996
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37915
In the Linux kernel, the following vulnerability has been resolved: net_sched: drr: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/26e75716b94d6ff9be5ea07d63675c4d189f30b4
- https://git.kernel.org/stable/c/2968632880f1792007eedd12eeedf7f6e2b7e9f3
- https://git.kernel.org/stable/c/4b07ac06b0a712923255aaf2691637693fc7100d
- https://git.kernel.org/stable/c/4f0ecf50cdf76da95828578a92f130b653ac2fcf
- https://git.kernel.org/stable/c/5da3aad1a13e7edb8ff0778a444ccf49930313e9
- https://git.kernel.org/stable/c/ab2248110738d4429668140ad22f530a9ee730e1
- https://git.kernel.org/stable/c/db205b92dfe0501e5b92fb7cf00971d0e44ba3eb
- https://git.kernel.org/stable/c/f99a3fbf023e20b626be4b0f042463d598050c9a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37917
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock and spin_unlock in mtk_star_emac driver to avoid spinlock recursion occurrence that can happen when enabling the DMA interrupts again in rx/tx poll. ``` BUG: spinlock recursion on CPU#0, swapper/0/0 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Hardware name: MediaTek MT8365 Open Platform EVK (DT) Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x60/0x80 dump_stack+0x18/0x24 spin_dump+0x78/0x88 do_raw_spin_lock+0x11c/0x120 _raw_spin_lock+0x20/0x2c mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac] __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x4c/0xb0 handle_fasteoi_irq+0xa0/0x1bc handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x120 do_interrupt_handler+0x50/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 regmap_mmio_read32le+0xc/0x20 (P) _regmap_bus_reg_read+0x6c/0xac _regmap_read+0x60/0xdc regmap_read+0x4c/0x80 mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac] __napi_poll+0x38/0x188 net_rx_action+0x164/0x2c0 handle_softirqs+0x100/0x244 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x20 call_on_irq_stack+0x24/0x64 do_softirq_own_stack+0x1c/0x40 __irq_exit_rcu+0xd4/0x10c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 cpuidle_enter_state+0xac/0x320 (P) cpuidle_enter+0x38/0x50 do_idle+0x1e4/0x260 cpu_startup_entry+0x34/0x3c rest_init+0xdc/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ```
- https://git.kernel.org/stable/c/6fe0866014486736cc3ba1c6fd4606d3dbe55c9c
- https://git.kernel.org/stable/c/7cb10f17bddc415f30fbc00a4e2b490e0d94c462
- https://git.kernel.org/stable/c/8d40bf73fa7f31eac2b0a7c9d85de67df82ee7f3
- https://git.kernel.org/stable/c/94107259f972d2fd896dbbcaa176b3b2451ff9e5
- https://git.kernel.org/stable/c/bedd287fdd3142dffad7ae2ac6ef15f4a2ad0629
- https://git.kernel.org/stable/c/d886f8d85494d12b2752fd7c6c32162d982d5dd5
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-10
CVE-2025-37921
In the Linux kernel, the following vulnerability has been resolved:
vxlan: vnifilter: Fix unlocked deletion of default FDB entry
When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").
Reproducer:
# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
# bridge vni add vni 10010 remote 198.51.100.1 dev vx0
# bridge vni del vni 10010 dev vx0
Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.
[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
- https://git.kernel.org/stable/c/087a9eb9e5978e3ba362e1163691e41097e8ca20
- https://git.kernel.org/stable/c/2d4a121296aa3940d2df9906f955c2b6b4e38bc3
- https://git.kernel.org/stable/c/3576e9a80b6c4381b01ce0cbaa07f5e92d4492ed
- https://git.kernel.org/stable/c/470206205588559e60035fceb5f256640cb45f99
- https://git.kernel.org/stable/c/5cb9e07f84e527974b12e82e2549fa6c0cc6eef0
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-10
CVE-2025-37923
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix oob write in trace_seq_to_buffer()
syzbot reported this bug:
==================================================================
BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260
CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
- https://git.kernel.org/stable/c/056ebbddb8faf4ddf83d005454dd78fc25c2d897
- https://git.kernel.org/stable/c/1a3f9482b50b74fa9421bff8ceecfefd0dc06f8f
- https://git.kernel.org/stable/c/1f27a3e93b8d674b24b27fcdbc6f72743cd96c0d
- https://git.kernel.org/stable/c/441021e5b3c7d9bd1b963590652c415929f3b157
- https://git.kernel.org/stable/c/665ce421041890571852422487f4c613d1824ba9
- https://git.kernel.org/stable/c/c5d2b66c5ef5037b4b4360e5447605ff00ba1bd4
- https://git.kernel.org/stable/c/f4b0174e9f18aaba59ee6ffdaf8827a7f94eb606
- https://git.kernel.org/stable/c/f5178c41bb43444a6008150fe6094497135d07cb
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2026-04-02
CVE-2025-37924
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.
- https://git.kernel.org/stable/c/28c756738af44a404a91b77830d017bb0c525890
- https://git.kernel.org/stable/c/b447463562238428503cfba1c913261047772f90
- https://git.kernel.org/stable/c/e18c616718018dfc440e4a2d2b94e28fe91b1861
- https://git.kernel.org/stable/c/e34a33d5d7e87399af0a138bb32f6a3e95dd83d2
- https://git.kernel.org/stable/c/e86e9134e1d1c90a960dd57f59ce574d27b9a124
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-10
CVE-2025-37927
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256. The same applies to the hid string with length 13 and uid string with length 250. Check the length of hid and uid strings separately to prevent buffer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/10d901a95f8e766e5aa0bb9a983fb41271f64718
- https://git.kernel.org/stable/c/13d67528e1ae4486e9ab24b70122fab104c73c29
- https://git.kernel.org/stable/c/2b65060c84ee4d8dc64fae6d2728b528e9e832e1
- https://git.kernel.org/stable/c/466d9da267079a8d3b69fa72dfa3a732e1f6dbb5
- https://git.kernel.org/stable/c/8dee308e4c01dea48fc104d37f92d5b58c50b96c
- https://git.kernel.org/stable/c/a65ebfed65fa62797ec1f5f1dcf7adb157a2de1e
- https://git.kernel.org/stable/c/c3f37faa71f5d26dd2144b3f2b14525ec8f5e41f
- https://git.kernel.org/stable/c/c8bdfc0297965bb13fa439d36ca9c4f7c8447f0f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-10
CVE-2025-37928
In the Linux kernel, the following vulnerability has been resolved:
dm-bufio: don't schedule in atomic context
A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and
try_verify_in_tasklet are enabled.
[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421
[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4
[ 129.444740][ T934] preempt_count: 201, expected: 0
[ 129.444756][ T934] RCU nest depth: 0, expected: 0
[ 129.444781][ T934] Preemption disabled at:
[ 129.444789][ T934] [
- https://git.kernel.org/stable/c/69a37b3ba85088fc6b903b8e1db7f0a1d4d0b52d
- https://git.kernel.org/stable/c/a3d8f0a7f5e8b193db509c7191fefeed3533fc44
- https://git.kernel.org/stable/c/a99f5bf4f7197009859dbce14c12f8e2ce5a5a69
- https://git.kernel.org/stable/c/c8c83052283bcf2fdd467a33d1d2bd5ba36e935a
- https://git.kernel.org/stable/c/f45108257280e0a1cc951ce254853721b40c0812
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-10
CVE-2025-37930
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill() Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveau_fence_signal(). However, in at least one other place, nouveau_fence_done(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveau_fence_update(). Should nouveau_fence_context_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence. Have nouveau_fence_context_kill() check for a fence being signaled.
- https://git.kernel.org/stable/c/0453825167ecc816ec15c736e52316f69db0deb9
- https://git.kernel.org/stable/c/126f5c6e0cb84e5c6f7a3a856d799d85668fb38e
- https://git.kernel.org/stable/c/2ec0f5f6d4768f292c8406ed92fa699f184577e5
- https://git.kernel.org/stable/c/39d6e889c0b19a2c79e1c74c843ea7c2d0f99c28
- https://git.kernel.org/stable/c/47ca11836c35c5698088fd87f7fb4b0ffa217e17
- https://git.kernel.org/stable/c/b771b2017260ffc3a8d4e81266619649bffcb242
- https://git.kernel.org/stable/c/bbe5679f30d7690a9b6838a583b9690ea73fe0e9
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-19
CVE-2025-37932
In the Linux kernel, the following vulnerability has been resolved: sch_htb: make htb_qlen_notify() idempotent htb_qlen_notify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life.
- https://git.kernel.org/stable/c/0a188c0e197383683fd093ab1ea6ce9a5869a6ea
- https://git.kernel.org/stable/c/32ae12ce6a9f6bace186ca7335220ff59b6cc3cd
- https://git.kernel.org/stable/c/5ba8b837b522d7051ef81bacf3d95383ff8edce5
- https://git.kernel.org/stable/c/73cf6af13153d62f9b76eff422eea79dbc70f15e
- https://git.kernel.org/stable/c/967955c9e57f8eebfccc298037d4aaf3d42bc1c9
- https://git.kernel.org/stable/c/a61f1b5921761fbaf166231418bc1db301e5bf59
- https://git.kernel.org/stable/c/bbbf5e0f87078b715e7a665d662a2c0e77f044ae
- https://git.kernel.org/stable/c/e6b45f4de763b00dc1c55e685e2dd1aaf525d3c1
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-19
CVE-2025-37936
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value. When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE value. Consulting only the host kernel's host vs. guest masks results in running the guest with PEBS enabled even when the guest doesn't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at exclude_host can't differentiate between events created by host userspace, and events created by KVM on behalf of the guest. Running the guest with PEBS unexpectedly enabled typically manifests as crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't written MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when trying to record PEBS events. The issue is most easily reproduced by running `perf kvm top` from before commit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (after which, `perf kvm top` effectively stopped using PEBS). The userspace side of perf creates a guest-only PEBS event, which intel_guest_get_msrs() misconstrues a guest-*owned* PEBS event. Arguably, this is a userspace bug, as enabling PEBS on guest-only events simply cannot work, and userspace can kill VMs in many other ways (there is no danger to the host). However, even if this is considered to be bad userspace behavior, there's zero downside to perf/KVM restricting PEBS to guest-owned events. Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") fixed the case where host userspace is profiling KVM *and* userspace, but missed the case where userspace is profiling only KVM.
- https://git.kernel.org/stable/c/160153cf9e4aa875ad086cc094ce34aac8e13d63
- https://git.kernel.org/stable/c/34b6fa11431aef71045ae5a00d90a7d630597eda
- https://git.kernel.org/stable/c/44ee0afc9d1e7a7c1932698de01362ed80cfc4b5
- https://git.kernel.org/stable/c/58f6217e5d0132a9f14e401e62796916aa055c1b
- https://git.kernel.org/stable/c/86aa62895fc2fb7ab09d7ca40fae8ad09841f66b
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-19
CVE-2025-37937
In the Linux kernel, the following vulnerability has been resolved: objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds() If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening. Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
- https://git.kernel.org/stable/c/536f7f3595ef8187cfa9ea50d7d24fcf4e84e166
- https://git.kernel.org/stable/c/6cfe46036b163e5a0f07c6b705b518148e1a8b2f
- https://git.kernel.org/stable/c/75b42dfe87657ede3da3f279bd6b1b16d69af954
- https://git.kernel.org/stable/c/976a85782246a29ba0f6d411a7a4f524cb9ea987
- https://git.kernel.org/stable/c/9b76b198cf209797abcb1314c18ddeb90fe0827b
- https://git.kernel.org/stable/c/b9249da6b0ed56269d4f21850df8e5b35dab50bd
- https://git.kernel.org/stable/c/c8430e72b99936c206b37a8e2daebb3f8df7f2d8
- https://git.kernel.org/stable/c/cd80277f652138d2619f149f86ae6d17bce721d1
- https://git.kernel.org/stable/c/e63d465f59011dede0a0f1d21718b59a64c3ff5c
- 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: 2026-03-17
CVE-2025-37947
In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds stream writes by validating *pos ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.
- https://git.kernel.org/stable/c/04c8a38c60346bb5a7c49b276de7233f703ce9cb
- https://git.kernel.org/stable/c/0ca6df4f40cf4c32487944aaf48319cb6c25accc
- https://git.kernel.org/stable/c/7f61da79df86fd140c7768e668ad846bfa7ec8e1
- https://git.kernel.org/stable/c/d62ba16563a86aae052f96d270b3b6f78fca154c
- https://git.kernel.org/stable/c/e6356499fd216ed6343ae0363f4c9303f02c5034
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://github.com/doyensec/KSMBD-CVE-2025-37947/blob/main/CVE-2025-37947.c
Modified: 2025-12-18
CVE-2025-37948
In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp.
- https://git.kernel.org/stable/c/0dfefc2ea2f29ced2416017d7e5b1253a54c2735
- https://git.kernel.org/stable/c/38c345fd54afd9d6ed8d3fcddf3f6ea23887bf78
- https://git.kernel.org/stable/c/42a20cf51011788f04cf2adbcd7681f02bdb6c27
- https://git.kernel.org/stable/c/852b8ae934b5cbdc62496fa56ce9969aa2edda7f
- https://git.kernel.org/stable/c/8fe5c37b0e08a97cf0210bb75970e945aaaeebab
- https://git.kernel.org/stable/c/993f63239c219696aef8887a4e7d3a16bf5a8ece
- https://git.kernel.org/stable/c/c6a8735d841bcb7649734bb3a787bb174c67c0d8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-37949
In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
- https://git.kernel.org/stable/c/0e94a246bb6d9538010b6c02d2b1d4717a97b2e5
- https://git.kernel.org/stable/c/1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27
- https://git.kernel.org/stable/c/2466b0f66795c3c426cacc8998499f38031dbb59
- https://git.kernel.org/stable/c/4d260a5558df4650eb87bc41b2c9ac2d6b2ba447
- https://git.kernel.org/stable/c/8b02f85e84dc6f7c150cef40ddb69af5a25659e5
- https://git.kernel.org/stable/c/8e9c8a0393b5f85f1820c565ab8105660f4e8f92
- https://git.kernel.org/stable/c/cbfaf46b88a4c01b64c4186cdccd766c19ae644c
- https://git.kernel.org/stable/c/f1bcac367bc95631afbb918348f30dec887d0e1b
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-37951
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Add job to pending list if the reset was skipped When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout.
- https://git.kernel.org/stable/c/12125f7d9c15e6d8ac91d10373b2db2f17dcf767
- https://git.kernel.org/stable/c/35e4079bf1a2570abffce6ababa631afcf8ea0e5
- https://git.kernel.org/stable/c/422a8b10ba42097a704d6909ada2956f880246f2
- https://git.kernel.org/stable/c/5235b56b7e5449d990d21d78723b1a5e7bb5738e
- https://git.kernel.org/stable/c/a5f162727b91e480656da1876247a91f651f76de
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37959
In the Linux kernel, the following vulnerability has been resolved: bpf: Scrub packet on bpf_redirect_peer When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace. As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2, In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption. This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.
- https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763
- https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a
- https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e
- https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503
- https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37961
In the Linux kernel, the following vulnerability has been resolved: ipvs: fix uninit-value for saddr in do_output_route4 syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---
- https://git.kernel.org/stable/c/0160ac84fb03a0bd8dce8a42cb25bfaeedd110f4
- https://git.kernel.org/stable/c/7d0032112a0380d0b8d7c9005f621928a9b9fc76
- https://git.kernel.org/stable/c/a3a1b784791a3cbfc6e05c4d8a3c321ac5136e25
- https://git.kernel.org/stable/c/adbc8cc1162951cb152ed7f147d5fbd35ce3e62f
- https://git.kernel.org/stable/c/e34090d7214e0516eb8722aee295cb2507317c07
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37963
In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.
- https://git.kernel.org/stable/c/038866e01ea5e5a3d948898ac216e531e7848669
- https://git.kernel.org/stable/c/477481c4348268136227348984b6699d6370b685
- https://git.kernel.org/stable/c/6e52d043f7dbf1839a24a3fab2b12b0d3839de7a
- https://git.kernel.org/stable/c/80251f62028f1ab2e09be5ca3123f84e8b00389a
- https://git.kernel.org/stable/c/df53d418709205450a02bb4d71cbfb4ff86f2c1e
- https://git.kernel.org/stable/c/e5f5100f1c64ac6c72671b2cf6b46542fce93706
- https://git.kernel.org/stable/c/f300769ead032513a68e4a02e806393402e626f8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37964
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: // Turn on IPIs for this CPU/mm combination, but only // if should_flush_tlb() agrees: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ After 'need_flush' is set to false, IPIs *MUST* // be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ Not until this point does should_flush_tlb() // become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.
- https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477
- https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac
- https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59
- https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89
- https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f
- https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37967
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix deadlock This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it.
- https://git.kernel.org/stable/c/364618c89d4c57c85e5fc51a2446cd939bf57802
- https://git.kernel.org/stable/c/5924b324468845fc795bd76f588f51d7ab4f202d
- https://git.kernel.org/stable/c/61fc1a8e1e10cc784cab5829930838aaf1d37af5
- https://git.kernel.org/stable/c/962ce9028ca6eb450d5c205238a3ee27de9d214d
- https://git.kernel.org/stable/c/f32451ca4cb7dc53f2a0e2e66b84d34162747eb7
- https://git.kernel.org/stable/c/f4bd982563c2fd41ec9ca6c517c392d759db801c
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37969
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/16857370b3a30663515956b3bd27f3def6a2cf06
- https://git.kernel.org/stable/c/35b8c0a284983b71d92d082c54b7eb655ed4194f
- https://git.kernel.org/stable/c/4db7d923a8c298788181b796f71adf6ca499f966
- https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4
- https://git.kernel.org/stable/c/8114ef86e2058e2554111b793596f17bee23fa15
- https://git.kernel.org/stable/c/9ce662851380fe2018e36e15c0bdcb1ad177ed95
- https://git.kernel.org/stable/c/9ddb4cf2192c213e4dba1733bbcdc94cf6d85bf7
- https://git.kernel.org/stable/c/dadf9116108315f2eb14c7415c7805f392c476b4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37970
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/159ca7f18129834b6f4c7eae67de48e96c752fc9
- https://git.kernel.org/stable/c/3bb6c02d6fe8347ce1785016d135ff539c20043c
- https://git.kernel.org/stable/c/6c4a5000618a8c44200d455c92e2f2a4db264717
- https://git.kernel.org/stable/c/84e39f628a3a3333add99076e4d6c8b42b12d3a0
- https://git.kernel.org/stable/c/a1cad8a3bca41dead9980615d35efc7bff1fd534
- https://git.kernel.org/stable/c/da33c4167b9cc1266a97215114cb74679f881d0c
- https://git.kernel.org/stable/c/f06a1a1954527cc4ed086d926c81ff236b2adde9
- https://git.kernel.org/stable/c/f3cf233c946531a92fe651ff2bd15ebbe60630a7
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37972
In the Linux kernel, the following vulnerability has been resolved: Input: mtk-pmic-keys - fix possible null pointer dereference In mtk_pmic_keys_probe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer. Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.
- https://git.kernel.org/stable/c/09429ddb5a91e9e8f72cd18c012ec4171c2f85ec
- https://git.kernel.org/stable/c/11cdb506d0fbf5ac05bf55f5afcb3a215c316490
- https://git.kernel.org/stable/c/334d74a798463ceec02a41eb0e2354aaac0d6249
- https://git.kernel.org/stable/c/619c05fb176c272ac6cecf723446b39723ee6d97
- https://git.kernel.org/stable/c/90fa6015ff83ef1c373cc61b7c924ab2bcbe1801
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.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: 2025-12-16
CVE-2025-37990
In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage() The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions. Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized. Improve the error message to report more detailed error information.
- https://git.kernel.org/stable/c/08424a0922fb9e32a19b09d852ee87fb6c497538
- https://git.kernel.org/stable/c/508be7c001437bacad7b9a43f08a723887bcd1ea
- https://git.kernel.org/stable/c/524b70441baba453b193c418e3142bd31059cc1f
- https://git.kernel.org/stable/c/62a4f2955d9a1745bdb410bf83fb16666d8865d6
- https://git.kernel.org/stable/c/8e089e7b585d95122c8122d732d1d5ef8f879396
- https://git.kernel.org/stable/c/972bf75e53f778c78039c5d139dd47443a6d66a1
- https://git.kernel.org/stable/c/bdb435ef9815b1ae28eefffa01c6959d0fcf1fa7
- https://git.kernel.org/stable/c/fa9b9f02212574ee1867fbefb0a675362a71b31d
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37991
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix double SIGFPE crash Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception
- https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6
- https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106
- https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f
- https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608
- https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143
- https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef
- https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e
- https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37992
In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.
- https://git.kernel.org/stable/c/2d3cbfd6d54a2c39ce3244f33f85c595844bd7b8
- https://git.kernel.org/stable/c/a7d6e0ac0a8861f6b1027488062251a8e28150fd
- https://git.kernel.org/stable/c/d1365ca80b012d8a7863e45949e413fb61fa4861
- https://git.kernel.org/stable/c/d3336f746f196c6a53e0480923ae93939f047b6c
- https://git.kernel.org/stable/c/d38939ebe0d992d581acb6885c1723fa83c1fb2c
- https://git.kernel.org/stable/c/ea1132ccb112f51ba749c56a912f67970c2cd542
- https://git.kernel.org/stable/c/fe88c7e4fc2c1cd75a278a15ffbf1689efad4e76
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37994
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.
- https://git.kernel.org/stable/c/076ab0631ed4928905736f1701e25f1e722bc086
- https://git.kernel.org/stable/c/14f298c52188c34acde9760bf5abc669c5c36fdb
- https://git.kernel.org/stable/c/312d79669e71283d05c05cc49a1a31e59e3d9e0e
- https://git.kernel.org/stable/c/5ad298d6d4aebe1229adba6427e417e89a5208d8
- https://git.kernel.org/stable/c/7804c4d63edfdd5105926cc291e806e8f4ce01b5
- https://git.kernel.org/stable/c/9dda1e2a666a8a32ce0f153b5dee05c7351f1020
- https://git.kernel.org/stable/c/a9931f1b52b2d0bf3952e003fd5901ea7eb851ed
- https://git.kernel.org/stable/c/e9b63faf5c97deb43fc39a52edbc39d626cc14bf
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37995
In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.
- https://git.kernel.org/stable/c/31d8df3f303c3ae9115230820977ef8c35c88808
- https://git.kernel.org/stable/c/93799fb988757cdacf19acba57807746c00378e6
- https://git.kernel.org/stable/c/9e7b49ce4f9d0cb5b6e87db9e07a2fb9e754b0dd
- https://git.kernel.org/stable/c/a63d99873547d8b39eb2f6db79dd235761e7098a
- https://git.kernel.org/stable/c/a6aeb739974ec73e5217c75a7c008a688d3d5cf1
- https://git.kernel.org/stable/c/d63851049f412cdfadaeef7a7eaef5031d11c1e9
- https://git.kernel.org/stable/c/f1c71b4bd721a4ea21da408806964b10468623f2
- https://git.kernel.org/stable/c/faa9059631d3491d699c69ecf512de9e1a3d6649
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37997
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix region locking in hash types Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.
- https://git.kernel.org/stable/c/00cfc5fad1491796942a948808afb968a0a3f35b
- https://git.kernel.org/stable/c/226ce0ec38316d9e3739e73a64b6b8304646c658
- https://git.kernel.org/stable/c/6e002ecc1c8cfdfc866b9104ab7888da54613e59
- https://git.kernel.org/stable/c/82c1eb32693bc48251d92532975e19160987e5b9
- https://git.kernel.org/stable/c/8478a729c0462273188263136880480729e9efca
- https://git.kernel.org/stable/c/a3dfec485401943e315c394c29afe2db8f9481d6
- https://git.kernel.org/stable/c/aa77294b0f73bb8265987591460cd25b8722c3df
- https://git.kernel.org/stable/c/e2ab67672b2288521a6146034a971f9a82ffc5c5
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37998
In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.
- https://git.kernel.org/stable/c/0236742bd959332181c1fcc41a05b7b709180501
- https://git.kernel.org/stable/c/06b4f110c79716c181a8c5da007c259807840232
- https://git.kernel.org/stable/c/47f7f00cf2fa3137d5c0416ef1a71bdf77901395
- https://git.kernel.org/stable/c/4fa672cbce9c86c3efb8621df1ae580d47813430
- https://git.kernel.org/stable/c/6712dc21506738f5f22b4f68b7c0d9e0df819dbd
- https://git.kernel.org/stable/c/6beb6835c1fbb3f676aebb51a5fee6b77fed9308
- https://git.kernel.org/stable/c/bca8df998cce1fead8cbc69144862eadc2e34c87
- https://git.kernel.org/stable/c/ec334aaab74705cc515205e1da3cb369fdfd93cd
- https://www.zerodayinitiative.com/advisories/ZDI-25-307/
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-38005
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma: Add missing locking
Recent kernels complain about a missing lock in k3-udma.c when the lock
validator is enabled:
[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238
[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28
[ 4.144867] Hardware name: pp-v12 (DT)
[ 4.148648] Workqueue: events udma_check_tx_completion
[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.160834] pc : udma_start.isra.0+0x34/0x238
[ 4.165227] lr : udma_start.isra.0+0x30/0x238
[ 4.169618] sp : ffffffc083cabcf0
[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005
[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000
[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670
[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030
[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048
[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001
[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68
[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8
[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000
[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000
[ 4.244986] Call trace:
[ 4.247463] udma_start.isra.0+0x34/0x238
[ 4.251509] udma_check_tx_completion+0xd0/0xdc
[ 4.256076] process_one_work+0x244/0x3fc
[ 4.260129] process_scheduled_works+0x6c/0x74
[ 4.264610] worker_thread+0x150/0x1dc
[ 4.268398] kthread+0xd8/0xe8
[ 4.271492] ret_from_fork+0x10/0x20
[ 4.275107] irq event stamp: 220
[ 4.278363] hardirqs last enabled at (219): [
- https://git.kernel.org/stable/c/0ea0433f822ed0549715f7044c9cd1cf132ff7fa
- https://git.kernel.org/stable/c/26e63b2fe30c61bd25981c6084f67a8af79945d0
- https://git.kernel.org/stable/c/27e71fa08711e09d81e06a54007b362a5426fd22
- https://git.kernel.org/stable/c/99df1edf17493cb49a8c01f6bde55c3abb6a2a6c
- https://git.kernel.org/stable/c/d87f1cddc592387359fde157cc4296556f6403c2
- https://git.kernel.org/stable/c/df5987e76a4ae4cbd705d81ab4b15ed232250a4a
- https://git.kernel.org/stable/c/fca280992af8c2fbd511bc43f65abb4a17363f2f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2026-03-17
CVE-2025-38007
In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Add NULL check in uclogic_input_configured() devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.
- https://git.kernel.org/stable/c/00d52b2fa6083dd0f5c44f3604cd1bad1f9177dc
- https://git.kernel.org/stable/c/01b76cc8ca243fc3376b035aa326bbc4f03d384b
- https://git.kernel.org/stable/c/94e7272b636a0677082e0604609e4c471e0a2caf
- https://git.kernel.org/stable/c/a9f58479a1a2c6f72907679c4df2f4ed92b05b39
- https://git.kernel.org/stable/c/ad6caaf29bc26a48b1241ce82561fcbcf0a75aa9
- https://git.kernel.org/stable/c/b616453d719ee1b8bf2ea6f6cc6c6258a572a590
- https://git.kernel.org/stable/c/bd07f751208ba190f9b0db5e5b7f35d5bb4a8a1e
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-17
CVE-2025-38009
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: disable napi on driver removal
A warning on driver removal started occurring after commit 9dd05df8403b
("net: warn if NAPI instance wasn't shut down"). Disable tx napi before
deleting it in mt76_dma_cleanup().
WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100
CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)
Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024
RIP: 0010:__netif_napi_del_locked+0xf0/0x100
Call Trace:
- https://git.kernel.org/stable/c/2b81e76db3667d1f7f2ad44e9835cdaf8dea95a8
- https://git.kernel.org/stable/c/5e700b06b970fc19e3a1ecb244e14785f3fbb8e3
- https://git.kernel.org/stable/c/78ab4be549533432d97ea8989d2f00b508fa68d8
- https://git.kernel.org/stable/c/b892e830d1ea8c5475254b98827771f7366f1039
- https://git.kernel.org/stable/c/ca5b213bf4b4224335a8131a26805d16503fca5f
- https://git.kernel.org/stable/c/e7bfbda5fddd27f3158e723d641c0fcdfb0552a7
- https://git.kernel.org/stable/c/ff0f820fa5b99035b3c654dd531226d8d83aec5f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-38015
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix memory leak in error handling path of idxd_alloc Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error.
- https://git.kernel.org/stable/c/46a5cca76c76c86063000a12936f8e7875295838
- https://git.kernel.org/stable/c/4f005eb68890698e5abc6a3af04dab76f175c50c
- https://git.kernel.org/stable/c/64afd9a1f644b27661420257dcc007d5009c99dd
- https://git.kernel.org/stable/c/6e94a2c3e4c166cd2736ac225fba5889fb1e8ac0
- https://git.kernel.org/stable/c/868dbce755ec92855362d213f47e045a8388361a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-17
CVE-2025-38018
In the Linux kernel, the following vulnerability has been resolved: net/tls: fix kernel panic when alloc_page failed We cannot set frag_list to NULL pointer when alloc_page failed. It will be used in tls_strp_check_queue_ok when the next time tls_strp_read_sock is called. This is because we don't reset full_len in tls_strp_flush_anchor_copy() so the recv path will try to continue handling the partial record on the next call but we dettached the rcvq from the frag list. Alternative fix would be to reset full_len. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Call trace: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798
- https://git.kernel.org/stable/c/406d05da26835943568e61bb751c569efae071d4
- https://git.kernel.org/stable/c/491deb9b8c4ad12fe51d554a69b8165b9ef9429f
- https://git.kernel.org/stable/c/5f1f833cb388592bb46104463a1ec1b7c41975b6
- https://git.kernel.org/stable/c/8f7f96549bc55e4ef3a6b499bc5011e5de2f46c4
- https://git.kernel.org/stable/c/a11b8c0be6acd0505a58ff40d474bd778b25b93a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-17
CVE-2025-38020
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Disable MACsec offload for uplink representor profile
MACsec offload is not supported in switchdev mode for uplink
representors. When switching to the uplink representor profile, the
MACsec offload feature must be cleared from the netdevice's features.
If left enabled, attempts to add offloads result in a null pointer
dereference, as the uplink representor does not support MACsec offload
even though the feature bit remains set.
Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().
Kernel log:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:__mutex_lock+0x128/0x1dd0
Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff
RSP: 0018:ffff888147a4f160 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078
RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000
FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1a69d53922c1221351739f17837d38e317234e5d
- https://git.kernel.org/stable/c/1e577aeb51e9deba4f2c10edfcb07cb3cb406598
- https://git.kernel.org/stable/c/1f80e6ff026041721d8089da8c269b1963628325
- https://git.kernel.org/stable/c/588431474eb7572e57a927fa8558c9ba2f8af143
- https://git.kernel.org/stable/c/b48a47e137cedfd79655accaeeea6b296ad0b9e1
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-17
CVE-2025-38023
In the Linux kernel, the following vulnerability has been resolved:
nfs: handle failure of nfs_get_lock_context in unlock path
When memory is insufficient, the allocation of nfs_lock_context in
nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat
an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)
as valid and proceed to execute rpc_run_task(), this will trigger a NULL
pointer dereference in nfs4_locku_prepare. For example:
BUG: kernel NULL pointer dereference, address: 000000000000000c
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40
Workqueue: rpciod rpc_async_schedule
RIP: 0010:nfs4_locku_prepare+0x35/0xc2
Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3
RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246
RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40
RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38
R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030
R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30
FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/4c189fd40a09a03f9a900bedb2d9064f1734d72a
- https://git.kernel.org/stable/c/72f552e00c50f265896d3c19edc6696aa2910081
- https://git.kernel.org/stable/c/85fb7f8ca5f8c138579fdfc9b97b3083e6077d40
- https://git.kernel.org/stable/c/a6879a076b98c99c9fe747816fe1c29543442441
- https://git.kernel.org/stable/c/c457dc1ec770a22636b473ce5d35614adfe97636
- https://git.kernel.org/stable/c/da824f1271633bcb515ca8084cda3eda4b3ace51
- https://git.kernel.org/stable/c/db6f5ee1fc8f54d079d0751292c2fc2d78e3aad1
- https://git.kernel.org/stable/c/f601960af04d2ecb007c928ba153d34051acd9c1
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-38024
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace:
- https://git.kernel.org/stable/c/16c45ced0b3839d3eee72a86bb172bef6cf58980
- https://git.kernel.org/stable/c/336edd6b0f5b7fbffc3e065285610624f59e88df
- https://git.kernel.org/stable/c/3a3b73e135e3bd18423d0baa72571319c7feb759
- https://git.kernel.org/stable/c/52daccfc3fa68ee1902d52124921453d7a335591
- https://git.kernel.org/stable/c/7c7c80c32e00665234e373ab03fe82f5c5c2c230
- https://git.kernel.org/stable/c/ee4c5a2a38596d548566560c0c022ab797e6f71a
- https://git.kernel.org/stable/c/f81b33582f9339d2dc17c69b92040d3650bb4bae
- https://git.kernel.org/stable/c/f8f470e3a757425a8f98fb9a5991e3cf62fc7134
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-18
CVE-2025-38027
In the Linux kernel, the following vulnerability has been resolved: regulator: max20086: fix invalid memory access max20086_parse_regulators_dt() calls of_regulator_match() using an array of struct of_regulator_match allocated on the stack for the matches argument. of_regulator_match() calls devm_of_regulator_put_matches(), which calls devres_alloc() to allocate a struct devm_of_regulator_matches which will be de-allocated using devm_of_regulator_put_matches(). struct devm_of_regulator_matches is populated with the stack allocated matches array. If the device fails to probe, devm_of_regulator_put_matches() will be called and will try to call of_node_put() on that stack pointer, generating the following dmesg entries: max20086 6-0028: Failed to read DEVICE_ID reg: -121 kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet kobject_put() is being called. Followed by a stack trace matching the call flow described above. Switch to allocating the matches array using devm_kcalloc() to avoid accessing the stack pointer long after it's out of scope. This also has the advantage of allowing multiple max20086 to probe without overriding the data stored inside the global of_regulator_match.
- https://git.kernel.org/stable/c/5578ab04bd7732f470fc614bbc0a924900399fb8
- https://git.kernel.org/stable/c/6b0cd72757c69bc2d45da42b41023e288d02e772
- https://git.kernel.org/stable/c/6ba30f7aa2c550b2ac04f16b81a19a8c045b8660
- https://git.kernel.org/stable/c/7bddac8603d4e396872c2fbf4403ec08e7b1d7c8
- https://git.kernel.org/stable/c/d2a9a92bb4cc7568cff68241b0051dc7268bdc68
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-38094
In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.
- https://git.kernel.org/stable/c/0772a608d799ac0d127c0a36047a2725777aba9d
- https://git.kernel.org/stable/c/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4
- https://git.kernel.org/stable/c/3e64d35475aa21d13dab71da51de51923c1a3a48
- https://git.kernel.org/stable/c/64675a9c00443b2e8af42af08c38fc1b78b68ba2
- https://git.kernel.org/stable/c/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37
- https://git.kernel.org/stable/c/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7
- https://git.kernel.org/stable/c/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-38095
In the Linux kernel, the following vulnerability has been resolved: dma-buf: insert memory barrier before updating num_fences smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.
- https://git.kernel.org/stable/c/08680c4dadc6e736c75bc2409d833f03f9003c51
- https://git.kernel.org/stable/c/3becc659f9cb76b481ad1fb71f54d5c8d6332d3f
- https://git.kernel.org/stable/c/72c7d62583ebce7baeb61acce6057c361f73be4a
- https://git.kernel.org/stable/c/90eb79c4ed98a4e24a62ccf61c199ab0f680fa8f
- https://git.kernel.org/stable/c/c9d2b9a80d06a58f37e0dc8c827075639b443927
- https://git.kernel.org/stable/c/d0b7f11dd68b593bd970e5735be00e8d89bace30
- https://git.kernel.org/stable/c/fe1bebd0edb22e3536cbc920ec713331d1367ad4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-03
CVE-2025-38152
In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Clear table_sz when rproc_shutdown There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc. When starting rproc with a firmware not have resource table, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will trigger dump, because rproc->cache_table is set to NULL during the last stop operation, but rproc->table_sz is still valid. This issue is found on i.MX8MP and i.MX9. Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 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 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Clear rproc->table_sz to address the issue.
- https://git.kernel.org/stable/c/068f6648ff5b0c7adeb6c363fae7fb188aa178fa
- https://git.kernel.org/stable/c/2df19f5f6f72da6f6ebab7cdb3a3b9f7686bb476
- https://git.kernel.org/stable/c/6e66bca8cd51ebedd5d32426906a38e4a3c69c5f
- https://git.kernel.org/stable/c/7c6bb82a6f3da6ab2d3fbea03901482231708b98
- https://git.kernel.org/stable/c/8e0fd2a3b9852ac3cf540edb06ccc0153b38b5af
- https://git.kernel.org/stable/c/e6015ca453b82ec54aec9682dcc38773948fcc48
- https://git.kernel.org/stable/c/efdde3d73ab25cef4ff2d06783b0aad8b093c0e4
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-18
CVE-2025-38177
In the Linux kernel, the following vulnerability has been resolved: sch_hfsc: make hfsc_qlen_notify() idempotent hfsc_qlen_notify() is not idempotent either and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life: 1. update_vf() decreases cl->cl_nactive, so we can check whether it is non-zero before calling it. 2. eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.
- https://git.kernel.org/stable/c/0475c85426b18eccdcb7f9fb58d8f8e9c6c58c87
- https://git.kernel.org/stable/c/51eb3b65544c9efd6a1026889ee5fb5aa62da3bb
- https://git.kernel.org/stable/c/72c61ffbeeb8c50f6d4d70c65d3283aa1bac57a7
- https://git.kernel.org/stable/c/9030a91235ae4845ec71902c3e0cecfc9ed1f2df
- https://git.kernel.org/stable/c/9a5fd5c2f4d4afdd5e405083ee53e0789ce76956
- https://git.kernel.org/stable/c/a5efc95a33bd4fcb879250852828cc58c7862970
- https://git.kernel.org/stable/c/c1175c4ad01dbc9c979d099861fa90a754f72059
- https://git.kernel.org/stable/c/d06476714d2819b550e0cc39222347e2c8941c9d
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2026-03-17
CVE-2025-38575
In the Linux kernel, the following vulnerability has been resolved: ksmbd: use aead_request_free to match aead_request_alloc Use aead_request_free() instead of kfree() to properly free memory allocated by aead_request_alloc(). This ensures sensitive crypto data is zeroed before being freed.
- https://git.kernel.org/stable/c/1de7fec4d3012672e31eeb6679ea60f7ca010ef9
- https://git.kernel.org/stable/c/3e341dbd5f5a6e5a558e67da80731dc38a7f758c
- https://git.kernel.org/stable/c/46caeae23035192b9cc41872c827f30d0233f16e
- https://git.kernel.org/stable/c/571b342d4688801fc1f6a1934389dac09425dc93
- https://git.kernel.org/stable/c/6171063e9d046ffa46f51579b2ca4a43caef581a
- https://git.kernel.org/stable/c/a6b594868268c3a7bfaeced912525cd2c445529a
- https://git.kernel.org/stable/c/aef10ccd74512c52e30c5ee19d0031850973e78d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-06
CVE-2025-38637
In the Linux kernel, the following vulnerability has been resolved: net_sched: skbprio: Remove overly strict queue assertions In the current implementation, skbprio enqueue/dequeue contains an assertion that fails under certain conditions when SKBPRIO is used as a child qdisc under TBF with specific parameters. The failure occurs because TBF sometimes peeks at packets in the child qdisc without actually dequeuing them when tokens are unavailable. This peek operation creates a discrepancy between the parent and child qdisc queue length counters. When TBF later receives a high-priority packet, SKBPRIO's queue length may show a different value than what's reflected in its internal priority queue tracking, triggering the assertion. The fix removes this overly strict assertions in SKBPRIO, they are not necessary at all.
- https://git.kernel.org/stable/c/034b293bf17c124fec0f0e663f81203b00aa7a50
- https://git.kernel.org/stable/c/1284733bab736e598341f1d3f3b94e2a322864a8
- https://git.kernel.org/stable/c/1dcc144c322a8d526b791135604c0663f1af9d85
- https://git.kernel.org/stable/c/2286770b07cb5268c03d11274b8efd43dff0d380
- https://git.kernel.org/stable/c/2f35b7673a3aa3d09b3eb05811669622ebaa98ca
- https://git.kernel.org/stable/c/32ee79682315e6d3c99947b3f38b078a09a66919
- https://git.kernel.org/stable/c/7abc8318ce0712182bf0783dcfdd9a6a8331160e
- https://git.kernel.org/stable/c/864ca690ff135078d374bd565b9872f161c614bc
- https://git.kernel.org/stable/c/ce8fe975fd99b49c29c42e50f2441ba53112b2e8
- 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-39728
In the Linux kernel, the following vulnerability has been resolved:
clk: samsung: Fix UBSAN panic in samsung_clk_init()
With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to
dereferencing `ctx->clk_data.hws` before setting
`ctx->clk_data.num = nr_clks`. Move that up to fix the crash.
UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
- https://git.kernel.org/stable/c/00307934eb94aaa0a99addfb37b9fe206f945004
- https://git.kernel.org/stable/c/0fef48f4a70e45a93e73c39023c3a6ea624714d6
- https://git.kernel.org/stable/c/157de9e48007a20c65d02fc0229a16f38134a72d
- https://git.kernel.org/stable/c/24307866e0ac0a5ddb462e766ceda5e27a6fbbe3
- https://git.kernel.org/stable/c/4d29a6dcb51e346595a15b49693eeb728925ca43
- https://git.kernel.org/stable/c/a1500b98cd81a32fdfb9bc63c33bb9f0c2a0a1bf
- https://git.kernel.org/stable/c/d19d7345a7bcdb083b65568a11b11adffe0687af
- https://git.kernel.org/stable/c/d974e177369c034984cece9d7d4fada9f8b9c740
- 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-39735
In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds read in ea_get() During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised.
- https://git.kernel.org/stable/c/0beddc2a3f9b9cf7d8887973041e36c2d0fa3652
- https://git.kernel.org/stable/c/16d3d36436492aa248b2d8045e75585ebcc2f34d
- https://git.kernel.org/stable/c/3d6fd5b9c6acbc005e53d0211c7381f566babec1
- https://git.kernel.org/stable/c/46e2c031aa59ea65128991cbca474bd5c0c2ecdb
- https://git.kernel.org/stable/c/50afcee7011155933d8d5e8832f52eeee018cfd3
- https://git.kernel.org/stable/c/5263822558a8a7c0d0248d5679c2dcf4d5cda61f
- https://git.kernel.org/stable/c/78c9cbde8880ec02d864c166bcb4fe989ce1d95f
- https://git.kernel.org/stable/c/a8c31808925b11393a6601f534bb63bac5366bab
- https://git.kernel.org/stable/c/fdf480da5837c23b146c4743c18de97202fcab37
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- 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
