ALT-PU-2024-6668-7
Package kernel-image-un-def updated to version 6.1.85-alt0.c10f.1 for branch c10f1 in task 344900.
Closed vulnerabilities
Modified: 2024-11-11
BDU:2023-02526
Уязвимость драйвера Infiniband ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-10-29
BDU:2024-00896
Уязвимость функции raid5_cache_count() (drivers/md/raid5.c) драйвера RAID ядра операционной системы Linux, связанная с целочисленным переполнением, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-11
BDU:2024-01602
Уязвимость функций crypto_aead_encrypt и crypto_aead_decrypt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-01673
Уязвимость функции smb2_parse_contexts() в модуле fs/smb/client/smb2pdu.c клиента SMB ядра операционной системы Linux , позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-12-06
BDU:2024-01751
Уязвимость функции __thp_get_unmapped_area() подсистемы управления памятью на 32-битных системах ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03636
Уязвимость функции nfs_direct_commit_schedule() в модуле fs/nfs/direct.c сетевой файловой системы Network File System (NFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03637
Уязвимость функции free_swap_and_cache() в модуле mm/swapfile.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-06
BDU:2024-03639
Уязвимость функции max310x_i2c_probe() в модуле drivers/tty/serial/max310x.c драйвера max310x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03642
Уязвимость функции mtk_spi_interrupt() в модуле drivers/spi/spi-mt65xx.c драйвера Mediatek SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03643
Уязвимость функции dvb_register_device() в модуле drivers/media/dvb-core/dvbdev.c драйвера DVB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-16
BDU:2024-03663
Уязвимость функции stack_map_alloc() в модуле kernel/bpf/stackmap.c подсистемы BPF ядра операционной системы Linux на 32-битных архитектурах, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-26
BDU:2024-03664
Уязвимость функции htab_map_alloc() в модуле kernel/bpf/hashtab.c подсистемы BPF ядра операционной системы Linux на 32-битных архитектурах, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03665
Уязвимость функции dev_map_init_map() в модуле kernel/bpf/devmap.c подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-03666
Уязвимость функции set_eth_seg() в модуле drivers/infiniband/hw/mlx5/wr.c драйвера Mellanox 5-го поколения сетевых адаптеров (серии ConnectX) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-12
BDU:2024-03667
Уязвимость функции sof_ipc3_fw_parse_ext_man() в модуле sound/soc/sof/ipc3-loader.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03668
Уязвимость функции cifs_debug_files_proc_show() в модуле fs/smb/client/cifs_debug.c подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03671
Уязвимость функции mac802154_llsec_key_del() в модуле net/mac802154/llsec.c подсистемы беспроводной связи ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и целостность защищаемой информации, или вызвать отказ в обслуживании
Modified: 2024-10-24
BDU:2024-03676
Уязвимость функции sk_psock_verdict_data_ready() в модуле net/core/skmsg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03678
Уязвимость функции seg6_init() в модуле net/ipv6/seg6.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03679
Уязвимость функции cdns3_gadget_giveback() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера USB Cadence ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-03680
Уязвимость функции cdns3_gadget_ep_disable() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера USB Cadence ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2024-11-26
BDU:2024-03681
Уязвимость функции gtp_init() в модуле drivers/net/gtp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03682
Уязвимость функции mptcp_sk_clone_init() в модуле net/mptcp/protocol.c реализации протокола Multipath TCP (MPTCP) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-03684
Уязвимость функции btrfs_get_root_ref() в модуле fs/btrfs/disk-io.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03685
Уязвимость функции gtp_init() в модуле drivers/net/gtp.c реализации протокола GPRS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03686
Уязвимость функции hci_error_reset() в модуле net/bluetooth/hci_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-03695
Уязвимость функции tcp_twsk_purge() в модуле net/ipv4/tcp_minisocks.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03696
Уязвимость функции sparx5_del_mact_entry() в модуле drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c драйвера sparx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03697
Уязвимость функции bnx2x_set_fw_mac_addr() в модуле drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h драйвера Broadcom NetXtremeII 10Gb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03700
Уязвимость функции wilc_netdev_cleanup() в модуле drivers/net/wireless/microchip/wilc1000/netdev.c драйвера Atmel WILC1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03701
Уязвимость функции dm_sw_fini() в модуле drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-10-24
BDU:2024-03702
Уязвимость функции smc_chan_free() в модуле drivers/firmware/arm_scmi/smc.c реализации протокола ARM System Control and Management Interface (SCMI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-03703
Уязвимость функции inet_frag_reasm_prepare() в модуле net/ipv4/inet_fragment.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03708
Уязвимость функции ip_tunnel_rcv() в модуле net/ipv4/ip_tunnel.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-03747
Уязвимость функции run_spu_dma() в модуле sound/sh/aica.c звуковой подсистемы (ALSA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-01
BDU:2024-03753
Уязвимость функции taprio_parse_tc_entry() в модуле net/sched/sch_taprio.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-03754
Уязвимость функции print_absolute_relocs() ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-05-06
BDU:2024-03763
Уязвимость функции sr9800_bind() в модуле drivers/net/usb/sr9800.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03771
Уязвимость функции nf_tables_unbind_set() в модуле net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2024-03939
Уязвимость функции xennet_alloc_one_rx_buffer() ядра операционной системы Linux, позволяющая нарушителю вызвыать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03941
Уязвимость функции io_uring_get_file() подсистемы io_uring ядра Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-04137
Уязвимость функции tomoyo_write_control() подсистемы безопасности TOMOYO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-04219
Уязвимость функции cifs_stats_proc_write() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04220
Уязвимость функции cifs_stats_proc_show() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-04222
Уязвимость функции smb2_is_valid_oplock_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04223
Уязвимость функции smb2_is_valid_lease_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04224
Уязвимость функции is_valid_oplock_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04225
Уязвимость функции smb2_is_network_name_deleted() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04226
Уязвимость функции cifs_signal_cifsd_for_reconnect() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-12
BDU:2024-04229
Уязвимость функции brcmf_notify_escan_complete() драйвера Broadcom FullMAC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-04232
Уязвимость функции sev_mem_enc_register_region() компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-04233
Уязвимость функции optee_register_device() драйвера Trusted Execution Environment (TEE) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-04234
Уязвимость функции pep_ioctl() реализации протокола PhoNet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-04580
Уязвимость функций disable_{show,store}() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04581
Уязвимость функции interface_authorized_store() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06494
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06495
Уязвимость компонента rfcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06496
Уязвимость функции do_sys_name_to_handle() в компоненте kernel-infoleak ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06895
Уязвимость компонента drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c ядра операционной системы Linux, связанная с недостаточной обработкой форматной строки, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06899
Уязвимость компонента drivers/usb/gadget/function/f_ncm.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06900
Уязвимость драйвера AoE ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06989
Уязвимость компонента arch/x86/kernel/fpu/xstate.c ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-07642
Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08626
Уязвимость компонента cxl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08630
Уязвимость компонента target ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08633
Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08636
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08637
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08649
Уязвимость компонента nvmet-fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08661
Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии
Modified: 2026-01-20
BDU:2024-08664
Уязвимость компонента dm-crypt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08665
Уязвимость компонента l2tp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-08666
Уязвимость компонента ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08667
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08668
Уязвимость компонента srpt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08669
Уязвимость компонента qedr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08670
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08671
Уязвимость компонента afs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08672
Уязвимость компонента arp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08673
Уязвимость компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08674
Уязвимость компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-02
BDU:2024-08677
Уязвимость компонента rt5645 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08681
Уязвимость компонентов fs/aio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09016
Уязвимость функции ext4_mb_find_by_goal() ядра операционной системы Linux, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09130
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09132
Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09133
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09134
Уязвимость компонентов dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09149
Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09150
Уязвимость компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09152
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09153
Уязвимость компонента savage ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09154
Уязвимость компонента sis ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09155
Уязвимость компонента hisi-sfc-v3xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09156
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09158
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09159
Уязвимость компонента edma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-09-05
BDU:2024-09160
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09162
Уязвимость компонента b43 ядра операционной системы Linux, связанная с циклом с недостижимым условием выхода, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09163
Уязвимость компонента nvme-fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09164
Уязвимость компонента target ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09165
Уязвимость компонента efi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09166
Уязвимость компонента hfi1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09167
Уязвимость компонента irdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09168
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09179
Уязвимость компонента zswap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09183
Уязвимость компонентов vfio/pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09184
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09186
Уязвимость компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09187
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09190
Уязвимость компонентов powerpc/pseries/iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09194
Уязвимость компонентов fbcon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09196
Уязвимость компонента stmmac ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09198
Уязвимость компонента veth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09199
Уязвимость компонента ip_tunnel ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-03-21
BDU:2024-09201
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09203
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании(DoS)
Modified: 2025-05-06
BDU:2024-09204
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09205
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании(DoS)
Modified: 2025-08-19
BDU:2024-09206
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09207
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09208
Уязвимость компонента stm32 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-09356
Уязвимость компонентов powerpc/pseries ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09358
Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09367
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09368
Уязвимость компонентов nouveau/dmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09369
Уязвимость компонентов kprobes/x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09373
Уязвимость компонента dwc3-am62 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09393
Уязвимость компонента qla2xxx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09394
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-09396
Уязвимость компонентов drm/i915/gt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09397
Уязвимость компонента wireguard ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09398
Уязвимость компонента wireguard ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09399
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09400
Уязвимость функции pci_iounmap() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09401
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09403
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-08-19
BDU:2024-09405
Уязвимость компонента fat ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-01-20
BDU:2024-09406
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09409
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09410
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09411
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09412
Уязвимость компонента xhci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09414
Уязвимость компонентов s390/zcrypt ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09415
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09716
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09723
Уязвимость компонента flower ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09725
Уязвимость компонента dsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09726
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09728
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09729
Уязвимость компонента zynq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09731
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09756
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09757
Уязвимость компонента octeontx2-af ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09758
Уязвимость компонента nbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09759
Уязвимость компонента NTB ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-09767
Уязвимость компонента usb-audio ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2024-09768
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09769
Уязвимость компонента ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09770
Уязвимость компонента qbman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09771
Уязвимость компонента dm snapshot ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09772
Уязвимость компонента x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09802
Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09804
Уязвимость компонента nft_flow_offload ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2024-09814
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09835
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09837
Уязвимость компонента rgb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09838
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09839
Уязвимость компонентов efi/capsule-loader ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09841
Уязвимость компонента supply ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09842
Уязвимость компонента rtl8xxxu ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-02-09
BDU:2024-09845
Уязвимость функции tpg_alloc() в модуле drivers/media/common/v4l2-tpg/v4l2-tpg-core.c компонента v4l2-tpg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09846
Уязвимость компонента v4l2-mem2mem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09847
Уязвимость компонента imx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09848
Уязвимость компонента cpufreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09849
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09850
Уязвимость компонента dvb-frontends ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09851
Уязвимость компонента go7007 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09852
Уязвимость компонента ttpci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09853
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09854
Уязвимость компонента hi3559a ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09855
Уязвимость компонента usb-storage ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09856
Уязвимость компонента wilc1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09857
Уязвимость компонентов s390/dasd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09858
Уязвимость компонента rtnetlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09883
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09884
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09885
Уязвимость компонента sockmap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09886
Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09888
Уязвимость компонента gro ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09896
Уязвимость компонента iwlwifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09897
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09898
Уязвимость компонента mlxbf_gige ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09915
Уязвимость компонента ncm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09917
Уязвимость компонента vt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09933
Уязвимость компонента udc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09938
Уязвимость компонента ubifs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09945
Уязвимость компонентов drm/lima ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09961
Уязвимость компонента micrel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09963
Уязвимость компонента tls ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09964
Уязвимость компонента t7xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09967
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2024-09968
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09969
Уязвимость компонента qbman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09971
Уязвимость компонента dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09972
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09973
Уязвимость компонента nci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09980
Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09981
Уязвимость компонента lis3lv02d_i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09985
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю манипулировать данными
Modified: 2025-05-06
BDU:2024-09988
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09989
Уязвимость компонентов PCI/PM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09990
Уязвимость компонента cpumap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09991
Уязвимость компонента netrom ядра операционной системы Linux, позволяющая нарушителю манипулировать данными
Modified: 2026-01-20
BDU:2024-09992
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-01-20
BDU:2024-09993
Уязвимость компонента hci_event ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-03-21
BDU:2024-09994
Уязвимость компонента bridge ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09999
Уязвимость компонента wilc1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10008
Уязвимость компонента mcast ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10009
Уязвимость компонента SUNRPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10034
Уязвимость компонента tc358743 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10048
Уязвимость компонента erspan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10050
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10052
Уязвимость компонента mlxbf_gige ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10053
Уязвимость компонента udp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10055
Уязвимость компонента dynamic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10057
Уязвимость компонентов mm/secretmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10059
Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10065
Уязвимость компонентов x86/mm/pat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10365
Уязвимость компонента compress ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10659
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10739
Уязвимость компонента libertas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-11575
Уязвимость функции io_recvmsg_mshot_prep() модуля io_uring/net.c компонентов io_uring/net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00024
Уязвимость компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-05-06
BDU:2025-01230
Уязвимость модуля nf_tables компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-02904
Уязвимость функции axg_clk_regmaps{} модуля drivers/clk/meson/axg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02907
Уязвимость функции hci_get_dev_info() модуля net/bluetooth/hci_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-02910
Уязвимость функции cik_ih_get_wptr() модуля drivers/gpu/drm/amd/amdgpu/cik_ih.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03085
Уязвимость функции bq27xxx_battery_i2c_remove() модуля drivers/power/supply/bq27xxx_battery_i2c.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03088
Уязвимость функции nvme_alloc_admin_tag_set() модуля drivers/nvme/host/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03606
Уязвимость функции ff_layout_cancel_io() модуля fs/nfs/flexfilelayout/flexfilelayout.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03608
Уязвимость функции ice_bridge_setlink() модуля drivers/net/ethernet/intel/ice/ice_main.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03613
Уязвимость функции acpi_processor_power_exit() модуля drivers/acpi/processor_idle.c - драйвера поддержки ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03615
Уязвимость функции pvr2_context_exit() модуля drivers/media/usb/pvrusb2/pvrusb2-context.c - драйвера поддержки мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-10-23
BDU:2025-03616
Уязвимость функции amdgpu_dm_atomic_check() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03909
Уязвимость компонента iommu/vt-d ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03911
Уязвимость компонента fs/quota/dquot.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03912
Уязвимость компонента crypto/xilinx/zynqmp-aes-gcm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03927
Уязвимость компонента x86/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03928
Уязвимость компонента drm/mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03929
Уязвимость компонента mm/usercopy.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03930
Уязвимость компонента net/core/dev.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2026-01-20
BDU:2025-03931
Уязвимость компонента wireguard/receive.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03932
Уязвимость компонента events_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04258
Уязвимость функции geneve_rx() модуля drivers/net/geneve.c - драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-04260
Уязвимость функции hsr_get_node() модуля net/hsr/hsr_framereg.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-23
BDU:2025-04395
Уязвимость функции aoeblk_gdalloc() модуля drivers/block/aoe/aoeblk.c - драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-04401
Уязвимость функции __dm_internal_suspend() модуля drivers/md/dm.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-06-09
BDU:2025-04402
Уязвимость определения структуры f2fs_fault_info{} модуля fs/f2fs/f2fs.h поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04404
Уязвимость функции bt_sock_recvmsg() модуля net/bluetooth/af_bluetooth.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-23
BDU:2025-07832
Уязвимость компонента fs/proc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-12481
Уязвимость компонента switchdev ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-01-20
BDU:2025-12996
Уязвимость функции recv() компонента tls ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13305
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13311
Уязвимость компонентов mm/swap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13312
Уязвимость компонента LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13346
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13347
Уязвимость компонента igc ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2025-13348
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13349
Уязвимость компонентов x86/efistub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13350
Уязвимость компонента LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13354
Уязвимость компонентов x86/coco ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13355
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13356
Уязвимость компонентов drm/i915/bios ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13358
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2025-13359
Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13360
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13365
Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15043
Уязвимость функции process_isoc_td() модуля drivers/usb/host/xhci-ring.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-16315
Уязвимость функции run_unpack() компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2026-01440
Уязвимость команды WMI_TXSTATUS_EVENTID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04263
Уязвимость функции __bio_release_pages() модуля block/bio.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04308
Уязвимость функции pstore_put_backend_records() модуля fs/pstore/inode.c поддержки постоянного хранилища ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05737
Уязвимость модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-08
CVE-2022-48669
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix potential memleak in papr_get_attr() `buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure.
- https://git.kernel.org/stable/c/1699fb915b9f61794d559b55114c09a390aaf234
- https://git.kernel.org/stable/c/7f7d39fe3d80d6143404940b2413010cf6527029
- https://git.kernel.org/stable/c/a3f22feb2220a945d1c3282e34199e8bcdc5afc4
- https://git.kernel.org/stable/c/cda9c0d556283e2d4adaa9960b2dc19b16156bae
- https://git.kernel.org/stable/c/d0647c3e81eff62b66d46fd4e475318cb8cb3610
- https://git.kernel.org/stable/c/1699fb915b9f61794d559b55114c09a390aaf234
- https://git.kernel.org/stable/c/7f7d39fe3d80d6143404940b2413010cf6527029
- https://git.kernel.org/stable/c/a3f22feb2220a945d1c3282e34199e8bcdc5afc4
- https://git.kernel.org/stable/c/cda9c0d556283e2d4adaa9960b2dc19b16156bae
- https://git.kernel.org/stable/c/d0647c3e81eff62b66d46fd4e475318cb8cb3610
Modified: 2025-05-05
CVE-2023-2176
A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.
Modified: 2025-01-17
CVE-2023-52434
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2_parse_contexts()
Validate offsets and lengths before dereferencing create contexts in
smb2_parse_contexts().
This fixes following oops when accessing invalid create contexts from
server:
BUG: unable to handle page fault for address: ffff8881178d8cc3
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 4a01067 P4D 4a01067 PUD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]
Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00
00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7
7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00
RSP: 0018:ffffc900007939e0 EFLAGS: 00010216
RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90
RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000
RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000
R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000
R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22
FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5
- https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa
- https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29
- https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb
- https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48
- https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144
- https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5
- https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa
- https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29
- https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb
- https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48
- https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20250117-0009/
Modified: 2025-09-16
CVE-2023-52620
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow timeout for anonymous sets Never used from userspace, disallow these parameters.
- https://git.kernel.org/stable/c/00b19ee0dcc1aef06294471ab489bae26d94524e
- https://git.kernel.org/stable/c/116b0e8e4673a5faa8a739a19b467010c4d3058c
- https://git.kernel.org/stable/c/49ce99ae43314d887153e07cec8bb6a647a19268
- https://git.kernel.org/stable/c/6f3ae02bbb62f151b19162d5fdc9fe3d48450323
- https://git.kernel.org/stable/c/b7be6c737a179a76901c872f6b4c1d00552d9a1b
- https://git.kernel.org/stable/c/e26d3009efda338f19016df4175f354a9bd0a4ab
- https://git.kernel.org/stable/c/00b19ee0dcc1aef06294471ab489bae26d94524e
- https://git.kernel.org/stable/c/116b0e8e4673a5faa8a739a19b467010c4d3058c
- https://git.kernel.org/stable/c/49ce99ae43314d887153e07cec8bb6a647a19268
- https://git.kernel.org/stable/c/6f3ae02bbb62f151b19162d5fdc9fe3d48450323
- https://git.kernel.org/stable/c/b7be6c737a179a76901c872f6b4c1d00552d9a1b
- https://git.kernel.org/stable/c/e26d3009efda338f19016df4175f354a9bd0a4ab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2023-52639
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm; Let children inherit the private field of the parent.
- https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082
- https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc
- https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380
- https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32
- https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082
- https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc
- https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380
- https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32
Modified: 2025-02-27
CVE-2023-52640
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea.
- https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c
- https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23
- https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb
- https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15
- https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd
- https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c
- https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23
- https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb
- https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15
- https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd
Modified: 2025-01-07
CVE-2023-52641
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there.
- https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc
- https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd
- https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c
- https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a
- https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b
- https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc
- https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd
- https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c
- https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a
- https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b
Modified: 2025-04-02
CVE-2023-52644
In the Linux kernel, the following vulnerability has been resolved: wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated---
- https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455
- https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010
- https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240
- https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436
- https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08
- https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc
- https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83
- https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d
- https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610
- https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455
- https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010
- https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240
- https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436
- https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08
- https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc
- https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83
- https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d
- https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52645
In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd.
- https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff
- https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b
- https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438
- https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5
- https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25
- https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff
- https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b
- https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438
- https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5
- https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25
Modified: 2024-12-23
CVE-2023-52650
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: dsi: Add missing check for of_find_device_by_node Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc
- https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80
- https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6
- https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976
- https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129
- https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d
- https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d
- https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9
- https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5
- https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc
- https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80
- https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6
- https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976
- https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129
- https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d
- https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d
- https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9
- https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-18
CVE-2023-52652
In the Linux kernel, the following vulnerability has been resolved: NTB: fix possible name leak in ntb_register_device() If device_register() fails in ntb_register_device(), the device name allocated by dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device() to give up the reference in the error path. So fix this by calling put_device() in the error path so that the name can be freed in kobject_cleanup(). As a result of this, put_device() in the error path of ntb_register_device() is removed and the actual error is returned. [mani: reworded commit message]
- https://git.kernel.org/stable/c/6632a54ac8057cc0b0d789c6f73883e871bcd25c
- https://git.kernel.org/stable/c/913421f9f7fd8324dcc41753d0f28b52e177ef04
- https://git.kernel.org/stable/c/a039690d323221eb5865f1f31db3ec264e7a14b6
- https://git.kernel.org/stable/c/a62b9f3d7bbfac874cc0c638bc1776dcf1f8ec06
- https://git.kernel.org/stable/c/aebfdfe39b9327a3077d0df8db3beb3160c9bdd0
- https://git.kernel.org/stable/c/e8025439ef8e16029dc313d78a351ef192469b7b
- https://git.kernel.org/stable/c/6632a54ac8057cc0b0d789c6f73883e871bcd25c
- https://git.kernel.org/stable/c/913421f9f7fd8324dcc41753d0f28b52e177ef04
- https://git.kernel.org/stable/c/a039690d323221eb5865f1f31db3ec264e7a14b6
- https://git.kernel.org/stable/c/a62b9f3d7bbfac874cc0c638bc1776dcf1f8ec06
- https://git.kernel.org/stable/c/aebfdfe39b9327a3077d0df8db3beb3160c9bdd0
- https://git.kernel.org/stable/c/e8025439ef8e16029dc313d78a351ef192469b7b
Modified: 2025-12-23
CVE-2023-52656
In the Linux kernel, the following vulnerability has been resolved: io_uring: drop any code related to SCM_RIGHTS This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it.
- https://git.kernel.org/stable/c/6e5e6d274956305f1fc0340522b38f5f5be74bdb
- https://git.kernel.org/stable/c/6fc19b3d8a45ff0e5d50ec8184cee1d5eac1a8ba
- https://git.kernel.org/stable/c/88c49d9c896143cdc0f77197c4dcf24140375e89
- https://git.kernel.org/stable/c/a3812a47a32022ca76bf46ddacdd823dc2aabf8b
- https://git.kernel.org/stable/c/a6771f343af90a25f3a14911634562bb5621df02
- https://git.kernel.org/stable/c/cfb24022bb2c31f1f555dc6bc3cc5e2547446fb3
- https://git.kernel.org/stable/c/d909d381c3152393421403be4b6435f17a2378b4
- https://git.kernel.org/stable/c/6e5e6d274956305f1fc0340522b38f5f5be74bdb
- https://git.kernel.org/stable/c/88c49d9c896143cdc0f77197c4dcf24140375e89
- https://git.kernel.org/stable/c/a3812a47a32022ca76bf46ddacdd823dc2aabf8b
- https://git.kernel.org/stable/c/a6771f343af90a25f3a14911634562bb5621df02
- https://git.kernel.org/stable/c/cfb24022bb2c31f1f555dc6bc3cc5e2547446fb3
- https://git.kernel.org/stable/c/d909d381c3152393421403be4b6435f17a2378b4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2023-52657
In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amd/pm: resolve reboot exception for si oland" This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86. This causes hangs on SI when DC is enabled and errors on driver reboot and power off cycles.
- https://git.kernel.org/stable/c/2e443ed55fe3ffb08327b331a9f45e9382413c94
- https://git.kernel.org/stable/c/955558030954b9637b41c97b730f9b38c92ac488
- https://git.kernel.org/stable/c/baac292852c0e347626fb5436916947188e5838f
- https://git.kernel.org/stable/c/c51468ac328d3922747be55507c117e47da813e6
- https://git.kernel.org/stable/c/2e443ed55fe3ffb08327b331a9f45e9382413c94
- https://git.kernel.org/stable/c/955558030954b9637b41c97b730f9b38c92ac488
- https://git.kernel.org/stable/c/baac292852c0e347626fb5436916947188e5838f
- https://git.kernel.org/stable/c/c51468ac328d3922747be55507c117e47da813e6
Modified: 2025-09-25
CVE-2023-52660
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ handling due to shared interrupts The driver requests the interrupts as IRQF_SHARED, so the interrupt handlers can be called at any time. If such a call happens while the ISP is powered down, the SoC will hang as the driver tries to access the ISP registers. This can be reproduced even without the platform sharing the IRQ line: Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will hang. Fix this by adding a new field, 'irqs_enabled', which is used to bail out from the interrupt handler when the ISP is not operational.
- https://git.kernel.org/stable/c/abd34206f396d3ae50cddbd5aa840b8cd7f68c63
- https://git.kernel.org/stable/c/b39b4d207d4f236a74e20d291f6356f2231fd9ee
- https://git.kernel.org/stable/c/edcf92bc66d8361c51dff953a55210e5cfd95587
- https://git.kernel.org/stable/c/ffb635bb398fc07cb38f8a7b4a82cbe5f412f08e
- https://git.kernel.org/stable/c/abd34206f396d3ae50cddbd5aa840b8cd7f68c63
- https://git.kernel.org/stable/c/b39b4d207d4f236a74e20d291f6356f2231fd9ee
- https://git.kernel.org/stable/c/edcf92bc66d8361c51dff953a55210e5cfd95587
- https://git.kernel.org/stable/c/ffb635bb398fc07cb38f8a7b4a82cbe5f412f08e
Modified: 2025-09-19
CVE-2023-52661
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be undone. Add the missing clk_put and a new 'put_pll_d_out0' label in the error handling path, and use it.
- https://git.kernel.org/stable/c/2388c36e028fff7f8ffd515681a14c6c2c07fea7
- https://git.kernel.org/stable/c/45c8034db47842b25a3ab6139d71e13b4e67b9b3
- https://git.kernel.org/stable/c/5c8dc26e31b8b410ad1895e0d314def50c76eed0
- https://git.kernel.org/stable/c/845322a9c06dd1dcf35b6c4e3af89684297c23cc
- https://git.kernel.org/stable/c/f3f407ccbe84a34de9be3195d22cdd5969f3fd9f
- https://git.kernel.org/stable/c/fa74e4f5d0821829545b9f7034a0e577c205c101
- https://git.kernel.org/stable/c/2388c36e028fff7f8ffd515681a14c6c2c07fea7
- https://git.kernel.org/stable/c/45c8034db47842b25a3ab6139d71e13b4e67b9b3
- https://git.kernel.org/stable/c/5c8dc26e31b8b410ad1895e0d314def50c76eed0
- https://git.kernel.org/stable/c/845322a9c06dd1dcf35b6c4e3af89684297c23cc
- https://git.kernel.org/stable/c/f3f407ccbe84a34de9be3195d22cdd5969f3fd9f
- https://git.kernel.org/stable/c/fa74e4f5d0821829545b9f7034a0e577c205c101
Modified: 2025-01-14
CVE-2023-52662
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init.
- https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf
- https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a
- https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6
- https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5
- https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce
- https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876
- https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf
- https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a
- https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6
- https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5
- https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce
- https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876
Modified: 2025-11-24
CVE-2023-53151
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing
writes, raid1 has cond_resched() while raid10 doesn't, and too many
writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for
raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
Call Trace:
- https://git.kernel.org/stable/c/00ecb6fa67c0f772290c5ea5ae8b46eefd503b83
- https://git.kernel.org/stable/c/010444623e7f4da6b4a4dd603a7da7469981e293
- https://git.kernel.org/stable/c/1d467e10507167eb6dc2c281a87675b731955d86
- https://git.kernel.org/stable/c/634daf6b2c81015cc5e28bf694a6a94a50c641cd
- https://git.kernel.org/stable/c/84a578961b2566e475bfa8740beaf0abcc781a6f
- https://git.kernel.org/stable/c/d0345f7c7dbc5d42e4e6f1db99c1c1879d7b0eb5
- https://git.kernel.org/stable/c/f45b2fa7678ab385299de345f7e85d05caea386b
- https://git.kernel.org/stable/c/fbf50184190d55f8717bd29aa9530c399be96f30
Modified: 2025-12-02
CVE-2023-53194
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add length check in indx_get_root
This adds a length check to guarantee the retrieved index root is legit.
[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320
[ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243
[ 162.460851]
[ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42
[ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 162.462609] Call Trace:
[ 162.462954]
Modified: 2026-01-20
CVE-2023-53486
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Enhance the attribute size check
This combines the overflow and boundary check so that all attribute size
will be properly examined while enumerating them.
[ 169.181521] BUG: KASAN: slab-out-of-bounds in run_unpack+0x2e3/0x570
[ 169.183161] Read of size 1 at addr ffff8880094b6240 by task mount/247
[ 169.184046]
[ 169.184925] CPU: 0 PID: 247 Comm: mount Not tainted 6.0.0-rc7+ #3
[ 169.185908] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 169.187066] Call Trace:
[ 169.187492]
Modified: 2025-01-22
CVE-2024-23307
Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.
Modified: 2025-11-04
CVE-2024-26584
In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.
- https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754
- https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368
- https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3
- https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694
- https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72
- https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754
- https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368
- https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3
- https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694
- https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-01-16
CVE-2024-26621
In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: don't force huge page alignment on 32 bit commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/
- https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d
- https://git.kernel.org/stable/c/6ea9aa8d97e6563676094cb35755884173269555
- https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47
- https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe
- http://www.openwall.com/lists/oss-security/2024/07/08/3
- http://www.openwall.com/lists/oss-security/2024/07/08/4
- http://www.openwall.com/lists/oss-security/2024/07/08/5
- http://www.openwall.com/lists/oss-security/2024/07/08/6
- http://www.openwall.com/lists/oss-security/2024/07/08/7
- http://www.openwall.com/lists/oss-security/2024/07/08/8
- http://www.openwall.com/lists/oss-security/2024/07/09/1
- http://www.openwall.com/lists/oss-security/2024/07/10/5
- http://www.openwall.com/lists/oss-security/2024/07/10/7
- http://www.openwall.com/lists/oss-security/2024/07/10/8
- http://www.openwall.com/lists/oss-security/2024/07/11/4
- http://www.openwall.com/lists/oss-security/2024/07/11/5
- http://www.openwall.com/lists/oss-security/2024/07/11/7
- http://www.openwall.com/lists/oss-security/2024/07/12/3
- http://www.openwall.com/lists/oss-security/2024/07/13/2
- http://www.openwall.com/lists/oss-security/2024/07/13/7
- http://www.openwall.com/lists/oss-security/2024/07/15/1
- http://www.openwall.com/lists/oss-security/2024/07/15/2
- http://www.openwall.com/lists/oss-security/2024/07/16/1
- http://www.openwall.com/lists/oss-security/2024/07/16/2
- http://www.openwall.com/lists/oss-security/2024/07/29/2
- http://www.openwall.com/lists/oss-security/2024/07/30/2
- https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d
- https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47
- https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe
- https://zolutal.github.io/aslrnt/
Modified: 2025-11-04
CVE-2024-26622
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems.
- https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f
- https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815
- https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824
- https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711
- https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc
- https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee
- https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f
- https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815
- https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824
- https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711
- https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc
- https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IVVYSTEVMPYGF6GDSOD44MUXZXAZHOHB/
Modified: 2025-03-13
CVE-2024-26642
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this. Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
- https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1
- https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a
- https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199
- https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7
- https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12
- https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9
- https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f
- https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351
- https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1
- https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a
- https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199
- https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7
- https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12
- https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9
- https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f
- https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-13
CVE-2024-26643
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.
- https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363
- https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163
- https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8
- https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36
- https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1
- https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033
- https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c
- https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf
- https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363
- https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163
- https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8
- https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36
- https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1
- https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033
- https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c
- https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2024-26651
In the Linux kernel, the following vulnerability has been resolved: sr9800: Add check for usbnet_get_endpoints Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error.
- https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61
- https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581
- https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7
- https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009
- https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a
- https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384
- https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028
- https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f
- https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774
- https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61
- https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581
- https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7
- https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009
- https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a
- https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384
- https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028
- https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f
- https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AXURWFKAKFEIUBN7RTCXI7GZYAHXNBX5/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SI2D7K2T6QCWALKLYEWZ22P4UXMEBCGB/
Modified: 2025-02-03
CVE-2024-26654
In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below: (Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | ... | run_spu_dma() //worker | mod_timer() flush_work() | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() | run_spu_dma() //worker ... | dreamcastcard->channel-> //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.
- https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457
- https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04
- https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2
- https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901
- https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5
- https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046
- https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845
- https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3
- https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2
- https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457
- https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04
- https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2
- https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901
- https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5
- https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046
- https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845
- https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3
- https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26659
In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.
- https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c
- https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3
- https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134
- https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e
- https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811
- https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97
- https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c
- https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3
- https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134
- https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e
- https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811
- https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-03
CVE-2024-26686
In the Linux kernel, the following vulnerability has been resolved: fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless.
- https://git.kernel.org/stable/c/0c35d1914353799c54fa1843fe7dea6fcbcdbac5
- https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071
- https://git.kernel.org/stable/c/3820b0fac7732a653bcc6f6ac20c1d72e697f8f6
- https://git.kernel.org/stable/c/4fe85bdaabd63f8f8579b24a10ed597c9c482164
- https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305
- https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d
- https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071
- https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305
- https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-03-17
CVE-2024-26687
In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated---
- https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd
- https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4
- https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5
- https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44
- https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b
- https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3
- https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9
- https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd
- https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4
- https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5
- https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44
- https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b
- https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3
- https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-07
CVE-2024-26700
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix MST Null Ptr for RV
The change try to fix below error specific to RV platform:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
Call Trace:
- https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238
- https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f
- https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5
- https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57
- https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238
- https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f
- https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5
- https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57
Modified: 2025-01-07
CVE-2024-26722
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/050ad2ca0ac169dd9e552075d2c6af1bbb46534c
- https://git.kernel.org/stable/c/1f0d7792e9023e8658e901b7b76a555f6aa052ec
- https://git.kernel.org/stable/c/3dd2d99e2352903d0e0b8769e6c9b8293c7454b2
- https://git.kernel.org/stable/c/422d5243b9f780abd3d39da2b746e3915677b07d
- https://git.kernel.org/stable/c/4a98bc739d0753a5810ce5630943cd7614c7717e
- https://git.kernel.org/stable/c/6ef5d5b92f7117b324efaac72b3db27ae8bb3082
- https://git.kernel.org/stable/c/d14b8e2005f36319df9412d42037416d64827f6b
- https://git.kernel.org/stable/c/ed5b8b735369b40d6c1f8ef3e62d369f74b4c491
- https://git.kernel.org/stable/c/050ad2ca0ac169dd9e552075d2c6af1bbb46534c
- https://git.kernel.org/stable/c/1f0d7792e9023e8658e901b7b76a555f6aa052ec
- https://git.kernel.org/stable/c/3dd2d99e2352903d0e0b8769e6c9b8293c7454b2
- https://git.kernel.org/stable/c/422d5243b9f780abd3d39da2b746e3915677b07d
- https://git.kernel.org/stable/c/4a98bc739d0753a5810ce5630943cd7614c7717e
- https://git.kernel.org/stable/c/6ef5d5b92f7117b324efaac72b3db27ae8bb3082
- https://git.kernel.org/stable/c/d14b8e2005f36319df9412d42037416d64827f6b
- https://git.kernel.org/stable/c/ed5b8b735369b40d6c1f8ef3e62d369f74b4c491
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-03
CVE-2024-26731
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()
syzbot reported the following NULL pointer dereference issue [1]:
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:0x0
[...]
Call Trace:
- https://git.kernel.org/stable/c/4588b13abcbd561ec67f5b3c1cb2eff690990a54
- https://git.kernel.org/stable/c/4cd12c6065dfcdeba10f49949bffcf383b3952d8
- https://git.kernel.org/stable/c/9b099ed46dcaf1403c531ff02c3d7400fa37fa26
- https://git.kernel.org/stable/c/d61608a4e394f23e0dca099df9eb8e555453d949
- https://git.kernel.org/stable/c/4588b13abcbd561ec67f5b3c1cb2eff690990a54
- https://git.kernel.org/stable/c/4cd12c6065dfcdeba10f49949bffcf383b3952d8
- https://git.kernel.org/stable/c/9b099ed46dcaf1403c531ff02c3d7400fa37fa26
- https://git.kernel.org/stable/c/d61608a4e394f23e0dca099df9eb8e555453d949
Modified: 2025-03-17
CVE-2024-26733
In the Linux kernel, the following vulnerability has been resolved:
arp: Prevent overflow in arp_req_get().
syzkaller reported an overflown write in arp_req_get(). [0]
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
the sa_data buffer is just 14 bytes.
In the splat below, 2 bytes are overflown to the next int field,
arp_flags. We initialise the field just after the memcpy(), so it's
not a problem.
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
in arp_ioctl() before calling arp_req_get().
To avoid the overflow, let's limit the max length of memcpy().
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
array in struct sockaddr") just silenced syzkaller.
[0]:
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Modules linked in:
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a
- https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50
- https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91
- https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667
- https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587
- https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0
- https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a
- https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50
- https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91
- https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667
- https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587
- https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20241101-0013/
Modified: 2025-03-17
CVE-2024-26735
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix possible use-after-free and null-ptr-deref The pernet operations structure for the subsystem must be registered before registering the generic netlink family.
- https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b
- https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b
- https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6
- https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d
- https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197
- https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee
- https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa
- https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44
- https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b
- https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b
- https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6
- https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d
- https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197
- https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee
- https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa
- https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241101-0012/
Modified: 2025-03-17
CVE-2024-26736
In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
- https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5
- https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e
- https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d
- https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa
- https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637
- https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e
- https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1
- https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5
- https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e
- https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d
- https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa
- https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637
- https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e
- https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-26737
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period.
- https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f
- https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c
- https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33
- https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6
- https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5
- https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f
- https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c
- https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33
- https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6
- https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5
Modified: 2025-03-17
CVE-2024-26741
In the Linux kernel, the following vulnerability has been resolved:
dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().
syzkaller reported a warning [0] in inet_csk_destroy_sock() with no
repro.
WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash);
However, the syzkaller's log hinted that connect() failed just before
the warning due to FAULT_INJECTION. [1]
When connect() is called for an unbound socket, we search for an
available ephemeral port. If a bhash bucket exists for the port, we
call __inet_check_established() or __inet6_check_established() to check
if the bucket is reusable.
If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num.
Later, we look up the corresponding bhash2 bucket and try to allocate
it if it does not exist.
Although it rarely occurs in real use, if the allocation fails, we must
revert the changes by check_established(). Otherwise, an unconnected
socket could illegally occupy an ehash entry.
Note that we do not put tw back into ehash because sk might have
already responded to a packet for tw and it would be better to free
tw earlier under such memory presure.
[0]:
WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
Modules linked in:
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05
RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40
RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8
RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0
R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000
FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/334a8348b2df26526f3298848ad6864285592caf
- https://git.kernel.org/stable/c/66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f
- https://git.kernel.org/stable/c/729bc77af438a6e67914c97f6f3d3af8f72c0131
- https://git.kernel.org/stable/c/f8c4a6b850882bc47aaa864b720c7a2ee3102f39
- https://git.kernel.org/stable/c/334a8348b2df26526f3298848ad6864285592caf
- https://git.kernel.org/stable/c/66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f
- https://git.kernel.org/stable/c/729bc77af438a6e67914c97f6f3d3af8f72c0131
- https://git.kernel.org/stable/c/f8c4a6b850882bc47aaa864b720c7a2ee3102f39
Modified: 2025-03-17
CVE-2024-26742
In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix disable_managed_interrupts Correct blk-mq registration issue with module parameter disable_managed_interrupts enabled. When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to register with blk-mq using blk_mq_map_queues(). The driver is currently calling blk_mq_pci_map_queues() which results in a stack trace and possibly undefined behavior. Stack Trace: [ 7.860089] scsi host2: smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.351193] process_one_work+0x1a7/0x360 [ 8.364462] ? create_worker+0x1a0/0x1a0 [ 8.379252] worker_thread+0x1ce/0x390 [ 8.392623] ? create_worker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? set_kthread_struct+0x50/0x50 [ 8.431532] ret_from_fork+0x1f/0x40 [ 8.444137] ---[ end trace 1bf0173d39354506 ]---
- https://git.kernel.org/stable/c/3c31b18a8dd8b7bf36af1cd723d455853b8f94fe
- https://git.kernel.org/stable/c/4f5b15c15e6016efb3e14582d02cc4ddf57227df
- https://git.kernel.org/stable/c/5761eb9761d2d5fe8248a9b719efc4d8baf1f24a
- https://git.kernel.org/stable/c/b9433b25cb06c415c9cb24782599649a406c8d6d
- https://git.kernel.org/stable/c/3c31b18a8dd8b7bf36af1cd723d455853b8f94fe
- https://git.kernel.org/stable/c/4f5b15c15e6016efb3e14582d02cc4ddf57227df
- https://git.kernel.org/stable/c/5761eb9761d2d5fe8248a9b719efc4d8baf1f24a
- https://git.kernel.org/stable/c/b9433b25cb06c415c9cb24782599649a406c8d6d
Modified: 2025-03-17
CVE-2024-26743
In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix qedr_create_user_qp error flow
Avoid the following warning by making sure to free the allocated
resources in case that qedr_init_user_queue() fail.
-----------[ cut here ]-----------
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
Call Trace:
- https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a
- https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a
- https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928
- https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc
- https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298
- https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6
- https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a
- https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a
- https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928
- https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc
- https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298
- https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-05-02
CVE-2024-26744
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Support specifying the srpt_service_guid parameter
Make loading ib_srpt with this parameter set work. The current behavior is
that setting that parameter while loading the ib_srpt kernel module
triggers the following kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
- https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82
- https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b
- https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4
- https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8
- https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d
- https://git.kernel.org/stable/c/e0055d6461b36bfc25a9d2ab974eef78d36a6738
- https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0
- https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f
- https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82
- https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b
- https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4
- https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8
- https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d
- https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0
- https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-26745
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due
to NULL pointer exception:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc000000020847ad4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop
CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12
Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c
REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)
MSR: 800000000280b033
- https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051
- https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28
- https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3
- https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf
- https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051
- https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28
- https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3
- https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf
Modified: 2025-04-04
CVE-2024-26747
In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations.
- https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa
- https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db
- https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e
- https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734
- https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1
- https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913
- https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa
- https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db
- https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e
- https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734
- https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1
- https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26748
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request); Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.
- https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48
- https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8
- https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3
- https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019
- https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3
- https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c
- https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7
- https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48
- https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8
- https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3
- https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019
- https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3
- https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c
- https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26749
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem.
- https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9
- https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16
- https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3
- https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d
- https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643
- https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6
- https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824
- https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9
- https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16
- https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3
- https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d
- https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643
- https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6
- https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26751
In the Linux kernel, the following vulnerability has been resolved: ARM: ep93xx: Add terminator to gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops.
- https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8
- https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482
- https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8
- https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997
- https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa
- https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e
- https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48
- https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557
- https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8
- https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482
- https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8
- https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997
- https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa
- https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e
- https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48
- https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26752
In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent.
- https://git.kernel.org/stable/c/0da15a70395182ee8cb75716baf00dddc0bea38d
- https://git.kernel.org/stable/c/13cd1daeea848614e585b2c6ecc11ca9c8ab2500
- https://git.kernel.org/stable/c/359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79
- https://git.kernel.org/stable/c/4c3ce64bc9d36ca9164dd6c77ff144c121011aae
- https://git.kernel.org/stable/c/804bd8650a3a2bf3432375f8c97d5049d845ce56
- https://git.kernel.org/stable/c/83340c66b498e49353530e41542500fc8a4782d6
- https://git.kernel.org/stable/c/c1d3a84a67db910ce28a871273c992c3d7f9efb5
- https://git.kernel.org/stable/c/dcb4d14268595065c85dc5528056713928e17243
- https://git.kernel.org/stable/c/0da15a70395182ee8cb75716baf00dddc0bea38d
- https://git.kernel.org/stable/c/13cd1daeea848614e585b2c6ecc11ca9c8ab2500
- https://git.kernel.org/stable/c/359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79
- https://git.kernel.org/stable/c/4c3ce64bc9d36ca9164dd6c77ff144c121011aae
- https://git.kernel.org/stable/c/804bd8650a3a2bf3432375f8c97d5049d845ce56
- https://git.kernel.org/stable/c/83340c66b498e49353530e41542500fc8a4782d6
- https://git.kernel.org/stable/c/c1d3a84a67db910ce28a871273c992c3d7f9efb5
- https://git.kernel.org/stable/c/dcb4d14268595065c85dc5528056713928e17243
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-27
CVE-2024-26753
In the Linux kernel, the following vulnerability has been resolved: crypto: virtio/akcipher - Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o
- https://git.kernel.org/stable/c/37077ed16c7793e21b005979d33f8a61565b7e86
- https://git.kernel.org/stable/c/62f361bfea60c6afc3df09c1ad4152e6507f6f47
- https://git.kernel.org/stable/c/b0365460e945e1117b47cf7329d86de752daff63
- https://git.kernel.org/stable/c/c0ec2a712daf133d9996a8a1b7ee2d4996080363
- https://git.kernel.org/stable/c/ef1e47d50324e232d2da484fe55a54274eeb9bc1
- https://git.kernel.org/stable/c/37077ed16c7793e21b005979d33f8a61565b7e86
- https://git.kernel.org/stable/c/62f361bfea60c6afc3df09c1ad4152e6507f6f47
- https://git.kernel.org/stable/c/b0365460e945e1117b47cf7329d86de752daff63
- https://git.kernel.org/stable/c/c0ec2a712daf133d9996a8a1b7ee2d4996080363
- https://git.kernel.org/stable/c/ef1e47d50324e232d2da484fe55a54274eeb9bc1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-07
CVE-2024-26754
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
The gtp_net_ops pernet operations structure for the subsystem must be
registered before registering the generic netlink family.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
RSP: 0018:ffff888014107220 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec
- https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca
- https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a
- https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576
- https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77
- https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e
- https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861
- https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7
- https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec
- https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca
- https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a
- https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576
- https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77
- https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e
- https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861
- https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-16
CVE-2024-26759
In the Linux kernel, the following vulnerability has been resolved:
mm/swap: fix race when skipping swapcache
When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
swapin the same entry at the same time, they get different pages (A, B).
Before one thread (T0) finishes the swapin and installs page (A) to the
PTE, another thread (T1) could finish swapin of page (B), swap_free the
entry, then swap out the possibly modified page reusing the same entry.
It breaks the pte_same check in (T0) because PTE value is unchanged,
causing ABA problem. Thread (T0) will install a stalled page (A) into the
PTE and cause data corruption.
One possible callstack is like this:
CPU0 CPU1
---- ----
do_swap_page() do_swap_page() with same entry
- https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458
- https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95
- https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a
- https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d
- https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458
- https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95
- https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a
- https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d
Modified: 2025-03-03
CVE-2024-26760
In the Linux kernel, the following vulnerability has been resolved: scsi: target: pscsi: Fix bio_put() for error case As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in bio_free().
- https://git.kernel.org/stable/c/1cfe9489fb563e9a0c9cdc5ca68257a44428c2ec
- https://git.kernel.org/stable/c/4ebc079f0c7dcda1270843ab0f38ab4edb8f7921
- https://git.kernel.org/stable/c/de959094eb2197636f7c803af0943cb9d3b35804
- https://git.kernel.org/stable/c/f49b20fd0134da84a6bd8108f9e73c077b7d6231
- https://git.kernel.org/stable/c/1cfe9489fb563e9a0c9cdc5ca68257a44428c2ec
- https://git.kernel.org/stable/c/4ebc079f0c7dcda1270843ab0f38ab4edb8f7921
- https://git.kernel.org/stable/c/de959094eb2197636f7c803af0943cb9d3b35804
- https://git.kernel.org/stable/c/f49b20fd0134da84a6bd8108f9e73c077b7d6231
Modified: 2025-03-17
CVE-2024-26761
In the Linux kernel, the following vulnerability has been resolved: cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window The Linux CXL subsystem is built on the assumption that HPA == SPA. That is, the host physical address (HPA) the HDM decoder registers are programmed with are system physical addresses (SPA). During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1, 8.1.3.8) are checked if the memory is enabled and the CXL range is in a HPA window that is described in a CFMWS structure of the CXL host bridge (cxl-3.1, 9.18.1.3). Now, if the HPA is not an SPA, the CXL range does not match a CFMWS window and the CXL memory range will be disabled then. The HDM decoder stops working which causes system memory being disabled and further a system hang during HDM decoder initialization, typically when a CXL enabled kernel boots. Prevent a system hang and do not disable the HDM decoder if the decoder's CXL range is not found in a CFMWS window. Note the change only fixes a hardware hang, but does not implement HPA/SPA translation. Support for this can be added in a follow on patch series.
- https://git.kernel.org/stable/c/031217128990d7f0ab8c46db1afb3cf1e075fd29
- https://git.kernel.org/stable/c/0cab687205986491302cd2e440ef1d253031c221
- https://git.kernel.org/stable/c/2cc1a530ab31c65b52daf3cb5d0883c8b614ea69
- https://git.kernel.org/stable/c/3a3181a71935774bda2398451256d7441426420b
- https://git.kernel.org/stable/c/031217128990d7f0ab8c46db1afb3cf1e075fd29
- https://git.kernel.org/stable/c/0cab687205986491302cd2e440ef1d253031c221
- https://git.kernel.org/stable/c/2cc1a530ab31c65b52daf3cb5d0883c8b614ea69
- https://git.kernel.org/stable/c/3a3181a71935774bda2398451256d7441426420b
Modified: 2025-03-18
CVE-2024-26763
In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/
- https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa
- https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529
- https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90
- https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e
- https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7
- https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75
- https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857
- https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6
- https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa
- https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529
- https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90
- https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e
- https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7
- https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75
- https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857
- https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-18
CVE-2024-26764
In the Linux kernel, the following vulnerability has been resolved: fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio.
- https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487
- https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6
- https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f
- https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942
- https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760
- https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353
- https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7
- https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f
- https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487
- https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6
- https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f
- https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942
- https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760
- https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353
- https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7
- https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-18
CVE-2024-26765
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 ... Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58
- https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a
- https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f
- https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53
- https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464
- https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a
- https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f
- https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53
- https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464
Modified: 2025-02-27
CVE-2024-26766
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
Unfortunately the commit `fd8958efe877` introduced another error
causing the `descs` array to overflow. This reults in further crashes
easily reproducible by `sendmsg` system call.
[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
--
[ 1080.974535] Call Trace:
[ 1080.976990]
- https://git.kernel.org/stable/c/115b7f3bc1dce590a6851a2dcf23dc1100c49790
- https://git.kernel.org/stable/c/3f38d22e645e2e994979426ea5a35186102ff3c2
- https://git.kernel.org/stable/c/47ae64df23ed1318e27bd9844e135a5e1c0e6e39
- https://git.kernel.org/stable/c/52dc9a7a573dbf778625a0efca0fca55489f084b
- https://git.kernel.org/stable/c/5833024a9856f454a964a198c63a57e59e07baf5
- https://git.kernel.org/stable/c/9034a1bec35e9f725315a3bb6002ef39666114d9
- https://git.kernel.org/stable/c/a2fef1d81becf4ff60e1a249477464eae3c3bc2a
- https://git.kernel.org/stable/c/e6f57c6881916df39db7d95981a8ad2b9c3458d6
- https://git.kernel.org/stable/c/115b7f3bc1dce590a6851a2dcf23dc1100c49790
- https://git.kernel.org/stable/c/3f38d22e645e2e994979426ea5a35186102ff3c2
- https://git.kernel.org/stable/c/47ae64df23ed1318e27bd9844e135a5e1c0e6e39
- https://git.kernel.org/stable/c/52dc9a7a573dbf778625a0efca0fca55489f084b
- https://git.kernel.org/stable/c/5833024a9856f454a964a198c63a57e59e07baf5
- https://git.kernel.org/stable/c/9034a1bec35e9f725315a3bb6002ef39666114d9
- https://git.kernel.org/stable/c/a2fef1d81becf4ff60e1a249477464eae3c3bc2a
- https://git.kernel.org/stable/c/e6f57c6881916df39db7d95981a8ad2b9c3458d6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-26769
In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item.
- https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd
- https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4
- https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397
- https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8
- https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30
- https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd
- https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4
- https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397
- https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8
- https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30
Modified: 2025-01-27
CVE-2024-26771
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Add some null pointer checks to the edma_probe devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
- https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d
- https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369
- https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27
- https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49
- https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce
- https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e
- https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d
- https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369
- https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27
- https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49
- https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce
- https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-26772
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap.
- https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a
- https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43
- https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d
- https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513
- https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff
- https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916
- https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586
- https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7
- https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a
- https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43
- https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d
- https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513
- https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff
- https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916
- https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586
- https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-18
CVE-2024-26773
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group
- https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1
- https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea
- https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d
- https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53
- https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5
- https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03
- https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe
- https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36
- https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1
- https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea
- https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d
- https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53
- https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5
- https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03
- https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe
- https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-06-19
CVE-2024-26774
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Determine if bb_fragments is 0 instead of determining bb_free to eliminate the risk of dividing by zero when the block bitmap is corrupted.
- https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150
- https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3
- https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b
- https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a
- https://git.kernel.org/stable/c/687061cfaa2ac3095170e136dd9c29a4974f41d4
- https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150
- https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3
- https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b
- https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a
Modified: 2025-07-17
CVE-2024-26775
In the Linux kernel, the following vulnerability has been resolved:
aoe: avoid potential deadlock at set_capacity
Move set_capacity() outside of the section procected by (&d->lock).
To avoid possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
[1] lock(&bdev->bd_size_lock);
local_irq_disable();
[2] lock(&d->lock);
[3] lock(&bdev->bd_size_lock);
- https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77
- https://git.kernel.org/stable/c/2499fa286fb010ceb289950050199f33c26667b9
- https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26
- https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c
- https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86
- https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77
- https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26
- https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c
- https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86
Modified: 2025-02-27
CVE-2024-26776
In the Linux kernel, the following vulnerability has been resolved: spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc
- https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d
- https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4
- https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9
- https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd
- https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5
- https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8
- https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d
- https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4
- https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9
- https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd
- https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5
- https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26777
In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.
- https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b
- https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207
- https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e
- https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb
- https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313
- https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1
- https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52
- https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99
- https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b
- https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207
- https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e
- https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb
- https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313
- https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1
- https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52
- https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-27
CVE-2024-26778
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.
- https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288
- https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4
- https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1
- https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24
- https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff
- https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1
- https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01
- https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13
- https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288
- https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4
- https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1
- https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24
- https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff
- https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1
- https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01
- https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-26779
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.
- https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9
- https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954
- https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd
- https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587
- https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5
- https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d
- https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f
- https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696
- https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9
- https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954
- https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd
- https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587
- https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5
- https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d
- https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f
- https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-18
CVE-2024-26780
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix task hung while purging oob_skb in GC.
syzbot reported a task hung; at the same time, GC was looping infinitely
in list_for_each_entry_safe() for OOB skb. [0]
syzbot demonstrated that the list_for_each_entry_safe() was not actually
safe in this case.
A single skb could have references for multiple sockets. If we free such
a skb in the list_for_each_entry_safe(), the current and next sockets could
be unlinked in a single iteration.
unix_notinflight() uses list_del_init() to unlink the socket, so the
prefetched next socket forms a loop itself and list_for_each_entry_safe()
never stops.
Here, we must use while() and make sure we always fetch the first socket.
[0]:
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline]
RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]
RIP: 0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207
Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74
RSP: 0018:ffffc900033efa58 EFLAGS: 00000283
RAX: ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189
RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70
RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c
R10: ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800
R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/25236c91b5ab4a26a56ba2e79b8060cf4e047839
- https://git.kernel.org/stable/c/2a3d40b4025fcfe51b04924979f1653993b17669
- https://git.kernel.org/stable/c/36f7371de977f805750748e80279be7e370df85c
- https://git.kernel.org/stable/c/69e0f04460f4037e01e29f0d9675544f62aafca3
- https://git.kernel.org/stable/c/cb8890318dde26fc89c6ea67d6e9070ab50b6e91
- https://git.kernel.org/stable/c/25236c91b5ab4a26a56ba2e79b8060cf4e047839
- https://git.kernel.org/stable/c/2a3d40b4025fcfe51b04924979f1653993b17669
- https://git.kernel.org/stable/c/36f7371de977f805750748e80279be7e370df85c
- https://git.kernel.org/stable/c/69e0f04460f4037e01e29f0d9675544f62aafca3
- https://git.kernel.org/stable/c/cb8890318dde26fc89c6ea67d6e9070ab50b6e91
Modified: 2025-01-10
CVE-2024-26782
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix double-free on socket dismantle
when MPTCP server accepts an incoming connection, it clones its listener
socket. However, the pointer to 'inet_opt' for the new socket has the same
value as the original one: as a consequence, on program exit it's possible
to observe the following splat:
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
Free of addr ffff888485950880 by task swapper/25/0
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
Call Trace:
- https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c
- https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e
- https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc
- https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582
- https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85
- https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e
- https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c
- https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e
- https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc
- https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582
- https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85
- https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-20
CVE-2024-26787
In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.
- https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53
- https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4
- https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c
- https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be
- https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef
- https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85
- https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53
- https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4
- https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c
- https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be
- https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef
- https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-01
CVE-2024-26788
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18
- https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478
- https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b
- https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99
- https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8
- https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd
- https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1
- https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d
- https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478
- https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b
- https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99
- https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8
- https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd
- https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1
- https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-26789
In the Linux kernel, the following vulnerability has been resolved: crypto: arm64/neonbs - fix out-of-bounds access on short input The bit-sliced implementation of AES-CTR operates on blocks of 128 bytes, and will fall back to the plain NEON version for tail blocks or inputs that are shorter than 128 bytes to begin with. It will call straight into the plain NEON asm helper, which performs all memory accesses in granules of 16 bytes (the size of a NEON register). For this reason, the associated plain NEON glue code will copy inputs shorter than 16 bytes into a temporary buffer, given that this is a rare occurrence and it is not worth the effort to work around this in the asm code. The fallback from the bit-sliced NEON version fails to take this into account, potentially resulting in out-of-bounds accesses. So clone the same workaround, and use a temp buffer for short in/outputs.
- https://git.kernel.org/stable/c/034e2d70b5c7f578200ad09955aeb2aa65d1164a
- https://git.kernel.org/stable/c/1291d278b5574819a7266568ce4c28bce9438705
- https://git.kernel.org/stable/c/1c0cf6d19690141002889d72622b90fc01562ce4
- https://git.kernel.org/stable/c/9e8ecd4908b53941ab6f0f51584ab80c6c6606c4
- https://git.kernel.org/stable/c/034e2d70b5c7f578200ad09955aeb2aa65d1164a
- https://git.kernel.org/stable/c/1291d278b5574819a7266568ce4c28bce9438705
- https://git.kernel.org/stable/c/1c0cf6d19690141002889d72622b90fc01562ce4
- https://git.kernel.org/stable/c/9e8ecd4908b53941ab6f0f51584ab80c6c6606c4
Modified: 2025-02-27
CVE-2024-26790
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ). Implement this workaround.
- https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce
- https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa
- https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da
- https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367
- https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e
- https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471
- https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580
- https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce
- https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa
- https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da
- https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367
- https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e
- https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471
- https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-20
CVE-2024-26791
In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).
- https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84
- https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d
- https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
- https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4
- https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9
- https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1
- https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311
- https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8
- https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84
- https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d
- https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
- https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4
- https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9
- https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1
- https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311
- https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-20
CVE-2024-26792
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix double free of anonymous device after snapshot creation failure
When creating a snapshot we may do a double free of an anonymous device
in case there's an error committing the transaction. The second free may
result in freeing an anonymous device number that was allocated by some
other subsystem in the kernel or another btrfs filesystem.
The steps that lead to this:
1) At ioctl.c:create_snapshot() we allocate an anonymous device number
and assign it to pending_snapshot->anon_dev;
2) Then we call btrfs_commit_transaction() and end up at
transaction.c:create_pending_snapshot();
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device
number stored in pending_snapshot->anon_dev;
4) btrfs_get_new_fs_root() frees that anonymous device number because
btrfs_lookup_fs_root() returned a root - someone else did a lookup
of the new root already, which could some task doing backref walking;
5) After that some error happens in the transaction commit path, and at
ioctl.c:create_snapshot() we jump to the 'fail' label, and after
that we free again the same anonymous device number, which in the
meanwhile may have been reallocated somewhere else, because
pending_snapshot->anon_dev still has the same value as in step 1.
Recently syzbot ran into this and reported the following trace:
------------[ cut here ]------------
ida_free called for id=51 which is not allocated.
WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525
Modules linked in:
CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525
Code: 10 42 80 3c 28 (...)
RSP: 0018:ffffc90015a67300 EFLAGS: 00010246
RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000
RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000
RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4
R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246
R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246
FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0
Call Trace:
- https://git.kernel.org/stable/c/c34adc20b91a8e55e048b18d63f4f4ae003ecf8f
- https://git.kernel.org/stable/c/c8ab7521665bd0f8bc4a900244d1d5a7095cc3b9
- https://git.kernel.org/stable/c/e2b54eaf28df0c978626c9736b94f003b523b451
- https://git.kernel.org/stable/c/eb3441093aad251418921246fc3b224fd1575701
- https://git.kernel.org/stable/c/c34adc20b91a8e55e048b18d63f4f4ae003ecf8f
- https://git.kernel.org/stable/c/c8ab7521665bd0f8bc4a900244d1d5a7095cc3b9
- https://git.kernel.org/stable/c/e2b54eaf28df0c978626c9736b94f003b523b451
- https://git.kernel.org/stable/c/eb3441093aad251418921246fc3b224fd1575701
Modified: 2024-12-20
CVE-2024-26793
In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated---
- https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb
- https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8
- https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e
- https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16
- https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e
- https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627
- https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69
- https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6
- https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb
- https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8
- https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e
- https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16
- https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e
- https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627
- https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69
- https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-19
CVE-2024-26795
In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments
- https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe
- https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef
- https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af
- https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd
- https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9
- https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e
- https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe
- https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef
- https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af
- https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd
- https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9
- https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-03-17
CVE-2024-26798
In the Linux kernel, the following vulnerability has been resolved:
fbcon: always restore the old font data in fbcon_do_set_font()
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().
This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
BUG: unable to handle page fault for address: fffffffffffffff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
Call Trace:
- https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f
- https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d
- https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b
- https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520
- https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8
- https://git.kernel.org/stable/c/ae68f57df3335679653868fafccd8c88ef84ae98
- https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f
- https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d
- https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b
- https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520
- https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8
Modified: 2024-12-20
CVE-2024-26801
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth
- https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592
- https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b
- https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1
- https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2
- https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090
- https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14
- https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1
- https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03
- https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592
- https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b
- https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1
- https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2
- https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090
- https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14
- https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1
- https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-04
CVE-2024-26802
In the Linux kernel, the following vulnerability has been resolved:
stmmac: Clear variable when destroying workqueue
Currently when suspending driver and stopping workqueue it is checked whether
workqueue is not NULL and if so, it is destroyed.
Function destroy_workqueue() does drain queue and does clear variable, but
it does not set workqueue variable to NULL. This can cause kernel/module
panic if code attempts to clear workqueue that was not initialized.
This scenario is possible when resuming suspended driver in stmmac_resume(),
because there is no handling for failed stmmac_hw_setup(),
which can fail and return if DMA engine has failed to initialize,
and workqueue is initialized after DMA engine.
Should DMA engine fail to initialize, resume will proceed normally,
but interface won't work and TX queue will eventually timeout,
causing 'Reset adapter' error.
This then does destroy workqueue during reset process.
And since workqueue is initialized after DMA engine and can be skipped,
it will cause kernel/module panic.
To secure against this possible crash, set workqueue variable to NULL when
destroying workqueue.
Log/backtrace from crash goes as follows:
[88.031977]------------[ cut here ]------------
[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out
[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398
- https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6
- https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3
- https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f
- https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462
- https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8
- https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6
- https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3
- https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f
- https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462
- https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8
Modified: 2025-04-01
CVE-2024-26803
In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths.
- https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664
- https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325
- https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941
- https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c
- https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736
- https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664
- https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325
- https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941
- https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c
- https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736
Modified: 2025-03-21
CVE-2024-26804
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.
- https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b
- https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee
- https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
- https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9
- https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96
- https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282
- https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383
- https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b
- https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee
- https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
- https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9
- https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96
- https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282
- https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26805
In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated---
- https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44
- https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d
- https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd
- https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777
- https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285
- https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736
- https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65
- https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77
- https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44
- https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d
- https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd
- https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777
- https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285
- https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736
- https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65
- https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-19
CVE-2024-26809
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: release elements in clone only from destroy path Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice. This fix requires: 212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol") which came after: 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").
- https://git.kernel.org/stable/c/362508506bf545e9ce18c72a2c48dcbfb891ab9c
- https://git.kernel.org/stable/c/5ad233dc731ab64cdc47b84a5c1f78fff6c024af
- https://git.kernel.org/stable/c/821e28d5b506e6a73ccc367ff792bd894050d48b
- https://git.kernel.org/stable/c/9384b4d85c46ce839f51af01374062ce6318b2f2
- https://git.kernel.org/stable/c/b0e256f3dd2ba6532f37c5c22e07cb07a36031ee
- https://git.kernel.org/stable/c/b36b83297ff4910dfc8705402c8abffd4bbf8144
- https://git.kernel.org/stable/c/ff90050771412b91e928093ccd8736ae680063c2
- https://git.kernel.org/stable/c/362508506bf545e9ce18c72a2c48dcbfb891ab9c
- https://git.kernel.org/stable/c/5ad233dc731ab64cdc47b84a5c1f78fff6c024af
- https://git.kernel.org/stable/c/821e28d5b506e6a73ccc367ff792bd894050d48b
- https://git.kernel.org/stable/c/9384b4d85c46ce839f51af01374062ce6318b2f2
- https://git.kernel.org/stable/c/b0e256f3dd2ba6532f37c5c22e07cb07a36031ee
- https://git.kernel.org/stable/c/b36b83297ff4910dfc8705402c8abffd4bbf8144
- https://git.kernel.org/stable/c/ff90050771412b91e928093ccd8736ae680063c2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26810
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows.
- https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf
- https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651
- https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42
- https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3
- https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5
- https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40
- https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7
- https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6
- https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf
- https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651
- https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42
- https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3
- https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5
- https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40
- https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7
- https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-18
CVE-2024-26812
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Create persistent INTx handler A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending. Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace. As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.
- https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034
- https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d
- https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897
- https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834
- https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c
- https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e
- https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3
- https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899
- https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034
- https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d
- https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897
- https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834
- https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c
- https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e
- https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3
- https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-20
CVE-2024-26813
In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index.
- https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e
- https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5
- https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29
- https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086
- https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375
- https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362
- https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a
- https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f
- https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e
- https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5
- https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29
- https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086
- https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375
- https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362
- https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a
- https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-27
CVE-2024-26814
In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.
- https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417
- https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d
- https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9
- https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012
- https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede
- https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d
- https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267
- https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417
- https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d
- https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9
- https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012
- https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede
- https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d
- https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-27
CVE-2024-26815
In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check
taprio_parse_tc_entry() is not correctly checking
TCA_TAPRIO_TC_ENTRY_INDEX attribute:
int tc; // Signed value
tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]);
if (tc >= TC_QOPT_MAX_QUEUE) {
NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range");
return -ERANGE;
}
syzbot reported that it could fed arbitary negative values:
UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18
shift exponent -2147418108 is negative
CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Call Trace:
- https://git.kernel.org/stable/c/343041b59b7810f9cdca371f445dd43b35c740b1
- https://git.kernel.org/stable/c/6915b1b28fe57e92c78e664366dc61c4f15ff03b
- https://git.kernel.org/stable/c/860e838fb089d652a446ced52cbdf051285b68e7
- https://git.kernel.org/stable/c/9b720bb1a69a9f12a4a5c86b6f89386fe05ed0f2
- https://git.kernel.org/stable/c/bd2474a45df7c11412c2587de3d4e43760531418
- https://git.kernel.org/stable/c/343041b59b7810f9cdca371f445dd43b35c740b1
- https://git.kernel.org/stable/c/6915b1b28fe57e92c78e664366dc61c4f15ff03b
- https://git.kernel.org/stable/c/860e838fb089d652a446ced52cbdf051285b68e7
- https://git.kernel.org/stable/c/9b720bb1a69a9f12a4a5c86b6f89386fe05ed0f2
- https://git.kernel.org/stable/c/bd2474a45df7c11412c2587de3d4e43760531418
Modified: 2025-03-27
CVE-2024-26816
In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map.
- https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03
- https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723
- https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088
- https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40
- https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a
- https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b
- https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa
- https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c
- https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af
- https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03
- https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723
- https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088
- https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40
- https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a
- https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b
- https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa
- https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c
- https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-02
CVE-2024-26832
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.
- https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffea
- https://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644
- https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abe
- https://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1d
- https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffea
- https://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644
- https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abe
- https://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1d
Modified: 2025-01-07
CVE-2024-26833
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:
unreferenced object 0xffff896302b45800 (size 1024):
comm "(udev-worker)", pid 222, jiffies 4294894636
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 6265fd77):
[
- https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2
- https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e
- https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b
- https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30
- https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857
- https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3
- https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2
- https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e
- https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b
- https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30
- https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857
- https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-02
CVE-2024-26835
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: set dormant flag on hook register failure We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core.
- https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376
- https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af
- https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be
- https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95
- https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7
- https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3
- https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec
- https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069
- https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376
- https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af
- https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be
- https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95
- https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7
- https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3
- https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec
- https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-02
CVE-2024-26837
In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.
- https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f
- https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db
- https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b
- https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8
- https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f
- https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db
- https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b
- https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8
Modified: 2025-04-02
CVE-2024-26838
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix KASAN issue with tasklet
KASAN testing revealed the following issue assocated with freeing an IRQ.
[50006.466686] Call Trace:
[50006.466691]
- https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc
- https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824
- https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa
- https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb
- https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848
- https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc
- https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824
- https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa
- https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb
- https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848
Modified: 2025-01-14
CVE-2024-26839
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.
- https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3
- https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7
- https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25
- https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2
- https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a
- https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896
- https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8
- https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b
- https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3
- https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7
- https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25
- https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2
- https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a
- https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896
- https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8
- https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-07
CVE-2024-26840
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix memory leak in cachefiles_add_cache()
The following memory leak was reported after unbinding /dev/cachefiles:
==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
comm "cachefilesd2", pid 680, jiffies 4294881224
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc ea38a44b):
[
- https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285
- https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3
- https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8
- https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58
- https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579
- https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a
- https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083
- https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444
- https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285
- https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3
- https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8
- https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58
- https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579
- https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a
- https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083
- https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-29
CVE-2024-26843
In the Linux kernel, the following vulnerability has been resolved: efi: runtime: Fix potential overflow of soft-reserved region size md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region.
- https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0
- https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9
- https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426
- https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be
- https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70
- https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4
- https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0
- https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9
- https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426
- https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be
- https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70
- https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-02
CVE-2024-26844
In the Linux kernel, the following vulnerability has been resolved: block: Fix WARNING in _copy_from_iter Syzkaller reports a warning in _copy_from_iter because an iov_iter is supposedly used in the wrong direction. The reason is that syzcaller managed to generate a request with a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs the kernel to copy user buffers into the kernel, read into the copied buffers and then copy the data back to user space. Thus the iovec is used in both directions. Detect this situation in the block layer and construct a new iterator with the correct direction for the copy-in.
- https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956
- https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6
- https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b
- https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b
- https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956
- https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6
- https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b
- https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b
Modified: 2026-01-05
CVE-2024-26845
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Add TMF to tmr_list handling An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core.
- https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d
- https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf
- https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb
- https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25
- https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d
- https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f
- https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a
- https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d
- https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf
- https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb
- https://git.kernel.org/stable/c/425a571a7e6fc389954cf2564e1edbba3740e171
- https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25
- https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d
- https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f
- https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-21
CVE-2024-26846
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue. While at it, remove the unused nvme_fc_wq workqueue too.
- https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17
- https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c
- https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2
- https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982
- https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9
- https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67
- https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17
- https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c
- https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2
- https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982
- https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9
- https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-04-18
CVE-2024-26849
In the Linux kernel, the following vulnerability has been resolved: netlink: add nla be16/32 types to minlen array BUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline] BUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline] BUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline] BUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [inline] nla_validate_int_range lib/nlattr.c:336 [inline] validate_nla lib/nlattr.c:575 [inline] ... The message in question matches this policy: [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255), but because NLA_BE32 size in minlen array is 0, the validation code will read past the malformed (too small) attribute. Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing: those likely should be added too.
- https://git.kernel.org/stable/c/000a68159c0326b46c42ec712ab98793e7e625a7
- https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32
- https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d
- https://git.kernel.org/stable/c/80b40f9cb87f3bf5877dfb852765cf92bc03ca77
- https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a
- https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d
- https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32
- https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d
- https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a
- https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d
Modified: 2025-04-02
CVE-2024-26851
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
that are out of bounds for their data type.
vmlinux get_bitmap(b=75) + 712
- https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c
- https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591
- https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a
- https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362
- https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416
- https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb
- https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13
- https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc
- https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c
- https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591
- https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a
- https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362
- https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416
- https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb
- https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13
- https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-21
CVE-2024-26852
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
Commit f7225172f25a ("net/ipv6: prevent use after free in
ip6_route_mpath_notify") was not able to fix the root cause.
We need to defer the fib6_info_release() calls after
ip6_route_mpath_notify(), in the cleanup phase.
[1]
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
- https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136
- https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18
- https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda
- https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e
- https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab
- https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe
- https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24
- https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a
- https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136
- https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18
- https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda
- https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e
- https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab
- https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe
- https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24
- https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-02
CVE-2024-26853
In the Linux kernel, the following vulnerability has been resolved: igc: avoid returning frame twice in XDP_REDIRECT When a frame can not be transmitted in XDP_REDIRECT (e.g. due to a full queue), it is necessary to free it by calling xdp_return_frame_rx_napi. However, this is the responsibility of the caller of the ndo_xdp_xmit (see for example bq_xmit_all in kernel/bpf/devmap.c) and thus calling it inside igc_xdp_xmit (which is the ndo_xdp_xmit of the igc driver) as well will lead to memory corruption. In fact, bq_xmit_all expects that it can return all frames after the last successfully transmitted one. Therefore, break for the first not transmitted frame, but do not call xdp_return_frame_rx_napi in igc_xdp_xmit. This is equally implemented in other Intel drivers such as the igb. There are two alternatives to this that were rejected: 1. Return num_frames as all the frames would have been transmitted and release them inside igc_xdp_xmit. While it might work technically, it is not what the return value is meant to represent (i.e. the number of SUCCESSFULLY transmitted packets). 2. Rework kernel/bpf/devmap.c and all drivers to support non-consecutively dropped packets. Besides being complex, it likely has a negative performance impact without a significant gain since it is anyway unlikely that the next frame can be transmitted if the previous one was dropped. The memory corruption can be reproduced with the following script which leads to a kernel panic after a few seconds. It basically generates more traffic than a i225 NIC can transmit and pushes it via XDP_REDIRECT from a virtual interface to the physical interface where frames get dropped. #!/bin/bash INTERFACE=enp4s0 INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex` sudo ip link add dev veth1 type veth peer name veth2 sudo ip link set up $INTERFACE sudo ip link set up veth1 sudo ip link set up veth2 cat << EOF > redirect.bpf.c SEC("prog") int redirect(struct xdp_md *ctx) { return bpf_redirect($INTERFACE_IDX, 0); } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o sudo ip link set veth2 xdp obj redirect.bpf.o cat << EOF > pass.bpf.c SEC("prog") int pass(struct xdp_md *ctx) { return XDP_PASS; } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o sudo ip link set $INTERFACE xdp obj pass.bpf.o cat << EOF > trafgen.cfg { /* Ethernet Header */ 0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, const16(ETH_P_IP), /* IPv4 Header */ 0b01000101, 0, # IPv4 version, IHL, TOS const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header)) const16(2), # IPv4 ident 0b01000000, 0, # IPv4 flags, fragmentation off 64, # IPv4 TTL 17, # Protocol UDP csumip(14, 33), # IPv4 checksum /* UDP Header */ 10, 0, 1, 1, # IP Src - adapt as needed 10, 0, 1, 2, # IP Dest - adapt as needed const16(6666), # UDP Src Port const16(6666), # UDP Dest Port const16(1008), # UDP length (UDP header 8 bytes + payload length) csumudp(14, 34), # UDP checksum /* Payload */ fill('W', 1000), } EOF sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp
- https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f
- https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2
- https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a
- https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b
- https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f
- https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2
- https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a
- https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b
Modified: 2025-01-07
CVE-2024-26855
In the Linux kernel, the following vulnerability has been resolved: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() The function ice_bridge_setlink() may encounter a NULL pointer dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration.
- https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c
- https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f
- https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3
- https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309
- https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19
- https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596
- https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb
- https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c
- https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f
- https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3
- https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309
- https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19
- https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596
- https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26856
In the Linux kernel, the following vulnerability has been resolved: net: sparx5: Fix use after free inside sparx5_del_mact_entry Based on the static analyzis of the code it looks like when an entry from the MAC table was removed, the entry was still used after being freed. More precise the vid of the mac_entry was used after calling devm_kfree on the mac_entry. The fix consists in first using the vid of the mac_entry to delete the entry from the HW and after that to free it.
- https://git.kernel.org/stable/c/0de693d68b0a18d5e256556c7c62d92cca35ad52
- https://git.kernel.org/stable/c/71809805b95052ff551922f11660008fb3666025
- https://git.kernel.org/stable/c/89d72d4125e94aa3c2140fedd97ce07ba9e37674
- https://git.kernel.org/stable/c/e46274df1100fb0c06704195bfff5bfbd418bf64
- https://git.kernel.org/stable/c/e83bebb718fd1f42549358730e1206164e0861d6
- https://git.kernel.org/stable/c/0de693d68b0a18d5e256556c7c62d92cca35ad52
- https://git.kernel.org/stable/c/71809805b95052ff551922f11660008fb3666025
- https://git.kernel.org/stable/c/89d72d4125e94aa3c2140fedd97ce07ba9e37674
- https://git.kernel.org/stable/c/e46274df1100fb0c06704195bfff5bfbd418bf64
- https://git.kernel.org/stable/c/e83bebb718fd1f42549358730e1206164e0861d6
Modified: 2025-03-21
CVE-2024-26857
In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
- https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca
- https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5
- https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74
- https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29
- https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5
- https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c
- https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914
- https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a
- https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca
- https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5
- https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74
- https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29
- https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5
- https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c
- https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914
- https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-04
CVE-2024-26859
In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge() 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp, 800 struct bnx2x_fastpath *fp, u16 index) 801 { 802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index]; 803 struct page *page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 To solve this issue, we need to verify page pool allocations before freeing.
- https://git.kernel.org/stable/c/3a9f78b297e08ca8e88ae3ecff1f6fe2766dc5eb
- https://git.kernel.org/stable/c/44f9f1abb0ecc43023225ab9539167facbabf0ec
- https://git.kernel.org/stable/c/4f37d3a7e004bbf560c21441ca9c022168017ec4
- https://git.kernel.org/stable/c/7bcc090c81116c66936a7415f2c6b1483a4bcfd9
- https://git.kernel.org/stable/c/8eebff95ce9558be66a36aa7cfb43223f3ab4699
- https://git.kernel.org/stable/c/8ffcd3ccdbda0c918c4a0f922ef1c17010f1b598
- https://git.kernel.org/stable/c/c51f8b6930db3f259b8820b589f2459d2df3fc68
- https://git.kernel.org/stable/c/cf7d8cba639ae792a42c2a137b495eac262ac36c
- https://git.kernel.org/stable/c/d27e2da94a42655861ca4baea30c8cd65546f25d
- https://git.kernel.org/stable/c/3a9f78b297e08ca8e88ae3ecff1f6fe2766dc5eb
- https://git.kernel.org/stable/c/44f9f1abb0ecc43023225ab9539167facbabf0ec
- https://git.kernel.org/stable/c/4f37d3a7e004bbf560c21441ca9c022168017ec4
- https://git.kernel.org/stable/c/7bcc090c81116c66936a7415f2c6b1483a4bcfd9
- https://git.kernel.org/stable/c/8eebff95ce9558be66a36aa7cfb43223f3ab4699
- https://git.kernel.org/stable/c/8ffcd3ccdbda0c918c4a0f922ef1c17010f1b598
- https://git.kernel.org/stable/c/c51f8b6930db3f259b8820b589f2459d2df3fc68
- https://git.kernel.org/stable/c/cf7d8cba639ae792a42c2a137b495eac262ac36c
- https://git.kernel.org/stable/c/d27e2da94a42655861ca4baea30c8cd65546f25d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-02
CVE-2024-26861
In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...
- https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6
- https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce
- https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b
- https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3
- https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0
- https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc
- https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed
- https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6
- https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce
- https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b
- https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3
- https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0
- https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc
- https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26862
In the Linux kernel, the following vulnerability has been resolved: packet: annotate data-races around ignore_outgoing ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt() Add appropriate READ_ONCE()/WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 [inline] dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 worker_thread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
- https://git.kernel.org/stable/c/2c02c5059c78a52d170bdee4a369b470de6deb37
- https://git.kernel.org/stable/c/68e84120319d4fc298fcdb14cf0bea6a0f64ffbd
- https://git.kernel.org/stable/c/6ebfad33161afacb3e1e59ed1c2feefef70f9f97
- https://git.kernel.org/stable/c/84c510411e321caff3c07e6cd0f917f06633cfc0
- https://git.kernel.org/stable/c/8b1e273c6afcf00d3c40a54ada7d6aac1b503b97
- https://git.kernel.org/stable/c/d35b62c224e70797f8a1c37fe9bc4b3e294b7560
- https://git.kernel.org/stable/c/ee413f30ec4fe94a0bdf32c8f042cb06fa913234
- https://git.kernel.org/stable/c/ef7eed7e11d23337310ecc2c014ecaeea52719c5
- https://git.kernel.org/stable/c/2c02c5059c78a52d170bdee4a369b470de6deb37
- https://git.kernel.org/stable/c/68e84120319d4fc298fcdb14cf0bea6a0f64ffbd
- https://git.kernel.org/stable/c/6ebfad33161afacb3e1e59ed1c2feefef70f9f97
- https://git.kernel.org/stable/c/84c510411e321caff3c07e6cd0f917f06633cfc0
- https://git.kernel.org/stable/c/8b1e273c6afcf00d3c40a54ada7d6aac1b503b97
- https://git.kernel.org/stable/c/d35b62c224e70797f8a1c37fe9bc4b3e294b7560
- https://git.kernel.org/stable/c/ee413f30ec4fe94a0bdf32c8f042cb06fa913234
- https://git.kernel.org/stable/c/ef7eed7e11d23337310ecc2c014ecaeea52719c5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-27
CVE-2024-26863
In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in hsr_get_node() KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.
- https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209
- https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122
- https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862
- https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a
- https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428
- https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e
- https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949
- https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6
- https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c
- https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209
- https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122
- https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862
- https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a
- https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428
- https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e
- https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949
- https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6
- https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-07
CVE-2024-26865
In the Linux kernel, the following vulnerability has been resolved:
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
syzkaller reported a warning of netns tracker [0] followed by KASAN
splat [1] and another ref tracker warning [1].
syzkaller could not find a repro, but in the log, the only suspicious
sequence was as follows:
18:26:22 executing program 1:
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
...
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
So, the scenario would be:
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
rds_tcp_listen_init().
2. syz-executor connect()s to it and creates a reqsk.
3. syz-executor exit()s immediately.
4. netns is dismantled. [0]
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
6. listener is freed after RCU grace period. [2]
Basically, reqsk assumes that the listener guarantees netns safety
until all reqsk timers are expired by holding the listener's refcount.
However, this was not the case for kernel sockets.
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
inet_twsk_purge()") fixed this issue only for per-netns ehash.
Let's apply the same fix for the global ehash.
[0]:
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
__sock_create (net/socket.c:1572)
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
rds_tcp_init_net (net/rds/tcp.c:577)
ops_init (net/core/net_namespace.c:137)
setup_net (net/core/net_namespace.c:340)
copy_net_ns (net/core/net_namespace.c:497)
create_new_namespaces (kernel/nsproxy.c:110)
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
ksys_unshare (kernel/fork.c:3429)
__x64_sys_unshare (kernel/fork.c:3496)
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
...
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
[1]:
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3
- https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24
- https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6
- https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500
- https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279
- https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3
- https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24
- https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6
- https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500
- https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279
Modified: 2025-01-14
CVE-2024-26868
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix panic when nfs4_ff_layout_prepare_ds() fails
We've been seeing the following panic in production
BUG: kernel NULL pointer dereference, address: 0000000000000065
PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0
RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
Call Trace:
- https://git.kernel.org/stable/c/31db25e3141b20e2a76a9f219eeca52e3cab126c
- https://git.kernel.org/stable/c/5ada9016b1217498fad876a3d5b07645cc955608
- https://git.kernel.org/stable/c/719fcafe07c12646691bd62d7f8d94d657fa0766
- https://git.kernel.org/stable/c/7ca651b4ec4a049f5a46a0e5ff921b86b91c47c5
- https://git.kernel.org/stable/c/dac068f164ad05b35e7c0be13f138c3f6adca58f
- https://git.kernel.org/stable/c/31db25e3141b20e2a76a9f219eeca52e3cab126c
- https://git.kernel.org/stable/c/5ada9016b1217498fad876a3d5b07645cc955608
- https://git.kernel.org/stable/c/719fcafe07c12646691bd62d7f8d94d657fa0766
- https://git.kernel.org/stable/c/7ca651b4ec4a049f5a46a0e5ff921b86b91c47c5
- https://git.kernel.org/stable/c/dac068f164ad05b35e7c0be13f138c3f6adca58f
Modified: 2025-04-30
CVE-2024-26870
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size.
- https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb
- https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf
- https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65
- https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b
- https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768
- https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf
- https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a
- https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb
- https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf
- https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65
- https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b
- https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768
- https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf
- https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26872
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete.
- https://git.kernel.org/stable/c/6413e78086caf7bf15639923740da0d91fdfd090
- https://git.kernel.org/stable/c/7104a00fa37ae898a827381f1161fa3286c8b346
- https://git.kernel.org/stable/c/85570b91e4820a0db9d9432098778cafafa7d217
- https://git.kernel.org/stable/c/bdd895e0190c464f54f84579e7535d80276f0fc5
- https://git.kernel.org/stable/c/c21a8870c98611e8f892511825c9607f1e2cd456
- https://git.kernel.org/stable/c/e362d007294955a4fb929e1c8978154a64efdcb6
- https://git.kernel.org/stable/c/ec77fa12da41260c6bf9e060b89234b980c5130f
- https://git.kernel.org/stable/c/6413e78086caf7bf15639923740da0d91fdfd090
- https://git.kernel.org/stable/c/7104a00fa37ae898a827381f1161fa3286c8b346
- https://git.kernel.org/stable/c/85570b91e4820a0db9d9432098778cafafa7d217
- https://git.kernel.org/stable/c/bdd895e0190c464f54f84579e7535d80276f0fc5
- https://git.kernel.org/stable/c/c21a8870c98611e8f892511825c9607f1e2cd456
- https://git.kernel.org/stable/c/e362d007294955a4fb929e1c8978154a64efdcb6
- https://git.kernel.org/stable/c/ec77fa12da41260c6bf9e060b89234b980c5130f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26874
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use.
- https://git.kernel.org/stable/c/3fc88b246a2fc16014e374040fc15af1d3752535
- https://git.kernel.org/stable/c/4688be96d20ffa49d2186523ee84f475f316fd49
- https://git.kernel.org/stable/c/9acee29a38b4d4b70f1f583e5ef9a245db4db710
- https://git.kernel.org/stable/c/9beec711a17245b853d64488fd5b739031612340
- https://git.kernel.org/stable/c/a3dd12b64ae8373a41a216a0b621df224210860a
- https://git.kernel.org/stable/c/accdac6b71d5a2b84040c3d2234f53a60edc398e
- https://git.kernel.org/stable/c/c958e86e9cc1b48cac004a6e245154dfba8e163b
- https://git.kernel.org/stable/c/d2bd30c710475b2e29288827d2c91f9e6e2b91d7
- https://git.kernel.org/stable/c/dfde84cc6c589f2a9f820f12426d97365670b731
- https://git.kernel.org/stable/c/3fc88b246a2fc16014e374040fc15af1d3752535
- https://git.kernel.org/stable/c/4688be96d20ffa49d2186523ee84f475f316fd49
- https://git.kernel.org/stable/c/9acee29a38b4d4b70f1f583e5ef9a245db4db710
- https://git.kernel.org/stable/c/9beec711a17245b853d64488fd5b739031612340
- https://git.kernel.org/stable/c/a3dd12b64ae8373a41a216a0b621df224210860a
- https://git.kernel.org/stable/c/accdac6b71d5a2b84040c3d2234f53a60edc398e
- https://git.kernel.org/stable/c/c958e86e9cc1b48cac004a6e245154dfba8e163b
- https://git.kernel.org/stable/c/d2bd30c710475b2e29288827d2c91f9e6e2b91d7
- https://git.kernel.org/stable/c/dfde84cc6c589f2a9f820f12426d97365670b731
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-21
CVE-2024-26875
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix uaf in pvr2_context_set_notify
[Syzbot reported]
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: usb_hub_wq hub_event
Call Trace:
- https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee
- https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475
- https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a
- https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592
- https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f
- https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb
- https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16
- https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7
- https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c
- https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee
- https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475
- https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a
- https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592
- https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f
- https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb
- https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16
- https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7
- https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-26877
In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling crypto_finalize_request, BH should be disabled to avoid
triggering the following calltrace:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
Modules linked in: cryptodev(O)
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : crypto_finalize_request+0xa0/0x118
lr : crypto_finalize_request+0x104/0x118
sp : ffffffc085353ce0
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
Call trace:
crypto_finalize_request+0xa0/0x118
crypto_finalize_aead_request+0x18/0x30
zynqmp_handle_aes_req+0xcc/0x388
crypto_pump_work+0x168/0x2d8
kthread_worker_fn+0xfc/0x3a0
kthread+0x118/0x138
ret_from_fork+0x10/0x20
irq event stamp: 40
hardirqs last enabled at (39): [
- https://git.kernel.org/stable/c/03e6d4e948432a61b35783323b6ab2be071d2619
- https://git.kernel.org/stable/c/23bc89fdce71124cd2126fc919c7076e7cb489cf
- https://git.kernel.org/stable/c/8a01335aedc50a66d04dd39203c89f4bc8042596
- https://git.kernel.org/stable/c/9db89b1fb85557892e6681724b367287de5f9f20
- https://git.kernel.org/stable/c/a71f66bd5f7b9b35a8aaa49e29565eca66299399
- https://git.kernel.org/stable/c/a853450bf4c752e664abab0b2fad395b7ad7701c
- https://git.kernel.org/stable/c/dbf291d8ffffb70f48286176a15c6c54f0bb0743
- https://git.kernel.org/stable/c/03e6d4e948432a61b35783323b6ab2be071d2619
- https://git.kernel.org/stable/c/23bc89fdce71124cd2126fc919c7076e7cb489cf
- https://git.kernel.org/stable/c/8a01335aedc50a66d04dd39203c89f4bc8042596
- https://git.kernel.org/stable/c/9db89b1fb85557892e6681724b367287de5f9f20
- https://git.kernel.org/stable/c/a71f66bd5f7b9b35a8aaa49e29565eca66299399
- https://git.kernel.org/stable/c/a853450bf4c752e664abab0b2fad395b7ad7701c
- https://git.kernel.org/stable/c/dbf291d8ffffb70f48286176a15c6c54f0bb0743
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26878
In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue.
- https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25
- https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5
- https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0
- https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0
- https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877
- https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754
- https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1
- https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f
- https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7
- https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25
- https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5
- https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0
- https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0
- https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877
- https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754
- https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1
- https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f
- https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-27
CVE-2024-26879
In the Linux kernel, the following vulnerability has been resolved: clk: meson: Add missing clocks to axg_clk_regmaps Some clocks were missing from axg_clk_regmaps, which caused kernel panic during cat /sys/kernel/debug/clk/clk_summary [ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc ... [ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.436900] pc : regmap_read+0x1c/0x88 [ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.445611] sp : ffff800082f1b690 [ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70 [ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000 [ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000 [ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff [ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000 [ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100 [ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24 [ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710 [ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000 [ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000 [ 57.519615] Call trace: [ 57.522030] regmap_read+0x1c/0x88 [ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.530050] clk_core_is_enabled+0x44/0x120 [ 57.534190] clk_summary_show_subtree+0x154/0x2f0 [ 57.538847] clk_summary_show_subtree+0x220/0x2f0 [ 57.543505] clk_summary_show_subtree+0x220/0x2f0 [ 57.548162] clk_summary_show_subtree+0x220/0x2f0 [ 57.552820] clk_summary_show_subtree+0x220/0x2f0 [ 57.557477] clk_summary_show_subtree+0x220/0x2f0 [ 57.562135] clk_summary_show_subtree+0x220/0x2f0 [ 57.566792] clk_summary_show_subtree+0x220/0x2f0 [ 57.571450] clk_summary_show+0x84/0xb8 [ 57.575245] seq_read_iter+0x1bc/0x4b8 [ 57.578954] seq_read+0x8c/0xd0 [ 57.582059] full_proxy_read+0x68/0xc8 [ 57.585767] vfs_read+0xb0/0x268 [ 57.588959] ksys_read+0x70/0x108 [ 57.592236] __arm64_sys_read+0x24/0x38 [ 57.596031] invoke_syscall+0x50/0x128 [ 57.599740] el0_svc_common.constprop.0+0x48/0xf8 [ 57.604397] do_el0_svc+0x28/0x40 [ 57.607675] el0_svc+0x34/0xb8 [ 57.610694] el0t_64_sync_handler+0x13c/0x158 [ 57.615006] el0t_64_sync+0x190/0x198 [ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00) [ 57.624668] ---[ end trace 0000000000000000 ]--- [jbrunet: add missing Fixes tag]
- https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7
- https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202
- https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8
- https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84
- https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10
- https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418
- https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7
- https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202
- https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8
- https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84
- https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10
- https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418
Modified: 2025-12-23
CVE-2024-26880
In the Linux kernel, the following vulnerability has been resolved:
dm: call the resume method on internal suspend
There is this reported crash when experimenting with the lvm2 testsuite.
The list corruption is caused by the fact that the postsuspend and resume
methods were not paired correctly; there were two consecutive calls to the
origin_postsuspend function. The second call attempts to remove the
"hash_list" entry from a list, while it was already removed by the first
call.
Fix __dm_internal_resume so that it calls the preresume and resume
methods of the table's targets.
If a preresume method of some target fails, we are in a tricky situation.
We can't return an error because dm_internal_resume isn't supposed to
return errors. We can't return success, because then the "resume" and
"postsuspend" methods would not be paired correctly. So, we set the
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
tools, but it won't cause a kernel crash.
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:56!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
- https://git.kernel.org/stable/c/03ad5ad53e51abf3a4c7538c1bc67a5982b41dc5
- https://git.kernel.org/stable/c/15a3fc5c8774c17589dabfe1d642d40685c985af
- https://git.kernel.org/stable/c/360a7d1be8112654f1fb328ed3862be630bca3f4
- https://git.kernel.org/stable/c/65e8fbde64520001abf1c8d0e573561b4746ef38
- https://git.kernel.org/stable/c/69836d9329f0b4c58faaf3d886a7748ddb5bf718
- https://git.kernel.org/stable/c/ad10289f68f45649816cc68eb93f45fd5ec48a15
- https://git.kernel.org/stable/c/da7ece2197101b1469853e6b5e915be1e3896d52
- https://git.kernel.org/stable/c/ef02d8edf738557af2865c5bfb66a03c4e071be7
- https://git.kernel.org/stable/c/f89bd27709376d37ff883067193320c58a8c1d5a
- https://git.kernel.org/stable/c/03ad5ad53e51abf3a4c7538c1bc67a5982b41dc5
- https://git.kernel.org/stable/c/15a3fc5c8774c17589dabfe1d642d40685c985af
- https://git.kernel.org/stable/c/360a7d1be8112654f1fb328ed3862be630bca3f4
- https://git.kernel.org/stable/c/65e8fbde64520001abf1c8d0e573561b4746ef38
- https://git.kernel.org/stable/c/69836d9329f0b4c58faaf3d886a7748ddb5bf718
- https://git.kernel.org/stable/c/ad10289f68f45649816cc68eb93f45fd5ec48a15
- https://git.kernel.org/stable/c/da7ece2197101b1469853e6b5e915be1e3896d52
- https://git.kernel.org/stable/c/ef02d8edf738557af2865c5bfb66a03c4e071be7
- https://git.kernel.org/stable/c/f89bd27709376d37ff883067193320c58a8c1d5a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26881
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is received on HIP08 devices The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash: [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] __handle_domain_irq+0x88/0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.460717] cpu_startup_entry+0x30/0xfc [ 5889.465523] secondary_start_kernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel...
- https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3
- https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4
- https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265
- https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70
- https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6
- https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108
- https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3
- https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4
- https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265
- https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70
- https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6
- https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108
Modified: 2024-12-20
CVE-2024-26882
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
- https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a
- https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a
- https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80
- https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3
- https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0
- https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1
- https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b
- https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5
- https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a
- https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a
- https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80
- https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3
- https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0
- https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1
- https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b
- https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20241220-0002/
Modified: 2025-03-07
CVE-2024-26883
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check on 32-bit arches The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem.
- https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a
- https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895
- https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d
- https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0
- https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a
- https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b
- https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae
- https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3
- https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d
- https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a
- https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895
- https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d
- https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0
- https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a
- https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b
- https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae
- https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3
- https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26884
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup.
- https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5
- https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d
- https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6
- https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1
- https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868
- https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace
- https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016
- https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93
- https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e
- https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5
- https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d
- https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6
- https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1
- https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868
- https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace
- https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016
- https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93
- https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-24
CVE-2024-26885
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation.
- https://git.kernel.org/stable/c/1f5e352b9088211fa5eb4e1639cd365f4f7d2f65
- https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c
- https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691
- https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3
- https://git.kernel.org/stable/c/4b81a9f92b3676cb74b907a7a209b3d15bd9a7f9
- https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3
- https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c
- https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737
- https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c
- https://git.kernel.org/stable/c/225da02acdc97af01b6bc6ce1a3e5362bf01d3fb
- https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691
- https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3
- https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3
- https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c
- https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-21
CVE-2024-26886
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: af_bluetooth: Fix deadlock
Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
bellow, so instead of using sock_sock this uses sk_receive_queue.lock
on bt_sock_ioctl to avoid the UAF:
INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
Not tainted 6.7.6-lemon #183
Workqueue: hci0 hci_rx_work
Call Trace:
- https://git.kernel.org/stable/c/2c9e2df022ef8b9d7fac58a04a2ef4ed25288955
- https://git.kernel.org/stable/c/64be3c6154886200708da0dfe259705fb992416c
- https://git.kernel.org/stable/c/817e8138ce86001b2fa5c63d6ede756e205a01f7
- https://git.kernel.org/stable/c/f7b94bdc1ec107c92262716b073b3e816d4784fb
- https://git.kernel.org/stable/c/2c9e2df022ef8b9d7fac58a04a2ef4ed25288955
- https://git.kernel.org/stable/c/64be3c6154886200708da0dfe259705fb992416c
- https://git.kernel.org/stable/c/817e8138ce86001b2fa5c63d6ede756e205a01f7
- https://git.kernel.org/stable/c/cb8adca52f306563d958a863bb0cbae9c184d1ae
- https://git.kernel.org/stable/c/f7b94bdc1ec107c92262716b073b3e816d4784fb
Modified: 2025-03-21
CVE-2024-26889
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix possible buffer overflow struct hci_dev_info has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy.
- https://git.kernel.org/stable/c/2e845867b4e279eff0a19ade253390470e07e8a1
- https://git.kernel.org/stable/c/2edce8e9a99dd5e4404259d52e754fdc97fb42c2
- https://git.kernel.org/stable/c/54a03e4ac1a41edf8a5087bd59f8241b0de96d3d
- https://git.kernel.org/stable/c/6d5a9d4a7bcbb7534ce45a18a52e7bd23e69d8ac
- https://git.kernel.org/stable/c/81137162bfaa7278785b24c1fd2e9e74f082e8e4
- https://git.kernel.org/stable/c/8c28598a2c29201d2ba7fc37539a7d41c264fb10
- https://git.kernel.org/stable/c/a41c8efe659caed0e21422876bbb6b73c15b5244
- https://git.kernel.org/stable/c/d47e6c1932cee02954ea588c9f09fd5ecefeadfc
- https://git.kernel.org/stable/c/2e845867b4e279eff0a19ade253390470e07e8a1
- https://git.kernel.org/stable/c/2edce8e9a99dd5e4404259d52e754fdc97fb42c2
- https://git.kernel.org/stable/c/54a03e4ac1a41edf8a5087bd59f8241b0de96d3d
- https://git.kernel.org/stable/c/68644bf5ec6baaff40fc39b3529c874bfda709bd
- https://git.kernel.org/stable/c/6d5a9d4a7bcbb7534ce45a18a52e7bd23e69d8ac
- https://git.kernel.org/stable/c/81137162bfaa7278785b24c1fd2e9e74f082e8e4
- https://git.kernel.org/stable/c/8c28598a2c29201d2ba7fc37539a7d41c264fb10
- https://git.kernel.org/stable/c/a41c8efe659caed0e21422876bbb6b73c15b5244
- https://git.kernel.org/stable/c/d47e6c1932cee02954ea588c9f09fd5ecefeadfc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-05-07
CVE-2024-26891
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected
For those endpoint devices connect to system via hotplug capable ports,
users could request a hot reset to the device by flapping device's link
through setting the slot's link control register, as pciehp_ist() DLLSC
interrupt sequence response, pciehp will unload the device driver and
then power it off. thus cause an IOMMU device-TLB invalidation (Intel
VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence
target device to be sent and deadly loop to retry that request after ITE
fault triggered in interrupt context.
That would cause following continuous hard lockup warning and system hang
[ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down
[ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present
[ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144
[ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
OE kernel version xxxx
[ 4223.822623] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490
[ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b
57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1
0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39
[ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093
[ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005
[ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340
[ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000
[ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200
[ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004
[ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000)
knlGS:0000000000000000
[ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0
[ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 4223.822628] PKRU: 55555554
[ 4223.822628] Call Trace:
[ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0
[ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250
[ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50
[ 4223.822629] intel_iommu_release_device+0x1f/0x30
[ 4223.822629] iommu_release_device+0x33/0x60
[ 4223.822629] iommu_bus_notifier+0x7f/0x90
[ 4223.822630] blocking_notifier_call_chain+0x60/0x90
[ 4223.822630] device_del+0x2e5/0x420
[ 4223.822630] pci_remove_bus_device+0x70/0x110
[ 4223.822630] pciehp_unconfigure_device+0x7c/0x130
[ 4223.822631] pciehp_disable_slot+0x6b/0x100
[ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320
[ 4223.822631] pciehp_ist+0x176/0x180
[ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110
[ 4223.822632] irq_thread_fn+0x19/0x50
[ 4223.822632] irq_thread+0x104/0x190
[ 4223.822632] ? irq_forced_thread_fn+0x90/0x90
[ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0
[ 4223.822633] kthread+0x114/0x130
[ 4223.822633] ? __kthread_cancel_work+0x40/0x40
[ 4223.822633] ret_from_fork+0x1f/0x30
[ 4223.822633] Kernel panic - not syncing: Hard LOCKUP
[ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
OE kernel version xxxx
[ 4223.822634] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822634] Call Trace:
[ 4223.822634]
- https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05
- https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062
- https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf
- https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b
- https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868
- https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554
- https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85
- https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05
- https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062
- https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf
- https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b
- https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868
- https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554
- https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-27
CVE-2024-26893
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in SMC transport cleanup path When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash.
- https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4
- https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c
- https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773
- https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d
- https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd
- https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4
- https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c
- https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773
- https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d
- https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd
Modified: 2025-03-21
CVE-2024-26894
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[
- https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2
- https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc
- https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e
- https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5
- https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9
- https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa
- https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51
- https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d
- https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8
- https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2
- https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc
- https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e
- https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5
- https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9
- https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa
- https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51
- https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d
- https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-26895
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver: echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind ================================================================== BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86 CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c [...] Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28 Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...] David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list. Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev) Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe. [1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/
- https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9
- https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447
- https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208
- https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb
- https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f
- https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c
- https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1
- https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9
- https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447
- https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208
- https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb
- https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f
- https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c
- https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-21
CVE-2024-26896
In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix memory leak when starting AP
Kmemleak reported this error:
unreferenced object 0xd73d1180 (size 184):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
backtrace:
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
[<127bdd74>] __alloc_skb+0x144/0x170
[
- https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3
- https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b
- https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3
- https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc
- https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487
- https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3
- https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b
- https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3
- https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc
- https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487
Modified: 2025-12-23
CVE-2024-26897
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data structures have been fully initialised by the time it runs. However, because of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k driver initialisation is completed. We already committed a partial fix for this in commit: 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()") However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event tasklet, pairing it with an "initialisation complete" bit in the TX struct. It seems syzbot managed to trigger the race for one of the other commands as well, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside ath9k_tx_init()).
- https://git.kernel.org/stable/c/1bc5461a21c56a36e2a7d81e152b90ce019a3905
- https://git.kernel.org/stable/c/24355fcb0d4cbcb6ddda262596558e8cfba70f11
- https://git.kernel.org/stable/c/4afa0246656d5680c8a4c3fb37ba6570c4ab819b
- https://git.kernel.org/stable/c/74d0639261dd795dce958d1b14815bdcbb48a715
- https://git.kernel.org/stable/c/a015fbf698c8957aa5fbeefc5c59dd2cf3107298
- https://git.kernel.org/stable/c/ac90e22e735bac44f74b5161fb096fbeb0ff8bc2
- https://git.kernel.org/stable/c/f8ff4b4df71e87f609be0cc37d92e918107f9b90
- https://git.kernel.org/stable/c/1bc5461a21c56a36e2a7d81e152b90ce019a3905
- https://git.kernel.org/stable/c/24355fcb0d4cbcb6ddda262596558e8cfba70f11
- https://git.kernel.org/stable/c/4afa0246656d5680c8a4c3fb37ba6570c4ab819b
- https://git.kernel.org/stable/c/74d0639261dd795dce958d1b14815bdcbb48a715
- https://git.kernel.org/stable/c/a015fbf698c8957aa5fbeefc5c59dd2cf3107298
- https://git.kernel.org/stable/c/ac90e22e735bac44f74b5161fb096fbeb0ff8bc2
- https://git.kernel.org/stable/c/f8ff4b4df71e87f609be0cc37d92e918107f9b90
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-26898
In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts This patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in kthread. Which means that the dev_put(ifp) should NOT be called in the success path of skb initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into use-after-free because the net_device is freed. This patch removed the dev_put(ifp) in the success path in aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().
- https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c
- https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881
- https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa
- https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4
- https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e
- https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99
- https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62
- https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662
- https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65
- https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c
- https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881
- https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa
- https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4
- https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e
- https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99
- https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62
- https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662
- https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26901
In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem.
- https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43
- https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71
- https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1
- https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b
- https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b
- https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b
- https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730
- https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126
- https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6
- https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43
- https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71
- https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1
- https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b
- https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b
- https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b
- https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730
- https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126
- https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26903
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx.
- https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26
- https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b
- https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5
- https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73
- https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85
- https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd
- https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96
- https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0
- https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26
- https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b
- https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5
- https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73
- https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85
- https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd
- https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96
- https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-16
CVE-2024-26906
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault()
When trying to use copy_from_kernel_nofault() to read vsyscall page
through a bpf program, the following oops was reported:
BUG: unable to handle page fault for address: ffffffffff600000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
RIP: 0010:copy_from_kernel_nofault+0x6f/0x110
......
Call Trace:
- https://git.kernel.org/stable/c/29bd6f86904682adafe9affbc7f79b14defcaff8
- https://git.kernel.org/stable/c/32019c659ecfe1d92e3bf9fcdfbb11a7c70acd58
- https://git.kernel.org/stable/c/57f78c46f08198e1be08ffe99c4c1ccc12855bf5
- https://git.kernel.org/stable/c/6e4694e65b6db4c3de125115dd4f55848cc48381
- https://git.kernel.org/stable/c/e8a67fe34b76a49320b33032228a794f40b0316b
- https://git.kernel.org/stable/c/f175de546a3eb77614d94d4c02550181c0a8493e
- https://git.kernel.org/stable/c/29bd6f86904682adafe9affbc7f79b14defcaff8
- https://git.kernel.org/stable/c/32019c659ecfe1d92e3bf9fcdfbb11a7c70acd58
- https://git.kernel.org/stable/c/57f78c46f08198e1be08ffe99c4c1ccc12855bf5
- https://git.kernel.org/stable/c/6e4694e65b6db4c3de125115dd4f55848cc48381
- https://git.kernel.org/stable/c/e8a67fe34b76a49320b33032228a794f40b0316b
- https://git.kernel.org/stable/c/f175de546a3eb77614d94d4c02550181c0a8493e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-26907
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
------------[ cut here ]------------
memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
[last unloaded: mlx_compat(OE)]
CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c
- https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350
- https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d
- https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd
- https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21
- https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa
- https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c
- https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350
- https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d
- https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd
- https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21
- https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26915
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reset IH OVERFLOW_CLEAR bit Allows us to detect subsequent IH ring buffer overflows as well.
- https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d
- https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd
- https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70
- https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1
- https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2
- https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d
- https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd
- https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70
- https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1
- https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2
Modified: 2025-11-03
CVE-2024-26921
In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.
- https://git.kernel.org/stable/c/18685451fc4e546fc0e718580d32df3c0e5c8272
- https://git.kernel.org/stable/c/1b6de5e6575b56502665c65cf93b0ae6aa0f51ab
- https://git.kernel.org/stable/c/4318608dc28ef184158b4045896740716bea23f0
- https://git.kernel.org/stable/c/7d0567842b78390dd9b60f00f1d8f838d540e325
- https://git.kernel.org/stable/c/9705f447bf9a6cd088300ad2c407b5e1c6591091
- https://git.kernel.org/stable/c/e09cbe017311508c21e0739e97198a8388b98981
- https://git.kernel.org/stable/c/f4877225313d474659ee53150ccc3d553a978727
- https://git.kernel.org/stable/c/18685451fc4e546fc0e718580d32df3c0e5c8272
- https://git.kernel.org/stable/c/7d0567842b78390dd9b60f00f1d8f838d540e325
- https://git.kernel.org/stable/c/e09cbe017311508c21e0739e97198a8388b98981
- https://git.kernel.org/stable/c/f4877225313d474659ee53150ccc3d553a978727
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-03-21
CVE-2024-26927
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Add some bounds checking to firmware data Smatch complains about "head->full_size - head->header_size" can underflow. To some extent, we're always going to have to trust the firmware a bit. However, it's easy enough to add a check for negatives, and let's add a upper bounds check as well.
- https://git.kernel.org/stable/c/044e220667157fb9d59320341badec59cf45ba48
- https://git.kernel.org/stable/c/98f681b0f84cfc3a1d83287b77697679e0398306
- https://git.kernel.org/stable/c/9eeb8e1231f6450c574c1db979122e171a1813ab
- https://git.kernel.org/stable/c/ced7df8b3c5c4751244cad79011e86cf1f809153
- https://git.kernel.org/stable/c/d133d67e7e724102d1e53009c4f88afaaf3e167c
- https://git.kernel.org/stable/c/044e220667157fb9d59320341badec59cf45ba48
- https://git.kernel.org/stable/c/98f681b0f84cfc3a1d83287b77697679e0398306
- https://git.kernel.org/stable/c/9eeb8e1231f6450c574c1db979122e171a1813ab
- https://git.kernel.org/stable/c/ced7df8b3c5c4751244cad79011e86cf1f809153
- https://git.kernel.org/stable/c/d133d67e7e724102d1e53009c4f88afaaf3e167c
Modified: 2025-12-01
CVE-2024-26928
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88
- https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1
- https://git.kernel.org/stable/c/8f8718afd446cd4ea3b62bacc3eec09f8aae85ee
- https://git.kernel.org/stable/c/a140224bcf87eb98a87b67ff4c6826c57e47b704
- https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d
- https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502
- https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88
- https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1
- https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d
- https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-03-04
CVE-2024-26931
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix command flush on cable pull System crash due to command failed to flush back to SCSI layer. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200. ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0 ? __switch_to+0x10c/0x450 ? process_one_work+0x1a7/0x360 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201. ? worker_thread+0x1ce/0x390 ? create_worker+0x1a0/0x1a0 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70 ? kthread+0x10a/0x120 qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8 ? set_kthread_struct+0x40/0x40 qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed. ? ret_from_fork+0x1f/0x40 qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout The system was under memory stress where driver was not able to allocate an SRB to carry out error recovery of cable pull. The failure to flush causes upper layer to start modifying scsi_cmnd. When the system frees up some memory, the subsequent cable pull trigger another command flush. At this point the driver access a null pointer when attempting to DMA unmap the SGL. Add a check to make sure commands are flush back on session tear down to prevent the null pointer access.
- https://git.kernel.org/stable/c/09c0ac18cac206ed1218b1fe6c1a0918e5ea9211
- https://git.kernel.org/stable/c/67b2d35853c2da25a8ca1c4190a5e96d3083c2ac
- https://git.kernel.org/stable/c/8de1584ec4fe0ebea33c273036e7e0a05e65c81d
- https://git.kernel.org/stable/c/8f0d32004e3a572bb77e6c11c2797c87f8c9703d
- https://git.kernel.org/stable/c/a27d4d0e7de305def8a5098a614053be208d1aa1
- https://git.kernel.org/stable/c/a859f6a8f4234b8ef62862bf7a92f1af5f8cd47a
- https://git.kernel.org/stable/c/b73377124f56d2fec154737c2f8d2e839c237d5a
- https://git.kernel.org/stable/c/d7a68eee87b05d4e29419e6f151aef99314970a9
- https://git.kernel.org/stable/c/ec7587eef003cab15a13446d67c3adb88146a150
- https://git.kernel.org/stable/c/09c0ac18cac206ed1218b1fe6c1a0918e5ea9211
- https://git.kernel.org/stable/c/67b2d35853c2da25a8ca1c4190a5e96d3083c2ac
- https://git.kernel.org/stable/c/8de1584ec4fe0ebea33c273036e7e0a05e65c81d
- https://git.kernel.org/stable/c/8f0d32004e3a572bb77e6c11c2797c87f8c9703d
- https://git.kernel.org/stable/c/a27d4d0e7de305def8a5098a614053be208d1aa1
- https://git.kernel.org/stable/c/a859f6a8f4234b8ef62862bf7a92f1af5f8cd47a
- https://git.kernel.org/stable/c/b73377124f56d2fec154737c2f8d2e839c237d5a
- https://git.kernel.org/stable/c/d7a68eee87b05d4e29419e6f151aef99314970a9
- https://git.kernel.org/stable/c/ec7587eef003cab15a13446d67c3adb88146a150
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-07
CVE-2024-26933
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in port "disable" sysfs attribute The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration: Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and device_del() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then. But the disable_show() or disable_store() routine can't return until after it has acquired the lock. The resulting deadlock can be avoided by calling sysfs_break_active_protection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hub_get().
- https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7
- https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e
- https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05
- https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1
- https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c
- https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7
- https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e
- https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05
- https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1
- https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c
Modified: 2024-11-21
CVE-2024-26934
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface's parent
USB device.
The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected. As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete. But usb_deauthorize_interface() can't complete
until the device lock has been released, and the lock won't be
released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.
Reported-and-tested by: Yue Sun
- https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6
- https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384
- https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947
- https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a
- https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5
- https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f
- https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5
- https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057
- https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9
- https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6
- https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384
- https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947
- https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a
- https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5
- https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f
- https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5
- https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057
- https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-26935
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix unremoved procfs host directory regression Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example. Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure): usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case. This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.
- https://git.kernel.org/stable/c/0053f15d50d50c9312d8ab9c11e2e405812dfcac
- https://git.kernel.org/stable/c/3678cf67ff7136db1dd3bf63c361650db5d92889
- https://git.kernel.org/stable/c/5c2386ba80e779a92ec3bb64ccadbedd88f779b1
- https://git.kernel.org/stable/c/cea234bb214b17d004dfdccce4491e6ff57c96ee
- https://git.kernel.org/stable/c/d4c34782b6d7b1e68d18d9549451b19433bd4c6c
- https://git.kernel.org/stable/c/e293c773c13b830cdc251f155df2254981abc320
- https://git.kernel.org/stable/c/f23a4d6e07570826fe95023ca1aa96a011fa9f84
- https://git.kernel.org/stable/c/f4ff08fab66eb5c0b97e1a24edac052fb40bf5d7
- https://git.kernel.org/stable/c/0053f15d50d50c9312d8ab9c11e2e405812dfcac
- https://git.kernel.org/stable/c/3678cf67ff7136db1dd3bf63c361650db5d92889
- https://git.kernel.org/stable/c/5c2386ba80e779a92ec3bb64ccadbedd88f779b1
- https://git.kernel.org/stable/c/cea234bb214b17d004dfdccce4491e6ff57c96ee
- https://git.kernel.org/stable/c/d4c34782b6d7b1e68d18d9549451b19433bd4c6c
- https://git.kernel.org/stable/c/e293c773c13b830cdc251f155df2254981abc320
- https://git.kernel.org/stable/c/f23a4d6e07570826fe95023ca1aa96a011fa9f84
- https://git.kernel.org/stable/c/f4ff08fab66eb5c0b97e1a24edac052fb40bf5d7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-26937
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Reset queue_priority_hint on parking
Originally, with strict in order execution, we could complete execution
only when the queue was empty. Preempt-to-busy allows replacement of an
active request that may complete before the preemption is processed by
HW. If that happens, the request is retired from the queue, but the
queue_priority_hint remains set, preventing direct submission until
after the next CS interrupt is processed.
This preempt-to-busy race can be triggered by the heartbeat, which will
also act as the power-management barrier and upon completion allow us to
idle the HW. We may process the completion of the heartbeat, and begin
parking the engine before the CS event that restores the
queue_priority_hint, causing us to fail the assertion that it is MIN.
<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
<0>[ 166.210781] Dumping ftrace buffer:
<0>[ 166.210795] ---------------------------------
...
<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646
<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40
<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }
<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
<0>[ 167.303534]
- https://git.kernel.org/stable/c/3b031e4fcb2740988143c303f81f69f18ce86325
- https://git.kernel.org/stable/c/4a3859ea5240365d21f6053ee219bb240d520895
- https://git.kernel.org/stable/c/67944e6db656bf1e986aa2a359f866f851091f8a
- https://git.kernel.org/stable/c/7eab7b021835ae422c38b968d5cc60e99408fb62
- https://git.kernel.org/stable/c/8fd9b0ce8c26533fe4d5d15ea15bbf7b904b611c
- https://git.kernel.org/stable/c/ac9b6b3e8d1237136c8ebf0fa1ce037dd7e2948f
- https://git.kernel.org/stable/c/aed034866a08bb7e6e34d50a5629a4d23fe83703
- https://git.kernel.org/stable/c/fe34587acc995e7b1d7a5d3444a0736721ec32b3
- https://git.kernel.org/stable/c/3b031e4fcb2740988143c303f81f69f18ce86325
- https://git.kernel.org/stable/c/4a3859ea5240365d21f6053ee219bb240d520895
- https://git.kernel.org/stable/c/67944e6db656bf1e986aa2a359f866f851091f8a
- https://git.kernel.org/stable/c/7eab7b021835ae422c38b968d5cc60e99408fb62
- https://git.kernel.org/stable/c/8fd9b0ce8c26533fe4d5d15ea15bbf7b904b611c
- https://git.kernel.org/stable/c/ac9b6b3e8d1237136c8ebf0fa1ce037dd7e2948f
- https://git.kernel.org/stable/c/aed034866a08bb7e6e34d50a5629a4d23fe83703
- https://git.kernel.org/stable/c/fe34587acc995e7b1d7a5d3444a0736721ec32b3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-01-05
CVE-2024-26938
In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() If we have no VBT, or the VBT didn't declare the encoder in question, we won't have the 'devdata' for the encoder. Instead of oopsing just bail early. We won't be able to tell whether the port is DP++ or not, but so be it. (cherry picked from commit 26410896206342c8a80d2b027923e9ee7d33b733)
- https://git.kernel.org/stable/c/32e39bab59934bfd3f37097d4dd85ac5eb0fd549
- https://git.kernel.org/stable/c/94cf2fb6feccd625e5b4e23e1b70f39a206f82ac
- https://git.kernel.org/stable/c/a891add409e3bc381f4f68c2ce9d953f1865cb1f
- https://git.kernel.org/stable/c/f4bbac954d8f9ab214ea1d4f385de4fa6bd92dd0
- https://git.kernel.org/stable/c/32e39bab59934bfd3f37097d4dd85ac5eb0fd549
- https://git.kernel.org/stable/c/72e4d3fb72e9f0f016946158a7d95304832768e6
- https://git.kernel.org/stable/c/94cf2fb6feccd625e5b4e23e1b70f39a206f82ac
- https://git.kernel.org/stable/c/a891add409e3bc381f4f68c2ce9d953f1865cb1f
- https://git.kernel.org/stable/c/f4bbac954d8f9ab214ea1d4f385de4fa6bd92dd0
Modified: 2025-03-20
CVE-2024-26940
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the corresponding ttm_resource_manager is not allocated. This leads to a crash when trying to read from this file. Add a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file only when the corresponding ttm_resource_manager is allocated. crash> bt PID: 3133409 TASK: ffff8fe4834a5000 CPU: 3 COMMAND: "grep" #0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a #2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1 #4 [ffffb954506b3c70] no_context at ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887 #7 [ffffb954506b3d40] page_fault at ffffffffb360116e [exception RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb954506b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: 00007ffdbba9e9f8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 0000000000000003 RBP: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b
- https://git.kernel.org/stable/c/016119154981d81c9e8f2ea3f56b9e2b4ea14500
- https://git.kernel.org/stable/c/042ef0afc40fa1a22b3608f22915b91ce39d128f
- https://git.kernel.org/stable/c/25e3ce59c1200f1f0563e39de151f34962ab0fe1
- https://git.kernel.org/stable/c/4be9075fec0a639384ed19975634b662bfab938f
- https://git.kernel.org/stable/c/eb08db0fc5354fa17b7ed66dab3c503332423451
- https://git.kernel.org/stable/c/016119154981d81c9e8f2ea3f56b9e2b4ea14500
- https://git.kernel.org/stable/c/042ef0afc40fa1a22b3608f22915b91ce39d128f
- https://git.kernel.org/stable/c/25e3ce59c1200f1f0563e39de151f34962ab0fe1
- https://git.kernel.org/stable/c/4be9075fec0a639384ed19975634b662bfab938f
- https://git.kernel.org/stable/c/eb08db0fc5354fa17b7ed66dab3c503332423451
Modified: 2025-03-04
CVE-2024-26943
In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations.
- https://git.kernel.org/stable/c/16e87fe23d4af6df920406494ced5c0f4354567b
- https://git.kernel.org/stable/c/2a84744a037b8a511d6a9055f3defddc28ff4a4d
- https://git.kernel.org/stable/c/3e82f7383e0b82a835e6b6b06a348b2bc4e2c2ee
- https://git.kernel.org/stable/c/5e81773757a95fc298e96cfd6d4700f07b6192a2
- https://git.kernel.org/stable/c/9acfd8b083a0ffbd387566800d89f55058a68af2
- https://git.kernel.org/stable/c/16e87fe23d4af6df920406494ced5c0f4354567b
- https://git.kernel.org/stable/c/2a84744a037b8a511d6a9055f3defddc28ff4a4d
- https://git.kernel.org/stable/c/3e82f7383e0b82a835e6b6b06a348b2bc4e2c2ee
- https://git.kernel.org/stable/c/5e81773757a95fc298e96cfd6d4700f07b6192a2
- https://git.kernel.org/stable/c/9acfd8b083a0ffbd387566800d89f55058a68af2
Modified: 2025-09-18
CVE-2024-26946
In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ]
- https://git.kernel.org/stable/c/20fdb21eabaeb8f78f8f701f56d14ea0836ec861
- https://git.kernel.org/stable/c/4e51653d5d871f40f1bd5cf95cc7f2d8b33d063b
- https://git.kernel.org/stable/c/6417684315087904fffe8966d27ca74398c57dd6
- https://git.kernel.org/stable/c/b69f577308f1070004cafac106dd1a44099e5483
- https://git.kernel.org/stable/c/f13edd1871d4fb4ab829aff629d47914e251bae3
- https://git.kernel.org/stable/c/20fdb21eabaeb8f78f8f701f56d14ea0836ec861
- https://git.kernel.org/stable/c/4e51653d5d871f40f1bd5cf95cc7f2d8b33d063b
- https://git.kernel.org/stable/c/6417684315087904fffe8966d27ca74398c57dd6
- https://git.kernel.org/stable/c/b69f577308f1070004cafac106dd1a44099e5483
- https://git.kernel.org/stable/c/f13edd1871d4fb4ab829aff629d47914e251bae3
Modified: 2025-03-20
CVE-2024-26950
In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.
- https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5
- https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068
- https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5
- https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f
- https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996
- https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37
- https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47
- https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5
- https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068
- https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5
- https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f
- https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996
- https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37
- https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-26951
In the Linux kernel, the following vulnerability has been resolved:
wireguard: netlink: check for dangling peer via is_dead instead of empty list
If all peers are removed via wg_peer_remove_all(), rather than setting
peer_list to empty, the peer is added to a temporary list with a head on
the stack of wg_peer_remove_all(). If a netlink dump is resumed and the
cursored peer is one that has been removed via wg_peer_remove_all(), it
will iterate from that peer and then attempt to dump freed peers.
Fix this by instead checking peer->is_dead, which was explictly created
for this purpose. Also move up the device_update_lock lockdep assertion,
since reading is_dead relies on that.
It can be reproduced by a small script like:
echo "Setting config..."
ip link add dev wg0 type wireguard
wg setconf wg0 /big-config
(
while true; do
echo "Showing config..."
wg showconf wg0 > /dev/null
done
) &
sleep 4
wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n")
Resulting in:
BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20
Read of size 8 at addr ffff88811956ec70 by task wg/59
CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5
Call Trace:
- https://git.kernel.org/stable/c/13d107794304306164481d31ce33f8fdb25a9c04
- https://git.kernel.org/stable/c/302b2dfc013baca3dea7ceda383930d9297d231d
- https://git.kernel.org/stable/c/55b6c738673871c9b0edae05d0c97995c1ff08c4
- https://git.kernel.org/stable/c/710a177f347282eea162aec8712beb1f42d5ad87
- https://git.kernel.org/stable/c/7bedfe4cfa38771840a355970e4437cd52d4046b
- https://git.kernel.org/stable/c/b7cea3a9af0853fdbb1b16633a458f991dde6aac
- https://git.kernel.org/stable/c/f52be46e3e6ecefc2539119784324f0cbc09620a
- https://git.kernel.org/stable/c/13d107794304306164481d31ce33f8fdb25a9c04
- https://git.kernel.org/stable/c/302b2dfc013baca3dea7ceda383930d9297d231d
- https://git.kernel.org/stable/c/55b6c738673871c9b0edae05d0c97995c1ff08c4
- https://git.kernel.org/stable/c/710a177f347282eea162aec8712beb1f42d5ad87
- https://git.kernel.org/stable/c/7bedfe4cfa38771840a355970e4437cd52d4046b
- https://git.kernel.org/stable/c/b7cea3a9af0853fdbb1b16633a458f991dde6aac
- https://git.kernel.org/stable/c/f52be46e3e6ecefc2539119784324f0cbc09620a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-26955
In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent kernel bug at submit_bh_wbc() Fix a bug where nilfs_get_block() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead. This prevents callers such as __block_write_begin_int() from requesting a read into a buffer that is not mapped, which would cause the BUG_ON check for the BH_Mapped flag in submit_bh_wbc() to fail.
- https://git.kernel.org/stable/c/0c8aa4cfda4e4adb15d5b6536d155eca9c9cd44c
- https://git.kernel.org/stable/c/192e9f9078c96be30b31c4b44d6294b24520fce5
- https://git.kernel.org/stable/c/269cdf353b5bdd15f1a079671b0f889113865f20
- https://git.kernel.org/stable/c/32eaee72e96590a75445c8a6c7c1057673b47e07
- https://git.kernel.org/stable/c/48d443d200237782dc82e6b60663ec414ef02e39
- https://git.kernel.org/stable/c/76ffbe911e2798c7296968f5fd72f7bf67207a8d
- https://git.kernel.org/stable/c/91e4c4595fae5e87069e44687ae879091783c183
- https://git.kernel.org/stable/c/ca581d237f3b8539c044205bb003de71d75d227c
- https://git.kernel.org/stable/c/f0fe7ad5aff4f0fcf988913313c497de85f1e186
- https://git.kernel.org/stable/c/0c8aa4cfda4e4adb15d5b6536d155eca9c9cd44c
- https://git.kernel.org/stable/c/192e9f9078c96be30b31c4b44d6294b24520fce5
- https://git.kernel.org/stable/c/269cdf353b5bdd15f1a079671b0f889113865f20
- https://git.kernel.org/stable/c/32eaee72e96590a75445c8a6c7c1057673b47e07
- https://git.kernel.org/stable/c/48d443d200237782dc82e6b60663ec414ef02e39
- https://git.kernel.org/stable/c/76ffbe911e2798c7296968f5fd72f7bf67207a8d
- https://git.kernel.org/stable/c/91e4c4595fae5e87069e44687ae879091783c183
- https://git.kernel.org/stable/c/ca581d237f3b8539c044205bb003de71d75d227c
- https://git.kernel.org/stable/c/f0fe7ad5aff4f0fcf988913313c497de85f1e186
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-26956
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix failure to detect DAT corruption in btree and direct mappings Patch series "nilfs2: fix kernel bug at submit_bh_wbc()". This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch. The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such. This patch (of 2): Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted. There are two flaws involved in this issue. The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently. The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing. This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.
- https://git.kernel.org/stable/c/2e2619ff5d0def4bb6c2037a32a6eaa28dd95c84
- https://git.kernel.org/stable/c/46b832e09d43b394ac0f6d9485d2b1a06593f0b7
- https://git.kernel.org/stable/c/82827ca21e7c8a91384c5baa656f78a5adfa4ab4
- https://git.kernel.org/stable/c/9cbe1ad5f4354f4df1445e5f4883983328cd6d8e
- https://git.kernel.org/stable/c/a8e4d098de1c0f4c5c1f2ed4633a860f0da6d713
- https://git.kernel.org/stable/c/b67189690eb4b7ecc84ae16fa1e880e0123eaa35
- https://git.kernel.org/stable/c/c3b5c5c31e723b568f83d8cafab8629d9d830ffb
- https://git.kernel.org/stable/c/f2f26b4a84a0ef41791bd2d70861c8eac748f4ba
- https://git.kernel.org/stable/c/f69e81396aea66304d214f175aa371f1b5578862
- https://git.kernel.org/stable/c/2e2619ff5d0def4bb6c2037a32a6eaa28dd95c84
- https://git.kernel.org/stable/c/46b832e09d43b394ac0f6d9485d2b1a06593f0b7
- https://git.kernel.org/stable/c/82827ca21e7c8a91384c5baa656f78a5adfa4ab4
- https://git.kernel.org/stable/c/9cbe1ad5f4354f4df1445e5f4883983328cd6d8e
- https://git.kernel.org/stable/c/a8e4d098de1c0f4c5c1f2ed4633a860f0da6d713
- https://git.kernel.org/stable/c/b67189690eb4b7ecc84ae16fa1e880e0123eaa35
- https://git.kernel.org/stable/c/c3b5c5c31e723b568f83d8cafab8629d9d830ffb
- https://git.kernel.org/stable/c/f2f26b4a84a0ef41791bd2d70861c8eac748f4ba
- https://git.kernel.org/stable/c/f69e81396aea66304d214f175aa371f1b5578862
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-20
CVE-2024-26957
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix reference counting on zcrypt card objects Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use. This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated---
- https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484
- https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c
- https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd
- https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058
- https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55
- https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6
- https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca
- https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d
- https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000
- https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484
- https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c
- https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd
- https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058
- https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55
- https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6
- https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca
- https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d
- https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-08-28
CVE-2024-26958
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af
- https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab
- https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3
- https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5
- https://git.kernel.org/stable/c/6cd3f13aaa62970b5169d990e936b2e96943bc6a
- https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f
- https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95
- https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605
- https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af
- https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab
- https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3
- https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5
- https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f
- https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95
- https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-20
CVE-2024-26960
In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8<----- __swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8<-----
- https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a
- https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a
- https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e
- https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b
- https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39
- https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e
- https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d
- https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a
- https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a
- https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e
- https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b
- https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39
- https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e
- https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-26961
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without
following the RCU rules for waiting before the end of a grace period. This
may lead to use-after-free in case llsec_lookup_key() is traversing the
list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
Modules linked in:
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
Call Trace:
- https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531
- https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d
- https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1
- https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88
- https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821
- https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f
- https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40
- https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531
- https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d
- https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1
- https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88
- https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821
- https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f
- https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-26963
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3-am62: fix module unload/reload behavior As runtime PM is enabled, the module can be runtime suspended when .remove() is called. Do a pm_runtime_get_sync() to make sure module is active before doing any register operations. Doing a pm_runtime_put_sync() should disable the refclk so no need to disable it again. Fixes the below warning at module removel. [ 39.705310] ------------[ cut here ]------------ [ 39.710004] clk:162:3 already disabled [ 39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 We called of_platform_populate() in .probe() so call the cleanup function of_platform_depopulate() in .remove(). Get rid of the now unnnecessary dwc3_ti_remove_core(). Without this, module re-load doesn't work properly.
- https://git.kernel.org/stable/c/3895780fabd120d0fbd54354014e85207b25687c
- https://git.kernel.org/stable/c/629b534c42d04f0797980f2d1ed105fdb8906975
- https://git.kernel.org/stable/c/6661befe41009c210efa2c1bcd16a5cc4cff8a06
- https://git.kernel.org/stable/c/6c6a45645a2e6a272dfde14eddbb6706de63c25d
- https://git.kernel.org/stable/c/7dfed9855397d0df4c6f748d1f66547ab3bad766
- https://git.kernel.org/stable/c/3895780fabd120d0fbd54354014e85207b25687c
- https://git.kernel.org/stable/c/629b534c42d04f0797980f2d1ed105fdb8906975
- https://git.kernel.org/stable/c/6661befe41009c210efa2c1bcd16a5cc4cff8a06
- https://git.kernel.org/stable/c/6c6a45645a2e6a272dfde14eddbb6706de63c25d
- https://git.kernel.org/stable/c/7dfed9855397d0df4c6f748d1f66547ab3bad766
Modified: 2024-12-23
CVE-2024-26964
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer.
- https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd
- https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4
- https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757
- https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d
- https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea
- https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052
- https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd
- https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4
- https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757
- https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d
- https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea
- https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052
Modified: 2025-12-23
CVE-2024-26965
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/3ff4a0f6a8f0ad4b4ee9e908bdfc3cacb7be4060
- https://git.kernel.org/stable/c/537040c257ab4cd0673fbae048f3940c8ea2e589
- https://git.kernel.org/stable/c/7e9926fef71e514b4a8ea9d11d5a84d52b181362
- https://git.kernel.org/stable/c/86bf75d9158f511db7530bc82a84b19a5134d089
- https://git.kernel.org/stable/c/8f562f3b25177c2055b20fd8cf000496f6fa9194
- https://git.kernel.org/stable/c/99740c4791dc8019b0d758c5389ca6d1c0604d95
- https://git.kernel.org/stable/c/ae99e199037c580b7350bfa3596f447a53bcf01f
- https://git.kernel.org/stable/c/ca2cf98d46748373e830a13d85d215d64a2d9bf2
- https://git.kernel.org/stable/c/e2c02a85bf53ae86d79b5fccf0a75ac0b78e0c96
- https://git.kernel.org/stable/c/3ff4a0f6a8f0ad4b4ee9e908bdfc3cacb7be4060
- https://git.kernel.org/stable/c/537040c257ab4cd0673fbae048f3940c8ea2e589
- https://git.kernel.org/stable/c/7e9926fef71e514b4a8ea9d11d5a84d52b181362
- https://git.kernel.org/stable/c/86bf75d9158f511db7530bc82a84b19a5134d089
- https://git.kernel.org/stable/c/8f562f3b25177c2055b20fd8cf000496f6fa9194
- https://git.kernel.org/stable/c/99740c4791dc8019b0d758c5389ca6d1c0604d95
- https://git.kernel.org/stable/c/ae99e199037c580b7350bfa3596f447a53bcf01f
- https://git.kernel.org/stable/c/ca2cf98d46748373e830a13d85d215d64a2d9bf2
- https://git.kernel.org/stable/c/e2c02a85bf53ae86d79b5fccf0a75ac0b78e0c96
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-26966
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99
- https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9
- https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2
- https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8
- https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38
- https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03
- https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f
- https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d
- https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0
- https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99
- https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9
- https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2
- https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8
- https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38
- https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03
- https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f
- https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d
- https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-26969
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429
- https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94
- https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe
- https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f
- https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d
- https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566
- https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255
- https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27
- https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9
- https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429
- https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94
- https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe
- https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f
- https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d
- https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566
- https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255
- https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27
- https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-20
CVE-2024-26970
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52
- https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb
- https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6
- https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b
- https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d
- https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d
- https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198
- https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52
- https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb
- https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6
- https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b
- https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d
- https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d
- https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26973
In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length.
- https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb
- https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3386c688
- https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63
- https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6
- https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee
- https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375
- https://git.kernel.org/stable/c/cdd33d54e789d229d6d5007cbf3f53965ca1a5c6
- https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f
- https://git.kernel.org/stable/c/fde2497d2bc3a063d8af88b258dbadc86bd7b57c
- https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb
- https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3386c688
- https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63
- https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6
- https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee
- https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375
- https://git.kernel.org/stable/c/cdd33d54e789d229d6d5007cbf3f53965ca1a5c6
- https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f
- https://git.kernel.org/stable/c/fde2497d2bc3a063d8af88b258dbadc86bd7b57c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-26974
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.
- https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be
- https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7
- https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f
- https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c
- https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc
- https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81
- https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828
- https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71
- https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7
- https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be
- https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7
- https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f
- https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c
- https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc
- https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81
- https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828
- https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71
- https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-08
CVE-2024-26976
In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
KVM must ensure that none of its workqueue callbacks is running when the
last reference to the KVM _module_ is put. Gifting a reference to the
associated VM prevents the workqueue callback from dereferencing freed
vCPU/VM memory, but does not prevent the KVM module from being unloaded
before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
result in deadlock. async_pf_execute() can't return until kvm_put_kvm()
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: events async_pf_execute [kvm]
RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
Call Trace:
- https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157
- https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750
- https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb
- https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac
- https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98
- https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5
- https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff
- https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b
- https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264
- https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157
- https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750
- https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb
- https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac
- https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98
- https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5
- https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff
- https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b
- https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-18
CVE-2024-26977
In the Linux kernel, the following vulnerability has been resolved: pci_iounmap(): Fix MMIO mapping leak The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(), which means MMIO mappings are leaked. Move the guard so we call iounmap() for MMIO mappings.
- https://git.kernel.org/stable/c/5e4b23e7a7b33a1e56bfa3e5598138a2234d55b6
- https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8
- https://git.kernel.org/stable/c/7626913652cc786c238e2dd7d8740b17d41b2637
- https://git.kernel.org/stable/c/af280e137e273935f2e09f4d73169998298792ed
- https://git.kernel.org/stable/c/b5d40f02e7222da032c2042aebcf2a07de9b342f
- https://git.kernel.org/stable/c/f3749345a9b7295dd071d0ed589634cb46364f77
- https://git.kernel.org/stable/c/5e4b23e7a7b33a1e56bfa3e5598138a2234d55b6
- https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8
- https://git.kernel.org/stable/c/7626913652cc786c238e2dd7d8740b17d41b2637
- https://git.kernel.org/stable/c/af280e137e273935f2e09f4d73169998298792ed
- https://git.kernel.org/stable/c/b5d40f02e7222da032c2042aebcf2a07de9b342f
- https://git.kernel.org/stable/c/f3749345a9b7295dd071d0ed589634cb46364f77
Modified: 2024-11-21
CVE-2024-26978
In the Linux kernel, the following vulnerability has been resolved: serial: max310x: fix NULL pointer dereference in I2C instantiation When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message.
- https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110
- https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3
- https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a
- https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a
- https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0
- https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733
- https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735
- https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110
- https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3
- https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a
- https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a
- https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0
- https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733
- https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-27023
In the Linux kernel, the following vulnerability has been resolved: md: Fix missing release of 'active_io' for flush submit_flushes atomic_set(&mddev->flush_pending, 1); rdev_for_each_rcu(rdev, mddev) atomic_inc(&mddev->flush_pending); bi->bi_end_io = md_end_flush submit_bio(bi); /* flush io is done first */ md_end_flush if (atomic_dec_and_test(&mddev->flush_pending)) percpu_ref_put(&mddev->active_io) -> active_io is not released if (atomic_dec_and_test(&mddev->flush_pending)) -> missing release of active_io For consequence, mddev_suspend() will wait for 'active_io' to be zero forever. Fix this problem by releasing 'active_io' in submit_flushes() if 'flush_pending' is decreased to zero.
- https://git.kernel.org/stable/c/02dad157ba11064d073f5499dc33552b227d5d3a
- https://git.kernel.org/stable/c/11f81438927f84edfaaeb5d5f10856c3a1c1fc82
- https://git.kernel.org/stable/c/6b2ff10390b19a2364af622b6666b690443f9f3f
- https://git.kernel.org/stable/c/855678ed8534518e2b428bcbcec695de9ba248e8
- https://git.kernel.org/stable/c/02dad157ba11064d073f5499dc33552b227d5d3a
- https://git.kernel.org/stable/c/11f81438927f84edfaaeb5d5f10856c3a1c1fc82
- https://git.kernel.org/stable/c/6b2ff10390b19a2364af622b6666b690443f9f3f
- https://git.kernel.org/stable/c/855678ed8534518e2b428bcbcec695de9ba248e8
Modified: 2024-12-23
CVE-2024-27024
In the Linux kernel, the following vulnerability has been resolved: net/rds: fix WARNING in rds_conn_connect_if_down If connection isn't established yet, get_mr() will fail, trigger connection after get_mr().
- https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85
- https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4
- https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1
- https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b
- https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80
- https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2
- https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0
- https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38
- https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85
- https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4
- https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1
- https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b
- https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80
- https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2
- https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0
- https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27025
In the Linux kernel, the following vulnerability has been resolved: nbd: null check for nla_nest_start nla_nest_start() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code.
- https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d
- https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e
- https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced
- https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8
- https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797
- https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983
- https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a
- https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf
- https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d
- https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e
- https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced
- https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8
- https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797
- https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983
- https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a
- https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27028
In the Linux kernel, the following vulnerability has been resolved: spi: spi-mt65xx: Fix NULL pointer access in interrupt handler The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes. Add a check to trans->tx_buf before using it.
- https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713
- https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38
- https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6
- https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753
- https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4
- https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55
- https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11
- https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4
- https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62
- https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713
- https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38
- https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6
- https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753
- https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4
- https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55
- https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11
- https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4
- https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27030
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Use separate handlers for interrupts For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data.
- https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44
- https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701
- https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c
- https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a
- https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70
- https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2
- https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c
- https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d
- https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44
- https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701
- https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c
- https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a
- https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70
- https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2
- https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c
- https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27032
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential panic during recovery During recovery, if FAULT_BLOCK is on, it is possible that f2fs_reserve_new_block() will return -ENOSPC during recovery, then it may trigger panic. Also, if fault injection rate is 1 and only FAULT_BLOCK fault type is on, it may encounter deadloop in loop of block reservation. Let's change as below to fix these issues: - remove bug_on() to avoid panic. - limit the loop count of block reservation to avoid potential deadloop.
- https://git.kernel.org/stable/c/21ec68234826b1b54ab980a8df6e33c74cfbee58
- https://git.kernel.org/stable/c/8844b2f8a3f0c428b74672f9726f9950b1a7764c
- https://git.kernel.org/stable/c/d034810d02a5af8eb74debe29877dcaf5f00fdd1
- https://git.kernel.org/stable/c/f26091a981318b5b7451d61f99bc073a6af8db67
- https://git.kernel.org/stable/c/fe4de493572a4263554903bf9c3afc5c196e15f0
- https://git.kernel.org/stable/c/21ec68234826b1b54ab980a8df6e33c74cfbee58
- https://git.kernel.org/stable/c/8844b2f8a3f0c428b74672f9726f9950b1a7764c
- https://git.kernel.org/stable/c/d034810d02a5af8eb74debe29877dcaf5f00fdd1
- https://git.kernel.org/stable/c/f26091a981318b5b7451d61f99bc073a6af8db67
- https://git.kernel.org/stable/c/fe4de493572a4263554903bf9c3afc5c196e15f0
Modified: 2025-09-18
CVE-2024-27034
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover normal cluster write with cp_rwsem When we overwrite compressed cluster w/ normal cluster, we should not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data will be corrupted if partial blocks were persisted before CP & SPOR, due to cluster metadata wasn't updated atomically.
- https://git.kernel.org/stable/c/2b1b14d9fc94b8feae20808684c8af28ec80f45b
- https://git.kernel.org/stable/c/52982edfcefd475cc34af663d5c47c0cddaa5739
- https://git.kernel.org/stable/c/542c8b3c774a480bfd0804291a12f6f2391b0cd1
- https://git.kernel.org/stable/c/75abfd61392b1db391bde6d738a30d685b843286
- https://git.kernel.org/stable/c/7d420eaaa18ec8e2bb4eeab8c65c00492ef6f416
- https://git.kernel.org/stable/c/fd244524c2cf07b5f4c3fe8abd6a99225c76544b
- https://git.kernel.org/stable/c/2b1b14d9fc94b8feae20808684c8af28ec80f45b
- https://git.kernel.org/stable/c/52982edfcefd475cc34af663d5c47c0cddaa5739
- https://git.kernel.org/stable/c/542c8b3c774a480bfd0804291a12f6f2391b0cd1
- https://git.kernel.org/stable/c/75abfd61392b1db391bde6d738a30d685b843286
- https://git.kernel.org/stable/c/7d420eaaa18ec8e2bb4eeab8c65c00492ef6f416
- https://git.kernel.org/stable/c/fd244524c2cf07b5f4c3fe8abd6a99225c76544b
Modified: 2025-09-18
CVE-2024-27035
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to guarantee persisting compressed blocks by CP If data block in compressed cluster is not persisted with metadata during checkpoint, after SPOR, the data may be corrupted, let's guarantee to write compressed page by checkpoint.
- https://git.kernel.org/stable/c/57e8b17d0522c8f4daf0c4d9969b4d7358033532
- https://git.kernel.org/stable/c/82704e598d7b33c7e45526e34d3c585426319bed
- https://git.kernel.org/stable/c/8a430dd49e9cb021372b0ad91e60aeef9c6ced00
- https://git.kernel.org/stable/c/c3311694b9bcced233548574d414c91d39214684
- https://git.kernel.org/stable/c/e54cce8137258a550b49cae45d09e024821fb28d
- https://git.kernel.org/stable/c/57e8b17d0522c8f4daf0c4d9969b4d7358033532
- https://git.kernel.org/stable/c/82704e598d7b33c7e45526e34d3c585426319bed
- https://git.kernel.org/stable/c/8a430dd49e9cb021372b0ad91e60aeef9c6ced00
- https://git.kernel.org/stable/c/c3311694b9bcced233548574d414c91d39214684
- https://git.kernel.org/stable/c/e54cce8137258a550b49cae45d09e024821fb28d
Modified: 2025-04-08
CVE-2024-27037
In the Linux kernel, the following vulnerability has been resolved: clk: zynq: Prevent null pointer dereference caused by kmalloc failure The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen. This patch uses a stack variable to replace the kmalloc().
- https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db
- https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85
- https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b
- https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6
- https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d
- https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8
- https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db
- https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85
- https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b
- https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6
- https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d
- https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8
Modified: 2024-12-23
CVE-2024-27038
In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_core_get NULL dereference It is possible for clk_core_get to dereference a NULL in the following sequence: clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw() __clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core. Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL. Reading the description of this function it talks about returning NULL but that cannot be so at the moment. Update the function to check for hw before dereferencing it and return NULL if hw is NULL.
- https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2
- https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185
- https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51
- https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed
- https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959
- https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6
- https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07
- https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428
- https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2
- https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185
- https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51
- https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed
- https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959
- https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6
- https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07
- https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-27039
In the Linux kernel, the following vulnerability has been resolved: clk: hisilicon: hi3559a: Fix an erroneous devm_kfree() 'p_clk' is an array allocated just before the for loop for all clk that need to be registered. It is incremented at each loop iteration. If a clk_register() call fails, 'p_clk' may point to something different from what should be freed. The best we can do, is to avoid this wrong release of memory.
- https://git.kernel.org/stable/c/2cc572e0085ebd4b662b74a0f43222bc00df9a00
- https://git.kernel.org/stable/c/3f8445f1c746fda180a7f75372ed06b24e9cefe2
- https://git.kernel.org/stable/c/64c6a38136b74a2f18c42199830975edd9fbc379
- https://git.kernel.org/stable/c/95d1f1228c1bb54803ae57525b76db60e99b37e4
- https://git.kernel.org/stable/c/d575765b1b62e8bdb00af11caa1aabeb01763d9f
- https://git.kernel.org/stable/c/e0b0d1c46a2ce1e46b79d004a7270fdef872e097
- https://git.kernel.org/stable/c/2cc572e0085ebd4b662b74a0f43222bc00df9a00
- https://git.kernel.org/stable/c/3f8445f1c746fda180a7f75372ed06b24e9cefe2
- https://git.kernel.org/stable/c/64c6a38136b74a2f18c42199830975edd9fbc379
- https://git.kernel.org/stable/c/95d1f1228c1bb54803ae57525b76db60e99b37e4
- https://git.kernel.org/stable/c/d575765b1b62e8bdb00af11caa1aabeb01763d9f
- https://git.kernel.org/stable/c/e0b0d1c46a2ce1e46b79d004a7270fdef872e097
Modified: 2024-12-23
CVE-2024-27043
In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free.
- https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644
- https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e
- https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d
- https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712
- https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62
- https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5
- https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b
- https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856
- https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086
- https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644
- https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e
- https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d
- https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712
- https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62
- https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5
- https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b
- https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856
- https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27044
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()' The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)
- https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7
- https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0
- https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7
- https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08
- https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb
- https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484
- https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656
- https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a
- https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7
- https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0
- https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7
- https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08
- https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb
- https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484
- https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656
- https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27045
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()' Tell snprintf() to store at most 10 bytes in the output buffer instead of 30. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10
- https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877
- https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141
- https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7
- https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4
- https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab
- https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65
- https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515
- https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877
- https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141
- https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7
- https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4
- https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab
- https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65
- https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27046
In the Linux kernel, the following vulnerability has been resolved: nfp: flower: handle acti_netdevs allocation failure The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen. This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again.
- https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5
- https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d
- https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642
- https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002
- https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f
- https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2
- https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d
- https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3
- https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e
- https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5
- https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d
- https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642
- https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002
- https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f
- https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2
- https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d
- https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3
- https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27047
In the Linux kernel, the following vulnerability has been resolved: net: phy: fix phy_get_internal_delay accessing an empty array The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0.
- https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad
- https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b
- https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a
- https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8
- https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79
- https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563
- https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b
- https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad
- https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b
- https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a
- https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8
- https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79
- https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563
- https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27051
In the Linux kernel, the following vulnerability has been resolved: cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5
- https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db
- https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035
- https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567
- https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6
- https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095
- https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6
- https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5
- https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db
- https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035
- https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567
- https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6
- https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095
- https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27052
In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().
- https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361
- https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e
- https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e
- https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a
- https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707
- https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59
- https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4
- https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361
- https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e
- https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e
- https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a
- https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707
- https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59
- https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27053
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix RCU usage in connect path With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning: ============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcu_dereference_check() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4 wilc_parse_join_bss_param from connect+0x2c4/0x648 connect from cfg80211_connect+0x30c/0xb74 cfg80211_connect from nl80211_connect+0x860/0xa94 nl80211_connect from genl_rcv_msg+0x3fc/0x59c genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb from genl_rcv+0x2c/0x3c genl_rcv from netlink_unicast+0x3b0/0x550 netlink_unicast from netlink_sendmsg+0x368/0x688 netlink_sendmsg from ____sys_sendmsg+0x190/0x430 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158 ___sys_sendmsg from sys_sendmsg+0xe8/0x150 sys_sendmsg from ret_fast_syscall+0x0/0x1c This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilc_parse_join_bss_param under the critical section, just use the critical section to copy ies data
- https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f
- https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce
- https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de
- https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2
- https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38
- https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2
- https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7
- https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2
- https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f
- https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce
- https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de
- https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2
- https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38
- https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2
- https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7
- https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-05-02
CVE-2024-27054
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix double module refcount decrement Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same.
- https://git.kernel.org/stable/c/9fe0562179d8fa960afca0eaed6d4ba4122a3cc6
- https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a
- https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06
- https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5
- https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e
- https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19
- https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650
- https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a
- https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06
- https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5
- https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e
- https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19
- https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650
Modified: 2025-01-14
CVE-2024-27059
In the Linux kernel, the following vulnerability has been resolved: USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer. Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).
- https://git.kernel.org/stable/c/014bcf41d946b36a8f0b8e9b5d9529efbb822f49
- https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133
- https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c61f01636
- https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964
- https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325
- https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34
- https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f
- https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa
- https://git.kernel.org/stable/c/014bcf41d946b36a8f0b8e9b5d9529efbb822f49
- https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133
- https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c61f01636
- https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964
- https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325
- https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34
- https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f
- https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27065
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not compare internal table flags on updates Restore skipping transaction if table update does not modify flags.
- https://git.kernel.org/stable/c/2531f907d3e40a6173090f10670ae76d117ab27b
- https://git.kernel.org/stable/c/3443e57654f90c9a843ab6a6040c10709fd033aa
- https://git.kernel.org/stable/c/4a0e7f2decbf9bd72461226f1f5f7dcc4b08f139
- https://git.kernel.org/stable/c/4d37f12707ee965d338028732575f0b85f6d9e4f
- https://git.kernel.org/stable/c/640dbf688ba955e83e03de84fbdda8e570b7cce4
- https://git.kernel.org/stable/c/845083249d6a392f3a88804e1669bdb936ee129f
- https://git.kernel.org/stable/c/9683cb6c2c6c0f45537bf0b8868b5d38fcb63fc7
- https://git.kernel.org/stable/c/df257c435e51651c43b86326d112ddadda76350e
- https://git.kernel.org/stable/c/fcf32a5bfcb8a57ac0ce717fcfa4d688c91f1005
- https://git.kernel.org/stable/c/2531f907d3e40a6173090f10670ae76d117ab27b
- https://git.kernel.org/stable/c/3443e57654f90c9a843ab6a6040c10709fd033aa
- https://git.kernel.org/stable/c/4a0e7f2decbf9bd72461226f1f5f7dcc4b08f139
- https://git.kernel.org/stable/c/4d37f12707ee965d338028732575f0b85f6d9e4f
- https://git.kernel.org/stable/c/640dbf688ba955e83e03de84fbdda8e570b7cce4
- https://git.kernel.org/stable/c/845083249d6a392f3a88804e1669bdb936ee129f
- https://git.kernel.org/stable/c/9683cb6c2c6c0f45537bf0b8868b5d38fcb63fc7
- https://git.kernel.org/stable/c/df257c435e51651c43b86326d112ddadda76350e
- https://git.kernel.org/stable/c/fcf32a5bfcb8a57ac0ce717fcfa4d688c91f1005
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27073
In the Linux kernel, the following vulnerability has been resolved: media: ttpci: fix two memleaks in budget_av_attach When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations.
- https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63
- https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb
- https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0
- https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c
- https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06
- https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b
- https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016
- https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837
- https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63
- https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb
- https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0
- https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c
- https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06
- https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b
- https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016
- https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27074
In the Linux kernel, the following vulnerability has been resolved: media: go7007: fix a memleak in go7007_load_encoder In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked.
- https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159
- https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4
- https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3
- https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5
- https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073
- https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12
- https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661
- https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3
- https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975
- https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159
- https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4
- https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3
- https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5
- https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073
- https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12
- https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661
- https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3
- https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27075
In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: avoid stack overflow warnings with clang A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang: drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe) Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled.
- https://git.kernel.org/stable/c/107052a8cfeff3a97326277192b4f052e4860a8a
- https://git.kernel.org/stable/c/7a4cf27d1f0538f779bf31b8c99eda394e277119
- https://git.kernel.org/stable/c/8fad9c5bb00d3a9508d18bbfe832e33a47377730
- https://git.kernel.org/stable/c/c073c8cede5abd3836e83d70d72606d11d0759d4
- https://git.kernel.org/stable/c/d20b64f156de5d10410963fe238d82a4e7e97a2f
- https://git.kernel.org/stable/c/d6b4895197ab5a47cb81c6852d49320b05052960
- https://git.kernel.org/stable/c/ed514ecf4f29c80a2f09ae3c877059b401efe893
- https://git.kernel.org/stable/c/fa8b472952ef46eb632825051078c21ce0cafe55
- https://git.kernel.org/stable/c/fb07104a02e87c06c39914d13ed67fd8f839ca82
- https://git.kernel.org/stable/c/107052a8cfeff3a97326277192b4f052e4860a8a
- https://git.kernel.org/stable/c/7a4cf27d1f0538f779bf31b8c99eda394e277119
- https://git.kernel.org/stable/c/8fad9c5bb00d3a9508d18bbfe832e33a47377730
- https://git.kernel.org/stable/c/c073c8cede5abd3836e83d70d72606d11d0759d4
- https://git.kernel.org/stable/c/d20b64f156de5d10410963fe238d82a4e7e97a2f
- https://git.kernel.org/stable/c/d6b4895197ab5a47cb81c6852d49320b05052960
- https://git.kernel.org/stable/c/ed514ecf4f29c80a2f09ae3c877059b401efe893
- https://git.kernel.org/stable/c/fa8b472952ef46eb632825051078c21ce0cafe55
- https://git.kernel.org/stable/c/fb07104a02e87c06c39914d13ed67fd8f839ca82
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27076
In the Linux kernel, the following vulnerability has been resolved: media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak Free the memory allocated in v4l2_ctrl_handler_init on release.
- https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce
- https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01
- https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684
- https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e
- https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282
- https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328
- https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b
- https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f
- https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce
- https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01
- https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684
- https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e
- https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282
- https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328
- https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b
- https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27077
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.
- https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4
- https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d
- https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333
- https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458
- https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211
- https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d
- https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f
- https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2
- https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef
- https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4
- https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d
- https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333
- https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458
- https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211
- https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d
- https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f
- https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2
- https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27078
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0.
- https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77
- https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09
- https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941
- https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7
- https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d
- https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511
- https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79
- https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c
- https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28
- https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77
- https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09
- https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941
- https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7
- https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d
- https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511
- https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79
- https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c
- https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-27388
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.
- https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d
- https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3
- https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c
- https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4
- https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69
- https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364
- https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8
- https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8
- https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044
- https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d
- https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3
- https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c
- https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4
- https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69
- https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364
- https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8
- https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8
- https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-18
CVE-2024-27389
In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---
- https://git.kernel.org/stable/c/340682ed1932b8e3bd0bfc6c31a0c6354eb57cc6
- https://git.kernel.org/stable/c/4cdf9006fc095af71da80e9b5f48a32e991b9ed3
- https://git.kernel.org/stable/c/a43e0fc5e9134a46515de2f2f8d4100b74e50de3
- https://git.kernel.org/stable/c/cb9e802e49c24eeb3af35e9e8c04d526f35f112a
- https://git.kernel.org/stable/c/db6e5e16f1ee9e3b01d2f71c7f0ba945f4bf0f4e
- https://git.kernel.org/stable/c/340682ed1932b8e3bd0bfc6c31a0c6354eb57cc6
- https://git.kernel.org/stable/c/4cdf9006fc095af71da80e9b5f48a32e991b9ed3
- https://git.kernel.org/stable/c/a43e0fc5e9134a46515de2f2f8d4100b74e50de3
- https://git.kernel.org/stable/c/cb9e802e49c24eeb3af35e9e8c04d526f35f112a
- https://git.kernel.org/stable/c/db6e5e16f1ee9e3b01d2f71c7f0ba945f4bf0f4e
Modified: 2025-09-18
CVE-2024-27390
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well.
- https://git.kernel.org/stable/c/17ef8efc00b34918b966388b2af0993811895a8c
- https://git.kernel.org/stable/c/26d4bac55750d535f1f0b8790dc26daf6089e373
- https://git.kernel.org/stable/c/5da9a218340a2bc804dc4327e5804392e24a0b88
- https://git.kernel.org/stable/c/7eb06ee5921189812e6b4bfe7b0f1e878be16df7
- https://git.kernel.org/stable/c/9d159d6637ccce25f879d662a480541ef4ba3a50
- https://git.kernel.org/stable/c/a03ede2282ebbd181bd6f5c38cbfcb5765afcd04
- https://git.kernel.org/stable/c/17ef8efc00b34918b966388b2af0993811895a8c
- https://git.kernel.org/stable/c/26d4bac55750d535f1f0b8790dc26daf6089e373
- https://git.kernel.org/stable/c/5da9a218340a2bc804dc4327e5804392e24a0b88
- https://git.kernel.org/stable/c/7eb06ee5921189812e6b4bfe7b0f1e878be16df7
- https://git.kernel.org/stable/c/9d159d6637ccce25f879d662a480541ef4ba3a50
- https://git.kernel.org/stable/c/a03ede2282ebbd181bd6f5c38cbfcb5765afcd04
Modified: 2025-09-18
CVE-2024-27391
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: do not realloc workqueue everytime an interface is added Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands: for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue.
- https://git.kernel.org/stable/c/328efda22af81130c2ad981c110518cb29ff2f1d
- https://git.kernel.org/stable/c/4041c60a9d543b3ad50225385b072ba68e96166e
- https://git.kernel.org/stable/c/515cc676dfbce40d93c92b1ff3c1070e917f4e52
- https://git.kernel.org/stable/c/90ae293d1d255f622318fce6eeea2e18f9fde5c1
- https://git.kernel.org/stable/c/9ab0c303ccabfd6bdce14432792d41090070008c
- https://git.kernel.org/stable/c/328efda22af81130c2ad981c110518cb29ff2f1d
- https://git.kernel.org/stable/c/4041c60a9d543b3ad50225385b072ba68e96166e
- https://git.kernel.org/stable/c/515cc676dfbce40d93c92b1ff3c1070e917f4e52
- https://git.kernel.org/stable/c/90ae293d1d255f622318fce6eeea2e18f9fde5c1
- https://git.kernel.org/stable/c/9ab0c303ccabfd6bdce14432792d41090070008c
Modified: 2025-04-08
CVE-2024-27393
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks").
- https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f
- https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629
- https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1
- https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6
- https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4
- http://www.openwall.com/lists/oss-security/2024/05/08/4
- http://xenbits.xen.org/xsa/advisory-457.html
- https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f
- https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629
- https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1
- https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6
- https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4
Modified: 2025-09-18
CVE-2024-27402
In the Linux kernel, the following vulnerability has been resolved: phonet/pep: fix racy skb_queue_empty() use The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.
- https://git.kernel.org/stable/c/0a9f558c72c47472c38c05fcb72c70abb9104277
- https://git.kernel.org/stable/c/7d2a894d7f487dcb894df023e9d3014cf5b93fe5
- https://git.kernel.org/stable/c/7d3914a477eed92b48c493a8631cc4554ab4fd4f
- https://git.kernel.org/stable/c/8ef4fcc7014b9f93619851d6b78d6cc2789a4c88
- https://git.kernel.org/stable/c/9d5523e065b568e79dfaa2ea1085a5bcf74baf78
- https://git.kernel.org/stable/c/0a9f558c72c47472c38c05fcb72c70abb9104277
- https://git.kernel.org/stable/c/7d2a894d7f487dcb894df023e9d3014cf5b93fe5
- https://git.kernel.org/stable/c/8ef4fcc7014b9f93619851d6b78d6cc2789a4c88
- https://git.kernel.org/stable/c/9d5523e065b568e79dfaa2ea1085a5bcf74baf78
Modified: 2025-09-18
CVE-2024-27403
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_flow_offload: reset dst in route object after setting up flow dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow.
- https://git.kernel.org/stable/c/012df10717da02367aaf92c65f9c89db206c15f4
- https://git.kernel.org/stable/c/4c167af9f6b5ae4a5dbc243d5983c295ccc2e43c
- https://git.kernel.org/stable/c/558b00a30e05753a62ecc7e05e939ca8f0241148
- https://git.kernel.org/stable/c/670548c8db44d76e40e1dfc06812bca36a61e9ae
- https://git.kernel.org/stable/c/9e0f0430389be7696396c62f037be4bf72cf93e3
- https://git.kernel.org/stable/c/012df10717da02367aaf92c65f9c89db206c15f4
- https://git.kernel.org/stable/c/4c167af9f6b5ae4a5dbc243d5983c295ccc2e43c
- https://git.kernel.org/stable/c/558b00a30e05753a62ecc7e05e939ca8f0241148
- https://git.kernel.org/stable/c/670548c8db44d76e40e1dfc06812bca36a61e9ae
- https://git.kernel.org/stable/c/9e0f0430389be7696396c62f037be4bf72cf93e3
Modified: 2025-09-18
CVE-2024-27404
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data races on remote_id Similar to the previous patch, address the data race on remote_id, adding the suitable ONCE annotations.
- https://git.kernel.org/stable/c/2dba5774e8ed326a78ad4339d921a4291281ea6e
- https://git.kernel.org/stable/c/967d3c27127e71a10ff5c083583a038606431b61
- https://git.kernel.org/stable/c/987c3ed7297e5661bc7f448f06fc366e497ac9b2
- https://git.kernel.org/stable/c/e64148635509bf13eea851986f5a0b150e5bd066
- https://git.kernel.org/stable/c/2dba5774e8ed326a78ad4339d921a4291281ea6e
- https://git.kernel.org/stable/c/967d3c27127e71a10ff5c083583a038606431b61
- https://git.kernel.org/stable/c/987c3ed7297e5661bc7f448f06fc366e497ac9b2
- https://git.kernel.org/stable/c/e64148635509bf13eea851986f5a0b150e5bd066
Modified: 2025-04-08
CVE-2024-27405
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.
- https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48
- https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e
- https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5
- https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca
- https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd
- https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd
- https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151
- https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e
- https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48
- https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e
- https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5
- https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca
- https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd
- https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd
- https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151
- https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27410
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject iftype change with mesh ID change It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID.
- https://git.kernel.org/stable/c/177d574be4b58f832354ab1ef5a297aa0c9aa2df
- https://git.kernel.org/stable/c/930e826962d9f01dcd2220176134427358d112f2
- https://git.kernel.org/stable/c/a2add961a5ed25cfd6a74f9ffb9e7ab6d6ded838
- https://git.kernel.org/stable/c/f78c1375339a291cba492a70eaf12ec501d28a8e
- https://git.kernel.org/stable/c/063715c33b4c37587aeca2c83cf08ead0c542995
- https://git.kernel.org/stable/c/0cfbb26ee5e7b3d6483a73883f9f6157bca22ec9
- https://git.kernel.org/stable/c/177d574be4b58f832354ab1ef5a297aa0c9aa2df
- https://git.kernel.org/stable/c/930e826962d9f01dcd2220176134427358d112f2
- https://git.kernel.org/stable/c/99eb2159680af8786104dac80528acd5acd45980
- https://git.kernel.org/stable/c/a2add961a5ed25cfd6a74f9ffb9e7ab6d6ded838
- https://git.kernel.org/stable/c/d38d31bbbb9dc0d4d71a45431eafba03d0bc150d
- https://git.kernel.org/stable/c/f78c1375339a291cba492a70eaf12ec501d28a8e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27412
In the Linux kernel, the following vulnerability has been resolved: power: supply: bq27xxx-i2c: Do not free non existing IRQ The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq(). But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to: [ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring probe() to fix this.
- https://git.kernel.org/stable/c/083686474e7c97b0f8b66df37fcb64e432e8b771
- https://git.kernel.org/stable/c/2df70149e73e79783bcbc7db4fa51ecef0e2022c
- https://git.kernel.org/stable/c/7394abc8926adee6a817bab10797e0adc898af77
- https://git.kernel.org/stable/c/cefe18e9ec84f8fe3e198ccebb815cc996eb9797
- https://git.kernel.org/stable/c/d4d813c0a14d6bf52d810a55db06a2e7e3d98eaa
- https://git.kernel.org/stable/c/d7acc4a569f5f4513120c85ea2b9f04909b7490f
- https://git.kernel.org/stable/c/e601ae81910ce6a3797876e190a2d8ef6cf828bc
- https://git.kernel.org/stable/c/fbca8bae1ba79d443a58781b45e92a73a24ac8f8
- https://git.kernel.org/stable/c/083686474e7c97b0f8b66df37fcb64e432e8b771
- https://git.kernel.org/stable/c/2df70149e73e79783bcbc7db4fa51ecef0e2022c
- https://git.kernel.org/stable/c/7394abc8926adee6a817bab10797e0adc898af77
- https://git.kernel.org/stable/c/cefe18e9ec84f8fe3e198ccebb815cc996eb9797
- https://git.kernel.org/stable/c/d4d813c0a14d6bf52d810a55db06a2e7e3d98eaa
- https://git.kernel.org/stable/c/d7acc4a569f5f4513120c85ea2b9f04909b7490f
- https://git.kernel.org/stable/c/e601ae81910ce6a3797876e190a2d8ef6cf828bc
- https://git.kernel.org/stable/c/fbca8bae1ba79d443a58781b45e92a73a24ac8f8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27413
In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect allocation size gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here.
- https://git.kernel.org/stable/c/00cf21ac526011a29fc708f8912da446fac19f7b
- https://git.kernel.org/stable/c/11aabd7487857b8e7d768fefb092f66dfde68492
- https://git.kernel.org/stable/c/4b73473c050a612fb4317831371073eda07c3050
- https://git.kernel.org/stable/c/537e3f49dbe88881a6f0752beaa596942d9efd64
- https://git.kernel.org/stable/c/62a5dcd9bd3097e9813de62fa6f22815e84a0172
- https://git.kernel.org/stable/c/950d4d74d311a18baed6878dbfba8180d7e5dddd
- https://git.kernel.org/stable/c/ddc547dd05a46720866c32022300f7376c40119f
- https://git.kernel.org/stable/c/fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e
- https://git.kernel.org/stable/c/00cf21ac526011a29fc708f8912da446fac19f7b
- https://git.kernel.org/stable/c/11aabd7487857b8e7d768fefb092f66dfde68492
- https://git.kernel.org/stable/c/4b73473c050a612fb4317831371073eda07c3050
- https://git.kernel.org/stable/c/537e3f49dbe88881a6f0752beaa596942d9efd64
- https://git.kernel.org/stable/c/62a5dcd9bd3097e9813de62fa6f22815e84a0172
- https://git.kernel.org/stable/c/950d4d74d311a18baed6878dbfba8180d7e5dddd
- https://git.kernel.org/stable/c/ddc547dd05a46720866c32022300f7376c40119f
- https://git.kernel.org/stable/c/fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27414
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic in the function `rtnl_bridge_setlink` to enable the loop to also check the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment removed the `break` statement and led to an error logic of the flags writing back at the end of this function. if (have_flags) memcpy(nla_data(attr), &flags, sizeof(flags)); // attr should point to IFLA_BRIDGE_FLAGS NLA !!! Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS. However, this is not necessarily true fow now as the updated loop will let the attr point to the last NLA, even an invalid NLA which could cause overflow writes. This patch introduces a new variable `br_flag` to save the NLA pointer that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned error logic.
- https://git.kernel.org/stable/c/167d8642daa6a44b51de17f8ff0f584e1e762db7
- https://git.kernel.org/stable/c/743ad091fb46e622f1b690385bb15e3cd3daf874
- https://git.kernel.org/stable/c/831bc2728fb48a8957a824cba8c264b30dca1425
- https://git.kernel.org/stable/c/882a51a10ecf24ce135d573afa0872aef02c5125
- https://git.kernel.org/stable/c/a1227b27fcccc99dc44f912b479e01a17e2d7d31
- https://git.kernel.org/stable/c/b9fbc44159dfc3e9a7073032752d9e03f5194a6f
- https://git.kernel.org/stable/c/f2261eb994aa5757c1da046b78e3229a3ece0ad9
- https://git.kernel.org/stable/c/167d8642daa6a44b51de17f8ff0f584e1e762db7
- https://git.kernel.org/stable/c/743ad091fb46e622f1b690385bb15e3cd3daf874
- https://git.kernel.org/stable/c/831bc2728fb48a8957a824cba8c264b30dca1425
- https://git.kernel.org/stable/c/882a51a10ecf24ce135d573afa0872aef02c5125
- https://git.kernel.org/stable/c/a1227b27fcccc99dc44f912b479e01a17e2d7d31
- https://git.kernel.org/stable/c/b9fbc44159dfc3e9a7073032752d9e03f5194a6f
- https://git.kernel.org/stable/c/f2261eb994aa5757c1da046b78e3229a3ece0ad9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27415
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: confirm multicast packets before passing them up the stack conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb. The Macvlan broadcast worker and normal confirm path will race. This race will not happen if step 2 already confirmed a clone. In that case later steps perform skb_clone() with skb->_nfct already confirmed (in hash table). This works fine. But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting. Pablo points out that nf_conntrack_bridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again. This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook. Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry. The downside is that this disables NAT and conntrack helpers. Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example: -m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5 For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings. Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.
- https://git.kernel.org/stable/c/2b1414d5e94e477edff1d2c79030f1d742625ea0
- https://git.kernel.org/stable/c/62e7151ae3eb465e0ab52a20c941ff33bb6332e9
- https://git.kernel.org/stable/c/7c3f28599652acf431a2211168de4a583f30b6d5
- https://git.kernel.org/stable/c/80cd0487f630b5382734997c3e5e3003a77db315
- https://git.kernel.org/stable/c/cb734975b0ffa688ff6cc0eed463865bf07b6c01
- https://git.kernel.org/stable/c/2b1414d5e94e477edff1d2c79030f1d742625ea0
- https://git.kernel.org/stable/c/62e7151ae3eb465e0ab52a20c941ff33bb6332e9
- https://git.kernel.org/stable/c/7c3f28599652acf431a2211168de4a583f30b6d5
- https://git.kernel.org/stable/c/80cd0487f630b5382734997c3e5e3003a77db315
- https://git.kernel.org/stable/c/cb734975b0ffa688ff6cc0eed463865bf07b6c01
Modified: 2025-12-17
CVE-2024-27416
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated.
- https://git.kernel.org/stable/c/30a5e812f78e3d1cced90e1ed750bf027599205f
- https://git.kernel.org/stable/c/79820a7e1e057120c49be07cbe10643d0706b259
- https://git.kernel.org/stable/c/7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865
- https://git.kernel.org/stable/c/8e2758cc25891d2b76717aaf89b40ed215de188c
- https://git.kernel.org/stable/c/afec8f772296dd8e5a2a6f83bbf99db1b9ca877f
- https://git.kernel.org/stable/c/c3df637266df29edee85e94cab5fd7041e5753ba
- https://git.kernel.org/stable/c/df193568d61234c81de7ed4d540c01975de60277
- https://git.kernel.org/stable/c/fba268ac36ab19f9763ff90d276cde0ce6cd5f31
- https://git.kernel.org/stable/c/30a5e812f78e3d1cced90e1ed750bf027599205f
- https://git.kernel.org/stable/c/79820a7e1e057120c49be07cbe10643d0706b259
- https://git.kernel.org/stable/c/7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865
- https://git.kernel.org/stable/c/8e2758cc25891d2b76717aaf89b40ed215de188c
- https://git.kernel.org/stable/c/afec8f772296dd8e5a2a6f83bbf99db1b9ca877f
- https://git.kernel.org/stable/c/c3df637266df29edee85e94cab5fd7041e5753ba
- https://git.kernel.org/stable/c/df193568d61234c81de7ed4d540c01975de60277
- https://git.kernel.org/stable/c/fba268ac36ab19f9763ff90d276cde0ce6cd5f31
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27417
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix potential "struct net" leak in inet6_rtm_getaddr() It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount.
- https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c48653cdb
- https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a
- https://git.kernel.org/stable/c/33a1b6bfef6def2068c8703403759024ce17053e
- https://git.kernel.org/stable/c/44112bc5c74e64f28f5a9127dc34066c7a09bd0f
- https://git.kernel.org/stable/c/810fa7d5e5202fcfb22720304b755f1bdfd4c174
- https://git.kernel.org/stable/c/8a54834c03c30e549c33d5da0975f3e1454ec906
- https://git.kernel.org/stable/c/9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132
- https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c48653cdb
- https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a
- https://git.kernel.org/stable/c/33a1b6bfef6def2068c8703403759024ce17053e
- https://git.kernel.org/stable/c/44112bc5c74e64f28f5a9127dc34066c7a09bd0f
- https://git.kernel.org/stable/c/810fa7d5e5202fcfb22720304b755f1bdfd4c174
- https://git.kernel.org/stable/c/8a54834c03c30e549c33d5da0975f3e1454ec906
- https://git.kernel.org/stable/c/9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27418
In the Linux kernel, the following vulnerability has been resolved: net: mctp: take ownership of skb in mctp_local_output Currently, mctp_local_output only takes ownership of skb on success, and we may leak an skb if mctp_local_output fails in specific states; the skb ownership isn't transferred until the actual output routing occurs. Instead, make mctp_local_output free the skb on all error paths up to the route action, so it always consumes the passed skb.
- https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3
- https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd
- https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b
- https://git.kernel.org/stable/c/cbebc55ceacef1fc0651e80e0103cc184552fc68
- https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3
- https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd
- https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b
- https://git.kernel.org/stable/c/cbebc55ceacef1fc0651e80e0103cc184552fc68
Modified: 2025-12-23
CVE-2024-27419
In the Linux kernel, the following vulnerability has been resolved: netrom: Fix data-races around sysctl_net_busy_read We need to protect the reader reading the sysctl value because the value can be changed concurrently.
- https://git.kernel.org/stable/c/0866afaff19d8460308b022345ed116a12b1d0e1
- https://git.kernel.org/stable/c/16d71319e29d5825ab53f263b59fdd8dc2d60ad4
- https://git.kernel.org/stable/c/34cab94f7473e7b09f5205d4583fb5096cb63b5b
- https://git.kernel.org/stable/c/43464808669ba9d23996f0b6d875450191687caf
- https://git.kernel.org/stable/c/bbf950a6e96a91cf8cf0c71117b94ed3fafc9dd3
- https://git.kernel.org/stable/c/d380ce70058a4ccddc3e5f5c2063165dc07672c6
- https://git.kernel.org/stable/c/d623fd5298d95b65d27ef5a618ebf39541074856
- https://git.kernel.org/stable/c/f9055fa2b2931261d5f89948ee5bc315b6a22d4a
- https://git.kernel.org/stable/c/0866afaff19d8460308b022345ed116a12b1d0e1
- https://git.kernel.org/stable/c/16d71319e29d5825ab53f263b59fdd8dc2d60ad4
- https://git.kernel.org/stable/c/34cab94f7473e7b09f5205d4583fb5096cb63b5b
- https://git.kernel.org/stable/c/43464808669ba9d23996f0b6d875450191687caf
- https://git.kernel.org/stable/c/bbf950a6e96a91cf8cf0c71117b94ed3fafc9dd3
- https://git.kernel.org/stable/c/d380ce70058a4ccddc3e5f5c2063165dc07672c6
- https://git.kernel.org/stable/c/d623fd5298d95b65d27ef5a618ebf39541074856
- https://git.kernel.org/stable/c/f9055fa2b2931261d5f89948ee5bc315b6a22d4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27431
In the Linux kernel, the following vulnerability has been resolved: cpumap: Zero-initialise xdp_rxq_info struct before running XDP program When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program.
- https://git.kernel.org/stable/c/2487007aa3b9fafbd2cb14068f49791ce1d7ede5
- https://git.kernel.org/stable/c/3420b3ff1ff489c177ea1cb7bd9fbbc4e9a0be95
- https://git.kernel.org/stable/c/5f4e51abfbe6eb444fa91906a5cd083044278297
- https://git.kernel.org/stable/c/eaa7cb836659ced2d9f814ac32aa3ec193803ed6
- https://git.kernel.org/stable/c/f0363af9619c77730764f10360e36c6445c12f7b
- https://git.kernel.org/stable/c/f562e4c4aab00986dde3093c4be919c3f2b85a4a
- https://git.kernel.org/stable/c/2487007aa3b9fafbd2cb14068f49791ce1d7ede5
- https://git.kernel.org/stable/c/3420b3ff1ff489c177ea1cb7bd9fbbc4e9a0be95
- https://git.kernel.org/stable/c/5f4e51abfbe6eb444fa91906a5cd083044278297
- https://git.kernel.org/stable/c/eaa7cb836659ced2d9f814ac32aa3ec193803ed6
- https://git.kernel.org/stable/c/f0363af9619c77730764f10360e36c6445c12f7b
- https://git.kernel.org/stable/c/f562e4c4aab00986dde3093c4be919c3f2b85a4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27432
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix PPE hanging issue A patch to resolve an issue was found in MediaTek's GPL-licensed SDK: In the mtk_ppe_stop() function, the PPE scan mode is not disabled before disabling the PPE. This can potentially lead to a hang during the process of disabling the PPE. Without this patch, the PPE may experience a hang during the reboot test.
- https://git.kernel.org/stable/c/09a1907433865b7c8ee6777e507f5126bdd38c0f
- https://git.kernel.org/stable/c/49202a8256fc50517ef06fd5e2084c4febde6369
- https://git.kernel.org/stable/c/943c14ece95eb1cf98d477462aebcbfdfd714633
- https://git.kernel.org/stable/c/9fcadd125044007351905d40c405fadc2d3bb6d6
- https://git.kernel.org/stable/c/ea80e3ed09ab2c2b75724faf5484721753e92c31
- https://git.kernel.org/stable/c/f78807362828ad01db2a9ed005bf79501b620f27
- https://git.kernel.org/stable/c/09a1907433865b7c8ee6777e507f5126bdd38c0f
- https://git.kernel.org/stable/c/49202a8256fc50517ef06fd5e2084c4febde6369
- https://git.kernel.org/stable/c/943c14ece95eb1cf98d477462aebcbfdfd714633
- https://git.kernel.org/stable/c/9fcadd125044007351905d40c405fadc2d3bb6d6
- https://git.kernel.org/stable/c/ea80e3ed09ab2c2b75724faf5484721753e92c31
- https://git.kernel.org/stable/c/f78807362828ad01db2a9ed005bf79501b620f27
Modified: 2025-09-26
CVE-2024-27435
In the Linux kernel, the following vulnerability has been resolved: nvme: fix reconnection fail due to reserved tag allocation We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue.
- https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8
- https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818
- https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96
- https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d
- https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a
- https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8
- https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818
- https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96
- https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d
- https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a
Modified: 2025-12-23
CVE-2024-27436
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Stop parsing channels bits when all channels are found. If a usb audio device sets more bits than the amount of channels it could write outside of the map array.
- https://git.kernel.org/stable/c/22cad1b841a63635a38273b799b4791f202ade72
- https://git.kernel.org/stable/c/5cd466673b34bac369334f66cbe14bb77b7d7827
- https://git.kernel.org/stable/c/629af0d5fe94a35f498ba2c3f19bd78bfa591be6
- https://git.kernel.org/stable/c/6d5dc96b154be371df0d62ecb07efe400701ed8a
- https://git.kernel.org/stable/c/6d88b289fb0a8d055cb79d1c46a56aba7809d96d
- https://git.kernel.org/stable/c/7e2c1b0f6dd9abde9e60f0f9730026714468770f
- https://git.kernel.org/stable/c/9af1658ba293458ca6a13f70637b9654fa4be064
- https://git.kernel.org/stable/c/a39d51ff1f52cd0b6fe7d379ac93bd8b4237d1b7
- https://git.kernel.org/stable/c/c8a24fd281dcdf3c926413dafbafcf35cde517a9
- https://git.kernel.org/stable/c/22cad1b841a63635a38273b799b4791f202ade72
- https://git.kernel.org/stable/c/5cd466673b34bac369334f66cbe14bb77b7d7827
- https://git.kernel.org/stable/c/629af0d5fe94a35f498ba2c3f19bd78bfa591be6
- https://git.kernel.org/stable/c/6d5dc96b154be371df0d62ecb07efe400701ed8a
- https://git.kernel.org/stable/c/6d88b289fb0a8d055cb79d1c46a56aba7809d96d
- https://git.kernel.org/stable/c/7e2c1b0f6dd9abde9e60f0f9730026714468770f
- https://git.kernel.org/stable/c/9af1658ba293458ca6a13f70637b9654fa4be064
- https://git.kernel.org/stable/c/a39d51ff1f52cd0b6fe7d379ac93bd8b4237d1b7
- https://git.kernel.org/stable/c/c8a24fd281dcdf3c926413dafbafcf35cde517a9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-27
CVE-2024-27437
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.
- https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060
- https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351
- https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2
- https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda
- https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5
- https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438
- https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec
- https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43
- https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060
- https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351
- https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2
- https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda
- https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5
- https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438
- https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec
- https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-01-22
CVE-2024-35785
In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix kernel panic caused by incorrect error handling The error path while failing to register devices on the TEE bus has a bug leading to kernel panic as follows: [ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c [ 15.406913] Mem abort info: [ 15.409722] ESR = 0x0000000096000005 [ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.418814] SET = 0, FnV = 0 [ 15.421878] EA = 0, S1PTW = 0 [ 15.425031] FSC = 0x05: level 1 translation fault [ 15.429922] Data abort info: [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000 [ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000 [ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration") lead to the introduction of this bug. So fix it appropriately.
- https://git.kernel.org/stable/c/4b12ff5edd141926d49c9ace4791adf3a4902fe7
- https://git.kernel.org/stable/c/520f79c110ff712b391b3d87fcacf03c74bc56ee
- https://git.kernel.org/stable/c/95915ba4b987cf2b222b0f251280228a1ff977ac
- https://git.kernel.org/stable/c/bc40ded92af55760d12bec8222d4108de725dbe4
- https://git.kernel.org/stable/c/bfa344afbe472a9be08f78551fa2190c1a07d7d3
- https://git.kernel.org/stable/c/e5b5948c769aa1ebf962dddfb972f87d8f166f95
- https://git.kernel.org/stable/c/4b12ff5edd141926d49c9ace4791adf3a4902fe7
- https://git.kernel.org/stable/c/520f79c110ff712b391b3d87fcacf03c74bc56ee
- https://git.kernel.org/stable/c/95915ba4b987cf2b222b0f251280228a1ff977ac
- https://git.kernel.org/stable/c/bc40ded92af55760d12bec8222d4108de725dbe4
- https://git.kernel.org/stable/c/bfa344afbe472a9be08f78551fa2190c1a07d7d3
- https://git.kernel.org/stable/c/e5b5948c769aa1ebf962dddfb972f87d8f166f95
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-35789
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change.
- https://git.kernel.org/stable/c/2884a50f52313a7a911de3afcad065ddbb3d78fc
- https://git.kernel.org/stable/c/4f2bdb3c5e3189297e156b3ff84b140423d64685
- https://git.kernel.org/stable/c/6b948b54c8bd620725e0c906e44b10c0b13087a7
- https://git.kernel.org/stable/c/7eeabcea79b67cc29563e6a9a5c81f9e2c664d5b
- https://git.kernel.org/stable/c/be1dd9254fc115321d6fbee042026d42afc8d931
- https://git.kernel.org/stable/c/c8bddbd91bc8e42c961a5e2cec20ab879f21100f
- https://git.kernel.org/stable/c/e8678551c0243f799b4859448781cbec1bd6f1cb
- https://git.kernel.org/stable/c/e8b067c4058c0121ac8ca71559df8e2e08ff1a7e
- https://git.kernel.org/stable/c/ea9a0cfc07a7d3601cc680718d9cff0d6927a921
- https://git.kernel.org/stable/c/2884a50f52313a7a911de3afcad065ddbb3d78fc
- https://git.kernel.org/stable/c/4f2bdb3c5e3189297e156b3ff84b140423d64685
- https://git.kernel.org/stable/c/6b948b54c8bd620725e0c906e44b10c0b13087a7
- https://git.kernel.org/stable/c/7eeabcea79b67cc29563e6a9a5c81f9e2c664d5b
- https://git.kernel.org/stable/c/be1dd9254fc115321d6fbee042026d42afc8d931
- https://git.kernel.org/stable/c/c8bddbd91bc8e42c961a5e2cec20ab879f21100f
- https://git.kernel.org/stable/c/e8678551c0243f799b4859448781cbec1bd6f1cb
- https://git.kernel.org/stable/c/e8b067c4058c0121ac8ca71559df8e2e08ff1a7e
- https://git.kernel.org/stable/c/ea9a0cfc07a7d3601cc680718d9cff0d6927a921
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35791
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has __unregister_enc_region_locked() already queued up for the region. Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed. Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory.
- https://git.kernel.org/stable/c/12f8e32a5a389a5d58afc67728c76e61beee1ad4
- https://git.kernel.org/stable/c/2d13b79640b147bd77c34a5998533b2021a4122d
- https://git.kernel.org/stable/c/4868c0ecdb6cfde7c70cf478c46e06bb9c7e5865
- https://git.kernel.org/stable/c/5ef1d8c1ddbf696e47b226e11888eaf8d9e8e807
- https://git.kernel.org/stable/c/e126b508ed2e616d679d85fca2fbe77bb48bbdd7
- https://git.kernel.org/stable/c/f6d53d8a2617dd58c89171a6b9610c470ebda38a
- https://git.kernel.org/stable/c/12f8e32a5a389a5d58afc67728c76e61beee1ad4
- https://git.kernel.org/stable/c/2d13b79640b147bd77c34a5998533b2021a4122d
- https://git.kernel.org/stable/c/4868c0ecdb6cfde7c70cf478c46e06bb9c7e5865
- https://git.kernel.org/stable/c/5ef1d8c1ddbf696e47b226e11888eaf8d9e8e807
- https://git.kernel.org/stable/c/e126b508ed2e616d679d85fca2fbe77bb48bbdd7
- https://git.kernel.org/stable/c/f6d53d8a2617dd58c89171a6b9610c470ebda38a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-35796
In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: platform_get_resource replaced by wrong function The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name. This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name)) It should have been replaced with devm_platform_ioremap_resource.
- https://git.kernel.org/stable/c/3a38a829c8bc27d78552c28e582eb1d885d07d11
- https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3
- https://git.kernel.org/stable/c/476eed5f1c22034774902a980aa48dc4662cb39a
- https://git.kernel.org/stable/c/553d294db94b5f139378022df480a9fb6c3ae39e
- https://git.kernel.org/stable/c/6d9395ba7f85bdb7af0b93272e537484ecbeff48
- https://git.kernel.org/stable/c/7e9edb569fd9f688d887e36db8170f6e22bafbc8
- https://git.kernel.org/stable/c/92c0c29f667870f17c0b764544bdf22ce0e886a1
- https://git.kernel.org/stable/c/3a38a829c8bc27d78552c28e582eb1d885d07d11
- https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3
- https://git.kernel.org/stable/c/476eed5f1c22034774902a980aa48dc4662cb39a
- https://git.kernel.org/stable/c/553d294db94b5f139378022df480a9fb6c3ae39e
- https://git.kernel.org/stable/c/6d9395ba7f85bdb7af0b93272e537484ecbeff48
- https://git.kernel.org/stable/c/7e9edb569fd9f688d887e36db8170f6e22bafbc8
- https://git.kernel.org/stable/c/92c0c29f667870f17c0b764544bdf22ce0e886a1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-19
CVE-2024-35801
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.
- https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422
- https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd
- https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d
- https://git.kernel.org/stable/c/92b0f04e937665bde5768f3fcc622dcce44413d8
- https://git.kernel.org/stable/c/b61e3b7055ac6edee4be071c52f48c26472d2624
- https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422
- https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd
- https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d
- https://git.kernel.org/stable/c/92b0f04e937665bde5768f3fcc622dcce44413d8
- https://git.kernel.org/stable/c/b61e3b7055ac6edee4be071c52f48c26472d2624
Modified: 2025-09-26
CVE-2024-35803
In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made.
- https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926
- https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc
- https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31
- https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02
- https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d
- https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926
- https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc
- https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31
- https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02
- https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d
Modified: 2025-09-19
CVE-2024-35804
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Mark target gfn of emulated atomic instruction as dirty When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty. Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase. Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit. Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging. base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64
- https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71
- https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06
- https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902
- https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551
- https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66
- https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71
- https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06
- https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902
- https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551
- https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66
Modified: 2025-12-23
CVE-2024-35805
In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.
- https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7
- https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1
- https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683
- https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc
- https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c
- https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2
- https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e
- https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366
- https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7
- https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1
- https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683
- https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc
- https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c
- https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2
- https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e
- https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-10
CVE-2024-35806
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Always disable interrupts when taking cgr_lock smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.
- https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397
- https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f
- https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3
- https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a
- https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03
- https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd
- https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9
- https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec
- https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430
- https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397
- https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f
- https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3
- https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a
- https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03
- https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd
- https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9
- https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec
- https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-35807
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix corruption during on-line resize
We observed a corruption during on-line resize of a file system that is
larger than 16 TiB with 4k block size. With having more then 2^32 blocks
resize_inode is turned off by default by mke2fs. The issue can be
reproduced on a smaller file system for convenience by explicitly
turning off resize_inode. An on-line resize across an 8 GiB boundary (the
size of a meta block group in this setup) then leads to a corruption:
dev=/dev/
- https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6
- https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5
- https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd
- https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1
- https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc
- https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c
- https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a
- https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c
- https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df
- https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6
- https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5
- https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd
- https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1
- https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc
- https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c
- https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a
- https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c
- https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35809
In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks.
- https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1
- https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627bdc6970
- https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674
- https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b
- https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6
- https://git.kernel.org/stable/c/9d5286d4e7f68beab450deddbb6a32edd5ecf4bf
- https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491
- https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5
- https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989
- https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1
- https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627bdc6970
- https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674
- https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b
- https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6
- https://git.kernel.org/stable/c/9d5286d4e7f68beab450deddbb6a32edd5ecf4bf
- https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491
- https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5
- https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-35811
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
- https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb
- https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744
- https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78
- https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a
- https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169
- https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a
- https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731
- https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1
- https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa
- https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb
- https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744
- https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78
- https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a
- https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169
- https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a
- https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731
- https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1
- https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-16
CVE-2024-35813
In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid negative index with array access Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns prev_idata = idatas[i - 1], but doesn't check that the iterator i is greater than zero. Let's fix this by adding a check.
- https://git.kernel.org/stable/c/064db53f9023a2d5877a2d12de6bc27995f6ca56
- https://git.kernel.org/stable/c/2b539c88940e22494da80a93ee1c5a28bbad10f6
- https://git.kernel.org/stable/c/4466677dcabe2d70de6aa3d4bd4a4fafa94a71f2
- https://git.kernel.org/stable/c/7d0e8a6147550aa058fa6ade8583ad252aa61304
- https://git.kernel.org/stable/c/81b8645feca08a54c7c4bf36e7b176f4983b2f28
- https://git.kernel.org/stable/c/ad9cc5e9e53ab94aa0c7ac65d43be7eb208dcb55
- https://git.kernel.org/stable/c/b9a7339ae403035ffe7fc37cb034b36947910f68
- https://git.kernel.org/stable/c/cf55a7acd1ed38afe43bba1c8a0935b51d1dc014
- https://git.kernel.org/stable/c/064db53f9023a2d5877a2d12de6bc27995f6ca56
- https://git.kernel.org/stable/c/2b539c88940e22494da80a93ee1c5a28bbad10f6
- https://git.kernel.org/stable/c/4466677dcabe2d70de6aa3d4bd4a4fafa94a71f2
- https://git.kernel.org/stable/c/7d0e8a6147550aa058fa6ade8583ad252aa61304
- https://git.kernel.org/stable/c/81b8645feca08a54c7c4bf36e7b176f4983b2f28
- https://git.kernel.org/stable/c/ad9cc5e9e53ab94aa0c7ac65d43be7eb208dcb55
- https://git.kernel.org/stable/c/b9a7339ae403035ffe7fc37cb034b36947910f68
- https://git.kernel.org/stable/c/cf55a7acd1ed38afe43bba1c8a0935b51d1dc014
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-35817
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue.
- https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe
- https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d
- https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb
- https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3
- https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3
- https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6
- https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe
- https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d
- https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb
- https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3
- https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3
- https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6
Modified: 2025-09-26
CVE-2024-35818
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition. Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch: radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
- https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0
- https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167
- https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb
- https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd
- https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d
- https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0
- https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167
- https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb
- https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd
- https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d
Modified: 2025-12-17
CVE-2024-35819
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Use raw spinlock for cgr_lock smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task. Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.
- https://git.kernel.org/stable/c/2b3fede8225133671ce837c0d284804aa3bc7a02
- https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1
- https://git.kernel.org/stable/c/54d26adf64c04f186098b39dba86b86037084baa
- https://git.kernel.org/stable/c/9a3ca8292ce9fdcce122706c28c3f07bc857fe5e
- https://git.kernel.org/stable/c/cd53a8ae5aacb4ecd25088486dea1cd02e74b506
- https://git.kernel.org/stable/c/d6b5aac451c9cc12e43ab7308e0e2ddc52c62c14
- https://git.kernel.org/stable/c/f39d36b7540cf0088ed7ce2de2794f2aa237f6df
- https://git.kernel.org/stable/c/fbec4e7fed89b579f2483041fabf9650fb0dd6bc
- https://git.kernel.org/stable/c/ff50716b7d5b7985979a5b21163cd79fb3d21d59
- https://git.kernel.org/stable/c/2b3fede8225133671ce837c0d284804aa3bc7a02
- https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1
- https://git.kernel.org/stable/c/54d26adf64c04f186098b39dba86b86037084baa
- https://git.kernel.org/stable/c/9a3ca8292ce9fdcce122706c28c3f07bc857fe5e
- https://git.kernel.org/stable/c/cd53a8ae5aacb4ecd25088486dea1cd02e74b506
- https://git.kernel.org/stable/c/d6b5aac451c9cc12e43ab7308e0e2ddc52c62c14
- https://git.kernel.org/stable/c/f39d36b7540cf0088ed7ce2de2794f2aa237f6df
- https://git.kernel.org/stable/c/fbec4e7fed89b579f2483041fabf9650fb0dd6bc
- https://git.kernel.org/stable/c/ff50716b7d5b7985979a5b21163cd79fb3d21d59
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35821
In the Linux kernel, the following vulnerability has been resolved: ubifs: Set page uptodate in the correct place Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page.
- https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3
- https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566
- https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e
- https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e
- https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f
- https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310
- https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f
- https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3
- https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f
- https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3
- https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566
- https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e
- https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e
- https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f
- https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310
- https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f
- https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3
- https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-35822
In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().
- https://git.kernel.org/stable/c/2a587a035214fa1b5ef598aea0b81848c5b72e5e
- https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8
- https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f02577a10252
- https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c
- https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a
- https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c
- https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290
- https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf
- https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf
- https://git.kernel.org/stable/c/2a587a035214fa1b5ef598aea0b81848c5b72e5e
- https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8
- https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f02577a10252
- https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c
- https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a
- https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c
- https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290
- https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf
- https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35823
In the Linux kernel, the following vulnerability has been resolved: vt: fix unicode buffer corruption when deleting characters This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.
- https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f
- https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d
- https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90
- https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1
- https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda
- https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51
- https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d
- https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a
- https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f
- https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d
- https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90
- https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1
- https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda
- https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51
- https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d
- https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-26
CVE-2024-35824
In the Linux kernel, the following vulnerability has been resolved: misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume When not configured for wakeup lis3lv02d_i2c_suspend() will call lis3lv02d_poweroff() even if the device has already been turned off by the runtime-suspend handler and if configured for wakeup and the device is runtime-suspended at this point then it is not turned back on to serve as a wakeup source. Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable the regulators which as a side effect made calling poweroff() twice ok. Now that poweroff() correctly disables the regulators, doing this twice triggers a WARN() in the regulator core: unbalanced disables for regulator-dummy WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable ... Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if already runtime-suspended and add a poweron() call when necessary to make wakeup work. lis3lv02d_i2c_resume() has similar issues, with an added weirness that it always powers on the device if it is runtime suspended, after which the first runtime-resume will call poweron() again, causing the enabled count for the regulator to increase by 1 every suspend/resume. These unbalanced regulator_enable() calls cause the regulator to never be turned off and trigger the following WARN() on driver unbind: WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put Fix this by making lis3lv02d_i2c_resume() mirror the new suspend().
- https://git.kernel.org/stable/c/4154e767354140db7804207117e7238fb337b0e7
- https://git.kernel.org/stable/c/997ca415384612c8df76d99d9a768e0b3f42b325
- https://git.kernel.org/stable/c/ac3e0384073b2408d6cb0d972fee9fcc3776053d
- https://git.kernel.org/stable/c/f6df761182fc953907b18aba5049fc2a044ecb45
- https://git.kernel.org/stable/c/4154e767354140db7804207117e7238fb337b0e7
- https://git.kernel.org/stable/c/997ca415384612c8df76d99d9a768e0b3f42b325
- https://git.kernel.org/stable/c/ac3e0384073b2408d6cb0d972fee9fcc3776053d
- https://git.kernel.org/stable/c/f6df761182fc953907b18aba5049fc2a044ecb45
Modified: 2025-12-17
CVE-2024-35825
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Fix handling of zero block length packets While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.
- https://git.kernel.org/stable/c/6b2c73111a252263807b7598682663dc33aa4b4c
- https://git.kernel.org/stable/c/7664ee8bd80309b90d53488b619764f0a057f2b7
- https://git.kernel.org/stable/c/92b051b87658df7649ffcdef522593f21a2b296b
- https://git.kernel.org/stable/c/a0f77b5d6067285b8eca0ee3bd1e448a6258026f
- https://git.kernel.org/stable/c/a766761d206e7c36d7526e0ae749949d17ca582c
- https://git.kernel.org/stable/c/e2dbfea520e60d58e0c498ba41bde10452257779
- https://git.kernel.org/stable/c/ef846cdbd100f7f9dc045e8bcd7fe4b3a3713c03
- https://git.kernel.org/stable/c/f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70
- https://git.kernel.org/stable/c/6b2c73111a252263807b7598682663dc33aa4b4c
- https://git.kernel.org/stable/c/7664ee8bd80309b90d53488b619764f0a057f2b7
- https://git.kernel.org/stable/c/92b051b87658df7649ffcdef522593f21a2b296b
- https://git.kernel.org/stable/c/a0f77b5d6067285b8eca0ee3bd1e448a6258026f
- https://git.kernel.org/stable/c/a766761d206e7c36d7526e0ae749949d17ca582c
- https://git.kernel.org/stable/c/e2dbfea520e60d58e0c498ba41bde10452257779
- https://git.kernel.org/stable/c/ef846cdbd100f7f9dc045e8bcd7fe4b3a3713c03
- https://git.kernel.org/stable/c/f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-26
CVE-2024-35826
In the Linux kernel, the following vulnerability has been resolved: block: Fix page refcounts for unaligned buffers in __bio_release_pages() Fix an incorrect number of pages being released for buffers that do not start at the beginning of a page.
- https://git.kernel.org/stable/c/242006996d15f5ca62e22f8c7de077d9c4a8f367
- https://git.kernel.org/stable/c/38b43539d64b2fa020b3b9a752a986769f87f7a6
- https://git.kernel.org/stable/c/7d3765550374f71248c55e6206ea1d6fd4537e65
- https://git.kernel.org/stable/c/c9d3d2fbde9b8197bce88abcbe8ee8e713ffe7c2
- https://git.kernel.org/stable/c/ecbd9ced84dd655a8f4cd49d2aad0e80dbf6bf35
- https://git.kernel.org/stable/c/242006996d15f5ca62e22f8c7de077d9c4a8f367
- https://git.kernel.org/stable/c/38b43539d64b2fa020b3b9a752a986769f87f7a6
- https://git.kernel.org/stable/c/7d3765550374f71248c55e6206ea1d6fd4537e65
- https://git.kernel.org/stable/c/c9d3d2fbde9b8197bce88abcbe8ee8e713ffe7c2
- https://git.kernel.org/stable/c/ecbd9ced84dd655a8f4cd49d2aad0e80dbf6bf35
Modified: 2025-02-03
CVE-2024-35827
In the Linux kernel, the following vulnerability has been resolved: io_uring/net: fix overflow check in io_recvmsg_mshot_prep() The "controllen" variable is type size_t (unsigned long). Casting it to int could lead to an integer underflow. The check_add_overflow() function considers the type of the destination which is type int. If we add two positive values and the result cannot fit in an integer then that's counted as an overflow. However, if we cast "controllen" to an int and it turns negative, then negative values *can* fit into an int type so there is no overflow. Good: 100 + (unsigned long)-4 = 96 <-- overflow Bad: 100 + (int)-4 = 96 <-- no overflow I deleted the cast of the sizeof() as well. That's not a bug but the cast is unnecessary.
- https://git.kernel.org/stable/c/0c8c74bb59e7d77554016efc34c2d10376985e5e
- https://git.kernel.org/stable/c/59a534690ecc3af72c6ab121aeac1237a4adae66
- https://git.kernel.org/stable/c/868ec868616438df487b9e2baa5a99f8662cc47c
- https://git.kernel.org/stable/c/8ede3db5061bb1fe28e2c9683329aafa89d2b1b4
- https://git.kernel.org/stable/c/b6563ad0d599110bd5cf8f56c47d279c3ed796fe
- https://git.kernel.org/stable/c/0c8c74bb59e7d77554016efc34c2d10376985e5e
- https://git.kernel.org/stable/c/59a534690ecc3af72c6ab121aeac1237a4adae66
- https://git.kernel.org/stable/c/868ec868616438df487b9e2baa5a99f8662cc47c
- https://git.kernel.org/stable/c/8ede3db5061bb1fe28e2c9683329aafa89d2b1b4
- https://git.kernel.org/stable/c/b6563ad0d599110bd5cf8f56c47d279c3ed796fe
Modified: 2025-01-14
CVE-2024-35828
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().
- https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9
- https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a
- https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab
- https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186
- https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf
- https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591
- https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3
- https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2
- https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7
- https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9
- https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a
- https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab
- https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186
- https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf
- https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591
- https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3
- https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2
- https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35829
In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix a memleak in lima_heap_alloc When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks.
- https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea
- https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab
- https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f
- https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7
- https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd
- https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed
- https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf
- https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea
- https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab
- https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f
- https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7
- https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd
- https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed
- https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-35830
In the Linux kernel, the following vulnerability has been resolved: media: tc358743: register v4l2 async device only after successful setup Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.
- https://git.kernel.org/stable/c/17c2650de14842c25c569cbb2126c421489a3a24
- https://git.kernel.org/stable/c/4f1490a5d7a0472ee5d9f36547bc4ba46be755c7
- https://git.kernel.org/stable/c/610f20e5cf35ca9c0992693cae0dd8643ce932e7
- https://git.kernel.org/stable/c/87399f1ff92203d65f1febf5919429f4bb613a02
- https://git.kernel.org/stable/c/8ba8db9786b55047df5ad3db3e01dd886687a77d
- https://git.kernel.org/stable/c/b8505a1aee8f1edc9d16d72ae09c93de086e2a1a
- https://git.kernel.org/stable/c/c915c46a25c3efb084c4f5e69a053d7f7a635496
- https://git.kernel.org/stable/c/daf21394f9898fb9f0698c3e50de08132d2164e6
- https://git.kernel.org/stable/c/edbb3226c985469a2f8eb69885055c9f5550f468
- https://git.kernel.org/stable/c/17c2650de14842c25c569cbb2126c421489a3a24
- https://git.kernel.org/stable/c/4f1490a5d7a0472ee5d9f36547bc4ba46be755c7
- https://git.kernel.org/stable/c/610f20e5cf35ca9c0992693cae0dd8643ce932e7
- https://git.kernel.org/stable/c/87399f1ff92203d65f1febf5919429f4bb613a02
- https://git.kernel.org/stable/c/8ba8db9786b55047df5ad3db3e01dd886687a77d
- https://git.kernel.org/stable/c/b8505a1aee8f1edc9d16d72ae09c93de086e2a1a
- https://git.kernel.org/stable/c/c915c46a25c3efb084c4f5e69a053d7f7a635496
- https://git.kernel.org/stable/c/daf21394f9898fb9f0698c3e50de08132d2164e6
- https://git.kernel.org/stable/c/edbb3226c985469a2f8eb69885055c9f5550f468
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-26
CVE-2024-35844
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix reserve_cblocks counting error when out of space When a file only needs one direct_node, performing the following operations will cause the file to be unrepairable: unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4.8M 100% /data unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0 This is because the file has only one direct_node. After returning to -ENOSPC, reserved_blocks += ret will not be executed. As a result, the reserved_blocks at this time is still 0, which is not the real number of reserved blocks. Therefore, fsck cannot be set to repair the file. After this patch, the fsck flag will be set to fix this problem. unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device adb reboot then fsck will be executed unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 924
- https://git.kernel.org/stable/c/2f6d721e14b69d6e1251f69fa238b48e8374e25f
- https://git.kernel.org/stable/c/569c198c9e2093fd29cc071856a4e548fda506bc
- https://git.kernel.org/stable/c/889846dfc8ee2cf31148a44bfd2faeb2faadc685
- https://git.kernel.org/stable/c/f0bf89e84c3afb79d7a3a9e4bc853ad6a3245c0a
- https://git.kernel.org/stable/c/fa3ac8b1a227d9b470b87972494293348b5839ee
- https://git.kernel.org/stable/c/fc0aed88afbf6f606205129a7466eebdf528e3f3
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/2f6d721e14b69d6e1251f69fa238b48e8374e25f
- https://git.kernel.org/stable/c/569c198c9e2093fd29cc071856a4e548fda506bc
- https://git.kernel.org/stable/c/889846dfc8ee2cf31148a44bfd2faeb2faadc685
- https://git.kernel.org/stable/c/f0bf89e84c3afb79d7a3a9e4bc853ad6a3245c0a
- https://git.kernel.org/stable/c/fa3ac8b1a227d9b470b87972494293348b5839ee
- https://git.kernel.org/stable/c/fc0aed88afbf6f606205129a7466eebdf528e3f3
Modified: 2025-04-07
CVE-2024-35845
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dbg-tlv: ensure NUL termination The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it.
- https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641
- https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c
- https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7
- https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a
- https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea
- https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209
- https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9
- https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641
- https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c
- https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7
- https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a
- https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea
- https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209
- https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-03-24
CVE-2024-35861
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1
- https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4
- https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f
- https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d
- https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1
- https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4
- https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f
- https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d
Modified: 2026-03-25
CVE-2024-35862
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_network_name_deleted() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d
- https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01
- https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645
- https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c
- https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d
- https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01
- https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645
- https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c
Modified: 2026-03-24
CVE-2024-35863
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2
- https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825
- https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac
- https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29
- https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2
- https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825
- https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac
- https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29
Modified: 2024-12-30
CVE-2024-35864
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1
- https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb
- https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5
- https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4
- https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1
- https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb
- https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5
- https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4
Modified: 2025-04-07
CVE-2024-35865
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd
- https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4
- https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628
- https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7
- https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd
- https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4
- https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628
- https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7
Modified: 2025-12-23
CVE-2024-35867
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65
- https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49
- https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7
- https://git.kernel.org/stable/c/838ec01ea8d3deb5d123e8ed9022e8162dc3f503
- https://git.kernel.org/stable/c/bb6570085826291dc392005f9fec16ea5da3c8ad
- https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39
- http://www.openwall.com/lists/oss-security/2024/05/29/2
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65
- https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49
- https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7
- https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2024-12-30
CVE-2024-35868
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_write() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b
- https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72
- https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7
- https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a
- https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b
- https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72
- https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7
- https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a
Modified: 2026-01-22
CVE-2024-35871
In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means. [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec. childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways: 1. kernel_execve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel __global_pointer$, all other integer registers zeroed by the memset in the patch comment. This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch. 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries. 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for user_mode_helpers before the exec completes, but gp is not one of the registers it returns. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to write exploit code. 5. Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers.
- https://git.kernel.org/stable/c/00effef72c98294edb1efa87ffa0f6cfb61b36a4
- https://git.kernel.org/stable/c/9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5
- https://git.kernel.org/stable/c/d14fa1fcf69db9d070e75f1c4425211fa619dfc8
- https://git.kernel.org/stable/c/d8dcba0691b8e42bddb61aab201e4d918a08e5d9
- https://git.kernel.org/stable/c/dff6072124f6df77bfd36951fbd88565746980ef
- https://git.kernel.org/stable/c/f6583444d7e78dae750798552b65a2519ff3ca84
- https://git.kernel.org/stable/c/00effef72c98294edb1efa87ffa0f6cfb61b36a4
- https://git.kernel.org/stable/c/9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5
- https://git.kernel.org/stable/c/d14fa1fcf69db9d070e75f1c4425211fa619dfc8
- https://git.kernel.org/stable/c/d8dcba0691b8e42bddb61aab201e4d918a08e5d9
- https://git.kernel.org/stable/c/dff6072124f6df77bfd36951fbd88565746980ef
- https://git.kernel.org/stable/c/f6583444d7e78dae750798552b65a2519ff3ca84
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-24
CVE-2024-35872
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check.
- https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5
- https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8
- https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706
- https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e
- https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48
- https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5
- https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8
- https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706
- https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e
- https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48
Modified: 2025-09-24
CVE-2024-35875
In the Linux kernel, the following vulnerability has been resolved: x86/coco: Require seeding RNG with RDRAND on CoCo systems There are few uses of CoCo that don't rely on working cryptography and hence a working RNG. Unfortunately, the CoCo threat model means that the VM host cannot be trusted and may actively work against guests to extract secrets or manipulate computation. Since a malicious host can modify or observe nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole is meant to gracefully continue on gathering entropy from other sources, but since there aren't other sources on CoCo, this is catastrophic. This is mostly a concern at boot time when initially seeding the RNG, as after that the consequences of a broken RDRAND are much more theoretical. So, try at boot to seed the RNG using 256 bits of RDRAND output. If this fails, panic(). This will also trigger if the system is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 driver feature" and not part of the RNG itself. Many device drivers and platforms have some desire to contribute something to the RNG, and add_device_randomness() is specifically meant for this purpose. Any driver can call it with seed data of any quality, or even garbage quality, and it can only possibly make the quality of the RNG better or have no effect, but can never make it worse. Rather than trying to build something into the core of the RNG, consider the particular CoCo issue just a CoCo issue, and therefore separate it all out into driver (well, arch/platform) code. [ bp: Massage commit message. ]
- https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e
- https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374
- https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5
- https://git.kernel.org/stable/c/99485c4c026f024e7cb82da84c7951dbe3deb584
- https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e
- https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374
- https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5
- https://git.kernel.org/stable/c/99485c4c026f024e7cb82da84c7951dbe3deb584
Modified: 2025-12-23
CVE-2024-35877
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or,
in fact, all PTEs) can be replaced during write faults to point at anon
folios. Reliably recovering the correct PFN and cachemode using
follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon
folio (which is very wrong), or fail on swap/nonswap entries, failing
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call
it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we
don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if
the first page was replaced by an anon folio, though: we'd have to store
the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that
case: it would have failed in the past with swap/nonswap entries already,
and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer --->
#include
- https://git.kernel.org/stable/c/04c35ab3bdae7fefbd7c7a7355f29fa03a035221
- https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173
- https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd32f2abc6
- https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec
- https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a
- https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f
- https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4
- https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b
- https://git.kernel.org/stable/c/04c35ab3bdae7fefbd7c7a7355f29fa03a035221
- https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173
- https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd32f2abc6
- https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec
- https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a
- https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f
- https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4
- https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35879
In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, of_node_put() will be called but wrongly too late from the workqueue job. In order to be sure that any ongoing devlink removals are done before the of_node destruction, synchronize the of_changeset_destroy() with the devlink removals.
- https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a
- https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c
- https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951
- https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82
- https://git.kernel.org/stable/c/8917e7385346bd6584890ed362985c219fe6ae84
- https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b17411db6f5c
- https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a
- https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c
- https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951
- https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82
- https://git.kernel.org/stable/c/8917e7385346bd6584890ed362985c219fe6ae84
- https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b17411db6f5c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-35884
In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the current logic there as it should cover most cases but we also need to make sure we handle tunnel packets being GROed too early. This is done by extending the checks in udp_unexpected_gso: GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must be segmented. [1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560
- https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19
- https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8
- https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4
- https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f
- https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd
- https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670
- https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19
- https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8
- https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4
- https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f
- https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd
- https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-03
CVE-2024-35885
In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: stop interface during shutdown The mlxbf_gige driver intermittantly encounters a NULL pointer exception while the system is shutting down via "reboot" command. The mlxbf_driver will experience an exception right after executing its shutdown() method. One example of this exception is: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000 [0000000000000070] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] SMP CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] sp : ffff8000080d3c10 x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58 x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008 x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128 x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7 x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101 x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404 x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080 x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20 Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002) ---[ end trace 7cc3941aa0d8e6a4 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x4ce722520000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x000005c1,a3330e5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- During system shutdown, the mlxbf_gige driver's shutdown() is always executed. However, the driver's stop() method will only execute if networking interface configuration logic within the Linux distribution has been setup to do so. If shutdown() executes but stop() does not execute, NAPI remains enabled and this can lead to an exception if NAPI is scheduled while the hardware interface has only been partially deinitialized. The networking interface managed by the mlxbf_gige driver must be properly stopped during system shutdown so that IFF_UP is cleared, the hardware interface is put into a clean state, and NAPI is fully deinitialized.
- https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6
- https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4
- https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971
- https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4
- https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5
- https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6
- https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4
- https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971
- https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4
- https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5
Modified: 2025-12-23
CVE-2024-35886
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during
netlink socket destruction. [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
the response was generated. The following recvmmsg() resumed the dump
for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
to the fault injection. [0]
12:01:34 executing program 3:
r0 = socket$nl_route(0x10, 0x3, 0x0)
sendmsg$nl_route(r0, ... snip ...)
recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call
of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped
receiving the response halfway through, and finally netlink_sock_destruct()
called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it
is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by
nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling
itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/167d4b47a9bdcb01541dfa29e9f3cbb8edd3dfd2
- https://git.kernel.org/stable/c/40a344b2ddc06c1a2caa7208a43911f39c662778
- https://git.kernel.org/stable/c/4a7c465a5dcd657d59d25bf4815e19ac05c13061
- https://git.kernel.org/stable/c/9472d07cd095cbd3294ac54c42f304a38fbe9bfe
- https://git.kernel.org/stable/c/9c5258196182c25b55c33167cd72fdd9bbf08985
- https://git.kernel.org/stable/c/d21d40605bca7bd5fc23ef03d4c1ca1f48bc2cae
- https://git.kernel.org/stable/c/f2dd75e57285f49e34af1a5b6cd8945c08243776
- https://git.kernel.org/stable/c/fd307f2d91d40fa7bc55df3e2cd1253fabf8a2d6
- https://git.kernel.org/stable/c/167d4b47a9bdcb01541dfa29e9f3cbb8edd3dfd2
- https://git.kernel.org/stable/c/40a344b2ddc06c1a2caa7208a43911f39c662778
- https://git.kernel.org/stable/c/4a7c465a5dcd657d59d25bf4815e19ac05c13061
- https://git.kernel.org/stable/c/9472d07cd095cbd3294ac54c42f304a38fbe9bfe
- https://git.kernel.org/stable/c/9c5258196182c25b55c33167cd72fdd9bbf08985
- https://git.kernel.org/stable/c/d21d40605bca7bd5fc23ef03d4c1ca1f48bc2cae
- https://git.kernel.org/stable/c/f2dd75e57285f49e34af1a5b6cd8945c08243776
- https://git.kernel.org/stable/c/fd307f2d91d40fa7bc55df3e2cd1253fabf8a2d6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35888
In the Linux kernel, the following vulnerability has been resolved: erspan: make sure erspan_base_hdr is present in skb->head syzbot reported a problem in ip6erspan_rcv() [1] Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it. Add the missing pskb_may_pull() calls. v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed. [1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0
- https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac
- https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446
- https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0
- https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d
- https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d
- https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85
- https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5
- https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7
- https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac
- https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446
- https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0
- https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d
- https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d
- https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85
- https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5
- https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-24
CVE-2024-35890
In the Linux kernel, the following vulnerability has been resolved: gro: fix ownership transfer If packets are GROed with fraglist they might be segmented later on and continue their journey in the stack. In skb_segment_list those skbs can be reused as-is. This is an issue as their destructor was removed in skb_gro_receive_list but not the reference to their socket, and then they can't be orphaned. Fix this by also removing the reference to the socket. For example this could be observed, kernel BUG at include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Call Trace: ipv6_list_rcv+0x250/0x3f0 __netif_receive_skb_list_core+0x49d/0x8f0 netif_receive_skb_list_internal+0x634/0xd40 napi_complete_done+0x1d2/0x7d0 gro_cell_poll+0x118/0x1f0 A similar construction is found in skb_gro_receive, apply the same change there.
- https://git.kernel.org/stable/c/2eeab8c47c3c0276e0746bc382f405c9a236a5ad
- https://git.kernel.org/stable/c/5b3b67f731296027cceb3efad881ae281213f86f
- https://git.kernel.org/stable/c/d225b0ac96dc40d7e8ae2bc227eb2c56e130975f
- https://git.kernel.org/stable/c/ed4cccef64c1d0d5b91e69f7a8a6697c3a865486
- https://git.kernel.org/stable/c/fc126c1d51e9552eacd2d717b9ffe9262a8a4cd6
- https://git.kernel.org/stable/c/2eeab8c47c3c0276e0746bc382f405c9a236a5ad
- https://git.kernel.org/stable/c/5b3b67f731296027cceb3efad881ae281213f86f
- https://git.kernel.org/stable/c/d225b0ac96dc40d7e8ae2bc227eb2c56e130975f
- https://git.kernel.org/stable/c/ed4cccef64c1d0d5b91e69f7a8a6697c3a865486
- https://git.kernel.org/stable/c/fc126c1d51e9552eacd2d717b9ffe9262a8a4cd6
- https://security.netapp.com/advisory/ntap-20250509-0008/
Modified: 2024-12-30
CVE-2024-35891
In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Fix potential null pointer dereference In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may return NULL as ptp_header due to abnormal packet type or corrupted packet. Fix this bug by adding ptp_header check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/10608161696c2768f53426642f78a42bcaaa53e8
- https://git.kernel.org/stable/c/49767b0df276f12e3e7184601e09ee7430e252dc
- https://git.kernel.org/stable/c/95c1016a2d92c4c28a9d1b6d09859c00b19c0ea4
- https://git.kernel.org/stable/c/96c155943a703f0655c0c4cab540f67055960e91
- https://git.kernel.org/stable/c/10608161696c2768f53426642f78a42bcaaa53e8
- https://git.kernel.org/stable/c/49767b0df276f12e3e7184601e09ee7430e252dc
- https://git.kernel.org/stable/c/95c1016a2d92c4c28a9d1b6d09859c00b19c0ea4
- https://git.kernel.org/stable/c/96c155943a703f0655c0c4cab540f67055960e91
Modified: 2025-09-19
CVE-2024-35892
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix lockdep splat in qdisc_tree_reduce_backlog()
qdisc_tree_reduce_backlog() is called with the qdisc lock held,
not RTNL.
We must use qdisc_lookup_rcu() instead of qdisc_lookup()
syzbot reported:
WARNING: suspicious RCU usage
6.1.74-syzkaller #0 Not tainted
-----------------------------
net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by udevd/1142:
#0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]
#0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]
#0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282
#1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]
#1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297
#2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]
#2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]
#2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792
stack backtrace:
CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
- https://git.kernel.org/stable/c/07696415526bee0607e495017369c7303a4792e1
- https://git.kernel.org/stable/c/7eb322360b0266481e560d1807ee79e0cef5742b
- https://git.kernel.org/stable/c/b7d1ce2cc7192e8a037faa3f5d3ba72c25976460
- https://git.kernel.org/stable/c/c040b99461a5bfc14c2d0cbb1780fcc3a4706c7e
- https://git.kernel.org/stable/c/07696415526bee0607e495017369c7303a4792e1
- https://git.kernel.org/stable/c/7eb322360b0266481e560d1807ee79e0cef5742b
- https://git.kernel.org/stable/c/b7d1ce2cc7192e8a037faa3f5d3ba72c25976460
- https://git.kernel.org/stable/c/c040b99461a5bfc14c2d0cbb1780fcc3a4706c7e
Modified: 2025-12-23
CVE-2024-35893
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: prevent kernel-infoleak syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1]. The issue here is that 'struct tc_skbmod' has a four bytes hole. We need to clear the structure before filling fields. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli ---truncated---
- https://git.kernel.org/stable/c/55d3fe7b2b7bc354e7cbc1f7b8f98a29ccd5a366
- https://git.kernel.org/stable/c/5e45dc4408857305f4685abfd7a528a1e58b51b5
- https://git.kernel.org/stable/c/729ad2ac2a2cdc9f4a4bdfd40bfd276e6bc33924
- https://git.kernel.org/stable/c/7bb2c7103d8c13b06a57bf997b8cdbe93cd7283c
- https://git.kernel.org/stable/c/a097fc199ab5f4b5392c5144034c0d2148b55a14
- https://git.kernel.org/stable/c/d313eb8b77557a6d5855f42d2234bd592c7b50dd
- https://git.kernel.org/stable/c/f190a4aa03cbd518bd9c62a66e1233984f5fd2ec
- https://git.kernel.org/stable/c/f356eb2fb567e0931143ac1769ac802d3b3e2077
- https://git.kernel.org/stable/c/55d3fe7b2b7bc354e7cbc1f7b8f98a29ccd5a366
- https://git.kernel.org/stable/c/5e45dc4408857305f4685abfd7a528a1e58b51b5
- https://git.kernel.org/stable/c/729ad2ac2a2cdc9f4a4bdfd40bfd276e6bc33924
- https://git.kernel.org/stable/c/7bb2c7103d8c13b06a57bf997b8cdbe93cd7283c
- https://git.kernel.org/stable/c/a097fc199ab5f4b5392c5144034c0d2148b55a14
- https://git.kernel.org/stable/c/d313eb8b77557a6d5855f42d2234bd592c7b50dd
- https://git.kernel.org/stable/c/f190a4aa03cbd518bd9c62a66e1233984f5fd2ec
- https://git.kernel.org/stable/c/f356eb2fb567e0931143ac1769ac802d3b3e2077
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-30
CVE-2024-35895
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes
elements from a sockmap/sockhash map. Because BPF tracing programs can be
invoked from any interrupt context, locks taken during a map_delete_elem
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock);
local_irq_disable();
lock(&host->lock);
lock(&htab->buckets[i].lock);
- https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86
- https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd
- https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5
- https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec
- https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75
- https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058
- https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48
- https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86
- https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd
- https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5
- https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec
- https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75
- https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058
- https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-21
CVE-2024-35896
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account
before copying data.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
- https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc
- https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6
- https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5
- https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b
- https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018
- https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525
- https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc
- https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6
- https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5
- https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b
- https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018
- https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20250321-0004/
Modified: 2025-04-07
CVE-2024-35898
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.
- https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304
- https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8
- https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007
- https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df
- https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331
- https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b
- https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77
- https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859
- https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304
- https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8
- https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007
- https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df
- https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331
- https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b
- https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77
- https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35899
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: flush pending destroy work before exit_net release
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy
work before netlink notifier") to address a race between exit_net and
the destroy workqueue.
The trace below shows an element to be released via destroy workqueue
while exit_net path (triggered via module removal) has already released
the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465
[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359
[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
[ 1360.547984] Call Trace:
[ 1360.547991]
- https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2
- https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7
- https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31
- https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e
- https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6
- https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86
- https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49
- https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2
- https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7
- https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31
- https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e
- https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6
- https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86
- https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-35900
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject new basechain after table flag update
When dormant flag is toggled, hooks are disabled in the commit phase by
iterating over current chains in table (existing and new).
The following configuration allows for an inconsistent state:
add table x
add chain x y { type filter hook input priority 0; }
add table x { flags dormant; }
add chain x w { type filter hook input priority 1; }
which triggers the following warning when trying to unregister chain w
which is already unregistered.
[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260
[...]
[ 127.322519] Call Trace:
[ 127.322521]
- https://git.kernel.org/stable/c/41bad13c0e8a5a2b47a7472cced922555372daab
- https://git.kernel.org/stable/c/420132bee3d0136b7fba253a597b098fe15493a7
- https://git.kernel.org/stable/c/6d12f21f8bbe23fde25b77c2bf5973c136b8bef8
- https://git.kernel.org/stable/c/745cf6a843896cdac8766c74379300ed73c78830
- https://git.kernel.org/stable/c/7b6fba6918714afee3e17796113ccab636255c7b
- https://git.kernel.org/stable/c/8ba81dca416adf82fc5a2a23abc1a8cc02ad32fb
- https://git.kernel.org/stable/c/994209ddf4f430946f6247616b2e33d179243769
- https://git.kernel.org/stable/c/e95bb4cba94c018be24b11f017d1c55dd6cda31a
- https://git.kernel.org/stable/c/41bad13c0e8a5a2b47a7472cced922555372daab
- https://git.kernel.org/stable/c/420132bee3d0136b7fba253a597b098fe15493a7
- https://git.kernel.org/stable/c/6d12f21f8bbe23fde25b77c2bf5973c136b8bef8
- https://git.kernel.org/stable/c/745cf6a843896cdac8766c74379300ed73c78830
- https://git.kernel.org/stable/c/7b6fba6918714afee3e17796113ccab636255c7b
- https://git.kernel.org/stable/c/8ba81dca416adf82fc5a2a23abc1a8cc02ad32fb
- https://git.kernel.org/stable/c/994209ddf4f430946f6247616b2e33d179243769
- https://git.kernel.org/stable/c/e95bb4cba94c018be24b11f017d1c55dd6cda31a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-30
CVE-2024-35905
In the Linux kernel, the following vulnerability has been resolved: bpf: Protect against int overflow for stack access size This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail. This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7.
- https://git.kernel.org/stable/c/203a68151e8eeb331d4a64ab78303f3a15faf103
- https://git.kernel.org/stable/c/37dc1718dc0c4392dbfcb9adec22a776e745dd69
- https://git.kernel.org/stable/c/3f0784b2f1eb9147973d8c43ba085c5fdf44ff69
- https://git.kernel.org/stable/c/98cdac206b112bec63852e94802791e316acc2c1
- https://git.kernel.org/stable/c/9970e059af471478455f9534e8c3db82f8c5496d
- https://git.kernel.org/stable/c/ecc6a2101840177e57c925c102d2d29f260d37c8
- https://git.kernel.org/stable/c/203a68151e8eeb331d4a64ab78303f3a15faf103
- https://git.kernel.org/stable/c/37dc1718dc0c4392dbfcb9adec22a776e745dd69
- https://git.kernel.org/stable/c/3f0784b2f1eb9147973d8c43ba085c5fdf44ff69
- https://git.kernel.org/stable/c/98cdac206b112bec63852e94802791e316acc2c1
- https://git.kernel.org/stable/c/9970e059af471478455f9534e8c3db82f8c5496d
- https://git.kernel.org/stable/c/ecc6a2101840177e57c925c102d2d29f260d37c8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-30
CVE-2024-35907
In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: call request_irq() after NAPI initialized The mlxbf_gige driver encounters a NULL pointer exception in mlxbf_gige_open() when kdump is enabled. The sequence to reproduce the exception is as follows: a) enable kdump b) trigger kdump via "echo c > /proc/sysrq-trigger" c) kdump kernel executes d) kdump kernel loads mlxbf_gige module e) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought up f) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] SMP CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000 x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398 x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2 x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238 Call trace: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x20/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 [mlxbf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink+0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg+0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+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 Code: bad PC value ---[ end trace 7d1c3f3bf9d81885 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x2870a7a00000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0,000005c1,a3332a5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- The exception happens because there is a pending RX interrupt before the call to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires immediately after this request_irq() completes. The ---truncated---
- https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab
- https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e
- https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52
- https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3
- https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc
- https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab
- https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e
- https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52
- https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3
- https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc
Modified: 2025-09-24
CVE-2024-35908
In the Linux kernel, the following vulnerability has been resolved: tls: get psock ref after taking rxlock to avoid leak At the start of tls_sw_recvmsg, we take a reference on the psock, and then call tls_rx_reader_lock. If that fails, we return directly without releasing the reference. Instead of adding a new label, just take the reference after locking has succeeded, since we don't need it before.
- https://git.kernel.org/stable/c/30fabe50a7ace3e9d57cf7f9288f33ea408491c8
- https://git.kernel.org/stable/c/417e91e856099e9b8a42a2520e2255e6afe024be
- https://git.kernel.org/stable/c/b565d294e3d5aa809566a4d819835da11997d8b3
- https://git.kernel.org/stable/c/f1b7f14130d782433bc98c1e1e41ce6b4d4c3096
- https://git.kernel.org/stable/c/30fabe50a7ace3e9d57cf7f9288f33ea408491c8
- https://git.kernel.org/stable/c/417e91e856099e9b8a42a2520e2255e6afe024be
- https://git.kernel.org/stable/c/b565d294e3d5aa809566a4d819835da11997d8b3
- https://git.kernel.org/stable/c/f1b7f14130d782433bc98c1e1e41ce6b4d4c3096
Modified: 2025-09-24
CVE-2024-35909
In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Split 64bit accesses to fix alignment issues Some of the registers are aligned on a 32bit boundary, causing alignment faults on 64bit platforms. Unable to handle kernel paging request at virtual address ffffffc084a1d004 Mem abort info: ESR = 0x0000000096000061 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment fault Data abort info: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Internal error: Oops: 0000000096000061 [#1] SMP Modules linked in: mtk_t7xx(+) qcserial pppoe ppp_async option nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) iwlwifi(O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm cdc_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 geniv des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys trusted CPU: 3 PID: 5266 Comm: kworker/u9:1 Tainted: G O 6.6.22 #0 Hardware name: Bananapi BPI-R4 (DT) Workqueue: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr : t7xx_cldma_start+0xac/0x13c [mtk_t7xx] sp : ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 0000000000000001 x19: ffffff80c814b080 x18: 0000000000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffffff80ca1ef6b4 x7 : ffffff80c814b818 x6 : 0000000000000018 x5 : 0000000000000870 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000010a947000 x1 : ffffffc084a1d004 x0 : ffffffc084a1d004 Call trace: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] process_one_work+0x154/0x2a0 worker_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Code: f9400800 91001000 8b214001 d50332bf (f9000022) ---[ end trace 0000000000000000 ]--- The inclusion of io-64-nonatomic-lo-hi.h indicates that all 64bit accesses can be replaced by pairs of nonatomic 32bit access. Fix alignment by forcing all accesses to be 32bit on 64bit platforms.
- https://git.kernel.org/stable/c/2e22c9cb618716b8e557fe17c3d4958171288082
- https://git.kernel.org/stable/c/7d5a7dd5a35876f0ecc286f3602a88887a788217
- https://git.kernel.org/stable/c/b4fdb3c197e35f655b2d9b6759ce29440eacdfda
- https://git.kernel.org/stable/c/beaf0e7996b79e06ccc2bdcb4442fbaeccc31200
- https://git.kernel.org/stable/c/2e22c9cb618716b8e557fe17c3d4958171288082
- https://git.kernel.org/stable/c/7d5a7dd5a35876f0ecc286f3602a88887a788217
- https://git.kernel.org/stable/c/b4fdb3c197e35f655b2d9b6759ce29440eacdfda
- https://git.kernel.org/stable/c/beaf0e7996b79e06ccc2bdcb4442fbaeccc31200
Modified: 2025-12-17
CVE-2024-35910
In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns. For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns. This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler. Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held. It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code) We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.
- https://git.kernel.org/stable/c/151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada
- https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4
- https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f
- https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08837a35a
- https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de
- https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50
- https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87
- https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810
- https://git.kernel.org/stable/c/151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada
- https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4
- https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f
- https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08837a35a
- https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de
- https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50
- https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87
- https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-23
CVE-2024-35912
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential response leaks If the rx payload length check fails, or if kmemdup() fails, we still need to free the command response. Fix that.
- https://git.kernel.org/stable/c/06a093807eb7b5c5b29b6cff49f8174a4e702341
- https://git.kernel.org/stable/c/28db0ae86cb91a4ab0e855cff779daead936b7d5
- https://git.kernel.org/stable/c/99a75d75007421d8e08ba139e24f77395cd08f62
- https://git.kernel.org/stable/c/c0a40f2f8eba07416f695ffe2011bf3f8b0b6dc8
- https://git.kernel.org/stable/c/f7f0e784894dfcb265f0f9fa499103b0ca7eabde
- https://git.kernel.org/stable/c/06a093807eb7b5c5b29b6cff49f8174a4e702341
- https://git.kernel.org/stable/c/28db0ae86cb91a4ab0e855cff779daead936b7d5
- https://git.kernel.org/stable/c/99a75d75007421d8e08ba139e24f77395cd08f62
- https://git.kernel.org/stable/c/c0a40f2f8eba07416f695ffe2011bf3f8b0b6dc8
- https://git.kernel.org/stable/c/f7f0e784894dfcb265f0f9fa499103b0ca7eabde
Modified: 2025-02-03
CVE-2024-35915
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes.
- https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff
- https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240
- https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c
- https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a
- https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a
- https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16
- https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7
- https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f
- https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff
- https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240
- https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c
- https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a
- https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a
- https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16
- https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7
- https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-35916
In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix NULL pointer dereference in sanitycheck() If due to a memory allocation failure mock_chain() returns NULL, it is passed to dma_fence_enable_sw_signaling() resulting in NULL pointer dereference there. Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/0336995512cdab0c65e99e4cdd47c4606debe14e
- https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c
- https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6
- https://git.kernel.org/stable/c/eabf131cba1db12005a68378305f13b9090a7a6b
- https://git.kernel.org/stable/c/0336995512cdab0c65e99e4cdd47c4606debe14e
- https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c
- https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6
- https://git.kernel.org/stable/c/eabf131cba1db12005a68378305f13b9090a7a6b
Modified: 2025-12-23
CVE-2024-36020
In the Linux kernel, the following vulnerability has been resolved: i40e: fix vf may be used uninitialized in this function warning To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause. In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf. Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity.
- https://git.kernel.org/stable/c/06df7618f591b2dc43c59967e294d7b9fc8675b6
- https://git.kernel.org/stable/c/0dcf573f997732702917af1563aa2493dc772fc0
- https://git.kernel.org/stable/c/3e89846283f3cf7c7a8e28b342576fd7c561d2ba
- https://git.kernel.org/stable/c/951d2748a2a8242853abc3d0c153ce4bf8faad31
- https://git.kernel.org/stable/c/9dcf0fcb80f6aeb01469e3c957f8d4c97365450a
- https://git.kernel.org/stable/c/b8e82128b44fa40bf99a50b919488ef361e1683c
- https://git.kernel.org/stable/c/cc9cd02dd9e8b7764ea9effb24f4f1dd73d1b23d
- https://git.kernel.org/stable/c/f37c4eac99c258111d414d31b740437e1925b8e8
- https://git.kernel.org/stable/c/06df7618f591b2dc43c59967e294d7b9fc8675b6
- https://git.kernel.org/stable/c/0dcf573f997732702917af1563aa2493dc772fc0
- https://git.kernel.org/stable/c/3e89846283f3cf7c7a8e28b342576fd7c561d2ba
- https://git.kernel.org/stable/c/951d2748a2a8242853abc3d0c153ce4bf8faad31
- https://git.kernel.org/stable/c/9dcf0fcb80f6aeb01469e3c957f8d4c97365450a
- https://git.kernel.org/stable/c/b8e82128b44fa40bf99a50b919488ef361e1683c
- https://git.kernel.org/stable/c/cc9cd02dd9e8b7764ea9effb24f4f1dd73d1b23d
- https://git.kernel.org/stable/c/f37c4eac99c258111d414d31b740437e1925b8e8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-30
CVE-2024-36021
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during pf initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization.
- https://git.kernel.org/stable/c/1b550dae55901c2cc9075d6a7155a71b4f516e86
- https://git.kernel.org/stable/c/50b69054f455dcdb34bd6b22764c7579b270eef3
- https://git.kernel.org/stable/c/7ca0f73e5e2da3c129935b97f3a0877cce8ebdf5
- https://git.kernel.org/stable/c/93305b77ffcb042f1538ecc383505e87d95aa05a
- https://git.kernel.org/stable/c/1b550dae55901c2cc9075d6a7155a71b4f516e86
- https://git.kernel.org/stable/c/50b69054f455dcdb34bd6b22764c7579b270eef3
- https://git.kernel.org/stable/c/7ca0f73e5e2da3c129935b97f3a0877cce8ebdf5
- https://git.kernel.org/stable/c/93305b77ffcb042f1538ecc383505e87d95aa05a
Modified: 2025-11-26
CVE-2024-58239
In the Linux kernel, the following vulnerability has been resolved: tls: stop recv() if initial process_rx_list gave us non-DATA If we have a non-DATA record on the rx_list and another record of the same type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATA Just check the record type and jump to the end in case process_rx_list did some work.
- https://git.kernel.org/stable/c/31e10d6cb0c9532ff070cf50da1657c3acee9276
- https://git.kernel.org/stable/c/3b952d8fdfcf6fd8ea0b8954bc9277642cf0977f
- https://git.kernel.org/stable/c/4338032aa90bd1d5b33a4274e8fa8347cda5ee09
- https://git.kernel.org/stable/c/6756168add1c6c3ef1c32c335bb843a5d1f99a75
- https://git.kernel.org/stable/c/a4ed943882a8fc057ea5a67643314245e048bbdd
- https://git.kernel.org/stable/c/f310143961e2d9a0479fca117ce869f8aaecc140
- https://git.kernel.org/stable/c/fdfbaec5923d9359698cbb286bc0deadbb717504
