ALT-PU-2024-6511-5
Package kernel-image-un-def updated to version 5.10.215-alt1 for branch p9 in task 345118.
Closed vulnerabilities
Modified: 2025-01-29
BDU:2024-00985
Уязвимость функции hugetlbfs_fill_super системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-10-24
BDU:2024-01673
Уязвимость функции smb2_parse_contexts() в модуле fs/smb/client/smb2pdu.c клиента SMB ядра операционной системы Linux , позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-02-13
BDU:2024-01724
Уязвимость функции nft_set_rbtree (net/netfilter/nft_set_rbtree.c) компонента Netfilter операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2024-01736
Уязвимость функции sys_membarrier компонента membarrier ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-01747
Уязвимость функции binder_enqueue_thread_work_ilocked() в модуле drivers/android/binder.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01832
Уязвимость функции i801_block_transaction_by_block() в модуле drivers/i2c/busses/i2c-i801.c драйвера шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01851
Уязвимость функции bpf_map_put() в модуле kernel/bpf/syscall.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-04
BDU:2024-01853
Уязвимость функции ext4_mb_generate_buddy() в модуле fs/ext4/mballoc.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01863
Уязвимость функциях map_usb_set_vbus() и omap_usb_start_srp() в модуле drivers/phy/ti/phy-omap-usb2.c драйвера USB устройств TI (Texas Instruments) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01878
Уязвимость функции sock_orphan() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-20
BDU:2024-01977
Уязвимость функции skb_segment компонента Net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01981
Уязвимость функции __smc_diag_dump() в модуле net/smc/smc_diag.c реализации протокола SMC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-03620
Уязвимость функции nci_free_device() реализации NFC Controller Interface (NCI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-03621
Уязвимость функции __prep_cap() файловой системы ceph ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-03622
Уязвимость функции __sev_platform_shutdown_locked() драйвера крипографического сопроцессора AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03623
Уязвимость функции ext4_move_extents() в модуле fs/ext4/move_extent.c файловой системы ext4 ядра операционной системы 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: 2025-05-06
BDU:2024-03651
Уязвимость функции __ip6_tnl_rcv() в модуле net/ipv6/ip6_tunnel.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03655
Уязвимость функции can_map_frag() в модуле net/ipv4/tcp.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03659
Уязвимость функции llc_conn_handler() в модуле net/llc/llc_conn.c реализации протокола LLC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-03660
Уязвимость функции llc_ui_sendmsg() в модуле net/llc/af_llc.c реализации протокола LLC2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03661
Уязвимость функции create_snapshot() в модуле fs/btrfs/ioctl.c файловой системы btrfs ядра операционной системы 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: 2025-08-19
BDU:2024-03671
Уязвимость функции mac802154_llsec_key_del() в модуле net/mac802154/llsec.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-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-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-05-06
BDU:2024-03708
Уязвимость функции ip_tunnel_rcv() в модуле net/ipv4/ip_tunnel.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-03712
Уязвимость функции kfd_ioctl_get_process_apertures_new() в модуле drivers/gpu/drm/amd/amdkfd/kfd_chardev.c драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03747
Уязвимость функции run_spu_dma() в модуле sound/sh/aica.c звуковой подсистемы (ALSA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
BDU:2024-03751
Уязвимость функции hugetlbfs_parse_param() в модуле fs/hugetlbfs/inode.c системы управления памятью HugeTLB ядра операционной системы 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: 2025-10-24
BDU:2024-03941
Уязвимость функции io_uring_get_file() подсистемы io_uring ядра Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-04132
Уязвимость функции blkpg_do_ioctl() в модуле block/ioctl.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-04137
Уязвимость функции tomoyo_write_control() подсистемы безопасности TOMOYO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04139
Уязвимость функции reqsk_queue_alloc() реализации протокола TCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04147
Уязвимость функции iwl_dbg_tlv_override_trig_node() драйвера адаптеров беспроводной связи Intel iwlwifi ядра операционной системы 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-08-19
BDU:2024-04369
Уязвимость функции nf_tables_abort() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04581
Уязвимость функции interface_authorized_store() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-06349
Уязвимость функции dm_table_create() в модуле drivers/md/dm-table.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-06
BDU:2024-06493
Уязвимость функции synchronize_rcu() в компоненте ipset ядра операционной системы 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: 2024-11-12
BDU:2024-06912
Уязвимость компонента dtSearch ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-02-06
BDU:2024-07646
Уязвимость функции nft_chain_filter компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07824
Уязвимость компонента x86/srso ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07840
Уязвимость компонента erofs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-07848
Уязвимость компонента ipoib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-07852
Уязвимость компонента ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-08401
Уязвимость компонента mtk-jpeg ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2024-08402
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-08403
Уязвимость компонента mhi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08633
Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08642
Уязвимость компонента kasan ядра операционной системы 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-08671
Уязвимость компонента afs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08672
Уязвимость компонента arp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08676
Уязвимость компонента btrfs ядра операционной системы 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: 2025-03-21
BDU:2024-09030
Уязвимость функции scsi_host_busy() компонента drivers/scsi/scsi_error.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09032
Уязвимость функции stdev_release() компонента drivers/pci/switch/switchtec.c ядра операционной системы 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-09134
Уязвимость компонентов dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09149
Уязвимость компонента riscv ядра операционной системы 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-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-09168
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09172
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09175
Уязвимость компонента hv_netvsc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09184
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09186
Уязвимость компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09189
Уязвимость компонента rc ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-08-19
BDU:2024-09199
Уязвимость компонента ip_tunnel ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-03-21
BDU:2024-09201
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09204
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
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-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: 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: 2025-10-24
BDU:2024-09414
Уязвимость компонентов s390/zcrypt ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09415
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09450
Уязвимость функции rm3100_common_probe() компонента drivers/iio/magnetometer/rm3100-core.c ядра операционной системы Linux, связанная с чтением за допустимыми границами буфера данных, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-09453
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09454
Уязвимость функции rcu_scheduler_active() компонента net/sunrpc/xprtmultipath.c ядра операционной системы Linux, связанная с переполнением буфера на стеке, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09455
Уязвимость функции kasprintf() компонента arch/powerpc/mm/init-common.c ядра операционной системы 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-05-06
BDU:2024-09731
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09754
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09755
Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09757
Уязвимость компонента octeontx2-af ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09758
Уязвимость компонента nbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09767
Уязвимость компонента usb-audio ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2024-09768
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09770
Уязвимость компонента qbman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09771
Уязвимость компонента dm snapshot ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09805
Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09806
Уязвимость компонента fbmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09808
Уязвимость компонента sysv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09810
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09814
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09821
Уязвимость компонента pipe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09830
Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09831
Уязвимость компонента crypto ядра операционной системы 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: 2025-08-19
BDU:2024-09855
Уязвимость компонента usb-storage ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09856
Уязвимость компонента wilc1000 ядра операционной системы 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: 2025-05-06
BDU:2024-09887
Уязвимость компонентов pstore/zone ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09893
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09894
Уязвимость компонента send ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-09895
Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09897
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09913
Уязвимость компонента btintel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09915
Уязвимость компонента ncm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09917
Уязвимость компонента vt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09931
Уязвимость компонента mvpp2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09933
Уязвимость компонента udc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09938
Уязвимость компонента ubifs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09939
Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09945
Уязвимость компонентов drm/lima ядра операционной системы 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-08-19
BDU:2024-09972
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09973
Уязвимость компонента nci ядра операционной системы 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-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-10053
Уязвимость компонента udp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10055
Уязвимость компонента dynamic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10064
Уязвимость компонента VMCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10065
Уязвимость компонентов x86/mm/pat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10658
Уязвимость компонента n_gsm ядра операционной системы Linux, позволяющая нарушителю обойти существующие ограничения безопасности
Modified: 2025-08-19
BDU:2024-10659
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10739
Уязвимость компонента libertas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00024
Уязвимость компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-03-21
BDU:2025-00163
Уязвимость функции jfs_mount() в модуле fs/jfs/jfs_mount.c файловой системы jfs ядра операционной системы Linux в , позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2025-01230
Уязвимость модуля nf_tables компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02907
Уязвимость функции hci_get_dev_info() модуля net/bluetooth/hci_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-02909
Уязвимость функции fcoe_ctlr_announce() модуля drivers/scsi/fcoe/fcoe_ctlr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03085
Уязвимость функции bq27xxx_battery_i2c_remove() модуля drivers/power/supply/bq27xxx_battery_i2c.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-06-09
BDU:2025-03618
Уязвимость функции nilfs_segctor_prepare_write() модуля fs/nilfs2/segment.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03817
Уязвимость функции do_fp_load() модуля arch/powerpc/lib/sstep.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03818
Уязвимость функции rt2x00lib_disable_radio() модуля drivers/net/wireless/ralink/rt2x00/rt2x00dev.c - драйвера поддержки адаптеров беспроводной связи Ralink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03821
Уязвимость функции section_nr_to_pfn() модуля include/linux/mmzone.h ядра операционной системы 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-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-08-19
BDU:2025-04401
Уязвимость функции __dm_internal_suspend() модуля drivers/md/dm.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-04570
Уязвимость функции dev_pm_skip_resume() модуля drivers/base/power/main.c - драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07474
Уязвимость функции ath9k_htc_txstatus() модуля drivers/net/wireless/ath/ath9k/htc_drv_txrx.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07475
Уязвимость функции diNewExt() модуля fs/jfs/jfs_imap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07476
Уязвимость функции dbAllocBits() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07477
Уязвимость функции dtSplitRoot() модуля fs/jfs/jfs_dtree.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07478
Уязвимость функции dbAdjTree() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07479
Уязвимость функции j1939_sk_match_dst() модуля net/can/j1939/socket.c поддержки сокетов j1939 шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-07510
Уязвимость функции __poke_user() модуля arch/s390/kernel/ptrace.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-07532
Уязвимость функции rng_get_data() модуля drivers/char/hw_random/core.c - драйвера поддержки алфавитно-цифровых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08237
Уязвимость функции drm_mode_page_flip_ioctls модуля drivers/gpu/drm/drm_plane.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-01-20
BDU:2025-10240
Уязвимость ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-10251
Уязвимость функции blk_mq_alloc_request_hctx() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-12996
Уязвимость функции recv() компонента tls ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14286
Уязвимость функции mpi_ec_init() модуля lib/mpi/ec.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14287
Уязвимость функции ramoops_init_przs() модуля fs/pstore/ram.c поддержки постоянного хранилища ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14288
Уязвимость функции alloc_flex_gd() модуля fs/ext4/resize.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14295
Уязвимость функции create_core_data() модуля drivers/hwmon/coretemp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-14591
Уязвимость функции devfreq_monitor() модуля drivers/devfreq/devfreq.c драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14602
Уязвимость функции rnbd_srv_get_full_path() модуля drivers/block/rnbd/rnbd-srv.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-15038
Уязвимость функции kvm_arch_vcpu_ioctl_set_fpu() модуля arch/s390/kvm/kvm-s390.c поддержки платформы S390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
BDU:2025-15042
Уязвимость функции __tracing_map_insert() модуля kernel/trace/tracing_map.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15043
Уязвимость функции process_isoc_td() модуля drivers/usb/host/xhci-ring.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15058
Уязвимость функции tipc_nl_bearer_add() модуля net/tipc/bearer.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15770
Уязвимость компонента arm64/entry ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01440
Уязвимость команды WMI_TXSTATUS_EVENTID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01455
Уязвимость функции nilfs_prepare_segment_for_recovery() модуля fs/nilfs2/recovery.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03343
Уязвимость функции blk_mq_mark_tag_wait() модуля block/blk-mq.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-01
CVE-2022-49720
In the Linux kernel, the following vulnerability has been resolved: block: Fix handling of offline queues in blk_mq_alloc_request_hctx() This patch prevents that test nvme/004 triggers the following: UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9 index 512 is out of range for type 'long unsigned int [512]' Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x3b __ubsan_handle_out_of_bounds.cold+0x44/0x49 blk_mq_alloc_request_hctx+0x304/0x310 __nvme_submit_sync_cmd+0x70/0x200 [nvme_core] nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics] nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop] nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop] nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics] nvmf_dev_write+0xae/0x111 [nvme_fabrics] vfs_write+0x144/0x560 ksys_write+0xb7/0x140 __x64_sys_write+0x42/0x50 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Modified: 2025-11-04
CVE-2023-52429
dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4
- 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%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/
- https://www.spinics.net/lists/dm-devel/msg56625.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4
- 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%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/
- https://www.spinics.net/lists/dm-devel/msg56625.html
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: 2024-11-21
CVE-2023-52435
In the Linux kernel, the following vulnerability has been resolved:
net: prevent mss overflow in skb_segment()
Once again syzbot is able to crash the kernel in skb_segment() [1]
GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :
mss = mss * partial_segs;
65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.
Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.
[1]
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0d3ffbbf8631d6db0552f46250015648991c856f
- https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7
- https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a
- https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3
- https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77
- https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137
- https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083
- https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7
- https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a
- https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3
- https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77
- https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137
- https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2023-52447
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map.
- https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6
- https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0
- https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368
- https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2
- https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5
- https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee
- https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6
- https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0
- https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368
- https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2
- https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5
- https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2023-52458
In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free.
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-25
CVE-2023-52482
In the Linux kernel, the following vulnerability has been resolved: x86/srso: Add SRSO mitigation for Hygon processors Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors too.
- https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96
- https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d
- https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4
- https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d
- https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37
- https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96
- https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d
- https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4
- https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d
- https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2023-52486
In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.
- https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229
- https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0
- https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7
- https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551
- https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a
- https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c
- https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c
- https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105
- https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229
- https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0
- https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7
- https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551
- https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a
- https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c
- https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c
- https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105
- 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-14
CVE-2023-52489
In the Linux kernel, the following vulnerability has been resolved: mm/sparsemem: fix race in accessing memory_section->usage The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1]. compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL] NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled. The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed. Fix this issue by the below steps: a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. Thanks to David/Pavan for their inputs on this patch. [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/ On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. For this particular issue below is the log. Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing. [ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated---
- https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7
- https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800
- https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a
- https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97
- https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea
- https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529
- https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7
- https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800
- https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a
- https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97
- https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea
- https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52491
In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
- https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590
- https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e
- https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9
- https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c
- https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7
- https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6
- https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590
- https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e
- https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9
- https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c
- https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7
- https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2023-52492
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function.
- https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79
- https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08
- https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b
- https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0
- https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17
- https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7
- https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79
- https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08
- https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b
- https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0
- https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17
- https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52493
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Drop chan lock before queuing buffers Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup. [mani: added fixes tag and cc'ed stable]
- https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b
- https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
- https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690
- https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece
- https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830
- https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e
- https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b
- https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
- https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690
- https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece
- https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830
- https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-09
CVE-2023-52497
In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order.
- https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847
- https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de
- https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184
- https://git.kernel.org/stable/c/9ff2d260b25df6fe1341a79113d88fecf6bd553e
- https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379
- https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e
- https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae
- https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847
- https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de
- https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184
- https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379
- https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e
- https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52498
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false.
- https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557
- https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7
- https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0
- https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34
- https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe
- https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d
- https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557
- https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7
- https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0
- https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34
- https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe
- https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-03
CVE-2023-52583
In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.
- https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160
- https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980
- https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67
- https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e
- https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca
- https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085
- https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3
- https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6
- https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160
- https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980
- https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67
- https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e
- https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca
- https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085
- https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3
- https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6
- 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-14
CVE-2023-52587
In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
`priv->multicast_list` and we keep | remove_list, list)
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.
crash> bc 31
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
--
[exception RIP: ipoib_mcast_join_task+0x1b1]
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
work (&priv->mcast_task{,.work})
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
&mcast->list
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
mcast
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
dev priv (&priv->lock) &priv->multicast_list (aka head)
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
---
- https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18
- https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825
- https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9
- https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a
- https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90
- https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89
- https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
- https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34
- https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18
- https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825
- https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9
- https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a
- https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90
- https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89
- https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
- https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34
- 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-12
CVE-2023-52594
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus() Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case. Found by a modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt
- https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234
- https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348
- https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1
- https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9
- https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1
- https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d
- https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225
- https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc
- https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234
- https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348
- https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1
- https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9
- https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1
- https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d
- https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225
- https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc
- 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-12
CVE-2023-52595
In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
- https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83
- https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c
- https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e
- https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957
- https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8
- https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48
- https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb
- https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83
- https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c
- https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e
- https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957
- https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8
- https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48
- https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-14
CVE-2023-52597
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu. Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c.
- https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3
- https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99
- https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7
- https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18
- https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1
- https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2
- https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55
- https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f
- https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3
- https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99
- https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7
- https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18
- https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1
- https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2
- https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55
- https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-14
CVE-2023-52598
In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc register correctly If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when returning to user space. In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs() before using test_fp_ctl().
- https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1
- https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25
- https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713
- https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8
- https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3
- https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a
- https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829
- https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4
- https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1
- https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25
- https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713
- https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8
- https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3
- https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a
- https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829
- https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52599
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diNewExt
[Syz report]
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
index -878706688 is out of range for type 'struct iagctl[128]'
CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
Call Trace:
- https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641
- https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402
- https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe
- https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b
- https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98
- https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017
- https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e
- https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41
- https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641
- https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402
- https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe
- https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b
- https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98
- https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017
- https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e
- https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41
- 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-12
CVE-2023-52600
In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap.
- https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e
- https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce
- https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35
- https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61
- https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f
- https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e
- https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8
- https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3
- https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e
- https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce
- https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35
- https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61
- https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f
- https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e
- https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8
- https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3
- 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-14
CVE-2023-52601
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbAdjTree Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add the required check added the bool is_ctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/
- https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317
- https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c
- https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555
- https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e
- https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603
- https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b
- https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e
- https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73
- https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317
- https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c
- https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555
- https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e
- https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603
- https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b
- https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e
- https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73
- 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-14
CVE-2023-52602
In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds Read in dtSearch Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO
- https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb
- https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6
- https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd
- https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7
- https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472
- https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612
- https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950
- https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f
- https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb
- https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6
- https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd
- https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7
- https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472
- https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612
- https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950
- https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f
- 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-12
CVE-2023-52603
In the Linux kernel, the following vulnerability has been resolved:
UBSAN: array-index-out-of-bounds in dtSplitRoot
Syzkaller reported the following issue:
oop0: detected capacity change from 0 to 32768
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type 'struct dtslot [128]'
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
- https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16
- https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2
- https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8
- https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af
- https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60
- https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39
- https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f
- https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07
- https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16
- https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2
- https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8
- https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af
- https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60
- https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39
- https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f
- https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07
- 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-12
CVE-2023-52604
In the Linux kernel, the following vulnerability has been resolved:
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
- https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03
- https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9
- https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd
- https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b
- https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68
- https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56
- https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b
- https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15
- https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03
- https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9
- https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd
- https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b
- https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68
- https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56
- https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b
- https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15
- 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-14
CVE-2023-52606
In the Linux kernel, the following vulnerability has been resolved: powerpc/lib: Validate size for vector operations Some of the fp/vmx code in sstep.c assume a certain maximum size for the instructions being emulated. The size of those operations however is determined separately in analyse_instr(). Add a check to validate the assumption on the maximum size of the operations, so as to prevent any unintended kernel stack corruption.
- https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf
- https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c
- https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414
- https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd
- https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59
- https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e
- https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678
- https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b
- https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf
- https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c
- https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414
- https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd
- https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59
- https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e
- https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678
- https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-14
CVE-2023-52607
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer dereference in pgtable_cache_add 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/145febd85c3bcc5c74d87ef9a598fc7d9122d532
- https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611
- https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b
- https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7
- https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1
- https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071
- https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e
- https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74
- https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532
- https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611
- https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b
- https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7
- https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1
- https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071
- https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e
- https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52615
In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user.
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- 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-10
CVE-2023-52616
In the Linux kernel, the following vulnerability has been resolved: crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately.
- https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165
- https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6
- https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49
- https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a
- https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a
- https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598
- https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165
- https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6
- https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49
- https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a
- https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a
- https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2023-52617
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2023-52618
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present).
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-10
CVE-2023-52619
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- 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-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-52622
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid online resizing failures due to oversized flex bg
When we online resize an ext4 filesystem with a oversized flexbg_size,
mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
mount $dev $dir
resize2fs $dev 16G
the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
- https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0
- https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954
- https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c
- https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07
- https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644
- https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8
- https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90
- https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2
- https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0
- https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954
- https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c
- https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07
- https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644
- https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8
- https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90
- https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2
- 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-31
CVE-2023-52623
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a suspicious RCU usage warning
I received the following warning while running cthon against an ontap
server running pNFS:
[ 57.202521] =============================
[ 57.202522] WARNING: suspicious RCU usage
[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
[ 57.202525] -----------------------------
[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
[ 57.202527]
other info that might help us debug this:
[ 57.202528]
rcu_scheduler_active = 2, debug_locks = 1
[ 57.202529] no locks held by test5/3567.
[ 57.202530]
stack backtrace:
[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
[ 57.202536] Call Trace:
[ 57.202537]
- https://git.kernel.org/stable/c/31b62908693c90d4d07db597e685d9f25a120073
- https://git.kernel.org/stable/c/69c7eeb4f622c2a28da965f970f982db171f3dc6
- https://git.kernel.org/stable/c/7a96d85bf196c170dcf1b47a82e9bb97cca69aa6
- https://git.kernel.org/stable/c/8f860c8407470baff2beb9982ad6b172c94f1d0a
- https://git.kernel.org/stable/c/c430e6bb43955c6bf573665fcebf31694925b9f7
- https://git.kernel.org/stable/c/e8ca3e73301e23e8c0ac0ce2e6bac4545cd776e0
- https://git.kernel.org/stable/c/f8cf4dabbdcb8bef85335b0ed7ad5b25fd82ff56
- https://git.kernel.org/stable/c/fece80a2a6718ed58487ce397285bb1b83a3e54e
- https://git.kernel.org/stable/c/31b62908693c90d4d07db597e685d9f25a120073
- https://git.kernel.org/stable/c/69c7eeb4f622c2a28da965f970f982db171f3dc6
- https://git.kernel.org/stable/c/7a96d85bf196c170dcf1b47a82e9bb97cca69aa6
- https://git.kernel.org/stable/c/8f860c8407470baff2beb9982ad6b172c94f1d0a
- https://git.kernel.org/stable/c/c430e6bb43955c6bf573665fcebf31694925b9f7
- https://git.kernel.org/stable/c/e8ca3e73301e23e8c0ac0ce2e6bac4545cd776e0
- https://git.kernel.org/stable/c/f8cf4dabbdcb8bef85335b0ed7ad5b25fd82ff56
- https://git.kernel.org/stable/c/fece80a2a6718ed58487ce397285bb1b83a3e54e
- 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-2023-52627
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7091r: Allow users to configure device events AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set. Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation. Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added.
- https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f
- https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4
- https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5
- https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091
- https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6
- https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2
- https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f
- https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4
- https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5
- https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091
- https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6
- https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2023-52635
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].
while true
do
echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
done
It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.
[1]
...
..
- https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675
- https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9
- https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9
- https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475
- https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22
- https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6
- https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675
- https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9
- https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9
- https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475
- https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22
- https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-07
CVE-2023-52637
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
modifies jsk->filters while receiving packets.
Following trace was seen on affected system:
==================================================================
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
Read of size 4 at addr ffff888012144014 by task j1939/350
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
print_report+0xd3/0x620
? kasan_complete_mode_report_info+0x7d/0x200
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
kasan_report+0xc2/0x100
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
__asan_load4+0x84/0xb0
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
j1939_sk_recv+0x20b/0x320 [can_j1939]
? __kasan_check_write+0x18/0x20
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
? j1939_simple_recv+0x69/0x280 [can_j1939]
? j1939_ac_recv+0x5e/0x310 [can_j1939]
j1939_can_recv+0x43f/0x580 [can_j1939]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
? raw_rcv+0x42/0x3c0 [can_raw]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
can_rcv_filter+0x11f/0x350 [can]
can_receive+0x12f/0x190 [can]
? __pfx_can_rcv+0x10/0x10 [can]
can_rcv+0xdd/0x130 [can]
? __pfx_can_rcv+0x10/0x10 [can]
__netif_receive_skb_one_core+0x13d/0x150
? __pfx___netif_receive_skb_one_core+0x10/0x10
? __kasan_check_write+0x18/0x20
? _raw_spin_lock_irq+0x8c/0xe0
__netif_receive_skb+0x23/0xb0
process_backlog+0x107/0x260
__napi_poll+0x69/0x310
net_rx_action+0x2a1/0x580
? __pfx_net_rx_action+0x10/0x10
? __pfx__raw_spin_lock+0x10/0x10
? handle_irq_event+0x7d/0xa0
__do_softirq+0xf3/0x3f8
do_softirq+0x53/0x80
- https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532
- https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8
- https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed
- https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba
- https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc
- https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50
- https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d
- https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532
- https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8
- https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed
- https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba
- https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc
- https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50
- https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-27
CVE-2023-52642
In the Linux kernel, the following vulnerability has been resolved: media: rc: bpf attach/detach requires write permission Note that bpf attach/detach also requires CAP_NET_ADMIN.
- https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f
- https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8
- https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f
- https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e
- https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be
- https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0
- https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f
- https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8
- https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f
- https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e
- https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be
- https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
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-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-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-12-23
CVE-2023-52669
In the Linux kernel, the following vulnerability has been resolved: crypto: s390/aes - Fix buffer overread in CTR mode When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2023-52670
In the Linux kernel, the following vulnerability has been resolved: rpmsg: virtio: Free driver_override when rpmsg_remove() Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur: unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- 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-2023-52672
In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 ("pipe: Add general notification queue support") a
regression was introduced that would lock up resized pipes under certain
conditions. See the reproducer in [1].
The commit resizing the pipe ring size was moved to a different
function, doing that moved the wakeup for pipe->wr_wait before actually
raising pipe->max_usage. If a pipe was full before the resize occured it
would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a
watch queue.
[Christian Brauner
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2023-52699
In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).
- https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76
- https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f
- https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09
- https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1
- https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac
- https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3
- https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e
- https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927
- https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76
- https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f
- https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09
- https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1
- https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac
- https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3
- https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e
- https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927
- 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-2023-52880
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that.
- https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167
- https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a
- https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88
- https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58
- https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed
- https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa
- https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167
- https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a
- https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88
- https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58
- https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed
- https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa
- 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-0841
A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2024-0841
- https://bugzilla.redhat.com/show_bug.cgi?id=2256490
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2024-0841
- https://bugzilla.redhat.com/show_bug.cgi?id=2256490
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-10-01
CVE-2024-26581
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just added in this transactions, skip end interval elements that are not yet active.
- https://git.kernel.org/stable/c/10e9cb39313627f2eae4cd70c4b742074e998fd8
- https://git.kernel.org/stable/c/1296c110c5a0b45a8fcf58e7d18bc5da61a565cb
- https://git.kernel.org/stable/c/2bab493a5624444ec6e648ad0d55a362bcb4c003
- https://git.kernel.org/stable/c/4cee42fcf54fec46b344681e7cc4f234bb22f85a
- https://git.kernel.org/stable/c/60c0c230c6f046da536d3df8b39a20b9a9fd6af0
- https://git.kernel.org/stable/c/6eb14441f10602fa1cf691da9d685718b68b78a9
- https://git.kernel.org/stable/c/b734f7a47aeb32a5ba298e4ccc16bb0c52b6dbf7
- https://git.kernel.org/stable/c/c60d252949caf9aba537525195edae6bbabc35eb
- https://git.kernel.org/stable/c/10e9cb39313627f2eae4cd70c4b742074e998fd8
- https://git.kernel.org/stable/c/1296c110c5a0b45a8fcf58e7d18bc5da61a565cb
- https://git.kernel.org/stable/c/2bab493a5624444ec6e648ad0d55a362bcb4c003
- https://git.kernel.org/stable/c/4cee42fcf54fec46b344681e7cc4f234bb22f85a
- https://git.kernel.org/stable/c/60c0c230c6f046da536d3df8b39a20b9a9fd6af0
- https://git.kernel.org/stable/c/6eb14441f10602fa1cf691da9d685718b68b78a9
- https://git.kernel.org/stable/c/b734f7a47aeb32a5ba298e4ccc16bb0c52b6dbf7
- https://git.kernel.org/stable/c/c60d252949caf9aba537525195edae6bbabc35eb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2024-26593
In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read.
- https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a
- https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c
- https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2
- https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9
- https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f
- https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21
- https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7
- https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a
- https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c
- https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2
- https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9
- https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f
- https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21
- https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2024-11-21
CVE-2024-26600
In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let's fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL.
- https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4
- https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4
- https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1
- https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b
- https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d
- https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5
- https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462
- https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3
- https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4
- https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4
- https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1
- https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b
- https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d
- https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5
- https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462
- https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3
- 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-26601
In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case.
- https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581
- https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4
- https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a
- https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326
- https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e
- https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb
- https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581
- https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4
- https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a
- https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326
- https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e
- https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-26602
In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.
- https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265
- https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a
- https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3
- https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee
- https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23
- https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71
- https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea
- https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6
- https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265
- https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a
- https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3
- https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee
- https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23
- https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71
- https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea
- https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-26606
In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work.
- https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61
- https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc
- https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769
- https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69
- https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7
- https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc
- https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68
- https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac
- https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61
- https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc
- https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769
- https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69
- https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7
- https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc
- https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68
- https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac
- 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/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2024-12-12
CVE-2024-26610
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix a memory corruption iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer.
- https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a
- https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b
- https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd
- https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32
- https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d
- https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67
- https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a
- https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b
- https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd
- https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32
- https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d
- https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-03
CVE-2024-26614
In the Linux kernel, the following vulnerability has been resolved:
tcp: make sure init the accept_queue's spinlocks once
When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02
- https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2
- https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a
- https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855
- https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882
- https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3
- https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02
- https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2
- https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a
- https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855
- https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882
- https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2024-26615
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d
- https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be
- https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22
- https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
- https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a
- https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a
- https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6
- https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9
- https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c
- https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be
- https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22
- https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
- https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a
- https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a
- https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6
- https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9
- https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
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-01-07
CVE-2024-26625
In the Linux kernel, the following vulnerability has been resolved:
llc: call sock_orphan() at release time
syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
pointer in a closed llc socket.
In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
calling proto_ops::release()") Eric Biggers hinted that some protocols
are missing a sock_orphan(), we need to perform a full audit.
In net-next, I plan to clear sock->sk from sock_orphan() and
amend Eric patch to add a warning.
[1]
BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812
- https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f
- https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b
- https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4
- https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee
- https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c
- https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7
- https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a
- https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812
- https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f
- https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b
- https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4
- https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee
- https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c
- https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7
- https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a
- 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-14
CVE-2024-26627
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart]
- https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb
- https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0
- https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1
- https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059
- https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c
- https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c
- https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb
- https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0
- https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1
- https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059
- https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c
- https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-10
CVE-2024-26635
In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring"). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let's remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
- https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62
- https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6
- https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd
- https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097
- https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828
- https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc
- https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61
- https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8
- https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62
- https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6
- https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd
- https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097
- https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828
- https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc
- https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61
- https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8
- 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-10
CVE-2024-26636
In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
- https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c
- https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4
- https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b
- https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d
- https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249
- https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb
- https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b
- https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647
- https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c
- https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4
- https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b
- https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d
- https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249
- https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb
- https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b
- https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647
- 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-10
CVE-2024-26640
In the Linux kernel, the following vulnerability has been resolved: tcp: add sanity checks to rx zerocopy TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs. This patch adds to can_map_frag() these additional checks: - Page must not be a compound one. - page->mapping must be NULL. This fixes the panic reported by ZhangPeng. syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy. r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)
- https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60
- https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894
- https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e
- https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e
- https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760
- https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f
- https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60
- https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894
- https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e
- https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e
- https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760
- https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-28
CVE-2024-26641
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() syzbot found __ip6_tnl_rcv() could access unitiliazed data [1]. Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head. [1] 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 IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 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:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 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+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 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 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+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
- https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6
- https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0
- https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080
- https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0
- https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a
- https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8
- https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6
- https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0
- https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080
- https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0
- https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a
- https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20241108-0008/
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-07-17
CVE-2024-26644
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
If the source file descriptor to the snapshot ioctl refers to a deleted
subvolume, we get the following abort:
BTRFS: Transaction aborted (error -2)
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c
- https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464
- https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b
- https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a
- https://git.kernel.org/stable/c/c06941564027bdbc01d2df7f41e333c11cb0482d
- https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff
- https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256
- https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c
- https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464
- https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b
- https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a
- https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff
- https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26645
In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when inserting an element into tracing_map Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt; The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---
- https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7
- https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b
- https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7
- https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177
- https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb
- https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c
- https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860
- https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a
- https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7
- https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b
- https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7
- https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177
- https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb
- https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c
- https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860
- https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-01-07
CVE-2024-26663
In the Linux kernel, the following vulnerability has been resolved:
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
syzbot reported the following general protection fault [1]:
general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
- https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87
- https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95
- https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1
- https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87
- https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6
- https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f
- https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59
- https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12
- https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87
- https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95
- https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1
- https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87
- https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6
- https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f
- https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59
- https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12
- 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-2024-26664
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.
- https://git.kernel.org/stable/c/1eb74c00c9c3b13cb65e508c5d5a2f11afb96b8b
- https://git.kernel.org/stable/c/3a7753bda55985dc26fae17795cb10d825453ad1
- https://git.kernel.org/stable/c/4e440abc894585a34c2904a32cd54af1742311b3
- https://git.kernel.org/stable/c/853a6503c586a71abf27e60a7f8c4fb28092976d
- https://git.kernel.org/stable/c/93f0f4e846fcb682c3ec436e3b2e30e5a3a8ee6a
- https://git.kernel.org/stable/c/9bce69419271eb8b2b3ab467387cb59c99d80deb
- https://git.kernel.org/stable/c/a16afec8e83c56b14a4a73d2e3fb8eec3a8a057e
- https://git.kernel.org/stable/c/f0da068c75c20ffc5ba28243ff577531dc2af1fd
- https://git.kernel.org/stable/c/1eb74c00c9c3b13cb65e508c5d5a2f11afb96b8b
- https://git.kernel.org/stable/c/3a7753bda55985dc26fae17795cb10d825453ad1
- https://git.kernel.org/stable/c/4e440abc894585a34c2904a32cd54af1742311b3
- https://git.kernel.org/stable/c/853a6503c586a71abf27e60a7f8c4fb28092976d
- https://git.kernel.org/stable/c/93f0f4e846fcb682c3ec436e3b2e30e5a3a8ee6a
- https://git.kernel.org/stable/c/9bce69419271eb8b2b3ab467387cb59c99d80deb
- https://git.kernel.org/stable/c/a16afec8e83c56b14a4a73d2e3fb8eec3a8a057e
- https://git.kernel.org/stable/c/f0da068c75c20ffc5ba28243ff577531dc2af1fd
- 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-03
CVE-2024-26665
In the Linux kernel, the following vulnerability has been resolved: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs.
- https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1
- https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab
- https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06
- https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a
- https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732
- https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d
- https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1
- https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab
- https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06
- https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a
- https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732
- https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26671
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag.
- https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56
- https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed
- https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0
- https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f
- https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b
- https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676
- https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10
- https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2
- https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56
- https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed
- https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0
- https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f
- https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b
- https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676
- https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10
- https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2
- 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-2024-26673
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.
- https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98
- https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8
- https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d
- https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4
- https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f
- https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e
- https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483
- https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98
- https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8
- https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d
- https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4
- https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f
- https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e
- https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26675
In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
- https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8
- https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16
- https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed
- https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982
- https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3
- https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719
- https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b
- https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8
- https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8
- https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16
- https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed
- https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982
- https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3
- https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719
- https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b
- https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8
- 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-2024-26679
In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning.
- https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830
- https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41
- https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2
- https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299
- https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd
- https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b
- https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40
- https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd
- https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830
- https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41
- https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2
- https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299
- https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd
- https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b
- https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40
- https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd
- 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-2024-26684
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
- https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37
- https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2
- https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3
- https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89
- https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf
- https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591
- https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00
- https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37
- https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2
- https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3
- https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89
- https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf
- https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591
- https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26685
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential bug in end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel. The use of async_write for segment summary buffers has already been removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer.
- https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803
- https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b
- https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff
- https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab
- https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8
- https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928
- https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd
- https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596
- https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803
- https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b
- https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff
- https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab
- https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8
- https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928
- https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd
- https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596
- 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-26688
In the Linux kernel, the following vulnerability has been resolved:
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
When configuring a hugetlb filesystem via the fsconfig() syscall, there is
a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
is non valid.
E.g: Taking the following steps:
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
with NULL, losing its previous value, and we will print an error:
...
...
case Opt_pagesize:
ps = memparse(param->string, &rest);
ctx->hstate = h;
if (!ctx->hstate) {
pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
return -EINVAL;
}
return 0;
...
...
This is a problem because later on, we will dereference ctxt->hstate in
hugetlbfs_fill_super()
...
...
sb->s_blocksize = huge_page_size(ctx->hstate);
...
...
Causing below Oops.
Fix this by replacing cxt->hstate value only when then pagesize is known
to be valid.
kernel: hugetlbfs: Unsupported page size 0 MB
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x0000) - not-present page
kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
kernel: Oops: 0000 [#1] PREEMPT SMP PTI
kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
kernel: Call Trace:
kernel:
- https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274
- https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557
- https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff
- https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9
- https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498
- https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773
- https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39
- https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274
- https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557
- https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff
- https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9
- https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498
- https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773
- https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26689
In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed. In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.
- https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77
- https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc
- https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214
- https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7
- https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef
- https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139
- https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77
- https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc
- https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214
- https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7
- https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef
- https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-07
CVE-2024-26695
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked
The SEV platform device can be shutdown with a null psp_master,
e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN:
[ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)
[ 137.162647] ccp 0000:23:00.1: no command queues available
[ 137.170598] ccp 0000:23:00.1: sev enabled
[ 137.174645] ccp 0000:23:00.1: psp enabled
[ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI
[ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]
[ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311
[ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180
[ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c
[ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216
[ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e
[ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0
[ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66
[ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28
[ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8
[ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000
[ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0
[ 137.182693] Call Trace:
[ 137.182693]
- https://git.kernel.org/stable/c/58054faf3bd29cd0b949b77efcb6157f66f401ed
- https://git.kernel.org/stable/c/7535ec350a5f09b5756a7607f5582913f21200f4
- https://git.kernel.org/stable/c/8731fe001a60581794ed9cf65da8cd304846a6fb
- https://git.kernel.org/stable/c/88aa493f393d2ee38ac140e1f6ac1881346e85d4
- https://git.kernel.org/stable/c/b5909f197f3b26aebedca7d8ac7b688fd993a266
- https://git.kernel.org/stable/c/ccb88e9549e7cfd8bcd511c538f437e20026e983
- https://git.kernel.org/stable/c/58054faf3bd29cd0b949b77efcb6157f66f401ed
- https://git.kernel.org/stable/c/7535ec350a5f09b5756a7607f5582913f21200f4
- https://git.kernel.org/stable/c/8731fe001a60581794ed9cf65da8cd304846a6fb
- https://git.kernel.org/stable/c/88aa493f393d2ee38ac140e1f6ac1881346e85d4
- https://git.kernel.org/stable/c/b5909f197f3b26aebedca7d8ac7b688fd993a266
- https://git.kernel.org/stable/c/ccb88e9549e7cfd8bcd511c538f437e20026e983
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26696
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.
- https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e
- https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534
- https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f
- https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32
- https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46
- https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6
- https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d
- https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28
- https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e
- https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534
- https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f
- https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32
- https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46
- https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6
- https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d
- https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28
- 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-2024-26697
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page.
- https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5
- https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9
- https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d
- https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa
- https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65
- https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1
- https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3
- https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba
- https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5
- https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9
- https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d
- https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa
- https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65
- https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1
- https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3
- https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba
- 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-2024-26698
In the Linux kernel, the following vulnerability has been resolved:
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
VMBus channel"), napi_disable was getting called for all channels,
including all subchannels without confirming if they are enabled or not.
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
has finished running but nvdev->subchan_work has not started yet.
netvsc_subchan_work() -> rndis_set_subchannel() has not created the
sub-channels and because of that netvsc_sc_open() is not running.
netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
netvsc_subchan_work did not run.
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
opposite.
Now during netvsc_device_remove(), when napi_disable is called for those
subchannels, napi_disable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napi_disable() is not
getting called for non-enabled NAPI struct.
But netif_napi_del() is still necessary for these non-enabled NAPI struct
for cleanup purpose.
Call trace:
[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
[ 654.568030] Call Trace:
[ 654.571221]
- https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd
- https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b
- https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518
- https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a
- https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f
- https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11
- https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd
- https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b
- https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518
- https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a
- https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f
- https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26702
In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC Recently, we encounter kernel crash in function rm3100_common_probe caused by out of bound access of array rm3100_samp_rates (because of underlying hardware failures). Add boundary check to prevent out of bound access.
- https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513
- https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01
- https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56
- https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1
- https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481
- https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e
- https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60
- https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513
- https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01
- https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56
- https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1
- https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481
- https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e
- https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26704
In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue.
- https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1
- https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f
- https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4
- https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6
- https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1
- https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1
- https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71
- https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537
- https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1
- https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f
- https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4
- https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6
- https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1
- https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1
- https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71
- https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537
- 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-2024-26707
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
Syzkaller reported [1] hitting a warning after failing to allocate
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
not help much in this case, it might be prudent to switch to
netdev_warn_once(). At the very least it will suppress syzkaller
reports such as [1].
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
for similar reasons.
[1]
HSR: Could not send supervision frame
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
...
Call Trace:
- https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb
- https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e
- https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51
- https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a
- https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8
- https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0
- https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb
- https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e
- https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51
- https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a
- https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8
- https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26712
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address.
- https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe
- https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058
- https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882
- https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6
- https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0
- https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25
- https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe
- https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058
- https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882
- https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6
- https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0
- https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
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-03-17
CVE-2024-26727
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not ASSERT() if the newly created subvolume already got read
[BUG]
There is a syzbot crash, triggered by the ASSERT() during subvolume
creation:
assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319
------------[ cut here ]------------
kernel BUG at fs/btrfs/disk-io.c:1319!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60
- https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f
- https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468
- https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d
- https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430
- https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb
- https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f
- https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f
- https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468
- https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d
- https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430
- https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb
- https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
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-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-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-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-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-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-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-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-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-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: 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-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-04-04
CVE-2024-26808
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list.
- https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913
- https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee
- https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58
- https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f
- https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3
- https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4
- https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913
- https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee
- https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58
- https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f
- https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3
- https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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: 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-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-11-04
CVE-2024-26817
In the Linux kernel, the following vulnerability has been resolved: amdkfd: use calloc instead of kzalloc to avoid integer overflow This uses calloc instead of doing the multiplication which might overflow.
- https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a
- https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7
- https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29
- https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0
- https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad
- https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751
- https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a
- https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91
- https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a
- https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7
- https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29
- https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0
- https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad
- https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751
- https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a
- https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91
- 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/P3TH6JK7ZZMSXSVHOJKIMSSOC6EQM4WV/
Modified: 2025-03-27
CVE-2024-26820
In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER handler cannot perform VF register successfully as the register call is received before netvsc_probe is finished. This is because we register register_netdevice_notifier() very early( even before vmbus_driver_register()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe.
- https://git.kernel.org/stable/c/309ef7de5d840e17607e7d65cbf297c0564433ef
- https://git.kernel.org/stable/c/4d29a58d96a78728cb01ee29ed70dc4bd642f135
- https://git.kernel.org/stable/c/5b10a88f64c0315cfdef45de0aaaa4eef57de0b7
- https://git.kernel.org/stable/c/9cae43da9867412f8bd09aee5c8a8dc5e8dc3dc2
- https://git.kernel.org/stable/c/a71302c8638939c45e4ba5a99ea438185fd3f418
- https://git.kernel.org/stable/c/b6d46f306b3964d05055ddaa96b58cd8bd3a472c
- https://git.kernel.org/stable/c/bcb7164258d0a9a8aa2e73ddccc2d78f67d2519d
- https://git.kernel.org/stable/c/c7441c77c91e47f653104be8353b44a3366a5366
- https://git.kernel.org/stable/c/309ef7de5d840e17607e7d65cbf297c0564433ef
- https://git.kernel.org/stable/c/4d29a58d96a78728cb01ee29ed70dc4bd642f135
- https://git.kernel.org/stable/c/5b10a88f64c0315cfdef45de0aaaa4eef57de0b7
- https://git.kernel.org/stable/c/9cae43da9867412f8bd09aee5c8a8dc5e8dc3dc2
- https://git.kernel.org/stable/c/a71302c8638939c45e4ba5a99ea438185fd3f418
- https://git.kernel.org/stable/c/b6d46f306b3964d05055ddaa96b58cd8bd3a472c
- https://git.kernel.org/stable/c/bcb7164258d0a9a8aa2e73ddccc2d78f67d2519d
- https://git.kernel.org/stable/c/c7441c77c91e47f653104be8353b44a3366a5366
- 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-26825
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free rx_data_reassembly skb on NCI device cleanup rx_data_reassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak. As by design the rx_data_reassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1
- https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d
- https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23
- https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895
- https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf
- https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81
- https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9
- https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c
- https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1
- https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d
- https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23
- https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895
- https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf
- https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81
- https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9
- https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c
- 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-26829
In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: fix a memleak in irtoy_tx When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak.
- https://git.kernel.org/stable/c/207557e393a135c1b6fe1df7cc0741d2c1789fff
- https://git.kernel.org/stable/c/7219a692ffc00089015ada33b85b334d1a4b6e8e
- https://git.kernel.org/stable/c/b37259448bbc70af1d0e52a9dd5559a9c29c9621
- https://git.kernel.org/stable/c/be76ad74a43f90f340f9f479e6b04f02125f6aef
- https://git.kernel.org/stable/c/dc9ceb90c4b42c6e5c6757df1d6257110433788e
- https://git.kernel.org/stable/c/207557e393a135c1b6fe1df7cc0741d2c1789fff
- https://git.kernel.org/stable/c/486a4176bc783df798bce2903824801af8d2c3ae
- https://git.kernel.org/stable/c/7219a692ffc00089015ada33b85b334d1a4b6e8e
- https://git.kernel.org/stable/c/b37259448bbc70af1d0e52a9dd5559a9c29c9621
- https://git.kernel.org/stable/c/be76ad74a43f90f340f9f479e6b04f02125f6aef
- https://git.kernel.org/stable/c/dc9ceb90c4b42c6e5c6757df1d6257110433788e
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-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: 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: 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-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-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-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-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-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-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-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-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: 2024-11-21
CVE-2024-26910
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback.
- https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c
- https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb
- https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001
- https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05
- https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397
- https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49
- https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225
- https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c
- https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb
- https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001
- https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05
- https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397
- https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49
- https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-03
CVE-2024-26917
In the Linux kernel, the following vulnerability has been resolved: scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock" This reverts commit 1a1975551943f681772720f639ff42fbaa746212. This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave". Instead, a work queue should be used, and will be addressed in a separate commit.
- https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b
- https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21
- https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783
- https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5
- https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0
- https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b
- https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6
- https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb
- https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b
- https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21
- https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783
- https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5
- https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0
- https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b
- https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6
- https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb
- 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-26925
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence. nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called.
- https://git.kernel.org/stable/c/0d459e2ffb541841714839e8228b845458ed3b27
- https://git.kernel.org/stable/c/2cee2ff7f8cce12a63a0a23ffe27f08d99541494
- https://git.kernel.org/stable/c/61ac7284346c32f9a8c8ceac56102f7914060428
- https://git.kernel.org/stable/c/8038ee3c3e5b59bcd78467686db5270c68544e30
- https://git.kernel.org/stable/c/8d3a58af50e46167b6f1db47adadad03c0045dae
- https://git.kernel.org/stable/c/a34ba4bdeec0c3b629160497594908dc820110f1
- https://git.kernel.org/stable/c/eb769ff4e281f751adcaf4f4445cbf30817be139
- https://git.kernel.org/stable/c/0d459e2ffb541841714839e8228b845458ed3b27
- https://git.kernel.org/stable/c/2cee2ff7f8cce12a63a0a23ffe27f08d99541494
- https://git.kernel.org/stable/c/61ac7284346c32f9a8c8ceac56102f7914060428
- https://git.kernel.org/stable/c/8038ee3c3e5b59bcd78467686db5270c68544e30
- https://git.kernel.org/stable/c/8d3a58af50e46167b6f1db47adadad03c0045dae
- https://git.kernel.org/stable/c/a34ba4bdeec0c3b629160497594908dc820110f1
- https://git.kernel.org/stable/c/eb769ff4e281f751adcaf4f4445cbf30817be139
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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: 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: 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-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: 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: 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: 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: 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-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-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-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-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-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-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: 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-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-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-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-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-04-07
CVE-2024-35833
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA This dma_alloc_coherent() is undone neither in the remove function, nor in the error handling path of fsl_qdma_probe(). Switch to the managed version to fix both issues.
- https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3
- https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24
- https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8
- https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59
- https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714
- https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6
- https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802
- https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3
- https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24
- https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8
- https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59
- https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714
- https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6
- https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2024-35835
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a double-free in arfs_create_groups When `in` allocated by kvzalloc fails, arfs_create_groups will free ft->g and return an error. However, arfs_create_table, the only caller of arfs_create_groups, will hold this error and call to mlx5e_destroy_flow_table, in which the ft->g will be freed again.
- https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7
- https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b
- https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb
- https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b
- https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7
- https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056
- https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5
- https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629
- https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7
- https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b
- https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb
- https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b
- https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7
- https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056
- https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5
- https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629
- 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-35837
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: clear BM pool before initialization Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue.
- https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f
- https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b
- https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38
- https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa
- https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec
- https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4
- https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f
- https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b
- https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38
- https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa
- https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec
- https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
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: 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-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-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-12-17
CVE-2024-35897
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: discard table flag update with pending basechain deletion Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.
- https://git.kernel.org/stable/c/1bc83a019bbe268be3526406245ec28c2458a518
- https://git.kernel.org/stable/c/2aeb805a1bcd5f27c8c0d1a9d4d653f16d1506f4
- https://git.kernel.org/stable/c/6cbbe1ba76ee7e674a86abd43009b083a45838cb
- https://git.kernel.org/stable/c/7f609f630951b624348373cef99991ce08831927
- https://git.kernel.org/stable/c/9627fd0c6ea1c446741a33e67bc5709c59923827
- https://git.kernel.org/stable/c/9a3b90904d8a072287480eed4c3ece4b99d64f78
- https://git.kernel.org/stable/c/b58d0ac35f6d75ec1db8650a29dfd6f292c11362
- https://git.kernel.org/stable/c/e75faf01e22ec7dc671640fa0e0968964fafd2fc
- https://git.kernel.org/stable/c/1bc83a019bbe268be3526406245ec28c2458a518
- https://git.kernel.org/stable/c/2aeb805a1bcd5f27c8c0d1a9d4d653f16d1506f4
- https://git.kernel.org/stable/c/6cbbe1ba76ee7e674a86abd43009b083a45838cb
- https://git.kernel.org/stable/c/7f609f630951b624348373cef99991ce08831927
- https://git.kernel.org/stable/c/9627fd0c6ea1c446741a33e67bc5709c59923827
- https://git.kernel.org/stable/c/9a3b90904d8a072287480eed4c3ece4b99d64f78
- https://git.kernel.org/stable/c/b58d0ac35f6d75ec1db8650a29dfd6f292c11362
- https://git.kernel.org/stable/c/e75faf01e22ec7dc671640fa0e0968964fafd2fc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
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: 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-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: 2024-12-30
CVE-2024-35922
In the Linux kernel, the following vulnerability has been resolved: fbmon: prevent division by zero in fb_videomode_from_videomode() The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode(). Found by Linux Verification Center (linuxtesting.org) with Svace.
- https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4
- https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f
- https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33
- https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029
- https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971
- https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270
- https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0
- https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126
- https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4
- https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f
- https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33
- https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029
- https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971
- https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270
- https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0
- https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126
- 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-31
CVE-2024-35925
In the Linux kernel, the following vulnerability has been resolved: block: prevent division by zero in blk_rq_stat_sum() The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero. Found by Linux Verification Center (linuxtesting.org) with Svace.
- https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8
- https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854
- https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe
- https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7
- https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02
- https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68
- https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c
- https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14
- https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8
- https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854
- https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe
- https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7
- https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02
- https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68
- https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c
- https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14
- 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-35930
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.
- https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf
- https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b
- https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f
- https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7
- https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a
- https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8
- https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8
- https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f
- https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf
- https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b
- https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f
- https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7
- https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a
- https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8
- https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8
- https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2026-01-05
CVE-2024-35933
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Fix null ptr deref in btintel_read_version If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue.
- https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e
- https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912
- https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645
- https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b
- https://git.kernel.org/stable/c/006936ecb4edfc3102464044f75858c714e34d28
- https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e
- https://git.kernel.org/stable/c/68a69bb2ecafaacdb998a87783068fb51736f43b
- https://git.kernel.org/stable/c/86e9b47e8a75c74b1bd83a479979b425c5dc8bd9
- https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912
- https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645
- https://git.kernel.org/stable/c/ec2049fb2b8be3e108fe2ef1f1040f91e72c9990
- https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b
- 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-35934
In the Linux kernel, the following vulnerability has been resolved: net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list() Many syzbot reports show extreme rtnl pressure, and many of them hint that smc acquires rtnl in netns creation for no good reason [1] This patch returns early from smc_pnet_net_init() if there is no netdevice yet. I am not even sure why smc_pnet_create_pnetids_list() even exists, because smc_pnet_netdev_event() is also calling smc_pnet_add_base_pnetid() when handling NETDEV_UP event. [1] extract of typical syzbot reports 2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
- https://git.kernel.org/stable/c/00af2aa93b76b1bade471ad0d0525d4d29ca5cc0
- https://git.kernel.org/stable/c/6e920422e7104928f760fc0e12b6d65ab097a2e7
- https://git.kernel.org/stable/c/a2e6bffc0388526ed10406040279a693d62b36ec
- https://git.kernel.org/stable/c/b9117dc783c0ab0a3866812f70e07bf2ea071ac4
- https://git.kernel.org/stable/c/bc4d1ebca11b4f194e262326bd45938e857c59d2
- https://git.kernel.org/stable/c/d7ee3bf0caf599c14db0bf4af7aacd6206ef8a23
- https://git.kernel.org/stable/c/00af2aa93b76b1bade471ad0d0525d4d29ca5cc0
- https://git.kernel.org/stable/c/6e920422e7104928f760fc0e12b6d65ab097a2e7
- https://git.kernel.org/stable/c/a2e6bffc0388526ed10406040279a693d62b36ec
- https://git.kernel.org/stable/c/b9117dc783c0ab0a3866812f70e07bf2ea071ac4
- https://git.kernel.org/stable/c/bc4d1ebca11b4f194e262326bd45938e857c59d2
- https://git.kernel.org/stable/c/d7ee3bf0caf599c14db0bf4af7aacd6206ef8a23
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-35935
In the Linux kernel, the following vulnerability has been resolved: btrfs: send: handle path ref underflow in header iterate_inode_ref() Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.
- https://git.kernel.org/stable/c/024529c27c8b4b273325a169e078337c8279e229
- https://git.kernel.org/stable/c/03938619a1e718b6168ae4528e1b0f979293f1a5
- https://git.kernel.org/stable/c/2f6174fd4ccf403b42b3d5f0d1b6b496a0e5330a
- https://git.kernel.org/stable/c/3c6ee34c6f9cd12802326da26631232a61743501
- https://git.kernel.org/stable/c/4720d590c4cb5d9ffa0060b89743651cc7e995f9
- https://git.kernel.org/stable/c/9ae356c627b493323e1433dcb27a26917668c07c
- https://git.kernel.org/stable/c/be2b6bcc936ae17f42fff6494106a5660b35d8d3
- https://git.kernel.org/stable/c/c1363ed8867b81ea169fba2ccc14af96a85ed183
- https://git.kernel.org/stable/c/024529c27c8b4b273325a169e078337c8279e229
- https://git.kernel.org/stable/c/03938619a1e718b6168ae4528e1b0f979293f1a5
- https://git.kernel.org/stable/c/2f6174fd4ccf403b42b3d5f0d1b6b496a0e5330a
- https://git.kernel.org/stable/c/3c6ee34c6f9cd12802326da26631232a61743501
- https://git.kernel.org/stable/c/4720d590c4cb5d9ffa0060b89743651cc7e995f9
- https://git.kernel.org/stable/c/9ae356c627b493323e1433dcb27a26917668c07c
- https://git.kernel.org/stable/c/be2b6bcc936ae17f42fff6494106a5660b35d8d3
- https://git.kernel.org/stable/c/c1363ed8867b81ea169fba2ccc14af96a85ed183
- 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-35936
In the Linux kernel, the following vulnerability has been resolved: btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions: - at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1 - after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints
- https://git.kernel.org/stable/c/0d23b34c68c46cd225b55868bc8a269e3134816d
- https://git.kernel.org/stable/c/1f9212cdbd005bc55f2b7422e7b560d9c02bd1da
- https://git.kernel.org/stable/c/36c2a2863bc3896243eb724dc3fd4cf9aea633f2
- https://git.kernel.org/stable/c/576164bd01bd795f8b09fb194b493103506b33c9
- https://git.kernel.org/stable/c/7411055db5ce64f836aaffd422396af0075fdc99
- https://git.kernel.org/stable/c/87299cdaae757f3f41212146cfb5b3af416b8385
- https://git.kernel.org/stable/c/bebd9e0ff90034875c5dfe4bd514fd7055fc7a89
- https://git.kernel.org/stable/c/d1ffa4ae2d591fdd40471074e79954ec45f147f7
- https://git.kernel.org/stable/c/0d23b34c68c46cd225b55868bc8a269e3134816d
- https://git.kernel.org/stable/c/1f9212cdbd005bc55f2b7422e7b560d9c02bd1da
- https://git.kernel.org/stable/c/36c2a2863bc3896243eb724dc3fd4cf9aea633f2
- https://git.kernel.org/stable/c/576164bd01bd795f8b09fb194b493103506b33c9
- https://git.kernel.org/stable/c/7411055db5ce64f836aaffd422396af0075fdc99
- https://git.kernel.org/stable/c/87299cdaae757f3f41212146cfb5b3af416b8385
- https://git.kernel.org/stable/c/bebd9e0ff90034875c5dfe4bd514fd7055fc7a89
- https://git.kernel.org/stable/c/d1ffa4ae2d591fdd40471074e79954ec45f147f7
- 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-35940
In the Linux kernel, the following vulnerability has been resolved: pstore/zone: Add a null pointer check to the psz_kmsg_read 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/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb
- https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682
- https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc
- https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8
- https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041
- https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70
- https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb
- https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682
- https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc
- https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8
- https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041
- https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-35944
In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() Syzkaller hit 'WARNING in dg_dispatch_as_host' bug. memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg" at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24) WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237 Some code commentry, based on my understanding: 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size) /// This is 24 + payload_size memcpy(&dg_info->msg, dg, dg_size); Destination = dg_info->msg ---> this is a 24 byte structure(struct vmci_datagram) Source = dg --> this is a 24 byte structure (struct vmci_datagram) Size = dg_size = 24 + payload_size {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32. 35 struct delayed_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg and msg_payload must be together. */ 40 struct vmci_datagram msg; 41 u8 msg_payload[]; 42 }; So those extra bytes of payload are copied into msg_payload[], a run time warning is seen while fuzzing with Syzkaller. One possible way to fix the warning is to split the memcpy() into two parts -- one -- direct assignment of msg and second taking care of payload. Gustavo quoted: "Under FORTIFY_SOURCE we should not copy data across multiple members in a structure."
- https://git.kernel.org/stable/c/130b0cd064874e0d0f58e18fb00e6f3993e90c74
- https://git.kernel.org/stable/c/19b070fefd0d024af3daa7329cbc0d00de5302ec
- https://git.kernel.org/stable/c/491a1eb07c2bd8841d63cb5263455e185be5866f
- https://git.kernel.org/stable/c/ad78c5047dc4076d0b3c4fad4f42ffe9c86e8100
- https://git.kernel.org/stable/c/dae70a57565686f16089737adb8ac64471570f73
- https://git.kernel.org/stable/c/e87bb99d2df6512d8ee37a5d63d2ca9a39a8c051
- https://git.kernel.org/stable/c/f15eca95138b3d4ec17b63c3c1937b0aa0d3624b
- https://git.kernel.org/stable/c/feacd430b42bbfa9ab3ed9e4f38b86c43e348c75
- https://git.kernel.org/stable/c/130b0cd064874e0d0f58e18fb00e6f3993e90c74
- https://git.kernel.org/stable/c/19b070fefd0d024af3daa7329cbc0d00de5302ec
- https://git.kernel.org/stable/c/491a1eb07c2bd8841d63cb5263455e185be5866f
- https://git.kernel.org/stable/c/ad78c5047dc4076d0b3c4fad4f42ffe9c86e8100
- https://git.kernel.org/stable/c/dae70a57565686f16089737adb8ac64471570f73
- https://git.kernel.org/stable/c/e87bb99d2df6512d8ee37a5d63d2ca9a39a8c051
- https://git.kernel.org/stable/c/f15eca95138b3d4ec17b63c3c1937b0aa0d3624b
- https://git.kernel.org/stable/c/feacd430b42bbfa9ab3ed9e4f38b86c43e348c75
- 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-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-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
Modified: 2026-01-22
CVE-2025-38670
In the Linux kernel, the following vulnerability has been resolved: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SP_EL0), clobbering it. In `call_on_irq_stack()`, it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls `call_on_irq_stack()` and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use ! This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK or FPAC if enabled. This is possible on a default config, but unlikely. However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very* frequently depending on the system configuration and workload, leading to unpredictable kernel panics. Completely mask DAIF in `cpu_switch_to()` and restore it when returning. Do the same in `call_on_irq_stack()`, but restore and mask around the branch. Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency of behaviour between all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF.
- https://git.kernel.org/stable/c/0f67015d72627bad72da3c2084352e0aa134416b
- https://git.kernel.org/stable/c/407047893a64399f2d2390ff35cc6061107d805d
- https://git.kernel.org/stable/c/708fd522b86d2a9544c34ec6a86fa3fc23336525
- https://git.kernel.org/stable/c/9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61
- https://git.kernel.org/stable/c/a6b0cb523eaa01efe8a3f76ced493ba60674c6e6
- https://git.kernel.org/stable/c/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
- https://git.kernel.org/stable/c/f7e0231eeaa33245c649fac0303cf97209605446
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
