ALT-PU-2025-8295-2
Package kernel-image-6.12 updated to version 6.12.34-alt1 for branch sisyphus in task 387624.
Closed vulnerabilities
Modified: 2026-03-18
BDU:2025-08508
Уязвимость функции COMP_DUMMY() модуля sound/soc/mediatek/mt8195/mt8195-mt6359.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08509
Уязвимость функции ath11k_core_halt() модуля drivers/net/wireless/ath/ath11k/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08510
Уязвимость функции sun8i_ce_cipher_prepare() модуля drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08622
Уязвимость модуля kernel/trace/bpf_trace.c подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08626
Уязвимость функции em_compute_costs() модуля kernel/power/energy_model.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08627
Уязвимость функции smp_processor_id() модуля drivers/perf/amlogic/meson_ddr_pmu_core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08628
Уязвимость функции smp_processor_id() модуля drivers/scsi/smartpqi/smartpqi_init.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08629
Уязвимость функции ath12k_core_halt() модуля drivers/net/wireless/ath/ath12k/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-08630
Уязвимость функции smp_processor_id() модуля drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08632
Уязвимость функции ath12k_dp_rx_msdu_coalesce() модуля drivers/net/wireless/ath/ath12k/dp_rx.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08706
Уязвимость компонента bus ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-08926
Уязвимость функции eir_create_adv_data() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08927
Уязвимость функции eir_get_service_data() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08997
Уязвимость функции __io_uring_show_fdinfo() компонента io_uring ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09001
Уязвимость модуля drivers/net/wwan/t7xx/t7xx_netdev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09002
Уязвимость функции ufshcd_err_handling_prepare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09003
Уязвимость функции mgmt_remove_adv_monitor_complete() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09004
Уязвимость функции gve_alloc_pending_packet() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09025
Уязвимость функции io_bitmap_exit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09026
Уязвимость функций ring_buffer_subbuf_order_set(), atomic_dec() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09047
Уязвимость компонента seg6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-19
BDU:2025-09048
Уязвимость функции atomctrl_initialize_mc_reg_table() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09050
Уязвимость функции parse_int_array() компонента ASoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09053
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю повредить память
Modified: 2026-03-19
BDU:2025-09058
Уязвимость функции platform_set_drvdata() компонента perf ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-09059
Уязвимость функции fb_cvt_hperiod() компонента fbdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09063
Уязвимость функции btintel_dsbr() компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09122
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09134
Уязвимость функции squashfs_fill_super() компонента Squashfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-09314
Уязвимость функции do_change_type() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09521
Уязвимость функции napi_complete() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09522
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09603
Уязвимость функции ptp_rate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09604
Уязвимость функции page_pool_recycle_in_ring() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09605
Уязвимость модуля net/ipv4/udp_offload.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09606
Уязвимость модуля drivers/net/ethernet/intel/ice/ice_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09609
Уязвимость функции key_extract_l3l4 модуля net/openvswitch/flow.c компонента openvswitch ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09610
Уязвимость драйвера mlx5 подсистемы RDMA ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии, выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09611
Уязвимость функции phy_detach() модуля drivers/net/phy/phy_device.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09613
Уязвимость функции cma_netevent_callback() модуля drivers/infiniband/core/cma.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09614
Уязвимость функции usbnet_read_cmd() библиотеки include/linux/etherdevice.h ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09615
Уязвимость функции cscfg_csdev_enable_active_config() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09616
Уязвимость функции total_valid_block_count библиотеки fs/f2fs/f2fs.h ядра операционных систем Linux, позволяющая наршителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09627
Уязвимость функции usb_acpi_add_usb4_devlink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09630
Уязвимость функции mlb_usio_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09631
Уязвимость функции usbhs_probe() компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09632
Уязвимость функций udma_probe() и devm_kasprintf() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09635
Уязвимость функции dm_get_live_table() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09636
Уязвимость функции read_string() компонента hwmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09638
Уязвимость функции wled_configure() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09640
Уязвимость функции txopt_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09641
Уязвимость модуля drivers/net/phy/mscc/mscc_ptp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09675
Уязвимость функции kernfs_should_drain_open_files() компонента kernfs ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2026-03-18
BDU:2025-09676
Уязвимость функции tcpm_queue_vdm_unlocked() компонента DisplayPort Alt Mode Driver ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09679
Уязвимость компонента octeontx2-pf файла net/core/net-sysfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09681
Уязвимость компонента ring-buffer файла kernel/trace/ring_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09683
Уязвимость функции bpf_prog_select_runtime() файла kernel/bpf/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09684
Уязвимость компонента mdiobus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09823
Уязвимость модулей drivers/net/ethernet/stmicro/stmmac/stmmac_main.c и drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09824
Уязвимость функции aspeed_lpc_enable_snoop() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09826
Уязвимость модуля arch/powerpc/platforms/powernv/memtrace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09835
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09918
Уязвимость функции skb_send_sock() компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10125
Уязвимость драйвера hisi_acc_vfio_pci ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-10126
Уязвимость функции skb_linearize() модуля net/core/skmsg.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10128
Уязвимость функции rtw_fw_bt_wifi_control() модуля drivers/net/wireless/realtek/rtw88/coex.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10130
Уязвимость функции mt7915_mmio_wed_init() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10131
Уязвимость функции aspberrypi_clk_register() модуля drivers/clk/bcm/clk-raspberrypi.c ядра операционной системы Linux, позволяющая нарушитею вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10132
Уязвимость функции ath9k_htc_swba() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-10309
Уязвимость функции get_net() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10310
Уязвимость компонента mtd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10311
Уязвимость функции at91_gpio_probe() файла drivers/pinctrl/pinctrl-at91.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-10313
Уязвимость функции btrfs_convert_extent_bit() компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10314
Уязвимость функции fpga_mgr_test_img_load_sgt() компонента fpga ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10739
Уязвимость функции ptp_vclock_in_use ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10740
Уязвимость функции submit_bio_noacct_nocheck ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10773
Уязвимость функции sk_is_readable() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-10774
Уязвимость функции __red_change() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-18
BDU:2025-10775
Уязвимость функции _pf_vf_vports() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-02-17
BDU:2025-10776
Уязвимость функции mgmt_pending() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-18
BDU:2025-10777
Уязвимость компонента mdiobus ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-18
BDU:2025-10778
Уязвимость функции for_each_possible_cpu() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-10779
Уязвимость функции usbhid_parse() компонента bNumDescriptors ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10780
Уязвимость компонента net_sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-10781
Уязвимость функции vmci_host_setup_notify() файла mm/gup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10783
Уязвимость функции ets_qdisc_change() компонента net_sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10784
Уязвимость функции nf_set_pipapo_avx2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2026-02-17
BDU:2025-10870
Уязвимость функции handle_posix_cpu_timers ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11385
Уязвимость модуля arch/arm64/boot/dts/qcom/x1e80100.dtsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11389
Уязвимость функции f2fs_gc_range() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11467
Уязвимость компонента net/sched/sch_prio.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации, нарушить её целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-11762
Уязвимость функции zynqmp_nvmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11765
Уязвимость функции mt7996_mmio_wed_init() модуля drivers/net/wireless/mediatek/mt76/mt7996/mmio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11767
Уязвимость функции fpsimd_thread_switch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11769
Уязвимость функции taprio_dev_notifier() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11770
Уязвимость функции arm_ni_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-13170
Уязвимость функции ath12k_service_ready_ext_event() модуля drivers/net/wireless/ath/ath12k/wmi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-13454
Уязвимость функции adxl_put ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
BDU:2025-14097
Уязвимость функции check_mul_overflow() компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-14098
Уязвимость функции hdr_first_de() компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-14099
Уязвимость функции bpf_exec_tx_verdict() компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-14100
Уязвимость функции do_sme_acc() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-17
CVE-2025-38083
In the Linux kernel, the following vulnerability has been resolved: net_sched: prio: fix a race in prio_tune() Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
- https://git.kernel.org/stable/c/20f68e6a9e41693cb0e55e5b9ebbcb40983a4b8f
- https://git.kernel.org/stable/c/3aaa7c01cf19d9b9bb64b88b65c3a6fd05da2eb4
- https://git.kernel.org/stable/c/4483d8b9127591c60c4eb789d6cab953bc4522a9
- https://git.kernel.org/stable/c/46c15c9d0f65c9ba857d63f53264f4b17e8a715f
- https://git.kernel.org/stable/c/53d11560e957d53ee87a0653d258038ce12361b7
- https://git.kernel.org/stable/c/93f9eeb678d4c9c1abf720b3615fa8299a490845
- https://git.kernel.org/stable/c/d35acc1be3480505b5931f17e4ea9b7617fea4d3
- https://git.kernel.org/stable/c/e3f6745006dc9423d2b065b90f191cfa11b1b584
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38088
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size.
- https://git.kernel.org/stable/c/620b77b23c41a6546e5548ffe2ea3ad71880dde4
- https://git.kernel.org/stable/c/81260c41b518b6f32c701425f1427562fa92f293
- https://git.kernel.org/stable/c/8635e325b85dfb9ddebdfaa6b5605d40d16cd147
- https://git.kernel.org/stable/c/9c340b56d60545e4a159e41523dd8b23f81d3261
- https://git.kernel.org/stable/c/bbd5a9ddb0f9750783a48a871c9e12c0b68c5f39
- https://git.kernel.org/stable/c/cd097df4596f3a1e9d75eb8520162de1eb8485b2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38093
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: x1e80100: Add GPU cooling Unlike the CPU, the GPU does not throttle its speed automatically when it reaches high temperatures. With certain high GPU loads it is possible to reach the critical hardware shutdown temperature of 120°C, endangering the hardware and making it impossible to run certain applications. Set up GPU cooling similar to the ACPI tables, by throttling the GPU speed when reaching 95°C and polling every 200ms.
Modified: 2025-12-16
CVE-2025-38100
In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.
- https://git.kernel.org/stable/c/2cfcbe1554c119402e7382de974c26b0549899fe
- https://git.kernel.org/stable/c/2dace5e016c991424a3dc6e83b1ae5dca8992d08
- https://git.kernel.org/stable/c/73cfcc8445585b8af7e18be3c9246b851fdf336c
- https://git.kernel.org/stable/c/8b68e978718f14fdcb080c2a7791c52a0d09bc6d
- https://git.kernel.org/stable/c/aa5ce1485562f20235b4c759eee5ab0c41d2c220
- https://git.kernel.org/stable/c/b3b3b6366dc8eb5b22edba9adc4bff3cdacfd64c
- https://git.kernel.org/stable/c/d64b7b05a827f98d068f412969eef65489b0cf03
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38101
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set() Enlarge the critical section in ring_buffer_subbuf_order_set() to ensure that error handling takes place with per-buffer mutex held, thus preventing list corruption and other concurrency-related issues.
Modified: 2025-12-16
CVE-2025-38102
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio
as follow:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
Modules linked in:
CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
RIP: 0010:try_grab_folio+0x106/0x130
Call Trace:
- https://git.kernel.org/stable/c/00ddc7dad55b7bbb78df80d6e174d0c4764dea0c
- https://git.kernel.org/stable/c/1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4
- https://git.kernel.org/stable/c/468aec888f838ce5174b96e0cb4396790d6f60ca
- https://git.kernel.org/stable/c/58a90db70aa6616411e5f69d1982d9b1dd97d774
- https://git.kernel.org/stable/c/6e3af836805ed1d7a699f76ec798626198917aa4
- https://git.kernel.org/stable/c/74095bbbb19ca74a0368d857603a2438c88ca86c
- https://git.kernel.org/stable/c/75b5313c80c39a26d27cbb602f968a05576c36f9
- https://git.kernel.org/stable/c/b4209e4b778e4e57d0636e1c9fc07a924dbc6043
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38103
In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors.
- https://git.kernel.org/stable/c/1df80d748f984290c895e843401824215dcfbfb0
- https://git.kernel.org/stable/c/41827a2dbdd7880df9881506dee13bc88d4230bb
- https://git.kernel.org/stable/c/485e1b741eb838cbe1d6b0e81e5ab62ae6c095cf
- https://git.kernel.org/stable/c/4fa7831cf0ac71a0a345369d1a6084f2b096e55e
- https://git.kernel.org/stable/c/74388368927e9c52a69524af5bbd6c55eb4690de
- https://git.kernel.org/stable/c/7a6d6b68db128da2078ccd9a751dfa3f75c9cf5b
- https://git.kernel.org/stable/c/a8f842534807985d3a676006d140541b87044345
- https://git.kernel.org/stable/c/fe7f7ac8e0c708446ff017453add769ffc15deed
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38106
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo()
syzbot reports:
BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60
Read of size 8 at addr ffff88810de2d2c8 by task a.out/304
CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary)
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
Modified: 2025-12-16
CVE-2025-38107
In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: fix a race in ets_qdisc_change() Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
- https://git.kernel.org/stable/c/0383b25488a545be168744336847549d4a2d3d6c
- https://git.kernel.org/stable/c/073f64c03516bcfaf790f8edc772e0cfb8a84ec3
- https://git.kernel.org/stable/c/0b479d0aa488cb478eb2e1d8868be946ac8afb4f
- https://git.kernel.org/stable/c/347867cb424edae5fec1622712c8dd0a2c42918f
- https://git.kernel.org/stable/c/d92adacdd8c2960be856e0b82acc5b7c5395fddb
- https://git.kernel.org/stable/c/eb7b74e9754e1ba2088f914ad1f57a778b11894b
- https://git.kernel.org/stable/c/fed94bd51d62d2e0e006aa61480e94e5cd0582b0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38108
In the Linux kernel, the following vulnerability has been resolved: net_sched: red: fix a race in __red_change() Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
- https://git.kernel.org/stable/c/110a47efcf23438ff8d31dbd9c854fae2a48bf98
- https://git.kernel.org/stable/c/2790c4ec481be45a80948d059cd7c9a06bc37493
- https://git.kernel.org/stable/c/2a71924ca4af59ffc00f0444732b6cd54b153d0e
- https://git.kernel.org/stable/c/444ad445df5496a785705019268a8a84b84484bb
- https://git.kernel.org/stable/c/4b755305b2b0618e857fdadb499365b5f2e478d1
- https://git.kernel.org/stable/c/85a3e0ede38450ea3053b8c45d28cf55208409b8
- https://git.kernel.org/stable/c/a1bf6a4e9264a685b0e642994031f9c5aad72414
- https://git.kernel.org/stable/c/f569984417a4e12c67366e69bdcb752970de921d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38109
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix ECVF vports unload on shutdown flow Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed. ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]---
Modified: 2025-11-20
CVE-2025-38110
In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds clause 45 read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.
Modified: 2025-12-16
CVE-2025-38111
In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.
- https://git.kernel.org/stable/c/014ad9210373d2104f6ef10e6bb999a7a0a4c50e
- https://git.kernel.org/stable/c/049af7ac45a6b407748ee0995278fd861e36df8f
- https://git.kernel.org/stable/c/0e629694126ca388916f059453a1c36adde219c4
- https://git.kernel.org/stable/c/19c5875e26c4ed5686d82a7d8f7051385461b9eb
- https://git.kernel.org/stable/c/73d478234a619f3476028cb02dee699c30ae8262
- https://git.kernel.org/stable/c/b02d9d2732483e670bc34cb233d28e1d43b15da4
- https://git.kernel.org/stable/c/bab6bca0834cbb5be2a7cfe59ec6ad016ec72608
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38112
In the Linux kernel, the following vulnerability has been resolved: net: Fix TOCTOU issue in sk_is_readable() sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL. This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference. Ensure the function pointer does not turn NULL after the check.
- https://git.kernel.org/stable/c/1b367ba2f94251822577daed031d6b9a9e11ba91
- https://git.kernel.org/stable/c/1e0de7582ceccbdbb227d4e0ddf65732f92526da
- https://git.kernel.org/stable/c/2660a544fdc0940bba15f70508a46cf9a6491230
- https://git.kernel.org/stable/c/6fa68d7eab34d448a61aa24ea31e68b3231ed20d
- https://git.kernel.org/stable/c/8926a7ef1977a832dd6bf702f1a99303dbf15b15
- https://git.kernel.org/stable/c/c2b26638476baee154920bb587fc94ff1bf04336
- https://git.kernel.org/stable/c/ff55c85a923e043d59d26b20a673a1b4a219c310
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38113
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Fix NULL pointer dereference when nosmp is used
With nosmp in cmdline, other CPUs are not brought up, leaving
their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu()
dereferences these NULL pointers, causing panic.
Panic backtrace:
[ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8
...
[ 0.403255] [
- https://git.kernel.org/stable/c/15eece6c5b05e5f9db0711978c3e3b7f1a2cfe12
- https://git.kernel.org/stable/c/1a677d0ceb4a5d62117b711a8b2e0aee80d33015
- https://git.kernel.org/stable/c/32a48db4cf28ea087214c261da8476db218d08bd
- https://git.kernel.org/stable/c/356d09c7f5bf525086002a34f8bae40b134d1611
- https://git.kernel.org/stable/c/c6dad167aade4bf0bef9130f2f149f4249fc4ad0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38115
In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: fix a potential crash on gso_skb handling SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 &
- https://git.kernel.org/stable/c/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72
- https://git.kernel.org/stable/c/82448d4dcd8406dec688632a405fdcf7f170ec69
- https://git.kernel.org/stable/c/82ffbe7776d0ac084031f114167712269bf3d832
- https://git.kernel.org/stable/c/9c19498bdd7cb9d854bd3c54260f71cf7408495e
- https://git.kernel.org/stable/c/b44f791f27b14c9eb6b907fbe51f2ba8bec32085
- https://git.kernel.org/stable/c/b4e9bab6011b9559b7c157b16b91ae46d4d8c533
- https://git.kernel.org/stable/c/c337efb20d6d9f9bbb4746f6b119917af5c886dc
- https://git.kernel.org/stable/c/d1bc80da75c789f2f6830df89d91fb2f7a509943
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38117
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Protect mgmt_pending list with its own lock This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT 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+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __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+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __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+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline ---truncated---
Modified: 2025-12-17
CVE-2025-38118
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to
avoid crashes like bellow:
==================================================================
BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406
Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341
CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #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: hci0 hci_cmd_sync_work
Call Trace:
- https://git.kernel.org/stable/c/32aa2fbe319f33b0318ec6f4fceb63879771a286
- https://git.kernel.org/stable/c/3c9aba9cbdf163e2654be9f82d43ff8a04273962
- https://git.kernel.org/stable/c/9df3e5e7f7e4653fd9802878cedc36defc5ef42d
- https://git.kernel.org/stable/c/9f66b6531c2b4e996bb61720ee94adb4b2e8d1be
- https://git.kernel.org/stable/c/e6ed54e86aae9e4f7286ce8d5c73780f91b48d1c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-19
CVE-2025-38119
In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 [ bvanassche: rewrote patch description ]
- https://git.kernel.org/stable/c/21f071261f946c5ca1adf378f818082a112b34d2
- https://git.kernel.org/stable/c/3464a707d137efc8aea1d4ae234d26a28d82b78c
- https://git.kernel.org/stable/c/8a3514d348de87a9d5e2ac00fbac4faae0b97996
- https://git.kernel.org/stable/c/bb37f795d01961286b8f768a6d7152f32b589067
- https://git.kernel.org/stable/c/ded80255c59a57cd3270d98461f6508730f9767c
- https://git.kernel.org/stable/c/f210ea4e7a790c9f5e613e5302175abd539fe9d5
- https://git.kernel.org/stable/c/f592eb12b43f21dbc972cbe583a12d256901e569
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38120
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo_avx2: fix initial map fill If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh.
- https://git.kernel.org/stable/c/251496ce1728c9fd47bd2b20a7b21b20b9a020ca
- https://git.kernel.org/stable/c/39bab2d3517b5b50c609b4f8c66129bf619fffa0
- https://git.kernel.org/stable/c/8068e1e42b46518ce680dc6470bcd710efc3fa0a
- https://git.kernel.org/stable/c/8164d0efaf370c425dc69a1e8216940d09e7de0c
- https://git.kernel.org/stable/c/90bc7f5a244aadee4292b28098b7c98aadd4b3aa
- https://git.kernel.org/stable/c/b5ad58285f9217d68cd5ea2ad86ce254a3fe7c4d
- https://git.kernel.org/stable/c/ea77c397bff8b6d59f6d83dae1425b08f465e8b5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38122
In the Linux kernel, the following vulnerability has been resolved: gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer. Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails. This improves robustness in low-memory scenarios.
- https://git.kernel.org/stable/c/12c331b29c7397ac3b03584e12902990693bc248
- https://git.kernel.org/stable/c/2e5ead9e4e91fbe7799bd38afd8904543be1cb51
- https://git.kernel.org/stable/c/7f6265fce3bd424ded666481b37f106d7915fb6b
- https://git.kernel.org/stable/c/a0319c9b1648a67511e947a596ca86888451c0a7
- https://git.kernel.org/stable/c/ae98a1787fdcb0096d122bc80d93c3c7d812c04b
- https://git.kernel.org/stable/c/c741a7ef68023ac800054e2131c3e22e647fd7e3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38123
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: Fix napi rx poll issue
When driver handles the napi rx polling requests, the netdev might
have been released by the dellink logic triggered by the disconnect
operation on user plane. However, in the logic of processing skb in
polling, an invalid netdev is still being used, which causes a panic.
BUG: kernel NULL pointer dereference, address: 00000000000000f1
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dev_gro_receive+0x3a/0x620
[...]
Call Trace:
Modified: 2025-12-17
CVE-2025-38124
In the Linux kernel, the following vulnerability has been resolved: net: fix udp gso skb_segment after pull from frag_list Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from frag_list") detected invalid geometry in frag_list skbs and redirects them from skb_segment_list to more robust skb_segment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skb_segment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust. If only part of the fraglist payload is pulled into head_skb, it will always cause exception when splitting skbs by skb_segment. For detailed call stack information, see below. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify fraglist skbs, breaking these invariants. In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes. The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because payload was pulled into head_skb, it needs to be linearized before pass to regular skb_segment. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770
- https://git.kernel.org/stable/c/0e65f38bd1aa14ea86e221b7bb814d38278d86c3
- https://git.kernel.org/stable/c/3382a1ed7f778db841063f5d7e317ac55f9e7f72
- https://git.kernel.org/stable/c/4399f59a9467a324ed46657555f0e1f209a14acb
- https://git.kernel.org/stable/c/85eef1748c024da1a191aed56b30a3a65958c50c
- https://git.kernel.org/stable/c/a04302867094bdc6efac1b598370fc47cf3f2388
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38125
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.
- https://git.kernel.org/stable/c/451ee661d0f6272017fa012f99617101aa8ddf2c
- https://git.kernel.org/stable/c/b15c9a21950e1af6d440ce5a8edfa8a94b9acb9b
- https://git.kernel.org/stable/c/b92ec4a848728460f181def33735605f154d438f
- https://git.kernel.org/stable/c/cbefe2ffa7784525ec5d008ba87c7add19ec631a
- https://git.kernel.org/stable/c/d5e3bfdba0dc419499b801937128957f77503761
- https://git.kernel.org/stable/c/d6b0f7ed3e9b6c5e2e3a006c8f72c95aa4ac4b74
Modified: 2025-12-17
CVE-2025-38126
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping The stmmac platform drivers that do not open-code the clk_ptp_rate value after having retrieved the default one from the device-tree can end up with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmac_ptp_register, which then becomes duplicate
- https://git.kernel.org/stable/c/030ce919e114a111e83b7976ecb3597cefd33f26
- https://git.kernel.org/stable/c/32af9c289234990752281c805500dfe03c5b2b8f
- https://git.kernel.org/stable/c/379cd990dfe752b38fcf46034698a9a150626c7a
- https://git.kernel.org/stable/c/b263088ee8ab14563817a8be3519af8e25225793
- https://git.kernel.org/stable/c/bb033c6781ce1b0264c3993b767b4aa9021959c2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38127
In the Linux kernel, the following vulnerability has been resolved:
ice: fix Tx scheduler error handling in XDP callback
When the XDP program is loaded, the XDP callback adds new Tx queues.
This means that the callback must update the Tx scheduler with the new
queue number. In the event of a Tx scheduler failure, the XDP callback
should also fail and roll back any changes previously made for XDP
preparation.
The previous implementation had a bug that not all changes made by the
XDP callback were rolled back. This caused the crash with the following
call trace:
[ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5
[ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI
[ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)
[ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022
[ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice]
[...]
[ +0.002715] Call Trace:
[ +0.002452]
Modified: 2026-01-19
CVE-2025-38129
In the Linux kernel, the following vulnerability has been resolved:
page_pool: Fix use-after-free in page_pool_recycle_in_ring
syzbot reported a uaf in page_pool_recycle_in_ring:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862
Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943
CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
- https://git.kernel.org/stable/c/1a8c0b61d4cb55c5440583ec9e7f86a730369e32
- https://git.kernel.org/stable/c/271683bb2cf32e5126c592b5d5e6a756fa374fd9
- https://git.kernel.org/stable/c/4914c0a166540e534a0c1d43affd329d95fb56fd
- https://git.kernel.org/stable/c/4ab8c0f8905c9c4d05e7f437e65a9a365573ff02
- https://git.kernel.org/stable/c/d69f28ef7cdafdcf37ee310f38b1399e7d05f9a8
- https://git.kernel.org/stable/c/e869a85acc2e60dc554579b910826a4919d8cd98
Modified: 2025-12-17
CVE-2025-38131
In the Linux kernel, the following vulnerability has been resolved: coresight: prevent deactivate active config while enabling the config While enable active config via cscfg_csdev_enable_active_config(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario: CPU0 CPU1 (sysfs enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() unload module // access to config_desc which freed // while unloading module. cscfg_csdev_enable_config To address this, use cscfg_config_desc's active_cnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when config_active_cnt == 0.
- https://git.kernel.org/stable/c/31028812724cef7bd57a51525ce58a32a6d73b22
- https://git.kernel.org/stable/c/408c97c4a5e0b634dcd15bf8b8808b382e888164
- https://git.kernel.org/stable/c/b3b4efa2e623aecaebd7c9b9e4171f5c659e9724
- https://git.kernel.org/stable/c/dfe8224c9c7a43d356eb9f74b06868aa05f90223
- https://git.kernel.org/stable/c/ed42ee1ed05ff2f4c36938379057413a40c56680
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38134
In the Linux kernel, the following vulnerability has been resolved: usb: acpi: Prevent null pointer dereference in usb_acpi_add_usb4_devlink() As demonstrated by the fix for update_port_device_state, commit 12783c0b9e2c ("usb: core: Prevent null pointer dereference in update_port_device_state"), usb_hub_to_struct_hub() can return NULL in certain scenarios, such as during hub driver unbind or teardown race conditions, even if the underlying usb_device structure exists. Plus, all other places that call usb_hub_to_struct_hub() in the same file do check for NULL return values. If usb_hub_to_struct_hub() returns NULL, the subsequent access to hub->ports[udev->portnum - 1] will cause a null pointer dereference.
Modified: 2025-12-17
CVE-2025-38135
In the Linux kernel, the following vulnerability has been resolved: serial: Fix potential null-ptr-deref in mlb_usio_probe() devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue.
- https://git.kernel.org/stable/c/19fd9f5a69363d33079097d866eb6082d61bf31d
- https://git.kernel.org/stable/c/548b0e81b9a0902a8bc8259430ed965663baadfc
- https://git.kernel.org/stable/c/81159a6b064142b993f2f39828b77e199c77872a
- https://git.kernel.org/stable/c/86bcae88c9209e334b2f8c252f4cc66beb261886
- https://git.kernel.org/stable/c/a05ebe384c7ca75476453f3070c67d9cf1d1a89f
- https://git.kernel.org/stable/c/a6c7c365734cd0fa1c5aa225a6294fdf80cad2ea
- https://git.kernel.org/stable/c/c23d87b43f7dba5eb12820f6cf21a1cd4f63eb3d
- https://git.kernel.org/stable/c/e1b144aebe6fb898d96ced8c990d7aa38fda4a7a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38136
In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Reorder clock handling and power management in probe Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/095cc0b5888acc228f12344e85b17539b9ce9367
- https://git.kernel.org/stable/c/0a1e16a6cbf4452b46f20b862d6141a1e90844ee
- https://git.kernel.org/stable/c/155453ada562c450a4ff5fcf4852b9fa5b6b793a
- https://git.kernel.org/stable/c/1637623ad6205162b17804d07512e6f4cbd2a050
- https://git.kernel.org/stable/c/6bab152e817fd41b9e178fa6b275354795c9703d
- https://git.kernel.org/stable/c/d4c368e4a638ddf4a9d6d687b0ff691aa46cce53
- https://git.kernel.org/stable/c/db96a4fd8614d47c0def265e0e6c996b0ee52a38
- https://git.kernel.org/stable/c/ffb34a60ce86656ba12d46e91f1ccc71dd221251
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38138
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Add NULL check in udma_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, udma_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/643db430f4cbd91dd2b63c49d62d0abb6debc13b
- https://git.kernel.org/stable/c/9f133e04c62246353b8b1f0a679535c65161ebcf
- https://git.kernel.org/stable/c/b79e10050d9d1e200541d25751dd5cb8ec58483c
- https://git.kernel.org/stable/c/bc6ddff79835f71310a21645d8fcf08ec473e969
- https://git.kernel.org/stable/c/d61d5ba5bd5b0e39e30b34dcd92946e084bca0d0
- https://git.kernel.org/stable/c/ec1ea394c40523835bbedd8fc4934b77b461b6fe
- https://git.kernel.org/stable/c/fd447415e74bccd7362f760d4ea727f8e1ebfe91
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38141
In the Linux kernel, the following vulnerability has been resolved: dm: fix dm_blk_report_zones If dm_get_live_table() returned NULL, dm_put_live_table() was never called. Also, it is possible that md->zone_revalidate_map will change while calling this function. Only read it once, so that we are always using the same value. Otherwise we might miss a call to dm_put_live_table(). Finally, while md->zone_revalidate_map is set and a process is calling blk_revalidate_disk_zones() to set up the zone append emulation resources, it is possible that another process, perhaps triggered by blkdev_report_zones_ioctl(), will call dm_blk_report_zones(). If blk_revalidate_disk_zones() fails, these resources can be freed while the other process is still using them, causing a use-after-free error. blk_revalidate_disk_zones() will only ever be called when initially setting up the zone append emulation resources, such as when setting up a zoned dm-crypt table for the first time. Further table swaps will not set md->zone_revalidate_map or call blk_revalidate_disk_zones(). However it must be called using the new table (referenced by md->zone_revalidate_map) and the new queue limits while the DM device is suspended. dm_blk_report_zones() needs some way to distinguish between a call from blk_revalidate_disk_zones(), which must be allowed to use md->zone_revalidate_map to access this not yet activated table, and all other calls to dm_blk_report_zones(), which should not be allowed while the device is suspended and cannot use md->zone_revalidate_map, since the zone resources might be freed by the process currently calling blk_revalidate_disk_zones(). Solve this by tracking the process that sets md->zone_revalidate_map in dm_revalidate_zones() and only allowing that process to make use of it in dm_blk_report_zones().
Modified: 2025-12-18
CVE-2025-38142
In the Linux kernel, the following vulnerability has been resolved: hwmon: (asus-ec-sensors) check sensor index in read_string() Prevent a potential invalid memory access when the requested sensor is not found. find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info(). Add a proper check to return -EINVAL if sensor_index is negative. Found by Linux Verification Center (linuxtesting.org) with SVACE. [groeck: Return error code returned from find_ec_sensor_index]
- https://git.kernel.org/stable/c/19bd9cde38dd4ca1771aed7afba623e7f4247c8e
- https://git.kernel.org/stable/c/25be318324563c63cbd9cb53186203a08d2f83a1
- https://git.kernel.org/stable/c/4e9e45746b861ebd54c03ef301da2cb8fc990536
- https://git.kernel.org/stable/c/6bf529ce84dccc0074dbc704e70aee4aa545057e
- https://git.kernel.org/stable/c/7eeb3df6f07a886bdfd52757ede127a59a8784dc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38143
In the Linux kernel, the following vulnerability has been resolved: backlight: pm8941: Add NULL check in wled_configure() devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() 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/1be2000b703b02e149f8f2061054489f6c18c972
- https://git.kernel.org/stable/c/21528806560510458378ea52c37e35b0773afaea
- https://git.kernel.org/stable/c/4a715be3fe80b68fa55cb3569af3d294be101626
- https://git.kernel.org/stable/c/6a56446595730a5e3f06a30902e23cb037d28146
- https://git.kernel.org/stable/c/9d06ac32c202142da40904180f2669ed4f5073ac
- https://git.kernel.org/stable/c/e12d3e1624a02706cdd3628bbf5668827214fa33
- https://git.kernel.org/stable/c/fde314445332015273c8f51d2659885c606fe135
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38145
In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop() devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. [arj: Fix Fixes: tag to use subject from 3772e5da4454]
- https://git.kernel.org/stable/c/1fd889c145722579aa038c31cbc07cfdd4d75166
- https://git.kernel.org/stable/c/2beee9cf833374550e673d428ad8b6ab37c175b3
- https://git.kernel.org/stable/c/45b2e8b0fdd280aba04c3cc869e9ae500c44e4b7
- https://git.kernel.org/stable/c/8312b1f776f71979bf33bda7acc05b348e8792c7
- https://git.kernel.org/stable/c/c550999f939b529d28a914d5034cc4290066aea6
- https://git.kernel.org/stable/c/d62a589eaaec6385e3e2b25cf5a28b4560ace93f
- https://git.kernel.org/stable/c/f1706e0e1a74b095cbc60375b9b1e6205f5f4c98
- https://git.kernel.org/stable/c/f697ef117ecbf3a367dfc559a6a3589905956530
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38146
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix the dead loop of MPLS parse
The unexpected MPLS packet may not end with the bottom label stack.
When there are many stacks, The label count value has wrapped around.
A dead loop occurs, soft lockup/CPU stuck finally.
stack backtrace:
UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26
index -1 is out of range for type '__be32 [3]'
CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu
Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021
Call Trace:
- https://git.kernel.org/stable/c/0bdc924bfb319fb10d1113cbf091fc26fb7b1f99
- https://git.kernel.org/stable/c/3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7
- https://git.kernel.org/stable/c/4b9a086eedc1fddae632310386098c12155e3d0a
- https://git.kernel.org/stable/c/69541e58323ec3e3904e1fa87a6213961b1f52f4
- https://git.kernel.org/stable/c/8ebcd311b4866ab911d1445ead08690e67f0c488
- https://git.kernel.org/stable/c/ad17eb86d042d72a59fd184ad1adf34f5eb36843
- https://git.kernel.org/stable/c/f26fe7c3002516dd3c288f1012786df31f4d89e0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38147
In the Linux kernel, the following vulnerability has been resolved:
calipso: Don't call calipso functions for AF_INET sk.
syzkaller reported a null-ptr-deref in txopt_get(). [0]
The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,
so struct ipv6_pinfo was NULL there.
However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6
is always set in inet6_create(), meaning the socket was not IPv6 one.
The root cause is missing validation in netlbl_conn_setattr().
netlbl_conn_setattr() switches branches based on struct
sockaddr.sa_family, which is passed from userspace. However,
netlbl_conn_setattr() does not check if the address family matches
the socket.
The syzkaller must have called connect() for an IPv6 address on
an IPv4 socket.
We have a proper validation in tcp_v[46]_connect(), but
security_socket_connect() is called in the earlier stage.
Let's copy the validation to netlbl_conn_setattr().
[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]
RIP: 0010:
Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00
RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c
RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070
RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e
R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00
R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80
FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
- https://git.kernel.org/stable/c/0c813dbc851dbf418fdc6dc883fd0592d6c555cd
- https://git.kernel.org/stable/c/26ce90f1ce60b0ff587de8d6aec399aa55cab28e
- https://git.kernel.org/stable/c/6e9f2df1c550ead7cecb3e450af1105735020c92
- https://git.kernel.org/stable/c/946bfdfcb76ac2bac5b8526447035885ff41c598
- https://git.kernel.org/stable/c/c32ebe33626335a536dbbdd09571c06dd9bc1729
- https://git.kernel.org/stable/c/dd8928897594931d6912ef2f7a43e110b4958d3d
- https://git.kernel.org/stable/c/e2ec310c7a50271843c585e27ef14e48c66ce649
- https://git.kernel.org/stable/c/fc2da88411470480b8b7e9177e930cedd893cf56
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38148
In the Linux kernel, the following vulnerability has been resolved: net: phy: mscc: Fix memory leak when using one step timestamping Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping.
- https://git.kernel.org/stable/c/0b40aeaf83ca04d4c9801e235b7533400c8b5f17
- https://git.kernel.org/stable/c/24b24295464f25fb771d36ed558c7cd942119361
- https://git.kernel.org/stable/c/66abe22017522dd56b820e41ca3a5b131a637001
- https://git.kernel.org/stable/c/846992645b25ec4253167e3f931e4597eb84af56
- https://git.kernel.org/stable/c/cdbabd316c5a4a9b0fda6aafe491e2db17fbb95d
- https://git.kernel.org/stable/c/db2a12ddd3a31f668137ff6a4befc1343c79cbc4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38149
In the Linux kernel, the following vulnerability has been resolved: net: phy: clear phydev->devlink when the link is deleted There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted.
Modified: 2025-12-18
CVE-2025-38151
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work The cited commit fixed a crash when cma_netevent_callback was called for a cma_id while work on that id from a previous call had not yet started. The work item was re-initialized in the second call, which corrupted the work item currently in the work queue. However, it left a problem when queue_work fails (because the item is still pending in the work queue from a previous call). In this case, cma_id_put (which is called in the work handler) is therefore not called. This results in a userspace process hang (zombie process). Fix this by calling cma_id_put() if queue_work fails.
- https://git.kernel.org/stable/c/02e45168e0fd6fdc6f8f7c42c4b500857aa5efb0
- https://git.kernel.org/stable/c/1ac40736c8c4255d8417b937c9715b193f4a87b3
- https://git.kernel.org/stable/c/8b05aa3692e45b8249379dc52b14acc6a104d2e5
- https://git.kernel.org/stable/c/92a251c3df8ea1991cd9fe00f1ab0cfce18d7711
- https://git.kernel.org/stable/c/ac7897c0124066b9705ffca252a3662d54fc0c9b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38153
In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: fix error handling of usbnet read calls Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 ("net: asix: add proper error handling of usb read errors"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
- https://git.kernel.org/stable/c/11273279012c922f37cfb4dd95d142803fc07b98
- https://git.kernel.org/stable/c/30a9e834c74e260533b8d0885e3c89f6f32f7993
- https://git.kernel.org/stable/c/405b0d610745fb5e84fc2961d9b960abb9f3d107
- https://git.kernel.org/stable/c/60790d287c1a1ced3554d4a87c2f27bf299a932a
- https://git.kernel.org/stable/c/7c01863b1c47f040d9674171e77789a423b9b128
- https://git.kernel.org/stable/c/8c97655275482ef5384ce0501640630a0fc0f6f4
- https://git.kernel.org/stable/c/acb47a40b5e38be03ef659b7bacdddc592ed73b7
- https://git.kernel.org/stable/c/f398d2dfe450ce2c031d10b585448862d74a0501
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38154
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and
during the call to skb_send_sock(), there is a race condition with
the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)
will be affected.
Race conditions:
'''
CPU0 CPU1
backlog::skb_send_sock
sendmsg_unlocked
sock_sendmsg
sock_sendmsg_nosec
close(fd):
...
ops->release() -> sock_map_close()
sk_socket->ops = NULL
free(socket)
sock->ops->sendmsg
^
panic here
'''
The ref of psock become 0 after sock_map_close() executed.
'''
void sock_map_close()
{
...
if (likely(psock)) {
...
// !! here we remove psock and the ref of psock become 0
sock_map_remove_links(sk, psock)
psock = sk_psock_get(sk);
if (unlikely(!psock))
goto no_psock; <=== Control jumps here via goto
...
cancel_delayed_work_sync(&psock->work); <=== not executed
sk_psock_put(sk, psock);
...
}
'''
Based on the fact that we already wait for the workqueue to finish in
sock_map_close() if psock is held, we simply increase the psock
reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will
wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will
fail when invoked by sk_psock_get(), as the psock reference count have
been zeroed, and sk_psock_drop() will cancel all jobs via
cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread
and close() thread.
The panic I catched:
'''
Workqueue: events sk_psock_backlog
RIP: 0010:sock_sendmsg+0x21d/0x440
RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001
...
Call Trace:
- https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90
- https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7
- https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546
- https://git.kernel.org/stable/c/7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987
- https://git.kernel.org/stable/c/8259eb0e06d8f64c700f5fbdb28a5c18e10de291
- https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38155
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init().
Modified: 2025-11-20
CVE-2025-38156
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init()
Modified: 2025-12-18
CVE-2025-38157
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Abort software beacon handling if disabled A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled.
- https://git.kernel.org/stable/c/0281c19074976ec48f0078d50530b406ddae75bc
- https://git.kernel.org/stable/c/40471b23147c86ea3ed97faee79937c618250bd0
- https://git.kernel.org/stable/c/5482ef9875eaa43f0435e14570e1193823de857e
- https://git.kernel.org/stable/c/5a85c21f812e02cb00ca07007d88acdd42d08c46
- https://git.kernel.org/stable/c/7ee3fb6258da8c890a51b514f60d7570dc703605
- https://git.kernel.org/stable/c/ac4e317a95a1092b5da5b9918b7118759342641c
- https://git.kernel.org/stable/c/e5ce9df1d68094d37360dbd9b09289d42fa21e54
- https://git.kernel.org/stable/c/ee5ee646385f5846dcbc881389f3c44a197c402a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38158
In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: fix XQE dma address error The dma addresses of EQE and AEQE are wrong after migration and results in guest kernel-mode encryption services failure. Comparing the definition of hardware registers, we found that there was an error when the data read from the register was combined into an address. Therefore, the address combination sequence needs to be corrected. Even after fixing the above problem, we still have an issue where the Guest from an old kernel can get migrated to new kernel and may result in wrong data. In order to ensure that the address is correct after migration, if an old magic number is detected, the dma address needs to be updated.
- https://git.kernel.org/stable/c/7710c883eb8cb5cf510ca47ec0e26c6cb7e94a4f
- https://git.kernel.org/stable/c/809a9c10274e1bcf6d05f1c0341459a425a4f05f
- https://git.kernel.org/stable/c/884a76e813178778d271fea59783763d32bb7e72
- https://git.kernel.org/stable/c/8bb7170c5a055ea17c6857c256ee73c10ff872eb
- https://git.kernel.org/stable/c/f0423873e7aeb69cb68f4e8fa3827832e7b037ba
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38159
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace.
- https://git.kernel.org/stable/c/1ee8ea6937d13b20f90ff35d71ccc03ba448182d
- https://git.kernel.org/stable/c/4c2c372de2e108319236203cce6de44d70ae15cd
- https://git.kernel.org/stable/c/68a1037f0bac4de9a585aa9c879ef886109f3647
- https://git.kernel.org/stable/c/74e18211c2c89ab66c9546baa7408288db61aa0d
- https://git.kernel.org/stable/c/9febcc8bded8be0d7efd8237fcef599b6d93b788
- https://git.kernel.org/stable/c/c13255389499275bc5489a0b5b7940ccea3aef04
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38160
In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() 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/0a2712cd24ecfeb520af60f6f859b442c7ab01ff
- https://git.kernel.org/stable/c/1b69a5299f28ce8e6afa37c3690dbc14c3a1f53f
- https://git.kernel.org/stable/c/3c1adc2f8c732ea09e8c4bce5941fec019c6205d
- https://git.kernel.org/stable/c/52562161df3567cdaedada46834a7a8d8c4ab737
- https://git.kernel.org/stable/c/54ce9bcdaee59d4ef0703f390d55708557818f9e
- https://git.kernel.org/stable/c/73c46d9a93d071ca69858dea3f569111b03e549e
- https://git.kernel.org/stable/c/938f625bd3364cfdc93916739add3b637ff90368
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38161
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8
- https://git.kernel.org/stable/c/0a7790cbba654e925243571cf2f24d61603d3ed3
- https://git.kernel.org/stable/c/26d2f662d3a6655a82fd8a287e8b1ce471567f36
- https://git.kernel.org/stable/c/50ac361ff8914133e3cf6ef184bac90c22cb8d79
- https://git.kernel.org/stable/c/5d2ea5aebbb2f3ebde4403f9c55b2b057e5dd2d6
- https://git.kernel.org/stable/c/7c4c84cdcc19e89d42f6bf117238e5471173423e
- https://git.kernel.org/stable/c/cf32affe6f3801cfb72a65e69c4bc7a8ee9be100
- https://git.kernel.org/stable/c/f9784da76ad7be66230e829e743bdf68a2c49e56
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-25
CVE-2025-38162
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: prevent overflow in lookup table allocation When calculating the lookup table size, ensure the following multiplication does not overflow: - desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case. - NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field. Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this. While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().
- https://git.kernel.org/stable/c/43fe1181f738295624696ae9ff611790edb65b5e
- https://git.kernel.org/stable/c/4c5c6aa9967dbe55bd017bb509885928d0f31206
- https://git.kernel.org/stable/c/91edc076439c9e2f34b176149f1c84a47a8ec32f
- https://git.kernel.org/stable/c/a9e757473561da93c6a4136f0e59aba91ec777fc
- https://git.kernel.org/stable/c/c1360ac8156c0a3f2385baef91d8d26fd9d39701
Modified: 2025-12-18
CVE-2025-38163
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sbi->total_valid_block_count syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.
- https://git.kernel.org/stable/c/05872a167c2cab80ef186ef23cc34a6776a1a30c
- https://git.kernel.org/stable/c/25f3776b58c1c45ad2e50ab4b263505b4d2378ca
- https://git.kernel.org/stable/c/49bc7bf38e42cfa642787e947f5721696ea73ac3
- https://git.kernel.org/stable/c/65b3f76592aed5a43c4d79375ac097acf975972b
- https://git.kernel.org/stable/c/6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d
- https://git.kernel.org/stable/c/a39cc43efc1bca74ed9d6cf9e60b995071f7d178
- https://git.kernel.org/stable/c/ccc28c0397f75a3ec9539cceed9db014d7b73869
- https://git.kernel.org/stable/c/f1b743c1955151bd392539b739a3ad155296be13
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-25
CVE-2025-38164
In the Linux kernel, the following vulnerability has been resolved:
f2fs: zone: fix to avoid inconsistence in between SIT and SSA
w/ below testcase, it will cause inconsistence in between SIT and SSA.
create_null_blk 512 2 1024 1024
mkfs.f2fs -m /dev/nullb0
mount /dev/nullb0 /mnt/f2fs/
touch /mnt/f2fs/file
f2fs_io pinfile set /mnt/f2fs/file
fallocate -l 4GiB /mnt/f2fs/file
F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT
CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84
Tainted: [O]=OOT_MODULE
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Call Trace:
Modified: 2025-12-18
CVE-2025-38165
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix panic when calling skb_linearize
The panic can be reproduced by executing the command:
./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000
Then a kernel panic was captured:
'''
[ 657.460555] kernel BUG at net/core/skbuff.c:2178!
[ 657.462680] Tainted: [W]=WARN
[ 657.463287] Workqueue: events sk_psock_backlog
...
[ 657.469610]
- https://git.kernel.org/stable/c/3d25fa2d7f127348c818e1dab9e58534f7ac56cc
- https://git.kernel.org/stable/c/4dba44333a11522df54b49aa1f2edfaf6ce35fc7
- https://git.kernel.org/stable/c/5ca2e29f6834c64c0e5a9ccf1278c21fb49b827e
- https://git.kernel.org/stable/c/9718ba6490732dbe70190d42c21deb1440834402
- https://git.kernel.org/stable/c/db1d15a26f21f97459508c42ae87cabe8d3afc3b
- https://git.kernel.org/stable/c/e9c1299d813fc04668042690f2c3cc76d013959a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38166
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix ktls panic with sockmap
[ 2172.936997] ------------[ cut here ]------------
[ 2172.936999] kernel BUG at lib/iov_iter.c:629!
......
[ 2172.944996] PKRU: 55555554
[ 2172.945155] Call Trace:
[ 2172.945299]
- https://git.kernel.org/stable/c/2e36a81d388ec9c3f78b6223f7eda2088cd40adb
- https://git.kernel.org/stable/c/328cac3f9f8ae394748485e769a527518a9137c8
- https://git.kernel.org/stable/c/54a3ecaeeeae8176da8badbd7d72af1017032c39
- https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7
- https://git.kernel.org/stable/c/603943f022a7fe5cc83ca7005faf34798fb7853f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38167
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: handle hdr_first_de() return value The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/2d5879f64554181b89f44d4817b9ea86e8e913e1
- https://git.kernel.org/stable/c/4ecd0cde89feee26525ccdf1af0c1ae156ca010b
- https://git.kernel.org/stable/c/5390b3d4c6d41d05bb9149d094d504cbc9ea85bf
- https://git.kernel.org/stable/c/701340a25b1ad210e6b8192195be21fd3fcc22c7
- https://git.kernel.org/stable/c/83cd0aa74793384dbdffc140500b200e9776a302
- https://git.kernel.org/stable/c/af5cab0e5b6f8edb0be51a9f47f3f620e0b4fd70
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38168
In the Linux kernel, the following vulnerability has been resolved: perf: arm-ni: Unregister PMUs on probe failure When a resource allocation fails in one clock domain of an NI device, we need to properly roll back all previously registered perf PMUs in other clock domains of the same device. Otherwise, it can lead to kernel panics. Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374 arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000 arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16 list_add corruption: next->prev should be prev (fffffd01e9698a18), but was 0000000000000000. (next=ffff10001a0decc8). pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : list_add_valid_or_report+0x7c/0xb8 lr : list_add_valid_or_report+0x7c/0xb8 Call trace: __list_add_valid_or_report+0x7c/0xb8 perf_pmu_register+0x22c/0x3a0 arm_ni_probe+0x554/0x70c [arm_ni] platform_probe+0x70/0xe8 really_probe+0xc6/0x4d8 driver_probe_device+0x48/0x170 __driver_attach+0x8e/0x1c0 bus_for_each_dev+0x64/0xf0 driver_add+0x138/0x260 bus_add_driver+0x68/0x138 __platform_driver_register+0x2c/0x40 arm_ni_init+0x14/0x2a [arm_ni] do_init_module+0x36/0x298 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception SMP: stopping secondary CPUs
Modified: 2025-11-20
CVE-2025-38169
In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP On system with SME, a thread's kernel FPSIMD state may be erroneously clobbered during a context switch immediately after that state is restored. Systems without SME are unaffected. If the CPU happens to be in streaming SVE mode before a context switch to a thread with kernel FPSIMD state, fpsimd_thread_switch() will restore the kernel FPSIMD state using fpsimd_load_kernel_state() while the CPU is still in streaming SVE mode. When fpsimd_thread_switch() subsequently calls fpsimd_flush_cpu_state(), this will execute an SMSTOP, causing an exit from streaming SVE mode. The exit from streaming SVE mode will cause the hardware to reset a number of FPSIMD/SVE/SME registers, clobbering the FPSIMD state. Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel FPSIMD state.
Modified: 2025-12-18
CVE-2025-38170
In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Discard stale CPU state when handling SME traps The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ]
- https://git.kernel.org/stable/c/43be952e885476dafb74aa832c0847b2f4f650c6
- https://git.kernel.org/stable/c/6103f9ba51a59afb5a0f32299c837377c5a5a693
- https://git.kernel.org/stable/c/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3
- https://git.kernel.org/stable/c/d3eaab3c70905c5467e5c4ea403053d67505adeb
- https://git.kernel.org/stable/c/de89368de3894a8db27caeb8fd902ba1c49f696a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38172
In the Linux kernel, the following vulnerability has been resolved: erofs: avoid using multiple devices with different type For multiple devices, both primary and extra devices should be the same type. `erofs_init_device` has already guaranteed that if the primary is a file-backed device, extra devices should also be regular files. However, if the primary is a block device while the extra device is a file-backed device, `erofs_init_device` will get an ENOTBLK, which is not treated as an error in `erofs_fc_get_tree`, and that leads to an UAF: erofs_fc_get_tree get_tree_bdev_flags(erofs_fc_fill_super) erofs_read_superblock erofs_init_device // sbi->dif0 is not inited yet, // return -ENOTBLK deactivate_locked_super free(sbi) if (err is -ENOTBLK) sbi->dif0.file = filp_open() // sbi UAF So if -ENOTBLK is hitted in `erofs_init_device`, it means the primary device must be a block device, and the extra device is not a block device. The error can be converted to -EINVAL.
Modified: 2025-12-18
CVE-2025-38173
In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0.
- https://git.kernel.org/stable/c/32d3e8049a8b60f18c5c39f5931bfb1130ac11c9
- https://git.kernel.org/stable/c/5e9666ac8b94c978690f937d59170c5237bd2c45
- https://git.kernel.org/stable/c/7894694b5d5b2ecfd7fb081d6f60b9e169ab4d13
- https://git.kernel.org/stable/c/78ea1ff6cb413a03ff6f7af4e28e24b4461a0965
- https://git.kernel.org/stable/c/8a4e047c6cc07676f637608a9dd675349b5de0a7
- https://git.kernel.org/stable/c/c064ae2881d839709bd72d484d5f2af157f46024
- https://git.kernel.org/stable/c/c9610dda42bd382a96f97e68825cb5f66cd9e1dc
- https://git.kernel.org/stable/c/e1cc69da619588b1488689fe3535a0ba75a2b0e7
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38267
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Do not trigger WARN_ON() due to a commit_overrun
When reading a memory mapped buffer the reader page is just swapped out
with the last page written in the write buffer. If the reader page is the
same as the commit buffer (the buffer that is currently being written to)
it was assumed that it should never have missed events. If it does, it
triggers a WARN_ON_ONCE().
But there just happens to be one scenario where this can legitimately
happen. That is on a commit_overrun. A commit overrun is when an interrupt
preempts an event being written to the buffer and then the interrupt adds
so many new events that it fills and wraps the buffer back to the commit.
Any new events would then be dropped and be reported as "missed_events".
In this case, the next page to read is the commit buffer and after the
swap of the reader page, the reader page will be the commit buffer, but
this time there will be missed events and this triggers the following
warning:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780
Modules linked in: kvm_intel kvm irqbypass
CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780
Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff <0f> 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50
RSP: 0018:ffff888121787dc0 EFLAGS: 00010002
RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49
RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8
RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982
R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00
R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008
FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0
Call Trace:
Modified: 2025-11-20
CVE-2025-38268
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous work A state check was previously added to tcpm_queue_vdm_unlocked to prevent a deadlock where the DisplayPort Alt Mode driver would be executing work and attempting to grab the tcpm_lock while the TCPM was holding the lock and attempting to unregister the altmode, blocking on the altmode driver's cancel_work_sync call. Because the state check isn't protected, there is a small window where the Alt Mode driver could determine that the TCPM is in a ready state and attempt to grab the lock while the TCPM grabs the lock and changes the TCPM state to one that causes the deadlock. The callstack is provided below: [110121.667392][ C7] Call trace: [110121.667396][ C7] __switch_to+0x174/0x338 [110121.667406][ C7] __schedule+0x608/0x9f0 [110121.667414][ C7] schedule+0x7c/0xe8 [110121.667423][ C7] kernfs_drain+0xb0/0x114 [110121.667431][ C7] __kernfs_remove+0x16c/0x20c [110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8 [110121.667442][ C7] sysfs_remove_group+0x84/0xe8 [110121.667450][ C7] sysfs_remove_groups+0x34/0x58 [110121.667458][ C7] device_remove_groups+0x10/0x20 [110121.667464][ C7] device_release_driver_internal+0x164/0x2e4 [110121.667475][ C7] device_release_driver+0x18/0x28 [110121.667484][ C7] bus_remove_device+0xec/0x118 [110121.667491][ C7] device_del+0x1e8/0x4ac [110121.667498][ C7] device_unregister+0x18/0x38 [110121.667504][ C7] typec_unregister_altmode+0x30/0x44 [110121.667515][ C7] tcpm_reset_port+0xac/0x370 [110121.667523][ C7] tcpm_snk_detach+0x84/0xb8 [110121.667529][ C7] run_state_machine+0x4c0/0x1b68 [110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4 [110121.667544][ C7] kthread_worker_fn+0x10c/0x244 [110121.667552][ C7] kthread+0x104/0x1d4 [110121.667557][ C7] ret_from_fork+0x10/0x20 [110121.667689][ C7] Workqueue: events dp_altmode_work [110121.667697][ C7] Call trace: [110121.667701][ C7] __switch_to+0x174/0x338 [110121.667710][ C7] __schedule+0x608/0x9f0 [110121.667717][ C7] schedule+0x7c/0xe8 [110121.667725][ C7] schedule_preempt_disabled+0x24/0x40 [110121.667733][ C7] __mutex_lock+0x408/0xdac [110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24 [110121.667748][ C7] mutex_lock+0x40/0xec [110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4 [110121.667764][ C7] typec_altmode_enter+0xdc/0x10c [110121.667769][ C7] dp_altmode_work+0x68/0x164 [110121.667775][ C7] process_one_work+0x1e4/0x43c [110121.667783][ C7] worker_thread+0x25c/0x430 [110121.667789][ C7] kthread+0x104/0x1d4 [110121.667794][ C7] ret_from_fork+0x10/0x20 Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work, which can perform the state check while holding the TCPM lock while the Alt Mode lock is no longer held. This requires a new struct to hold the vdm data, altmode_vdm_event.
Modified: 2025-11-20
CVE-2025-38269
In the Linux kernel, the following vulnerability has been resolved: btrfs: exit after state insertion failure at btrfs_convert_extent_bit() If insert_state() state failed it returns an error pointer and we call extent_io_tree_panic() which will trigger a BUG() call. However if CONFIG_BUG is disabled, which is an uncommon and exotic scenario, then we fallthrough and call cache_state() which will dereference the error pointer, resulting in an invalid memory access. So jump to the 'out' label after calling extent_io_tree_panic(), it also makes the code more clear besides dealing with the exotic scenario where CONFIG_BUG is disabled.
Modified: 2025-11-20
CVE-2025-38270
In the Linux kernel, the following vulnerability has been resolved: net: drv: netdevsim: don't napi_complete() from netpoll netdevsim supports netpoll. Make sure we don't call napi_complete() from it, since it may not be scheduled. Breno reports hitting a warning in napi_complete_done(): WARNING: CPU: 14 PID: 104 at net/core/dev.c:6592 napi_complete_done+0x2cc/0x560 __napi_poll+0x2d8/0x3a0 handle_softirqs+0x1fe/0x710 This is presumably after netpoll stole the SCHED bit prematurely.
Modified: 2025-12-18
CVE-2025-38273
In the Linux kernel, the following vulnerability has been resolved: net: tipc: fix refcount warning in tipc_aead_encrypt syzbot reported a refcount warning [1] caused by calling get_net() on a network namespace that is being destroyed (refcount=0). This happens when a TIPC discovery timer fires during network namespace cleanup. The recently added get_net() call in commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") attempts to hold a reference to the network namespace. However, if the namespace is already being destroyed, its refcount might be zero, leading to the use-after-free warning. Replace get_net() with maybe_get_net(), which safely checks if the refcount is non-zero before incrementing it. If the namespace is being destroyed, return -ENODEV early, after releasing the bearer reference. [1]: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2
- https://git.kernel.org/stable/c/307391e8fe70401a6d39ecc9978e13c2c0cdf81f
- https://git.kernel.org/stable/c/445d59025d76d0638b03110f8791d5b89ed5162d
- https://git.kernel.org/stable/c/9ff60e0d9974dccf24e89bcd3ee7933e538d929f
- https://git.kernel.org/stable/c/acab7ca5ff19889b80a8ee7dec220ee1a96dede9
- https://git.kernel.org/stable/c/c762fc79d710d676b793f9d98b1414efe6eb51e6
- https://git.kernel.org/stable/c/e0b11227c4e8eb4bdf1b86aa8f0f3abb24e0f029
- https://git.kernel.org/stable/c/f29ccaa07cf3d35990f4d25028cc55470d29372b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38274
In the Linux kernel, the following vulnerability has been resolved: fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt() fpga_mgr_test_img_load_sgt() allocates memory for sgt using kunit_kzalloc() however it does not check if the allocation failed. It then passes sgt to sg_alloc_table(), which passes it to __sg_alloc_table(). This function calls memset() on sgt in an attempt to zero it out. If the allocation fails then sgt will be NULL and the memset will trigger a NULL pointer dereference. Fix this by checking the allocation with KUNIT_ASSERT_NOT_ERR_OR_NULL().
Modified: 2025-12-18
CVE-2025-38275
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling.
- https://git.kernel.org/stable/c/0b979a409e40457ca1b5cb48755d1f34eee58805
- https://git.kernel.org/stable/c/0c33117f00c8c5363c22676931b22ae5041f7603
- https://git.kernel.org/stable/c/127dfb4f1c5a2b622039c5d203f321380ea36665
- https://git.kernel.org/stable/c/5072c1749197fc28b27d7efc0d80320d7cac9572
- https://git.kernel.org/stable/c/d14402a38c2d868cacb1facaf9be908ca6558e59
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38277
In the Linux kernel, the following vulnerability has been resolved: mtd: nand: ecc-mxic: Fix use of uninitialized variable ret If ctx->steps is zero, the loop processing ECC steps is skipped, and the variable ret remains uninitialized. It is later checked and returned, which leads to undefined behavior and may cause unpredictable results in user space or kernel crashes. This scenario can be triggered in edge cases such as misconfigured geometry, ECC engine misuse, or if ctx->steps is not validated after initialization. Initialize ret to zero before the loop to ensure correct and safe behavior regardless of the ctx->steps value. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/49482f4a39620f6afedcd3f6aa9e0d558b6a460b
- https://git.kernel.org/stable/c/4d9d6e4be09472aa72953caca3dbefdc27846170
- https://git.kernel.org/stable/c/7a23cc510ecaabab4f6df7e9d910d16e279b72ad
- https://git.kernel.org/stable/c/a0d9d9b5a4634e146ae41cb25667322e5c7d74d2
- https://git.kernel.org/stable/c/d95846350aac72303036a70c4cdc69ae314aa26d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38278
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callback This patch addresses below issues, 1. Active traffic on the leaf node must be stopped before its send queue is reassigned to the parent. This patch resolves the issue by marking the node as 'Inner'. 2. During a system reboot, the interface receives TC_HTB_LEAF_DEL and TC_HTB_LEAF_DEL_LAST callbacks to delete its HTB queues. In the case of TC_HTB_LEAF_DEL_LAST, although the same send queue is reassigned to the parent, the current logic still attempts to update the real number of queues, leadning to below warnings New queues can't be registered after device unregistration. WARNING: CPU: 0 PID: 6475 at net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200
Modified: 2025-12-18
CVE-2025-38280
In the Linux kernel, the following vulnerability has been resolved:
bpf: Avoid __bpf_prog_ret0_warn when jit fails
syzkaller reported an issue:
WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Modules linked in:
CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39
RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Call Trace:
- https://git.kernel.org/stable/c/0b9bb52796b239de6792d0d68cdc6eb505ebff96
- https://git.kernel.org/stable/c/2bc6dffb4b72d53d6a6ada510269bf548c3f7ae0
- https://git.kernel.org/stable/c/6f639c25bfad17d9fd7379ab91ff9678ea9aac85
- https://git.kernel.org/stable/c/86bc9c742426a16b52a10ef61f5b721aecca2344
- https://git.kernel.org/stable/c/e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66
- https://git.kernel.org/stable/c/ef92b96530d1731d9ac167bc7c193c683cd78fff
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38282
In the Linux kernel, the following vulnerability has been resolved: kernfs: Relax constraint in draining guard The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong: kernfs_remove_by_name_ns kernfs_get_active // active=1 __kernfs_remove // active=0x80000002 kernfs_drain ... wait_event //waiting (active == 0x80000001) kernfs_break_active_protection // active = 0x80000001 // continue kernfs_unbreak_active_protection // active = 0x80000002 ... kernfs_should_drain_open_files // warning occurs kernfs_put_active To avoid the false positives (mind panic_on_warn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.)
- https://git.kernel.org/stable/c/071d8e4c2a3b0999a9b822e2eb8854784a350f8a
- https://git.kernel.org/stable/c/2d6a67c2b3b87808a347dc1047b520a9dd177a4f
- https://git.kernel.org/stable/c/6bfb154f95d5f0ab7ed056f23aba8c1a94cb3927
- https://git.kernel.org/stable/c/6c81f1c7812c61f187bed1b938f1d2e391d503ab
- https://git.kernel.org/stable/c/72275c888f8962b406ee9c6885c79bf68cca5a63
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38283
In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: bugfix live migration function without VF device driver If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors. Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.
Modified: 2025-12-18
CVE-2025-38285
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861
Modules linked in:
CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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
RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861
RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c
RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005
RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003
R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004
R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900
FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/147ea936fc6fa8fe0c93f0df918803a5375ca535
- https://git.kernel.org/stable/c/18e8cbbae79cb35bdce8a01c889827b9799c762e
- https://git.kernel.org/stable/c/3880cdbed1c4607e378f58fa924c5d6df900d1d3
- https://git.kernel.org/stable/c/44ebe361abb322d2afd77930fa767a99f271c4d1
- https://git.kernel.org/stable/c/6d8f39875a10a194051c3eaefebc7ac06a34aaf3
- https://git.kernel.org/stable/c/c98cdf6795a36bca163ebb40411fef1687b9eb13
- https://git.kernel.org/stable/c/e167414beabb1e941fe563a96becc98627d5bdf6
- https://git.kernel.org/stable/c/ee90be48edb3dac612e0b7f5332482a9e8be2696
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38286
In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91: Fix possible out-of-boundary access at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks.
- https://git.kernel.org/stable/c/264a5cf0c422e65c94447a1ebebfac7c92690670
- https://git.kernel.org/stable/c/288c39286f759314ee8fb3a80a858179b4f306da
- https://git.kernel.org/stable/c/2ecafe59668d2506a68459a9d169ebe41a147a41
- https://git.kernel.org/stable/c/762ef7d1e6eefad9896560bfcb9bcf7f1b6df9c1
- https://git.kernel.org/stable/c/db5665cbfd766db7d8cd0e5fd6e3c0b412916774
- https://git.kernel.org/stable/c/e02e12d6a7ab76c83849a4122785650dc7edef65
- https://git.kernel.org/stable/c/eb435bc4c74acbb286cec773deac13d117d3ef39
- https://git.kernel.org/stable/c/f1c1fdc41fbf7e308ced9c86f3f66345a3f6f478
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38288
In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix smp_processor_id() call trace for preemptible kernels
Correct kernel call trace when calling smp_processor_id() when called in
preemptible kernels by using raw_smp_processor_id().
smp_processor_id() checks to see if preemption is disabled and if not,
issue an error message followed by a call to dump_stack().
Brief example of call trace:
kernel: check_preemption_disabled: 436 callbacks suppressed
kernel: BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/u1025:0/2354
kernel: caller is pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0
kernel: ...
kernel: Workqueue: writeback wb_workfn (flush-253:0)
kernel: Call Trace:
kernel:
Modified: 2025-11-19
CVE-2025-38290
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath12k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute normally. Call trace: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Modified: 2025-11-19
CVE-2025-38292
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix invalid access to memory In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only.
Modified: 2025-12-18
CVE-2025-38293
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
- https://git.kernel.org/stable/c/31e98e277ae47f56632e4d663b1d4fd12ba33ea8
- https://git.kernel.org/stable/c/6c139015b597e570dd5962934e9f9a2f4cc8ef48
- https://git.kernel.org/stable/c/6d6cb27fe146061f2512e904618f5e005bb7bb6a
- https://git.kernel.org/stable/c/b0974ed82e6ad5ff246fd90a5b14f3e7be4f2924
- https://git.kernel.org/stable/c/f50ba7e7b607f2d00618799312e7fdb76a1ff48e
- https://git.kernel.org/stable/c/f5d77d0d41ea7a204d47288d0cf0404a52b5890e
- https://git.kernel.org/stable/c/f9507cf2dd0e1ed5028c0e8240da6fe5fd3110d3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38295
In the Linux kernel, the following vulnerability has been resolved: perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create() The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses smp_processor_id(), which assumes disabled preemption. This leads to kernel warnings during module loading because meson_ddr_pmu_create() can be called in a preemptible context. Following kernel warning and stack trace: [ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289 [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38 [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0 [ 31.745181] [ T2289] Tainted: [W]=WARN [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT) [ 31.745188] [ T2289] Call trace: [ 31.745191] [ T2289] show_stack+0x28/0x40 (C) [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198 [ 31.745205] [ T2289] dump_stack+0x20/0x50 [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0 [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38 [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745246] [ T2289] platform_probe+0x98/0xe0 [ 31.745254] [ T2289] really_probe+0x144/0x3f8 [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180 [ 31.745261] [ T2289] driver_probe_device+0x54/0x268 [ 31.745264] [ T2289] __driver_attach+0x11c/0x288 [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160 [ 31.745274] [ T2289] driver_attach+0x34/0x50 [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0 [ 31.745281] [ T2289] driver_register+0x78/0x120 [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48 [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438 [ 31.745303] [ T2289] do_init_module+0x68/0x228 [ 31.745311] [ T2289] load_module+0x118c/0x13a8 [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390 [ 31.745320] [ T2289] invoke_syscall+0x74/0x108 [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8 [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48 [ 31.745333] [ T2289] el0_svc+0x60/0x150 [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118 [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0 Changes replaces smp_processor_id() with raw_smp_processor_id() to ensure safe CPU ID retrieval in preemptible contexts.
Modified: 2025-11-19
CVE-2025-38297
In the Linux kernel, the following vulnerability has been resolved: PM: EM: Fix potential division-by-zero error in em_compute_costs() When the device is of a non-CPU type, table[i].performance won't be initialized in the previous em_init_performance(), resulting in division by zero when calculating costs in em_compute_costs(). Since the 'cost' algorithm is only used for EAS energy efficiency calculations and is currently not utilized by other device drivers, we should add the _is_cpu_device(dev) check to prevent this division-by-zero issue.
Modified: 2025-12-19
CVE-2025-38298
In the Linux kernel, the following vulnerability has been resolved:
EDAC/skx_common: Fix general protection fault
After loading i10nm_edac (which automatically loads skx_edac_common), if
unload only i10nm_edac, then reload it and perform error injection testing,
a general protection fault may occur:
mce: [Hardware Error]: Machine check events logged
Oops: general protection fault ...
...
Workqueue: events mce_gen_pool_process
RIP: 0010:string+0x53/0xe0
...
Call Trace:
- https://git.kernel.org/stable/c/20d2d476b3ae18041be423671a8637ed5ffd6958
- https://git.kernel.org/stable/c/31ef6f7c9aee3be78d63789653e92350f2537f93
- https://git.kernel.org/stable/c/3f5d0659000923735350da60ad710f8c804544fe
- https://git.kernel.org/stable/c/80bf28fd623d97dd4f4825fbbe9d736cec2afba3
- https://git.kernel.org/stable/c/a13e8343ffcff27af1ff79597ff7ba241e6d9471
- https://git.kernel.org/stable/c/a6ed3a6edff09c1187cc6ade7f5967bca2376a13
- https://git.kernel.org/stable/c/bf6a8502a5f4ff6e4d135d795945cdade49ec8b0
- https://git.kernel.org/stable/c/e8530ed3c0769a4d8f79c212715ec1cf277787f8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38299
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY() ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(), in the case the codec dai_name will be null. Avoid a crash if the device tree is not assigning a codec to these links. [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]---
Modified: 2025-12-19
CVE-2025-38300
In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- To fix this, check for !dma_mapping_error() before calling dma_unmap_single() on the "theend_iv" path.
- https://git.kernel.org/stable/c/19d267d9fad00d94ad8477899e38ed7c11f33fb6
- https://git.kernel.org/stable/c/4051250e5db489f8ad65fc337e2677b9b568ac72
- https://git.kernel.org/stable/c/a0ac3f85b2e3ef529e852f252a70311f9029d5e6
- https://git.kernel.org/stable/c/c62b79c1c51303dbcb6edfa4de0ee176f4934c52
- https://git.kernel.org/stable/c/f31adc3e356f7350d4a4d68c98d3f60f2f6e26b3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38301
In the Linux kernel, the following vulnerability has been resolved: nvmem: zynqmp_nvmem: unbreak driver after cleanup Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed.
Modified: 2025-11-19
CVE-2025-38302
In the Linux kernel, the following vulnerability has been resolved: block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work Bios queued up in the zone write plug have already gone through all all preparation in the submit_bio path, including the freeze protection. Submitting them through submit_bio_noacct_nocheck duplicates the work and can can cause deadlocks when freezing a queue with pending bio write plugs. Go straight to ->submit_bio or blk_mq_submit_bio to bypass the superfluous extra freeze protection and checks.
Modified: 2026-04-11
CVE-2025-38303
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.
Modified: 2025-12-19
CVE-2025-38304
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA.
- https://git.kernel.org/stable/c/20a2aa01f5aeb6daad9aeaa7c33dd512c58d81eb
- https://git.kernel.org/stable/c/497c9d2d7d3983826bb02c10fb4a5818be6550fb
- https://git.kernel.org/stable/c/4bf29910570666e668a60d953f8da78e95bb7fa2
- https://git.kernel.org/stable/c/7d99cc0f8e6fa0f35570887899f178122a61d44e
- https://git.kernel.org/stable/c/842f7c3154d5b25ca11753c02ee8cf6ee64c0142
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38305
In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking.
- https://git.kernel.org/stable/c/259119595227fd20f6aa29d85abe086b6fdd9eb1
- https://git.kernel.org/stable/c/5d217e7031a5c06d366580fc6ddbf43527b780d4
- https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf1006795157a2
- https://git.kernel.org/stable/c/b1b73c452331451020be3bf4b014901015ae6663
- https://git.kernel.org/stable/c/b93e6fef4eda48e17d9c642b9abad98a066fd4a3
- https://git.kernel.org/stable/c/ef8fc007c28a30a4c0d90bf755e0f343d99bb392
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38307
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Verify content returned by parse_int_array() The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref.
Modified: 2025-12-19
CVE-2025-38310
In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one.
- https://git.kernel.org/stable/c/668923c474608dd9ebce0fbcc41bd8a27aa73dd6
- https://git.kernel.org/stable/c/7632fedb266d93ed0ed9f487133e6c6314a9b2d1
- https://git.kernel.org/stable/c/cd4cd09810211fa23609c5c1018352e9e1cd8e5a
- https://git.kernel.org/stable/c/cef33a86bcb04ecf4dc10c56f6c42ee9d1c54bac
- https://git.kernel.org/stable/c/d2507aeea45b3c5aa24d5daae0cf3db76895c0b7
- https://git.kernel.org/stable/c/d5d9fd13bc19a3f9f2a951c5b6e934d84205789e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38312
In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
- https://git.kernel.org/stable/c/2d63433e8eaa3c91b2948190e395bc67009db0d9
- https://git.kernel.org/stable/c/3f6dae09fc8c306eb70fdfef70726e1f154e173a
- https://git.kernel.org/stable/c/53784073cbad18f75583fd3da9ffdfc4d1f05405
- https://git.kernel.org/stable/c/54947530663edcbaaee1314c01fdd8c72861b124
- https://git.kernel.org/stable/c/610f247f2772e4f92b63442125a1b7ade79898d8
- https://git.kernel.org/stable/c/9027ce4c037b566b658b8939a76326b7125e3627
- https://git.kernel.org/stable/c/ab91647acdf43b984824776559a452212eaeb21a
- https://git.kernel.org/stable/c/b235393b9f43ff86a38ca2bde6372312ea215dc5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38313
In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);
- https://git.kernel.org/stable/c/12e4431e5078847791936820bd39df9e1ee26d2e
- https://git.kernel.org/stable/c/1d5baab39e5b09a76870b345cdee7933871b881f
- https://git.kernel.org/stable/c/3135e03a92f6b5259d0a7f25f728e9e7866ede3f
- https://git.kernel.org/stable/c/4b23c46eb2d88924b93aca647bde9a4b9cf62cf9
- https://git.kernel.org/stable/c/7002b954c4a8b9965ba0f139812ee4a6f71beac8
- https://git.kernel.org/stable/c/873d47114fd5e5a1cad2018843671537cc71ac84
- https://git.kernel.org/stable/c/b2057374f326303c86d8423415ab58656eebc695
- https://git.kernel.org/stable/c/d694bf8a9acdbd061596f3e7549bc8cb70750a60
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38315
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Check dsbr size from EFI variable Since the size of struct btintel_dsbr is already known, we can just start there instead of querying the EFI variable size. If the final result doesn't match what we expect also fail. This fixes a stack buffer overflow when the EFI variable is larger than struct btintel_dsbr.
Modified: 2025-11-18
CVE-2025-38317
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix buffer overflow in debugfs If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users.
Modified: 2025-11-18
CVE-2025-38318
In the Linux kernel, the following vulnerability has been resolved: perf: arm-ni: Fix missing platform_set_drvdata() Add missing platform_set_drvdata in arm_ni_probe(), otherwise calling platform_get_drvdata() in remove returns NULL.
Modified: 2025-12-19
CVE-2025-38319
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.
- https://git.kernel.org/stable/c/64f3acc8c7e6809631457b75638601b36dea3129
- https://git.kernel.org/stable/c/7080c20a9139842033ed4af604dc1fa4028593ad
- https://git.kernel.org/stable/c/820116a39f96bdc7d426c33a804b52f53700a919
- https://git.kernel.org/stable/c/85cdcb834fb490731ff2d123f87ca799c57dacf2
- https://git.kernel.org/stable/c/a4ff7391c8b75b1541900bd9d0c238e558c11fb3
- https://git.kernel.org/stable/c/cdf7e1ff99ab06ef15d0b5d1aca5258a4fb62b85
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-08
CVE-2025-38352
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case.
- https://git.kernel.org/stable/c/2c72fe18cc5f9f1750f5bc148cf1c94c29e106ff
- https://git.kernel.org/stable/c/2f3daa04a9328220de46f0d5c919a6c0073a9f0b
- https://git.kernel.org/stable/c/460188bc042a3f40f72d34b9f7fc6ee66b0b757b
- https://git.kernel.org/stable/c/764a7a5dfda23f69919441f2eac2a83e7db6e5bb
- https://git.kernel.org/stable/c/78a4b8e3795b31dae58762bc091bb0f4f74a2200
- https://git.kernel.org/stable/c/c076635b3a42771ace7d276de8dc3bc76ee2ba1b
- https://git.kernel.org/stable/c/c29d5318708e67ac13c1b6fc1007d179fb65b4d7
- https://git.kernel.org/stable/c/f90fff1e152dedf52b932240ebbd670d83330eca
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
- https://github.com/farazsth98/chronomaly
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-38352
Modified: 2025-11-19
CVE-2025-38414
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms. Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Modified: 2025-12-23
CVE-2025-38415
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize().
- https://git.kernel.org/stable/c/0aff95d9bc7fb5400ca8af507429c4b067bdb425
- https://git.kernel.org/stable/c/295ab18c2dbce8d0ac6ecf7c5187e16e1ac8b282
- https://git.kernel.org/stable/c/4f99357dadbf9c979ad737156ad4c37fadf7c56b
- https://git.kernel.org/stable/c/549f9e3d7b60d53808c98b9fde49b4f46d0524a5
- https://git.kernel.org/stable/c/5c51aa862cbeed2f3887f0382a2708956710bd68
- https://git.kernel.org/stable/c/6abf6b78c6fb112eee495f5636ffcc350dd2ce25
- https://git.kernel.org/stable/c/734aa85390ea693bb7eaf2240623d41b03705c84
- https://git.kernel.org/stable/c/db7096ea160e40d78c67fce52e7cc51bde049497
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38498
In the Linux kernel, the following vulnerability has been resolved: do_change_type(): refuse to operate on unmounted/not ours mounts Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2).
- https://git.kernel.org/stable/c/064014f7812744451d5d0592f3d2bcd727f2ee93
- https://git.kernel.org/stable/c/12f147ddd6de7382dad54812e65f3f08d05809fc
- https://git.kernel.org/stable/c/19554c79a2095ddde850906a067915c1ef3a4114
- https://git.kernel.org/stable/c/432a171d60056489270c462e651e6c3a13f855b1
- https://git.kernel.org/stable/c/4f091ad0862b02dc42a19a120b7048de848561f8
- https://git.kernel.org/stable/c/787937c4e373f1722c4343e5a5a4eb0f8543e589
- https://git.kernel.org/stable/c/9c1ddfeb662b668fff69c5f1cfdd9f5d23d55d23
- https://git.kernel.org/stable/c/c7d11fdf8e5db5f34a6c062c7e6ba3a0971879d2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-14
CVE-2025-39890
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps is not freed in the failure case, causing a memory leak. The following trace is observed in kmemleak: unreferenced object 0xffff8b3eb5789c00 (size 1024): comm "softirq", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): __kmalloc_noprof+0x30b/0x410 ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k] ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k] ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k] ath12k_ce_recv_process_cb+0x218/0x300 [ath12k] ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k] process_one_work+0x219/0x680 bh_worker+0x198/0x1f0 tasklet_action+0x13/0x30 handle_softirqs+0xca/0x460 __irq_exit_rcu+0xbe/0x110 irq_exit_rcu+0x9/0x30 Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Closed bugs
Отсутствует модуль для поддержки mt7925
