ALT-BU-2024-5085-4
Branch c9f2 update bulletin.
Package kernel-image-std-def updated to version 5.10.214-alt0.c9f.2 for branch c9f2 in task 343709.
Closed vulnerabilities
Modified: 2025-12-08
BDU:2023-09024
Уязвимость функции __nvmet_req_complete() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-08
BDU:2023-09026
Уязвимость функции nvmet_tcp_build_pdu_iovec() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-00474
Уязвимость функции nf_tables_newtable() ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-08-19
BDU:2024-00674
Уязвимость функции tls_sw_sendmsg_splice (/net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-11
BDU:2024-00738
Уязвимость функции xenvif_get_requests() кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-00985
Уязвимость функции hugetlbfs_fill_super системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2026-01-20
BDU:2024-01590
Уязвимость функции f2fs_rename() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-12-05
BDU:2024-01667
Уязвимость функции of_syscon_register драйвера MFD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01669
Уязвимость функции kv_parse_power_table компонента PM Driver ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-10-24
BDU:2024-01673
Уязвимость функции smb2_parse_contexts() в модуле fs/smb/client/smb2pdu.c клиента SMB ядра операционной системы Linux , позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01695
Уязвимость функции radeon_crtc_init драйвера видеокарт AMD Radeon ядра операционной системы 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-01833
Уязвимость функции omap8250_remove() в модуле drivers/tty/serial/8250/8250_omap.c драйвера последовательного интерфейса 8250 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2025-10-24
BDU:2024-01834
Уязвимость функции vgic_its_check_cache() в модуле arch/arm64/kvm/vgic/vgic-its.c подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01837
Уязвимость функции thunderx_ocx_com_threaded_isr() в модуле drivers/edac/thunderx_edac.c драйвера EDAC (Error Detection and Correction) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01838
Уязвимость функции pvr2_context_disconnect() в модуле drivers/media/usb/pvrusb2/pvrusb2-context.c драйвера Hauppauge WinTV-PVR USB2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01840
Уязвимость функции mlxsw_sp_acl_tcam_init() в модуле drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c драйвера сетевых карт Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
Modified: 2025-01-29
BDU:2024-01842
Уязвимость функции rmnet_fill_info() в модуле drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c реализации протокола MAP (Multiplexing and Aggregation Protocol) драйвера сетевых карт Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-10
BDU:2024-01843
Уязвимость функции imx_uart_stop_tx() в модуле drivers/tty/serial/imx.c драйвера последовательных устройств Motorolla IMX ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01848
Уязвимость функции gfs2_rgrp_dump() в модуле fs/gfs2/rgrp.c файловой системы gfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01849
Уязвимость функции efivarfs_reconfigure() в модуле fs/efivarfs/super.c файловой системы EFI Variable Filesystem ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-01851
Уязвимость функции bpf_map_put() в модуле kernel/bpf/syscall.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-09
BDU:2024-01852
Уязвимость функции dlpar_memory_remove_by_index() драйвера управления памятью powerpc pseries ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-04
BDU:2024-01853
Уязвимость функции ext4_mb_generate_buddy() в модуле fs/ext4/mballoc.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-04
BDU:2024-01858
Уязвимость драйвера MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-01860
Уязвимость функции nvmet_tcp_build_pdu_iovec() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы 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-19
BDU:2024-01865
Уязвимость функции check_stack_write_fixed_off() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
Modified: 2025-01-29
BDU:2024-01867
Уязвимость функции unpack_profile() в модуле security/apparmor/policy_unpack.c модуля безопасности AppArmor ядра операционной системы 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: 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-01-29
BDU:2024-03652
Уязвимость функции ip6_tnl_parse_tlv_enc_lim() в модуле 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-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: 2026-01-20
BDU:2024-03704
Уязвимость функции __f2fs_setxattr() в модуле fs/f2fs/xattr.c файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-03705
Уязвимость функции binder_alloc_free_page() в модуле drivers/android/binder_alloc.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03706
Уязвимость функции uio_open() в модуле drivers/uio/uio.c драйвера uio ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-03708
Уязвимость функции ip_tunnel_rcv() в модуле net/ipv4/ip_tunnel.c реализации протокола IPv4 ядра операционной системы 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-10-24
BDU:2024-03941
Уязвимость функции io_uring_get_file() подсистемы io_uring ядра Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-04137
Уязвимость функции tomoyo_write_control() подсистемы безопасности TOMOYO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 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-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-06911
Уязвимость функции opal_powercap_init() компонента arch/powerpc/platforms/powernv/opal-powercap.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06912
Уязвимость компонента dtSearch ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-02-06
BDU:2024-07646
Уязвимость функции nft_chain_filter компонента Netfilter ядра операционной системы 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-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-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-03-21
BDU:2024-09207
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09208
Уязвимость компонента stm32 ядра операционной системы 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-02-25
BDU:2024-09722
Уязвимость компонента tpd12s015 ядра операционной системы 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-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-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-05-06
BDU:2024-09856
Уязвимость компонента wilc1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09858
Уязвимость компонента rtnetlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09919
Уязвимость компонента LPIT ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2024-09921
Уязвимость компонента of ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09927
Уязвимость компонентов powerpc/imc-pmu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09931
Уязвимость компонента mvpp2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09945
Уязвимость компонентов drm/lima ядра операционной системы 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-02-24
BDU:2024-10028
Уязвимость компонента calipso ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10029
Уязвимость компонента ACPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10031
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10032
Уязвимость компонента powerpc/powernv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10033
Уязвимость компонентов powerpc/powernv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10034
Уязвимость компонента tc358743 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10739
Уязвимость компонента libertas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2025-00163
Уязвимость функции jfs_mount() в модуле fs/jfs/jfs_mount.c файловой системы jfs ядра операционной системы 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: 2025-08-07
BDU:2025-08239
Уязвимость функции scomp_acomp_comp_decomp() модуля crypto/scompress.c криптографической подсистемы ядра операционной системы 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-14584
Уязвимость функции binder_update_page_range() модуля drivers/android/binder_alloc.c драйвера поддержки связи с Android ядра операционной системы 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-46838
Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code.
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://xenbits.xenproject.org/xsa/advisory-448.html
- http://xenbits.xen.org/xsa/advisory-448.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://xenbits.xenproject.org/xsa/advisory-448.html
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-52436
In the Linux kernel, the following vulnerability has been resolved: f2fs: explicitly null-terminate the xattr list When setting an xattr, explicitly null-terminate the xattr list. This eliminates the fragile assumption that the unused xattr space is always zeroed.
- https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a
- https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135
- https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36
- https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11
- https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52
- https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a
- https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564
- https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea
- https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a
- https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135
- https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36
- https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11
- https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52
- https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a
- https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564
- https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52438
In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in shinker's callback The mmap read lock is used during the shrinker's callback, which means that using alloc->vma pointer isn't safe as it can race with munmap(). As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") the mmap lock is downgraded after the vma has been isolated. I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker's debug sysfs. The following KASAN report confirms the UAF: ================================================================== BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8 Read of size 8 at addr ffff356ed50e50f0 by task bash/478 CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 Hardware name: linux,dummy-virt (DT) Call trace: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Allocated by task 492: kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Freed by task 491: kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 Last potentially related work creation: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c Fix this issue by performing instead a vma_lookup() which will fail to find the vma that was isolated before the mmap lock downgrade. Note that this option has better performance than upgrading to a mmap write lock which would increase contention. Plus, mmap_write_trylock() has been recently removed anyway.
- https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906
- https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6
- https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56
- https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869
- https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3
- https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c
- https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727
- https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906
- https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6
- https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56
- https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869
- https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3
- https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c
- https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-12-27
CVE-2023-52439
In the Linux kernel, the following vulnerability has been resolved: uio: Fix use-after-free in uio_open core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.
- https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2
- https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea
- https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c
- https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad
- https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7
- https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570
- https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41
- https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50
- https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2
- https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea
- https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c
- https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad
- https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7
- https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570
- https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41
- https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241227-0006/
Modified: 2024-11-21
CVE-2023-52443
In the Linux kernel, the following vulnerability has been resolved:
apparmor: avoid crash when parsed profile name is empty
When processing a packed profile in unpack_profile() described like
"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().
aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
- https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4
- https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf
- https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200
- https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203
- https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87
- https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e
- https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e
- https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45
- https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4
- https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf
- https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200
- https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203
- https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87
- https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e
- https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e
- https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52444
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail]
- https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46
- https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862
- https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28
- https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024
- https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310
- https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728
- https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7
- https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77
- https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46
- https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862
- https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28
- https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024
- https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310
- https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728
- https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7
- https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52445
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack.
- https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795
- https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e
- https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb
- https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c
- https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d
- https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1
- https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08
- https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab
- https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795
- https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e
- https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb
- https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c
- https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d
- https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1
- https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08
- https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-52448
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that.
- https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05
- https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37
- https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa
- https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a
- https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a
- https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178
- https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde
- https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05
- https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37
- https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa
- https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a
- https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a
- https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178
- https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52449
In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME.
- https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8
- https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745
- https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5
- https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6
- https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022
- https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc
- https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65
- https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c
- https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8
- https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745
- https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5
- https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6
- https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022
- https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc
- https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65
- https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52451
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry.
- https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0
- https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc
- https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d
- https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7
- https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e
- https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c
- https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5
- https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e
- https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0
- https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc
- https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d
- https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7
- https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e
- https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c
- https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5
- https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52454
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq().
- https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88
- https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42
- https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d
- https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68
- https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d
- https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be
- https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510
- https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88
- https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42
- https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d
- https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68
- https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d
- https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be
- https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52456
In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND.
- https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06
- https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda
- https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181
- https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0
- https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b
- https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19
- https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06
- https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda
- https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181
- https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0
- https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b
- https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52457
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup.
- https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130b0af690
- https://git.kernel.org/stable/c/887a558d0298d36297daea039954c39940228d9b
- https://git.kernel.org/stable/c/95e4e0031effad9837af557ecbfd4294a4d8aeee
- https://git.kernel.org/stable/c/ad90d0358bd3b4554f243a425168fc7cebe7d04e
- https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93
- https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0
- https://git.kernel.org/stable/c/d74173bda29aba58f822175d983d07c8ed335494
- https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130b0af690
- https://git.kernel.org/stable/c/887a558d0298d36297daea039954c39940228d9b
- https://git.kernel.org/stable/c/95e4e0031effad9837af557ecbfd4294a4d8aeee
- https://git.kernel.org/stable/c/ad90d0358bd3b4554f243a425168fc7cebe7d04e
- https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93
- https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0
- https://git.kernel.org/stable/c/d74173bda29aba58f822175d983d07c8ed335494
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52462
In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper.
- https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef
- https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036
- https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf
- https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174
- https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae
- https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104
- https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef
- https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036
- https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf
- https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174
- https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae
- https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52463
In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime.
- https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737
- https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe
- https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826
- https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8
- https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548
- https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b
- https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737
- https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe
- https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826
- https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8
- https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548
- https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52464
In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ]
- https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5
- https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8
- https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6
- https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
- https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21
- https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601
- https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398
- https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057
- https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5
- https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8
- https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6
- https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
- https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21
- https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601
- https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398
- https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52467
In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c
- https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1
- https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001
- https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973
- https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875
- https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b
- https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c
- https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1
- https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001
- https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973
- https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875
- https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52469
In the Linux kernel, the following vulnerability has been resolved: drivers/amd/pm: fix a use-after-free in kv_parse_power_table When ps allocated by kzalloc equals to NULL, kv_parse_power_table frees adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call chains: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its first free in kv_parse_power_table and causes a use-after-free bug.
- https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743
- https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02
- https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706
- https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3
- https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e
- https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63
- https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3
- https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a
- https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743
- https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02
- https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706
- https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3
- https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e
- https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63
- https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3
- https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52470
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() check the alloc_workqueue return value in radeon_crtc_init() to avoid null-ptr-deref.
- https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088
- https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1
- https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41
- https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb
- https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4
- https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310
- https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85
- https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97
- https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088
- https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1
- https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41
- https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb
- https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4
- https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310
- https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85
- https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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: 2025-03-10
CVE-2023-52609
In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then. In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A.
- https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097
- https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3
- https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e
- https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01
- https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918
- https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608
- https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9
- https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5
- https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097
- https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3
- https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e
- https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01
- https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918
- https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608
- https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9
- https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-27
CVE-2023-52612
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.
- https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe
- https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e
- https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5
- https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883
- https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131
- https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759
- https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625
- https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76
- https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe
- https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e
- https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5
- https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883
- https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131
- https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759
- https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625
- https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-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-03-04
CVE-2023-52675
In the Linux kernel, the following vulnerability has been resolved: powerpc/imc-pmu: Add a null pointer check in update_events_in_group() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/024352f7928b28f53609660663329d8c0f4ad032
- https://git.kernel.org/stable/c/0a233867a39078ebb0f575e2948593bbff5826b3
- https://git.kernel.org/stable/c/1e80aa25d186a7aa212df5acd8c75f55ac8dae34
- https://git.kernel.org/stable/c/5a669f3511d273c8c1ab1c1d268fbcdf53fc7a05
- https://git.kernel.org/stable/c/75fc599bcdcb1de093c9ced2e3cccc832f3787f3
- https://git.kernel.org/stable/c/a2da3f9b1a1019c887ee1d164475a8fcdb0a3fec
- https://git.kernel.org/stable/c/c7d828e12b326ea50fb80c369d7aa87519ed14c6
- https://git.kernel.org/stable/c/f105c263009839d80fad6998324a4e1b3511cba0
- https://git.kernel.org/stable/c/024352f7928b28f53609660663329d8c0f4ad032
- https://git.kernel.org/stable/c/0a233867a39078ebb0f575e2948593bbff5826b3
- https://git.kernel.org/stable/c/1e80aa25d186a7aa212df5acd8c75f55ac8dae34
- https://git.kernel.org/stable/c/5a669f3511d273c8c1ab1c1d268fbcdf53fc7a05
- https://git.kernel.org/stable/c/75fc599bcdcb1de093c9ced2e3cccc832f3787f3
- https://git.kernel.org/stable/c/a2da3f9b1a1019c887ee1d164475a8fcdb0a3fec
- https://git.kernel.org/stable/c/c7d828e12b326ea50fb80c369d7aa87519ed14c6
- https://git.kernel.org/stable/c/f105c263009839d80fad6998324a4e1b3511cba0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-01-10
CVE-2023-52679
In the Linux kernel, the following vulnerability has been resolved: of: Fix double free in of_parse_phandle_with_args_map In of_parse_phandle_with_args_map() the inner loop that iterates through the map entries calls of_node_put(new) to free the reference acquired by the previous iteration of the inner loop. This assumes that the value of "new" is NULL on the first iteration of the inner loop. Make sure that this is true in all iterations of the outer loop by setting "new" to NULL after its value is assigned to "cur". Extend the unittest to detect the double free and add an additional test case that actually triggers this path.
- https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db
- https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21
- https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b
- https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2
- https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8
- https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd
- https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7
- https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea
- https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db
- https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21
- https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b
- https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2
- https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8
- https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd
- https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7
- https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2023-52683
In the Linux kernel, the following vulnerability has been resolved: ACPI: LPIT: Avoid u32 multiplication overflow In lpit_update_residency() there is a possibility of overflow in multiplication, if tsc_khz is large enough (> UINT_MAX/1000). Change multiplication to mul_u32_u32(). Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/56d2eeda87995245300836ee4dbd13b002311782
- https://git.kernel.org/stable/c/647d1d50c31e60ef9ccb9756a8fdf863329f7aee
- https://git.kernel.org/stable/c/6c38e791bde07d6ca2a0a619ff9b6837e0d5f9ad
- https://git.kernel.org/stable/c/72222dfd76a79d9666ab3117fcdd44ca8cd0c4de
- https://git.kernel.org/stable/c/b7aab9d906e2e252a7783f872406033ec49b6dae
- https://git.kernel.org/stable/c/c1814a4ffd016ce5392c6767d22ef3aa2f0d4bd1
- https://git.kernel.org/stable/c/d1ac288b2742aa4af746c5613bac71760fadd1c4
- https://git.kernel.org/stable/c/f39c3d578c7d09a18ceaf56750fc7f20b02ada63
- https://git.kernel.org/stable/c/56d2eeda87995245300836ee4dbd13b002311782
- https://git.kernel.org/stable/c/647d1d50c31e60ef9ccb9756a8fdf863329f7aee
- https://git.kernel.org/stable/c/6c38e791bde07d6ca2a0a619ff9b6837e0d5f9ad
- https://git.kernel.org/stable/c/72222dfd76a79d9666ab3117fcdd44ca8cd0c4de
- https://git.kernel.org/stable/c/b7aab9d906e2e252a7783f872406033ec49b6dae
- https://git.kernel.org/stable/c/c1814a4ffd016ce5392c6767d22ef3aa2f0d4bd1
- https://git.kernel.org/stable/c/d1ac288b2742aa4af746c5613bac71760fadd1c4
- https://git.kernel.org/stable/c/f39c3d578c7d09a18ceaf56750fc7f20b02ada63
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-04
CVE-2023-52686
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_event_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/8422d179cf46889c15ceff9ede48c5bfa4e7f0b4
- https://git.kernel.org/stable/c/8649829a1dd25199bbf557b2621cedb4bf9b3050
- https://git.kernel.org/stable/c/9a523e1da6d88c2034f946adfa4f74b236c95ca9
- https://git.kernel.org/stable/c/a14c55eb461d630b836f80591d8caf1f74e62877
- https://git.kernel.org/stable/c/c0b111ea786ddcc8be0682612830796ece9436c7
- https://git.kernel.org/stable/c/e08c2e275fa1874de945b87093f925997722ee42
- https://git.kernel.org/stable/c/e6ad05e3ae9c84c5a71d7bb2d44dc845ae7990cf
- https://git.kernel.org/stable/c/e93d7cf4c1ddbcd846739e7ad849f955a4f18031
- https://git.kernel.org/stable/c/8422d179cf46889c15ceff9ede48c5bfa4e7f0b4
- https://git.kernel.org/stable/c/8649829a1dd25199bbf557b2621cedb4bf9b3050
- https://git.kernel.org/stable/c/9a523e1da6d88c2034f946adfa4f74b236c95ca9
- https://git.kernel.org/stable/c/a14c55eb461d630b836f80591d8caf1f74e62877
- https://git.kernel.org/stable/c/c0b111ea786ddcc8be0682612830796ece9436c7
- https://git.kernel.org/stable/c/e08c2e275fa1874de945b87093f925997722ee42
- https://git.kernel.org/stable/c/e6ad05e3ae9c84c5a71d7bb2d44dc845ae7990cf
- https://git.kernel.org/stable/c/e93d7cf4c1ddbcd846739e7ad849f955a4f18031
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-03-04
CVE-2023-52690
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check to scom_debug_init_one() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Add a null pointer check, and release 'ent' to avoid memory leaks.
- https://git.kernel.org/stable/c/1eefa93faf69188540b08b024794fa90b1d82e8b
- https://git.kernel.org/stable/c/2a82c4439b903639e0a1f21990cd399fb0a49c19
- https://git.kernel.org/stable/c/9a260f2dd827bbc82cc60eb4f4d8c22707d80742
- https://git.kernel.org/stable/c/a9c05cbb6644a2103c75b6906e9dafb9981ebd13
- https://git.kernel.org/stable/c/dd8422ff271c22058560832fc3006324ded895a9
- https://git.kernel.org/stable/c/ed8d023cfa97b559db58c0e1afdd2eec7a83d8f2
- https://git.kernel.org/stable/c/f84c1446daa552e9699da8d1f8375eac0f65edc7
- https://git.kernel.org/stable/c/1eefa93faf69188540b08b024794fa90b1d82e8b
- https://git.kernel.org/stable/c/2a82c4439b903639e0a1f21990cd399fb0a49c19
- https://git.kernel.org/stable/c/9a260f2dd827bbc82cc60eb4f4d8c22707d80742
- https://git.kernel.org/stable/c/a9c05cbb6644a2103c75b6906e9dafb9981ebd13
- https://git.kernel.org/stable/c/dd8422ff271c22058560832fc3006324ded895a9
- https://git.kernel.org/stable/c/ed8d023cfa97b559db58c0e1afdd2eec7a83d8f2
- https://git.kernel.org/stable/c/f84c1446daa552e9699da8d1f8375eac0f65edc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-01-10
CVE-2023-52691
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix a double-free in si_dpm_init When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered.
- https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706
- https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334
- https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30
- https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4
- https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0
- https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a
- https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2
- https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9
- https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706
- https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334
- https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30
- https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4
- https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0
- https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a
- https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2
- https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2023-52693
In the Linux kernel, the following vulnerability has been resolved: ACPI: video: check for error while searching for backlight device parent If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device. Check acpi_get_parent() result and set parent device only in case of success. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3
- https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95
- https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c
- https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af
- https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8
- https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852df0f15f
- https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f
- https://git.kernel.org/stable/c/ccd45faf4973746c4f30ea41eec864e5cf191099
- https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3
- https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95
- https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c
- https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af
- https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8
- https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852df0f15f
- https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f
- https://git.kernel.org/stable/c/ccd45faf4973746c4f30ea41eec864e5cf191099
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2023-52694
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function With tpd12s015_remove() marked with __exit this function is discarded when the driver is compiled as a built-in. The result is that when the driver unbinds there is no cleanup done which results in resource leakage or worse.
- https://git.kernel.org/stable/c/08ccff6ece35f08e8107e975903c370d849089e5
- https://git.kernel.org/stable/c/53926e2a39629702f7f809d614b3ca89c2478205
- https://git.kernel.org/stable/c/81f1bd85960b7a089a91e679ff7cd2524390bbf1
- https://git.kernel.org/stable/c/a8657406e12aa10412134622c58977ac657f16d2
- https://git.kernel.org/stable/c/ce3e112e7ae854249d8755906acc5f27e1542114
- https://git.kernel.org/stable/c/e00ec5901954d85b39b5f10f94e60ab9af463eb1
- https://git.kernel.org/stable/c/08ccff6ece35f08e8107e975903c370d849089e5
- https://git.kernel.org/stable/c/53926e2a39629702f7f809d614b3ca89c2478205
- https://git.kernel.org/stable/c/81f1bd85960b7a089a91e679ff7cd2524390bbf1
- https://git.kernel.org/stable/c/a8657406e12aa10412134622c58977ac657f16d2
- https://git.kernel.org/stable/c/ce3e112e7ae854249d8755906acc5f27e1542114
- https://git.kernel.org/stable/c/e00ec5901954d85b39b5f10f94e60ab9af463eb1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-04-07
CVE-2023-52696
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_powercap_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664
- https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219
- https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc
- https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1
- https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab
- https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d
- https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0
- https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664
- https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219
- https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc
- https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1
- https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab
- https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d
- https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-01-07
CVE-2023-52698
In the Linux kernel, the following vulnerability has been resolved: calipso: fix memory leak in netlbl_calipso_add_pass() If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free(). BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 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: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller [PM: merged via the LSM tree at Jakub Kicinski request]
- https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149
- https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53
- https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031
- https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01
- https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da
- https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded
- https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99
- https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c
- https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149
- https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53
- https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031
- https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01
- https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da
- https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded
- https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99
- https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-20
CVE-2023-6040
An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access.
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- http://www.openwall.com/lists/oss-security/2024/01/12/1
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6040
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://www.openwall.com/lists/oss-security/2024/01/12/1
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- http://www.openwall.com/lists/oss-security/2024/01/12/1
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6040
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://www.openwall.com/lists/oss-security/2024/01/12/1
Modified: 2025-11-04
CVE-2023-6356
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6356
- https://bugzilla.redhat.com/show_bug.cgi?id=2254054
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6356
- https://bugzilla.redhat.com/show_bug.cgi?id=2254054
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://security.netapp.com/advisory/ntap-20240415-0002/
Modified: 2025-11-04
CVE-2023-6536
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6536
- https://bugzilla.redhat.com/show_bug.cgi?id=2254052
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6536
- https://bugzilla.redhat.com/show_bug.cgi?id=2254052
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://security.netapp.com/advisory/ntap-20240415-0001/
Modified: 2024-11-25
CVE-2024-0646
An out-of-bounds memory write flaw was found in the Linux kernel’s Transport Layer Security functionality in how a user calls a function splice with a ktls socket as the destination. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0850
- https://access.redhat.com/errata/RHSA-2024:0851
- https://access.redhat.com/errata/RHSA-2024:0876
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1251
- https://access.redhat.com/errata/RHSA-2024:1253
- https://access.redhat.com/errata/RHSA-2024:1268
- https://access.redhat.com/errata/RHSA-2024:1269
- https://access.redhat.com/errata/RHSA-2024:1278
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1367
- https://access.redhat.com/errata/RHSA-2024:1368
- https://access.redhat.com/errata/RHSA-2024:1377
- https://access.redhat.com/errata/RHSA-2024:1382
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/security/cve/CVE-2024-0646
- https://bugzilla.redhat.com/show_bug.cgi?id=2253908
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0850
- https://access.redhat.com/errata/RHSA-2024:0851
- https://access.redhat.com/errata/RHSA-2024:0876
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1251
- https://access.redhat.com/errata/RHSA-2024:1253
- https://access.redhat.com/errata/RHSA-2024:1268
- https://access.redhat.com/errata/RHSA-2024:1269
- https://access.redhat.com/errata/RHSA-2024:1278
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1367
- https://access.redhat.com/errata/RHSA-2024:1368
- https://access.redhat.com/errata/RHSA-2024:1377
- https://access.redhat.com/errata/RHSA-2024:1382
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/security/cve/CVE-2024-0646
- https://bugzilla.redhat.com/show_bug.cgi?id=2253908
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.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: 2024-11-21
CVE-2024-26586
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b
- https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62
- https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15
- https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706
- https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182
- https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819
- https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383
- https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62
- https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15
- https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706
- https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182
- https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819
- https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.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-26597
In the Linux kernel, the following vulnerability has been resolved:
net: qualcomm: rmnet: fix global oob in rmnet_policy
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
global out-of-bounds read when parsing the netlink attributes. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5
- https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590
- https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1
- https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447
- https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468
- https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc
- https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c
- https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534
- https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5
- https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590
- https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1
- https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447
- https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468
- https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc
- https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c
- https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26598
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt.
- https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4
- https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1
- https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f
- https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703
- https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88
- https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6
- https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80
- https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4
- https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1
- https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f
- https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703
- https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88
- https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6
- https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
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-04-04
CVE-2024-26633
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim() syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken. Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage. [1] BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __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] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 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: 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_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __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] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 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_sendms ---truncated---
- https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee
- https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c
- https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d
- https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2
- https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183
- https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087
- https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198
- https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd
- https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee
- https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c
- https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d
- https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2
- https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183
- https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087
- https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198
- https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241220-0001/
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-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-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-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-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-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-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: 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-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: 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-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
