ALT-PU-2024-3291-6
Package kernel-image-un-def updated to version 6.1.79-alt0.c10f.1 for branch c10f1 in task 341306.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2023-07182
Уязвимость модуля vmwgfx ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-08958
Уязвимость функции nft_pipapo_walk() в модуле net/netfilter/nft_set_pipapo.c подсистемы Netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии в системе
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-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: 2025-02-19
BDU:2024-01186
Уязвимость функции nft_setelem_catchall_deactivate() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии
Modified: 2026-04-21
BDU:2024-01187
Уязвимость функции nft_verdict_init() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии
Modified: 2026-03-11
BDU:2024-01589
Уязвимость функции tls_decrypt_done (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-01590
Уязвимость функции f2fs_rename() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-10-24
BDU:2024-01606
Уязвимость функции ksmbd_tcp_new_connection() модуля fs/smb/server/transport_tcp.c реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы 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: 2024-11-11
BDU:2024-01681
Уязвимость функции tls_decrypt_done() модуля net/tls/tls_sw.c реализации протокола TLS (Transport Layer Security) ядра операционной системы 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-10-14
BDU:2024-01829
Уязвимость в функции sii902x_init() драйвера Silicon Image sii902x ядра операционной системы 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: 2024-11-11
BDU:2024-01835
Уязвимость функции of_pwm_single_xlate() в модуле drivers/pwm/core.c драйвера устройств PWM (ШИМ, широтно-импульсной модуляции) ядра операционной системы 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: 2024-12-04
BDU:2024-01844
Уязвимость функции bpf_tracing_prog_attach() в модуле kernel/bpf/syscall.c ядра операционной системы 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: 2025-08-19
BDU:2024-01854
Уязвимость функции restore_fpregs_from_user() в модуле arch/x86/kernel/fpu/signal.c драйвера FPU ядра операционной системы 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-10-24
BDU:2024-01862
Уязвимость реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы 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: 2026-01-20
BDU:2024-01866
Уязвимость функции adjust_ptr_min_max_vals() в модуле 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-11
BDU:2024-01924
Уязвимость функции build_insn() модуля arch/loongarch/net/bpf_jit.c компонента BPF ядра операционной системы 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: 2025-08-19
BDU:2024-03614
Уязвимость функции i2c_hid_of_probe() драйвера HID устройств шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03616
Уязвимость драйвера Intel Hardware Feedback Interface ядра операционной системы 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: 2024-05-21
BDU:2024-03624
Уязвимость функции dwc3_gadget_suspend() драйвера USB DesignWare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03650
Уязвимость функции ipv6_mc_down() в модуле net/ipv6/mcast.c реализации протокола IPv6 ядра операционной системы 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-03653
Уязвимость функции __sock_xmit() в модуле drivers/block/nbd.c драйвера nbd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-03654
Уязвимость функции default_device_exit_net() в модуле net/core/dev.c сетевой подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-03655
Уязвимость функции can_map_frag() в модуле net/ipv4/tcp.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-03656
Уязвимость функции check_for_locks() в модуле fs/nfsd/nfs4state.c сервера файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-03657
Уязвимость функции fscache_put_cache() в модуле fs/netfs/fscache_cache.c файловой системы netfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03658
Уязвимость функции bio_first_folio() в модуле include/linux/bio.h подсистемы управления блочными устройствами ядра операционной системы 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: 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-05
BDU:2024-03751
Уязвимость функции hugetlbfs_parse_param() в модуле fs/hugetlbfs/inode.c системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03940
Уязвимость функции aqc111_rx_fixup() драйвера адаптера Aquantia AQtion USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-04132
Уязвимость функции blkpg_do_ioctl() в модуле block/ioctl.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-02-27
BDU:2024-04138
Уязвимость функции vfio_ap_mdev_filter_matrix() драйвера криптографического устройства платформы IBM S/390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04139
Уязвимость функции reqsk_queue_alloc() реализации протокола TCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-04146
Уязвимость функции ksmbd_nl_policy() реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы 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: 2024-11-12
BDU:2024-06901
Уязвимость ядра операционной системы 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-02-25
BDU:2024-08413
Уязвимость компонента mhi ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации
Modified: 2025-03-21
BDU:2024-08642
Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08676
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09030
Уязвимость функции scsi_host_busy() компонента drivers/scsi/scsi_error.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09031
Уязвимость компонента fs/ntfs3 ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09032
Уязвимость функции stdev_release() компонента drivers/pci/switch/switchtec.c ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09172
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09173
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09175
Уязвимость компонента hv_netvsc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09176
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09189
Уязвимость компонента rc ядра операционной системы 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-04-29
BDU:2024-09707
Уязвимость компонентов io_uring/af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09722
Уязвимость компонента tpd12s015 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09754
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09755
Уязвимость компонента fsl-qdma ядра операционной системы 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-08-19
BDU:2024-09834
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09862
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09863
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-09919
Уязвимость компонента LPIT ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2024-09921
Уязвимость компонента of ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09923
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09925
Уязвимость в компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09927
Уязвимость компонентов powerpc/imc-pmu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09930
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09931
Уязвимость компонента mvpp2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09943
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10027
Уязвимость компонента mptcp ядра операционной системы 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-10030
Уязвимость компонента scarlett2 ядра операционной системы 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: 2024-12-03
BDU:2024-10211
Уязвимость компонента blk-mq ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10268
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10660
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю выполнить атаку методом подмены
Modified: 2025-08-19
BDU:2025-00023
Уязвимость функции stream_enc_regs() подсистемы Direct Rendering Manager (DRM) ядра операционной системы Linux ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2025-00163
Уязвимость функции jfs_mount() в модуле fs/jfs/jfs_mount.c файловой системы jfs ядра операционной системы Linux в , позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-06-09
BDU:2025-02909
Уязвимость функции fcoe_ctlr_announce() модуля drivers/scsi/fcoe/fcoe_ctlr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03617
Уязвимость функции unix_gc() модуля net/unix/garbage.c реализации сетевых функций ядра операционной системы 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-10-14
BDU:2025-03819
Уязвимость функции rkisp1_csi_disable() модуля drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03821
Уязвимость функции section_nr_to_pfn() модуля include/linux/mmzone.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-03938
Уязвимость компонента sc16is7xx.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-23
BDU:2025-04405
Уязвимость функции parse_server_interfaces() модуля fs/smb/client/smb2ops.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04548
Уязвимость функции trans_stat_show() модуля drivers/devfreq/devfreq.c - драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-04570
Уязвимость функции dev_pm_skip_resume() модуля drivers/base/power/main.c - драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06409
Уязвимость компонента wifi ядра операционной системы 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: 2025-10-24
BDU:2025-07481
Уязвимость функции aq_ptp_ring_alloc() модуля drivers/net/ethernet/aquantia/atlantic/aq_ptp.c - драйвера поддержки сетевых адаптеров Ethernet с чипсетом aQuantia Atlantic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07509
Уязвимость функции set_cluster_dirty() модуля fs/f2fs/compress.c поддержки файловой системы F2FS ядра операционной системы 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-07831
Уязвимость компонента tracing/trigger ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08236
Уязвимость функции wfx_upload_ap_templates() модуля drivers/net/wireless/silabs/wfx/sta.c - драйвера поддержки адаптеров беспроводной связи Silicon Laboratories ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-08237
Уязвимость функции drm_mode_page_flip_ioctls модуля drivers/gpu/drm/drm_plane.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-08238
Уязвимость функции shmem_fetch_notification() модуля drivers/firmware/arm_scmi/common.h - драйвера поддержки прошивок ядра операционной системы 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-10256
Уязвимость функций rcu_read_lock_held(), BPF_CALL_4() and BPF_CALL_2() (kernel/bpf/helpers.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-12942
Уязвимость компонента mediatek c ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2025-13304
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13306
Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-13309
Уязвимость компонента sc8180x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13310
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13313
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13351
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13352
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13361
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14281
Уязвимость функции tcf_ct_handle_fragments() модуля net/sched/act_ct.c ядра операционной системы 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-14290
Уязвимость функции j1939_netdev_start() модуля net/can/j1939/main.c поддержки сокетов j1939 шины CAN ядра операционной системы 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-15029
Уязвимость функции nft_limit_eval() модуля net/netfilter/nft_limit.c компонента netfilter ядра операционной системы 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-15058
Уязвимость функции tipc_nl_bearer_add() модуля net/tipc/bearer.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15084
Уязвимость функции time_travel_update_time() модуля arch/um/kernel/time.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15086
Уязвимость функции dpu_encoder_helper_phys_cleanup() модуля drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы 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-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: 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-52458
In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free.
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 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-52488
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte. The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_ versions in order to remove the manual cache control which was a workaround when using the _raw_ versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses.
- https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db
- https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573
- https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611
- https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23
- https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b
- https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169
- https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db
- https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573
- https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611
- https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23
- https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b
- https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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-02-14
CVE-2023-52494
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Add alignment check for event ring read pointer Though we do check the event ring read pointer by "is_valid_ring_ptr" to make sure it is in the buffer range, but there is another risk the pointer may be not aligned. Since we are expecting event ring elements are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer could lead to multiple issues like DoS or ring buffer memory corruption. So add a alignment check for event ring read pointer.
- https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551
- https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08
- https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010
- https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b
- https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f
- https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551
- https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08
- https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010
- https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b
- https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f
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-03-14
CVE-2023-52584
In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller.
- https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8
- https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e
- https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9
- https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e
- https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8
- https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e
- https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9
- https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e
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: 2025-02-14
CVE-2023-52588
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to tag gcing flag on page during block migration It needs to add missing gcing flag on page during block migration, in order to garantee migrated data be persisted during checkpoint, otherwise out-of-order persistency between data and node may cause data corruption after SPOR. Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag gcing flag on page during file defragment").
- https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde
- https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b
- https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c
- https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136
- https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3
- https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde
- https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b
- https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c
- https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136
- https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3
Modified: 2025-02-14
CVE-2023-52589
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ disable race issue In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup.
- https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7
- https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395
- https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe
- https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545
- https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7
- https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395
- https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe
- https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545
Modified: 2024-12-12
CVE-2023-52593
In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only.
- https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878
- https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03
- https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132
- https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d
- https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878
- https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03
- https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132
- https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d
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-02-25
CVE-2023-52608
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Check mailbox/SMT channel for consistency On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR.
- https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda
- https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306
- https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d
- https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350
- https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2
- https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda
- https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306
- https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d
- https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350
- https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2
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-03-10
CVE-2023-52610
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix skb leak and crash on ooo frags
act_ct adds skb->users before defragmentation. If frags arrive in order,
the last frag's reference is reset in:
inet_frag_reasm_prepare
skb_morph
which is not straightforward.
However when frags arrive out of order, nobody unref the last frag, and
all frags are leaked. The situation is even worse, as initiating packet
capture can lead to a crash[0] when skb has been cloned and shared at the
same time.
Fix the issue by removing skb_get() before defragmentation. act_ct
returns TC_ACT_CONSUMED when defrag failed or in progress.
[0]:
[ 843.804823] ------------[ cut here ]------------
[ 843.809659] kernel BUG at net/core/skbuff.c:2091!
[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 843.894229] PKRU: 55555554
[ 843.898539] Call Trace:
[ 843.902772]
- https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4
- https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4
- https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6
- https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97
- https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441
- https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4
- https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4
- https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6
- https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97
- https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441
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-52614
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error.
- https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c
- https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4
- https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f
- https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c
- https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8
- https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87
- https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c
- https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4
- https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f
- https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c
- https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8
- https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52615
In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user.
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-10
CVE-2023-52616
In the Linux kernel, the following vulnerability has been resolved: crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately.
- https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165
- https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6
- https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49
- https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a
- https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a
- https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598
- https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165
- https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6
- https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49
- https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a
- https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a
- https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2023-52617
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2023-52618
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present).
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-10
CVE-2023-52619
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-25
CVE-2023-52621
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
These three bpf_map_{lookup,update,delete}_elem() helpers are also
available for sleepable bpf program, so add the corresponding lock
assertion for sleepable bpf program, otherwise the following warning
will be reported when a sleepable bpf program manipulates bpf map under
interpreter mode (aka bpf_jit_enable=0):
WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
RIP: 0010:bpf_map_lookup_elem+0x54/0x60
......
Call Trace:
- https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d
- https://git.kernel.org/stable/c/3516f93cc63d956e1b290ae4b7bf2586074535a0
- https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d
- https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612
- https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304
- https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3
- https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d
- https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d
- https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304
- https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.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-04-08
CVE-2023-52631
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix an NULL dereference bug The issue here is when this is called from ntfs_load_attr_list(). The "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line.
- https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2
- https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b
- https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c
- https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6
- https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7
- https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2
- https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b
- https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c
- https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6
- https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7
Modified: 2025-03-17
CVE-2023-52632
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);
- https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4
- https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340
- https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c
- https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94
- https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4
- https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340
- https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c
- https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94
Modified: 2025-03-17
CVE-2023-52633
In the Linux kernel, the following vulnerability has been resolved: um: time-travel: fix time corruption In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled.
- https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab
- https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025
- https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c
- https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283
- https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c
- https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab
- https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025
- https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c
- https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283
- https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c
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-02-03
CVE-2023-52638
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change]
- https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170
- https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e
- https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284
- https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d
- https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf
- https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170
- https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e
- https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284
- https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d
- https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf
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-01-14
CVE-2023-52643
In the Linux kernel, the following vulnerability has been resolved: iio: core: fix memleak in iio_device_register_sysfs When iio_device_register_sysfs_group() fails, we should free iio_dev_opaque->chan_attr_group.attrs to prevent potential memleak.
- https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363
- https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2
- https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93
- https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81
- https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728
- https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363
- https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2
- https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93
- https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81
- https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728
Modified: 2025-09-18
CVE-2023-52654
In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: disable sending io_uring over sockets File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary.
- https://git.kernel.org/stable/c/18824f592aad4124d79751bbc1500ea86ac3ff29
- https://git.kernel.org/stable/c/3fe1ea5f921bf5b71cbfdc4469fb96c05936610e
- https://git.kernel.org/stable/c/5a33d385eb36991a91e3dddb189d8679e2aac2be
- https://git.kernel.org/stable/c/705318a99a138c29a512a72c3e0043b3cd7f55f4
- https://git.kernel.org/stable/c/bcedd497b3b4a0be56f3adf7c7542720eced0792
- https://git.kernel.org/stable/c/f2f57f51b53be153a522300454ddb3887722fb2c
- https://git.kernel.org/stable/c/18824f592aad4124d79751bbc1500ea86ac3ff29
- https://git.kernel.org/stable/c/3fe1ea5f921bf5b71cbfdc4469fb96c05936610e
- https://git.kernel.org/stable/c/5a33d385eb36991a91e3dddb189d8679e2aac2be
- https://git.kernel.org/stable/c/705318a99a138c29a512a72c3e0043b3cd7f55f4
- https://git.kernel.org/stable/c/bcedd497b3b4a0be56f3adf7c7542720eced0792
- https://git.kernel.org/stable/c/f2f57f51b53be153a522300454ddb3887722fb2c
Modified: 2025-09-18
CVE-2023-52655
In the Linux kernel, the following vulnerability has been resolved: usb: aqc111: check packet for fixup for true limit If a device sends a packet that is inbetween 0 and sizeof(u64) the value passed to skb_trim() as length will wrap around ending up as some very large value. The driver will then proceed to parse the header located at that position, which will either oops or process some random value. The fix is to check against sizeof(u64) rather than 0, which the driver currently does. The issue exists since the introduction of the driver.
- https://git.kernel.org/stable/c/2ebf775f0541ae0d474836fa0cf3220e502f8e3e
- https://git.kernel.org/stable/c/46412b2fb1f9cc895d6d4036bf24f640b5d86dab
- https://git.kernel.org/stable/c/82c386d73689a45d5ee8c1290827bce64056dddd
- https://git.kernel.org/stable/c/84f2e5b3e70f08fce3cb1ff73414631c5e490204
- https://git.kernel.org/stable/c/ccab434e674ca95d483788b1895a70c21b7f016a
- https://git.kernel.org/stable/c/d69581c17608d81824dd497d9a54b6a5b6139975
- https://git.kernel.org/stable/c/2ebf775f0541ae0d474836fa0cf3220e502f8e3e
- https://git.kernel.org/stable/c/46412b2fb1f9cc895d6d4036bf24f640b5d86dab
- https://git.kernel.org/stable/c/82c386d73689a45d5ee8c1290827bce64056dddd
- https://git.kernel.org/stable/c/84f2e5b3e70f08fce3cb1ff73414631c5e490204
- https://git.kernel.org/stable/c/ccab434e674ca95d483788b1895a70c21b7f016a
- https://git.kernel.org/stable/c/d69581c17608d81824dd497d9a54b6a5b6139975
Modified: 2025-01-07
CVE-2023-52664
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.
- https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d
- https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928
- https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf
- https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d
- https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d
- https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928
- https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf
- https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d
Modified: 2025-01-10
CVE-2023-52667
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a potential double-free in fs_any_create_groups When kcalloc() for ft->g succeeds but kvzalloc() for in fails, fs_any_create_groups() will free ft->g. However, its caller fs_any_create_table() will free ft->g again through calling mlx5e_destroy_flow_table(), which will lead to a double-free. Fix this by setting ft->g to NULL in fs_any_create_groups().
- https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8
- https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779
- https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1
- https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e
- https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe
- https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8
- https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779
- https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1
- https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e
- https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe
Modified: 2025-12-23
CVE-2023-52669
In the Linux kernel, the following vulnerability has been resolved: crypto: s390/aes - Fix buffer overread in CTR mode When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2023-52670
In the Linux kernel, the following vulnerability has been resolved: rpmsg: virtio: Free driver_override when rpmsg_remove() Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur: unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2023-52672
In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 ("pipe: Add general notification queue support") a
regression was introduced that would lock up resized pipes under certain
conditions. See the reproducer in [1].
The commit resizing the pipe ring size was moved to a different
function, doing that moved the wakeup for pipe->wr_wait before actually
raising pipe->max_usage. If a pipe was full before the resize occured it
would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a
watch queue.
[Christian Brauner
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2023-52674
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put() Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside scarlett2_mixer_values[].
- https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572
- https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7
- https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2
- https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810
- https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b
- https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572
- https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7
- https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2
- https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810
- https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b
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-09-25
CVE-2023-52677
In the Linux kernel, the following vulnerability has been resolved: riscv: Check if the code to patch lies in the exit section Otherwise we fall through to vmalloc_to_page() which panics since the address does not lie in the vmalloc region.
- https://git.kernel.org/stable/c/1d7a03052846f34d624d0ab41a879adf5e85c85f
- https://git.kernel.org/stable/c/420370f3ae3d3b883813fd3051a38805160b2b9f
- https://git.kernel.org/stable/c/890cfe5337e0aaf03ece1429db04d23c88da72e7
- https://git.kernel.org/stable/c/8db56df4a954b774bdc68917046a685a9fa2e4bc
- https://git.kernel.org/stable/c/938f70d14618ec72e10d6fcf8a546134136d7c13
- https://git.kernel.org/stable/c/1d7a03052846f34d624d0ab41a879adf5e85c85f
- https://git.kernel.org/stable/c/420370f3ae3d3b883813fd3051a38805160b2b9f
- https://git.kernel.org/stable/c/890cfe5337e0aaf03ece1429db04d23c88da72e7
- https://git.kernel.org/stable/c/8db56df4a954b774bdc68917046a685a9fa2e4bc
- https://git.kernel.org/stable/c/938f70d14618ec72e10d6fcf8a546134136d7c13
Modified: 2025-09-25
CVE-2023-52678
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c Before using list_first_entry, make sure to check that list is not empty, if list is empty return -ENODATA. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?
- https://git.kernel.org/stable/c/4525525cb7161d08f95d0e47025323dd10214313
- https://git.kernel.org/stable/c/499839eca34ad62d43025ec0b46b80e77065f6d8
- https://git.kernel.org/stable/c/4ac4e023ed7ab1c7c67d2d12b7b6198fcd099e5c
- https://git.kernel.org/stable/c/5024cce888e11e5688f77df81db9e14828495d64
- https://git.kernel.org/stable/c/4525525cb7161d08f95d0e47025323dd10214313
- https://git.kernel.org/stable/c/499839eca34ad62d43025ec0b46b80e77065f6d8
- https://git.kernel.org/stable/c/4ac4e023ed7ab1c7c67d2d12b7b6198fcd099e5c
- https://git.kernel.org/stable/c/5024cce888e11e5688f77df81db9e14828495d64
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-09-25
CVE-2023-52680
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add missing error checks to *_ctl_get() The *_ctl_get() functions which call scarlett2_update_*() were not checking the return value. Fix to check the return value and pass to the caller.
- https://git.kernel.org/stable/c/3a09488f4f67f7ade59b8ac62a6c7fb29439cf51
- https://git.kernel.org/stable/c/50603a67daef161c78c814580d57f7f0be57167e
- https://git.kernel.org/stable/c/773e38f73461ef2134a0d33a08f1668edde9b7c3
- https://git.kernel.org/stable/c/821fbaeaaae23d483d3df799fe91ec8045973ec3
- https://git.kernel.org/stable/c/cda7762bea857e6951315a2f7d0632ea1850ed43
- https://git.kernel.org/stable/c/3a09488f4f67f7ade59b8ac62a6c7fb29439cf51
- https://git.kernel.org/stable/c/50603a67daef161c78c814580d57f7f0be57167e
- https://git.kernel.org/stable/c/773e38f73461ef2134a0d33a08f1668edde9b7c3
- https://git.kernel.org/stable/c/821fbaeaaae23d483d3df799fe91ec8045973ec3
- https://git.kernel.org/stable/c/cda7762bea857e6951315a2f7d0632ea1850ed43
Modified: 2025-09-19
CVE-2023-52682
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A GC-Thread - f2fs_gc - do_garbage_collect - gc_data_segment - move_data_block - f2fs_submit_page_write migrate normal cluster's block via meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io IRQ old data overrides new data due to out-of-order GC and common IO. - f2fs_read_end_io
- https://git.kernel.org/stable/c/4535be48780431753505e74e1b1ad4836a189bc2
- https://git.kernel.org/stable/c/55fdc1c24a1d6229fe0ecf31335fb9a2eceaaa00
- https://git.kernel.org/stable/c/9bfd5ea71521d0e522ba581c6ccc5db93759c0c3
- https://git.kernel.org/stable/c/f904c156d8011d8291ffd5b6b398f3747e294986
- https://git.kernel.org/stable/c/4535be48780431753505e74e1b1ad4836a189bc2
- https://git.kernel.org/stable/c/55fdc1c24a1d6229fe0ecf31335fb9a2eceaaa00
- https://git.kernel.org/stable/c/9bfd5ea71521d0e522ba581c6ccc5db93759c0c3
- https://git.kernel.org/stable/c/f904c156d8011d8291ffd5b6b398f3747e294986
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-09-25
CVE-2023-52687
In the Linux kernel, the following vulnerability has been resolved: crypto: safexcel - Add error handling for dma_map_sg() calls Macro dma_map_sg() may return 0 on error. This patch enables checks in case of the macro failure and ensures unmapping of previously mapped buffers with dma_unmap_sg(). Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
- https://git.kernel.org/stable/c/4c0ac81a172a69a7733290915276672787e904ec
- https://git.kernel.org/stable/c/8084b788c2fb1260f7d44c032d5124680b20d2b2
- https://git.kernel.org/stable/c/87e02063d07708cac5bfe9fd3a6a242898758ac8
- https://git.kernel.org/stable/c/fc0b785802b856566df3ac943e38a072557001c4
- https://git.kernel.org/stable/c/4c0ac81a172a69a7733290915276672787e904ec
- https://git.kernel.org/stable/c/8084b788c2fb1260f7d44c032d5124680b20d2b2
- https://git.kernel.org/stable/c/87e02063d07708cac5bfe9fd3a6a242898758ac8
- https://git.kernel.org/stable/c/fc0b785802b856566df3ac943e38a072557001c4
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-09-25
CVE-2023-52692
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config() scarlett2_usb_set_config() calls scarlett2_usb_get() but was not checking the result. Return the error if it fails rather than continuing with an invalid value.
- https://git.kernel.org/stable/c/145c5aa51486171025ab47f35cff34bff8d0cea3
- https://git.kernel.org/stable/c/51d5697e1c0380d482c3eab002bfc8d0be177e99
- https://git.kernel.org/stable/c/996fde492ad9b9563ee483b363af40d7696a8467
- https://git.kernel.org/stable/c/be96acd3eaa790d10a5b33e65267f52d02f6ad88
- https://git.kernel.org/stable/c/ca459dfa7d4ed9098fcf13e410963be6ae9b6bf3
- https://git.kernel.org/stable/c/145c5aa51486171025ab47f35cff34bff8d0cea3
- https://git.kernel.org/stable/c/51d5697e1c0380d482c3eab002bfc8d0be177e99
- https://git.kernel.org/stable/c/996fde492ad9b9563ee483b363af40d7696a8467
- https://git.kernel.org/stable/c/be96acd3eaa790d10a5b33e65267f52d02f6ad88
- https://git.kernel.org/stable/c/ca459dfa7d4ed9098fcf13e410963be6ae9b6bf3
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-09-26
CVE-2023-52787
In the Linux kernel, the following vulnerability has been resolved: blk-mq: make sure active queue usage is held for bio_integrity_prep() blk_integrity_unregister() can come if queue usage counter isn't held for one bio with integrity prepared, so this request may be completed with calling profile->complete_fn, then kernel panic. Another constraint is that bio_integrity_prep() needs to be called before bio merge. Fix the issue by: - call bio_integrity_prep() with one queue usage counter grabbed reliably - call bio_integrity_prep() before bio merge
- https://git.kernel.org/stable/c/b0077e269f6c152e807fdac90b58caf012cdbaab
- https://git.kernel.org/stable/c/b5c8e0ff76d10f6bf70a7237678f27c20cf59bc9
- https://git.kernel.org/stable/c/b80056bd75a16e4550873ecefe12bc8fd190b1cf
- https://git.kernel.org/stable/c/e9c309ded295b7f8849097d71ae231456ca79f78
- https://git.kernel.org/stable/c/b0077e269f6c152e807fdac90b58caf012cdbaab
- https://git.kernel.org/stable/c/b5c8e0ff76d10f6bf70a7237678f27c20cf59bc9
- https://git.kernel.org/stable/c/b80056bd75a16e4550873ecefe12bc8fd190b1cf
- https://git.kernel.org/stable/c/e9c309ded295b7f8849097d71ae231456ca79f78
Modified: 2025-09-27
CVE-2023-52881
In the Linux kernel, the following vulnerability has been resolved:
tcp: do not accept ACK of bytes we never sent
This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.
ACK seq validation is currently following RFC 5961 5.2 guidelines:
The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded and an ACK sent back. It needs to
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
ACK, drop the segment, and return". The "ignored" above implies that
the processing of the incoming data segment continues, which means
the ACK value is treated as acceptable. This mitigation makes the
ACK check more stringent since any ACK < SND.UNA wouldn't be
accepted, instead only ACKs that are in the range ((SND.UNA -
MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.
This greatly improves TCP security at a little cost.
I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.
tp->bytes_acked was added in linux-4.2
Following packetdrill test (courtesy of Yepeng Pan) shows
the issue at hand:
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1024) = 0
// ---------------- Handshake ------------------- //
// when window scale is set to 14 the window size can be extended to
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
// ,though this ack number acknowledges some data never
// sent by the server.
+0 < S 0:0(0) win 65535
- https://git.kernel.org/stable/c/008b807fe487e0b15a3a6c39add4eb477f73e440
- https://git.kernel.org/stable/c/0d4e0afdd6658cd21dd5be61880411a2553fd1fc
- https://git.kernel.org/stable/c/2087d53a66e97a5eb5d1bf558d5bef9e5f891757
- https://git.kernel.org/stable/c/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27
- https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a
- https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57
- https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0
- https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c69e3c1a
- https://git.kernel.org/stable/c/008b807fe487e0b15a3a6c39add4eb477f73e440
- https://git.kernel.org/stable/c/0d4e0afdd6658cd21dd5be61880411a2553fd1fc
- https://git.kernel.org/stable/c/2087d53a66e97a5eb5d1bf558d5bef9e5f891757
- https://git.kernel.org/stable/c/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27
- https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a
- https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57
- https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0
- https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c69e3c1a
Modified: 2026-02-25
CVE-2023-5633
The reference count changes made as part of the CVE-2023-33951 and CVE-2023-33952 fixes exposed a use-after-free flaw in the way memory objects were handled when they were being used to store a surface. When running inside a VMware guest with 3D acceleration enabled, a local, unprivileged user could potentially use this flaw to escalate their privileges.
- https://access.redhat.com/errata/RHSA-2024:0113
- https://access.redhat.com/errata/RHSA-2024:0134
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-5633
- https://bugzilla.redhat.com/show_bug.cgi?id=2245663
- https://access.redhat.com/errata/RHSA-2024:0113
- https://access.redhat.com/errata/RHSA-2024:0134
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-5633
- https://bugzilla.redhat.com/show_bug.cgi?id=2245663
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: 2025-02-13
CVE-2023-6817
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free. We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- http://www.openwall.com/lists/oss-security/2023/12/22/13
- http://www.openwall.com/lists/oss-security/2023/12/22/6
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a
- https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- http://www.openwall.com/lists/oss-security/2023/12/22/13
- http://www.openwall.com/lists/oss-security/2023/12/22/6
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a
- https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
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: 2024-11-21
CVE-2024-1085
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability. We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
Modified: 2025-10-27
CVE-2024-1086
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
- http://www.openwall.com/lists/oss-security/2024/04/10/22
- http://www.openwall.com/lists/oss-security/2024/04/10/23
- http://www.openwall.com/lists/oss-security/2024/04/14/1
- http://www.openwall.com/lists/oss-security/2024/04/15/2
- http://www.openwall.com/lists/oss-security/2024/04/17/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660
- https://github.com/Notselwyn/CVE-2024-1086
- https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660
- 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/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/
- https://news.ycombinator.com/item?id=39828424
- https://pwning.tech/nftables/
- https://security.netapp.com/advisory/ntap-20240614-0009/
- http://www.openwall.com/lists/oss-security/2024/04/10/22
- http://www.openwall.com/lists/oss-security/2024/04/10/23
- http://www.openwall.com/lists/oss-security/2024/04/14/1
- http://www.openwall.com/lists/oss-security/2024/04/15/2
- http://www.openwall.com/lists/oss-security/2024/04/17/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660
- https://github.com/Notselwyn/CVE-2024-1086
- https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660
- 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/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/
- https://news.ycombinator.com/item?id=39828424
- https://pwning.tech/nftables/
- https://security.netapp.com/advisory/ntap-20240614-0009/
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-1086
Modified: 2025-10-01
CVE-2024-26581
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just added in this transactions, skip end interval elements that are not yet active.
- https://git.kernel.org/stable/c/10e9cb39313627f2eae4cd70c4b742074e998fd8
- https://git.kernel.org/stable/c/1296c110c5a0b45a8fcf58e7d18bc5da61a565cb
- https://git.kernel.org/stable/c/2bab493a5624444ec6e648ad0d55a362bcb4c003
- https://git.kernel.org/stable/c/4cee42fcf54fec46b344681e7cc4f234bb22f85a
- https://git.kernel.org/stable/c/60c0c230c6f046da536d3df8b39a20b9a9fd6af0
- https://git.kernel.org/stable/c/6eb14441f10602fa1cf691da9d685718b68b78a9
- https://git.kernel.org/stable/c/b734f7a47aeb32a5ba298e4ccc16bb0c52b6dbf7
- https://git.kernel.org/stable/c/c60d252949caf9aba537525195edae6bbabc35eb
- https://git.kernel.org/stable/c/10e9cb39313627f2eae4cd70c4b742074e998fd8
- https://git.kernel.org/stable/c/1296c110c5a0b45a8fcf58e7d18bc5da61a565cb
- https://git.kernel.org/stable/c/2bab493a5624444ec6e648ad0d55a362bcb4c003
- https://git.kernel.org/stable/c/4cee42fcf54fec46b344681e7cc4f234bb22f85a
- https://git.kernel.org/stable/c/60c0c230c6f046da536d3df8b39a20b9a9fd6af0
- https://git.kernel.org/stable/c/6eb14441f10602fa1cf691da9d685718b68b78a9
- https://git.kernel.org/stable/c/b734f7a47aeb32a5ba298e4ccc16bb0c52b6dbf7
- https://git.kernel.org/stable/c/c60d252949caf9aba537525195edae6bbabc35eb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2024-26582
In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when we try to read from the partially-read skb.
- https://git.kernel.org/stable/c/20b4ed034872b4d024b26e2bc1092c3f80e5db96
- https://git.kernel.org/stable/c/32b55c5ff9103b8508c1e04bfa5a08c64e7a925f
- https://git.kernel.org/stable/c/754c9bab77a1b895b97bd99d754403c505bc79df
- https://git.kernel.org/stable/c/d684763534b969cca1022e2a28645c7cc91f7fa5
- https://git.kernel.org/stable/c/20b4ed034872b4d024b26e2bc1092c3f80e5db96
- https://git.kernel.org/stable/c/32b55c5ff9103b8508c1e04bfa5a08c64e7a925f
- https://git.kernel.org/stable/c/754c9bab77a1b895b97bd99d754403c505bc79df
- https://git.kernel.org/stable/c/d684763534b969cca1022e2a28645c7cc91f7fa5
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-11-04
CVE-2024-26583
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.
- https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33
- https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01
- https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a
- https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d
- https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7
- https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33
- https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01
- https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a
- https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d
- https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
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: 2024-11-21
CVE-2024-26588
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Prevent out-of-bounds memory access The test_tag test triggers an unhandled page fault: # ./test_tag [ 130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Oops[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 130.642815] Modules linked in: [last unloaded: bpf_testmod(O)] [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd) [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] Call Trace: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ end trace 0000000000000000 ]--- On my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at loading a BPF prog with 2039 instructions: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated---
- https://git.kernel.org/stable/c/36a87385e31c9343af9a4756598e704741250a67
- https://git.kernel.org/stable/c/4631c2dd69d928bca396f9f58baeddf85e14ced5
- https://git.kernel.org/stable/c/7924ade13a49c0067da6ea13e398102979c0654a
- https://git.kernel.org/stable/c/9aeb09f4d85a87bac46c010d75a2ea299d462f28
- https://git.kernel.org/stable/c/36a87385e31c9343af9a4756598e704741250a67
- https://git.kernel.org/stable/c/4631c2dd69d928bca396f9f58baeddf85e14ced5
- https://git.kernel.org/stable/c/7924ade13a49c0067da6ea13e398102979c0654a
- https://git.kernel.org/stable/c/9aeb09f4d85a87bac46c010d75a2ea299d462f28
Modified: 2024-11-21
CVE-2024-26589
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.
The following prog is accepted:
func#0 @0
0: R1=ctx() R10=fp0
0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()
1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()
2: (b7) r8 = 1024 ; R8_w=1024
3: (37) r8 /= 1 ; R8_w=scalar()
4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
5: (0f) r7 += r8
mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024
mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
=(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
var_off=(0x0; 0x400))
6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()
7: (95) exit
This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:
BUG: unable to handle page fault for address: ffffc90014c80038
[...]
Call Trace:
- https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3
- https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
- https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0
- https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8
- https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d
- https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3
- https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
- https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0
- https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8
- https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d
Modified: 2024-11-21
CVE-2024-26591
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix re-attachment branch in bpf_tracing_prog_attach
The following case can cause a crash due to missing attach_btf:
1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3
In the end we have:
- prog->aux->dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one
BUG: kernel NULL pointer dereference, address: 0000000000000058
Call Trace:
- https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b
- https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0
- https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee
- https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c
- https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653
- https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b
- https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0
- https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee
- https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c
- https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653
Modified: 2024-11-21
CVE-2024-26592
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix UAF issue in ksmbd_tcp_new_connection() The race is between the handling of a new TCP connection and its disconnection. It leads to UAF on `struct tcp_transport` in ksmbd_tcp_new_connection() function.
- https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111
- https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1
- https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544
- https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126
- https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6
- https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111
- https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1
- https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544
- https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126
- https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6
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-26594
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate mech token in session setup If client send invalid mech token in session setup request, ksmbd validate and make the error if it is invalid.
- https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e
- https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9
- https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d
- https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a
- https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b
- https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e
- https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9
- https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d
- https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a
- https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b
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-26599
In the Linux kernel, the following vulnerability has been resolved: pwm: Fix out-of-bounds access in of_pwm_single_xlate() With args->args_count == 2 args->args[2] is not defined. Actually the flags are contained in args->args[1].
- https://git.kernel.org/stable/c/7b85554c7c2aee91171e038e4d5442ffa130b282
- https://git.kernel.org/stable/c/a297d07b9a1e4fb8cda25a4a2363a507d294b7c9
- https://git.kernel.org/stable/c/bae45b7ebb31984b63b13c3519fd724b3ce92123
- https://git.kernel.org/stable/c/e5f2b4b62977fb6c2efcbc5779e0c9dce18215f7
- https://git.kernel.org/stable/c/7b85554c7c2aee91171e038e4d5442ffa130b282
- https://git.kernel.org/stable/c/a297d07b9a1e4fb8cda25a4a2363a507d294b7c9
- https://git.kernel.org/stable/c/bae45b7ebb31984b63b13c3519fd724b3ce92123
- https://git.kernel.org/stable/c/e5f2b4b62977fb6c2efcbc5779e0c9dce18215f7
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-26603
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ]
- https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996
- https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda
- https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a
- https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2
- https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835
- https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996
- https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda
- https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a
- https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2
- https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
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: 2025-01-09
CVE-2024-26607
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: sii902x: Fix probing race issue A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 The issue here is as follows: - tidss probes, but is deferred as sii902x is still missing. - sii902x starts probing and enters sii902x_init(). - sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective. - sii902x calls sii902x_audio_codec_init() and platform_device_register_data() - The registration of the audio platform device causes probing of the deferred devices. - tidss probes, which eventually causes sii902x_bridge_get_edid() to be called. - sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash. Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe().
- https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9
- https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c
- https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1
- https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076
- https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9
- https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c
- https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1
- https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076
Modified: 2025-04-03
CVE-2024-26608
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix global oob in ksmbd_nl_policy
Similar to a reported issue (check the commit b33fb5b801c6 ("net:
qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds
another global out-of-bounds read for policy ksmbd_nl_policy. 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 ffffffff8f24b100 by task syz-executor.1/62810
CPU: 0 PID: 62810 Comm: syz-executor.1 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/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a
- https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95
- https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d
- https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5
- https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa
- https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a
- https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95
- https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d
- https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5
- https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa
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-26612
In the Linux kernel, the following vulnerability has been resolved: netfs, fscache: Prevent Oops in fscache_put_cache() This function dereferences "cache" and then checks if it's IS_ERR_OR_NULL(). Check first, then dereference.
- https://git.kernel.org/stable/c/1c45256e599061021e2c848952e50f406457e448
- https://git.kernel.org/stable/c/3be0b3ed1d76c6703b9ee482b55f7e01c369cc68
- https://git.kernel.org/stable/c/4200ad3e46ce50f410fdda302745489441bc70f0
- https://git.kernel.org/stable/c/82a9bc343ba019665d3ddc1d9a180bf0e0390cf3
- https://git.kernel.org/stable/c/1c45256e599061021e2c848952e50f406457e448
- https://git.kernel.org/stable/c/3be0b3ed1d76c6703b9ee482b55f7e01c369cc68
- https://git.kernel.org/stable/c/4200ad3e46ce50f410fdda302745489441bc70f0
- https://git.kernel.org/stable/c/82a9bc343ba019665d3ddc1d9a180bf0e0390cf3
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-02-14
CVE-2024-26620
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: always filter entire AP matrix The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or domain is assigned to the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not reference a queue device bound to the vfio_ap device driver, then it's APID will be filtered from the mdev's matrix when updating the guest's AP configuration. Inspecting only the APID of the new adapter or APQI of the new domain will result in passing AP queues through to a guest that are not bound to the vfio_ap device driver under certain circumstances. Consider the following: guest's AP configuration (all also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006 unassign domain 4 unbind queue 16.0005 assign domain 4 When domain 4 is re-assigned, since only domain 4 will be inspected, the APQNs that will be examined will be: 14.0004 16.0004 Since both of those APQNs reference queue devices that are bound to the vfio_ap device driver, nothing will get filtered from the mdev's matrix when updating the guest's AP configuration. Consequently, queue 16.0005 will get passed through despite not being bound to the driver. This violates the linux device model requirement that a guest shall only be given access to devices bound to the device driver facilitating their pass-through. To resolve this problem, every adapter and domain assigned to the mdev will be inspected when filtering the mdev's matrix.
- https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11
- https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a
- https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e
- https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6
- https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11
- https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a
- https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e
- https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6
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-12-23
CVE-2024-26629
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids. If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded). When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe. For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'.
- https://git.kernel.org/stable/c/10d75984495f7fe62152c3b0dbfa3f0a6b739c9b
- https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098
- https://git.kernel.org/stable/c/99fb654d01dc3f08b5905c663ad6c89a9d83302f
- https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b
- https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
- https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
- https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd
- https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098
- https://git.kernel.org/stable/c/99fb654d01dc3f08b5905c663ad6c89a9d83302f
- https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b
- https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
- https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
- https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd
Modified: 2025-03-10
CVE-2024-26631
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...
- https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155
- https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663
- https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855
- https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900
- https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c
- https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155
- https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663
- https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855
- https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900
- https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c
Modified: 2025-03-03
CVE-2024-26632
In the Linux kernel, the following vulnerability has been resolved: block: Fix iterating over an empty bio with bio_for_each_folio_all If the bio contains no data, bio_first_folio() calls page_folio() on a NULL pointer and oopses. Move the test that we've reached the end of the bio from bio_next_folio() to bio_first_folio(). [axboe: add unlikely() to error case]
- https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7
- https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659
- https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe
- https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde
- https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7
- https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659
- https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe
- https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde
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-26634
In the Linux kernel, the following vulnerability has been resolved: net: fix removing a namespace with conflicting altnames Mark reports a BUG() when a net namespace is removed. kernel BUG at net/core/dev.c:11520! Physical interfaces moved outside of init_net get "refunded" to init_net when that namespace disappears. The main interface name may get overwritten in the process if it would have conflicted. We need to also discard all conflicting altnames. Recent fixes addressed ensuring that altnames get moved with the main interface, which surfaced this problem.
- https://git.kernel.org/stable/c/8072699aa9e67d1727692cfb3c347263bb627fb9
- https://git.kernel.org/stable/c/a2232f29bf52c24f827865b3c90829c44b6c695b
- https://git.kernel.org/stable/c/d09486a04f5da0a812c26217213b89a3b1acf836
- https://git.kernel.org/stable/c/e855dded4b70d1975ee7b9fed0c700391e3c8ea6
- https://git.kernel.org/stable/c/8072699aa9e67d1727692cfb3c347263bb627fb9
- https://git.kernel.org/stable/c/a2232f29bf52c24f827865b3c90829c44b6c695b
- https://git.kernel.org/stable/c/d09486a04f5da0a812c26217213b89a3b1acf836
- https://git.kernel.org/stable/c/e855dded4b70d1975ee7b9fed0c700391e3c8ea6
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-19
CVE-2024-26638
In the Linux kernel, the following vulnerability has been resolved: nbd: always initialize struct msghdr completely syzbot complains that msg->msg_get_inq value can be uninitialized [1] struct msghdr got many new fields recently, we should always make sure their values is zero by default. [1] BUG: KMSAN: uninit-value in tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 inet_recvmsg+0x131/0x580 net/ipv4/af_inet.c:879 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x12b/0x1e0 net/socket.c:1066 __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700 worker_thread+0xf45/0x1490 kernel/workqueue.c:2781 kthread+0x3ed/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Local variable msg created at: __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 CPU: 1 PID: 7465 Comm: kworker/u5:1 Not tainted 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: nbd5-recv recv_work
- https://git.kernel.org/stable/c/1960f2b534da1e6c65fb96f9e98bda773495f406
- https://git.kernel.org/stable/c/78fbb92af27d0982634116c7a31065f24d092826
- https://git.kernel.org/stable/c/b0028f333420a65a53a63978522db680b37379dd
- https://git.kernel.org/stable/c/d9c54763e5cdbbd3f81868597fe8aca3c96e6387
- https://git.kernel.org/stable/c/1960f2b534da1e6c65fb96f9e98bda773495f406
- https://git.kernel.org/stable/c/78fbb92af27d0982634116c7a31065f24d092826
- https://git.kernel.org/stable/c/b0028f333420a65a53a63978522db680b37379dd
- https://git.kernel.org/stable/c/d9c54763e5cdbbd3f81868597fe8aca3c96e6387
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-03-17
CVE-2024-26646
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ]
- https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee
- https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566
- https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9
- https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c
- https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee
- https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566
- https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9
- https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c
Modified: 2025-03-03
CVE-2024-26660
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN301 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn301_stream_encoder_create reported by Smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5
- https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054
- https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2
- https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738
- https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d
- https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a
- https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054
- https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2
- https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738
- https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d
- https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a
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-26667
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output") introduced a smatch warning about another conditional block in dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it. Patchwork: https://patchwork.freedesktop.org/patch/574878/
- https://git.kernel.org/stable/c/79592a6e7bdc1d05460c95f891f5e5263a107af8
- https://git.kernel.org/stable/c/7f3d03c48b1eb6bc45ab20ca98b8b11be25f9f52
- https://git.kernel.org/stable/c/eb4f56f3ff5799ca754ae6d811803a63fe25a4a2
- https://git.kernel.org/stable/c/fb8bfc6ea3cd8c5ac3d35711d064e2f6646aec17
- https://git.kernel.org/stable/c/79592a6e7bdc1d05460c95f891f5e5263a107af8
- https://git.kernel.org/stable/c/7f3d03c48b1eb6bc45ab20ca98b8b11be25f9f52
- https://git.kernel.org/stable/c/eb4f56f3ff5799ca754ae6d811803a63fe25a4a2
- https://git.kernel.org/stable/c/fb8bfc6ea3cd8c5ac3d35711d064e2f6646aec17
Modified: 2025-03-17
CVE-2024-26668
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit.
- https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a
- https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1
- https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0
- https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b
- https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa
- https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a
- https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1
- https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0
- https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b
- https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa
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-05-07
CVE-2024-26676
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
syzbot reported a warning [0] in __unix_gc() with a repro, which
creates a socketpair and sends one socket's fd to itself using the
peer.
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}],
msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, cmsg_data=[3]}],
msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1
This forms a self-cyclic reference that GC should finally untangle
but does not due to lack of MSG_OOB handling, resulting in memory
leak.
Recently, commit 11498715f266 ("af_unix: Remove io_uring code for
GC.") removed io_uring's dead code in GC and revealed the problem.
The code was executed at the final stage of GC and unconditionally
moved all GC candidates from gc_candidates to gc_inflight_list.
That papered over the reported problem by always making the following
WARN_ON_ONCE(!list_empty(&gc_candidates)) false.
The problem has been there since commit 2aab4b969002 ("af_unix: fix
struct pid leaks in OOB support") added full scm support for MSG_OOB
while fixing another bug.
To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb
if the socket still exists in gc_candidates after purging collected skb.
Then, we need to set NULL to oob_skb before calling kfree_skb() because
it calls last fput() and triggers unix_release_sock(), where we call
duplicate kfree_skb(u->oob_skb) if not NULL.
Note that the leaked socket remained being linked to a global list, so
kmemleak also could not detect it. We need to check /proc/net/protocol
to notice the unfreed socket.
[0]:
WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345
Modules linked in:
CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: events_unbound __unix_gc
RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345
Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8
RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e
RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30
RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66
R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000
R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d
- https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668
- https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140
- https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276
- https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b
- https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d
- https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668
- https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140
- https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276
- https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b
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-26680
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: Fix DMA mapping for PTP hwts ring
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
for PTP HWTS ring but then generic aq_ring_free() does not take this
into account.
Create and use a specific function to free HWTS ring to fix this
issue.
Trace:
[ 215.351607] ------------[ cut here ]------------
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
...
[ 215.581176] Call Trace:
[ 215.583632]
- https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56
- https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887
- https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12
- https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1
- https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56
- https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887
- https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12
- https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1
Modified: 2025-03-17
CVE-2024-26681
In the Linux kernel, the following vulnerability has been resolved:
netdevsim: avoid potential loop in nsim_dev_trap_report_work()
Many syzbot reports include the following trace [1]
If nsim_dev_trap_report_work() can not grab the mutex,
it should rearm itself at least one jiffie later.
[1]
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Workqueue: events nsim_dev_trap_report_work
RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline]
RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline]
RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline]
RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline]
RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]
RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189
Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00
RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046
RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3
RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0
RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e
R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002
R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0193e0660cc6689c794794b471492923cfd7bfbc
- https://git.kernel.org/stable/c/6eecddd9c3c8d6e3a097531cdc6d500335b35e46
- https://git.kernel.org/stable/c/ba5e1272142d051dcc57ca1d3225ad8a089f9858
- https://git.kernel.org/stable/c/d91964cdada76740811b7c621239f9c407820dbc
- https://git.kernel.org/stable/c/0193e0660cc6689c794794b471492923cfd7bfbc
- https://git.kernel.org/stable/c/6eecddd9c3c8d6e3a097531cdc6d500335b35e46
- https://git.kernel.org/stable/c/ba5e1272142d051dcc57ca1d3225ad8a089f9858
- https://git.kernel.org/stable/c/d91964cdada76740811b7c621239f9c407820dbc
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-26706
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer.
- https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592
- https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831
- https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003
- https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2
- https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592
- https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831
- https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003
- https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2
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-26714
In the Linux kernel, the following vulnerability has been resolved: interconnect: qcom: sc8180x: Mark CO0 BCM keepalive The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases.
- https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7
- https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0
- https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0
- https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43
- https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7
- https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0
- https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0
- https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43
Modified: 2025-01-07
CVE-2024-26715
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur.
- https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182
- https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751
- https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316
- https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7
- https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b
- https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182
- https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751
- https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316
- https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7
- https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b
Modified: 2025-01-07
CVE-2024-26717
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures.
- https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f
- https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776
- https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783
- https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c
- https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3
- https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f
- https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776
- https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783
- https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c
- https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3
Modified: 2025-03-17
CVE-2024-26718
In the Linux kernel, the following vulnerability has been resolved: dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet callback frees the structure that contains the tasklet or if it calls some code that may free it, tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer from the memory corruption problem. But we need something that stops the memory corruption now and that can be backported to the stable kernels. So, I'm proposing this commit that disables tasklets in both dm-crypt and dm-verity. This commit doesn't remove the tasklet support, because the tasklet code will be reused when atomic workqueues will be implemented. [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/ [2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/
- https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189
- https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257
- https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94
- https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc
- https://git.kernel.org/stable/c/b825e0f9d68c178072bffd32dd34c39e3d2d597a
- https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189
- https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257
- https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94
- https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc
Modified: 2025-04-04
CVE-2024-26723
In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix crash when adding interface under a lag There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0 The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places.
- https://git.kernel.org/stable/c/15faa1f67ab405d47789d4702f587ec7df7ef03e
- https://git.kernel.org/stable/c/2a492f01228b7d091dfe38974ef40dccf8f9f2f1
- https://git.kernel.org/stable/c/48fae67d837488c87379f0c9f27df7391718477c
- https://git.kernel.org/stable/c/b9357489c46c7a43999964628db8b47d3a1f8672
- https://git.kernel.org/stable/c/15faa1f67ab405d47789d4702f587ec7df7ef03e
- https://git.kernel.org/stable/c/2a492f01228b7d091dfe38974ef40dccf8f9f2f1
- https://git.kernel.org/stable/c/48fae67d837488c87379f0c9f27df7391718477c
- https://git.kernel.org/stable/c/b9357489c46c7a43999964628db8b47d3a1f8672
Modified: 2025-07-10
CVE-2024-26726
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't drop extent_map for free space inode on write error
While running the CI for an unrelated change I hit the following panic
with generic/648 on btrfs_holes_spacecache.
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
Call Trace:
- https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555
- https://git.kernel.org/stable/c/143842584c1237ebc248b2547c29d16bbe400a92
- https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade
- https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7
- https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e
- https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555
- https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade
- https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7
- https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e
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-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-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-03-27
CVE-2024-26826
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data re-injection from stale subflow When the MPTCP PM detects that a subflow is stale, all the packet scheduler must re-inject all the mptcp-level unacked data. To avoid acquiring unneeded locks, it first try to check if any unacked data is present at all in the RTX queue, but such check is currently broken, as it uses TCP-specific helper on an MPTCP socket. Funnily enough fuzzers and static checkers are happy, as the accessed memory still belongs to the mptcp_sock struct, and even from a functional perspective the recovery completed successfully, as the short-cut test always failed. A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize tcp_sock fast path variables") - exposed the issue, as the tcp field reorganization makes the mptcp code always skip the re-inection. Fix the issue dropping the bogus call: we are on a slow path, the early optimization proved once again to be evil.
- https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8
- https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8
- https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2
- https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5
- https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598
- https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8
- https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8
- https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2
- https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5
- https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598
Modified: 2025-04-08
CVE-2024-26828
In the Linux kernel, the following vulnerability has been resolved: cifs: fix underflow in parse_server_interfaces() In this loop, we step through the buffer and after each item we check if the size_left is greater than the minimum size we need. However, the problem is that "bytes_left" is type ssize_t while sizeof() is type size_t. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.
- https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512
- https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204
- https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301
- https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308
- https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512
- https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204
- https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301
- https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308
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-04-02
CVE-2024-26830
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0:
- https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893
- https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc
- https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404
- https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d
- https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893
- https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc
- https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404
- https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d
Modified: 2024-11-21
CVE-2024-26910
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback.
- https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c
- https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb
- https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001
- https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05
- https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397
- https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49
- https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225
- https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c
- https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb
- https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001
- https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05
- https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397
- https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49
- https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-03
CVE-2024-26917
In the Linux kernel, the following vulnerability has been resolved: scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock" This reverts commit 1a1975551943f681772720f639ff42fbaa746212. This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave". Instead, a work queue should be used, and will be addressed in a separate commit.
- https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b
- https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21
- https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783
- https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5
- https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0
- https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b
- https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6
- https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb
- https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b
- https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21
- https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783
- https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5
- https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0
- https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b
- https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6
- https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-16
CVE-2024-26919
In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: Fix debugfs directory leak The ULPI per-device debugfs root is named after the ulpi device's parent, but ulpi_unregister_interface tries to remove a debugfs directory named after the ulpi device itself. This results in the directory sticking around and preventing subsequent (deferred) probes from succeeding. Change the directory name to match the ulpi device.
- https://git.kernel.org/stable/c/330d22aba17a4d30a56f007d0f51291d7e00862b
- https://git.kernel.org/stable/c/33713945cc92ea9c4a1a9479d5c1b7acb7fc4df3
- https://git.kernel.org/stable/c/3caf2b2ad7334ef35f55b95f3e1b138c6f77b368
- https://git.kernel.org/stable/c/d31b886ed6a5095214062ee4fb55037eb930adb6
- https://git.kernel.org/stable/c/330d22aba17a4d30a56f007d0f51291d7e00862b
- https://git.kernel.org/stable/c/33713945cc92ea9c4a1a9479d5c1b7acb7fc4df3
- https://git.kernel.org/stable/c/3caf2b2ad7334ef35f55b95f3e1b138c6f77b368
- https://git.kernel.org/stable/c/d31b886ed6a5095214062ee4fb55037eb930adb6
Modified: 2025-09-16
CVE-2024-26920
In the Linux kernel, the following vulnerability has been resolved: tracing/trigger: Fix to return error if failed to alloc snapshot Fix register_snapshot_trigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error.
- https://git.kernel.org/stable/c/0958b33ef5a04ed91f61cef4760ac412080c4e08
- https://git.kernel.org/stable/c/36be97e9eb535fe3008a5cb040b1e56f29f2e398
- https://git.kernel.org/stable/c/4b001ef14baab16b553a002cb9979e31b8fc0c6b
- https://git.kernel.org/stable/c/6022c065c9ec465d84cebff8f480db083e4ee06b
- https://git.kernel.org/stable/c/0958b33ef5a04ed91f61cef4760ac412080c4e08
- https://git.kernel.org/stable/c/2450a69d2ee75d1f0112d509ac82ef98f5ad6b5f
- https://git.kernel.org/stable/c/26ebeffff238488466fa578be3b35b8a46e69906
- https://git.kernel.org/stable/c/2a3073d58382157ab396734ed4e421ba9e969db1
- https://git.kernel.org/stable/c/34925d01baf3ee62ab21c21efd9e2c44c24c004a
- https://git.kernel.org/stable/c/36be97e9eb535fe3008a5cb040b1e56f29f2e398
- https://git.kernel.org/stable/c/4b001ef14baab16b553a002cb9979e31b8fc0c6b
- https://git.kernel.org/stable/c/56cfbe60710772916a5ba092c99542332b48e870
- https://git.kernel.org/stable/c/6022c065c9ec465d84cebff8f480db083e4ee06b
- https://git.kernel.org/stable/c/8ffd5590f4d6ef5460acbeac7fbdff7025f9b419
- https://git.kernel.org/stable/c/b5085b5ac1d96ea2a8a6240f869655176ce44197
- https://git.kernel.org/stable/c/bcf4a115a5068f3331fafb8c176c1af0da3d8b19
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-09-19
CVE-2024-35838
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential sta-link leak When a station is allocated, links are added but not set to valid yet (e.g. during connection to an AP MLD), we might remove the station without ever marking links valid, and leak them. Fix that.
- https://git.kernel.org/stable/c/49aaeb8c539b1633b3bd7c2df131ec578aa1eae1
- https://git.kernel.org/stable/c/587c5892976108674bbe61a8ff659de279318034
- https://git.kernel.org/stable/c/b01a74b3ca6fd51b62c67733ba7c3280fa6c5d26
- https://git.kernel.org/stable/c/e04bf59bdba0fa45d52160be676114e16be855a9
- https://git.kernel.org/stable/c/49aaeb8c539b1633b3bd7c2df131ec578aa1eae1
- https://git.kernel.org/stable/c/587c5892976108674bbe61a8ff659de279318034
- https://git.kernel.org/stable/c/b01a74b3ca6fd51b62c67733ba7c3280fa6c5d26
- https://git.kernel.org/stable/c/e04bf59bdba0fa45d52160be676114e16be855a9
Modified: 2025-09-24
CVE-2024-35839
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge. As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.
- https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c
- https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b
- https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547
- https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86
- https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c
- https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b
- https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547
- https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86
Modified: 2025-09-24
CVE-2024-35840
In the Linux kernel, the following vulnerability has been resolved: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect() subflow_finish_connect() uses four fields (backup, join_id, thmac, none) that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set in mptcp_parse_option()
- https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
- https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
- https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
- https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
- https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb
- https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
- https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
- https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
- https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
- https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb
Modified: 2025-09-19
CVE-2024-35842
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: sof-common: Add NULL check for normal_link string It's not granted that all entries of struct sof_conn_stream declare a `normal_link` (a non-SOF, direct link) string, and this is the case for SoCs that support only SOF paths (hence do not support both direct and SOF usecases). For example, in the case of MT8188 there is no normal_link string in any of the sof_conn_stream entries and there will be more drivers doing that in the future. To avoid possible NULL pointer KPs, add a NULL check for `normal_link`.
- https://git.kernel.org/stable/c/b1d3db6740d0997ffc6e5a0d96ef7cbd62b35fdd
- https://git.kernel.org/stable/c/cad471227a37c0c7c080bfc9ed01b53750e82afe
- https://git.kernel.org/stable/c/cde6ca5872bf67744dffa875a7cb521ab007b7ef
- https://git.kernel.org/stable/c/e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed
- https://git.kernel.org/stable/c/b1d3db6740d0997ffc6e5a0d96ef7cbd62b35fdd
- https://git.kernel.org/stable/c/cad471227a37c0c7c080bfc9ed01b53750e82afe
- https://git.kernel.org/stable/c/cde6ca5872bf67744dffa875a7cb521ab007b7ef
- https://git.kernel.org/stable/c/e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed
Closed bugs
Включить расчёт параметров CAN по битрейту
