ALT-BU-2024-13769-11
Branch sisyphus update bulletin.
Package kernel-image-rpi-un updated to version 6.6.51-alt1 for branch sisyphus in task 359031.
Closed vulnerabilities
Modified: 2025-10-29
BDU:2024-00896
Уязвимость функции raid5_cache_count() (drivers/md/raid5.c) драйвера RAID ядра операционной системы Linux, связанная с целочисленным переполнением, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01193
Уязвимость функции conn_info_{min,max}_age_set() в модуле net/bluetooth/hci_debugfs.c. реализации протокола HCI драйвера bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации и вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-01194
Уязвимость функции {conn,adv}_{min,max}_interval_set() реализации протокола HCI драйвера bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации и вызвать отказ в обслуживании
Modified: 2024-12-06
BDU:2024-01751
Уязвимость функции __thp_get_unmapped_area() подсистемы управления памятью на 32-битных системах ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03615
Уязвимость функции __unix_gc() в модуле net/unix/garbage.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03625
Уязвимость функции nft_pipapo_remove() в модуле net/netfilter/nft_set_pipapo.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03632
Уязвимость функции qla2x00_mem_alloc() в модуле drivers/scsi/qla2xxx/qla_os.c драйвера QLogic QLA2XXX ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
Modified: 2025-10-24
BDU:2024-03634
Уязвимость функции __i915_vma_active() в модуле drivers/gpu/drm/i915/i915_vma.c драйвера графических адаптеров Intel 8xx/9xx/G3x/G4x/HD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03636
Уязвимость функции nfs_direct_commit_schedule() в модуле fs/nfs/direct.c сетевой файловой системы Network File System (NFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03637
Уязвимость функции free_swap_and_cache() в модуле mm/swapfile.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-06
BDU:2024-03638
Уязвимость функции rapl_config() в модуле drivers/powercap/intel_rapl_common.c драйвера Intel Running Average Power Limit (RAPL) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-06
BDU:2024-03639
Уязвимость функции max310x_i2c_probe() в модуле drivers/tty/serial/max310x.c драйвера max310x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03640
Уязвимость функции __handle_ksmbd_work() реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03641
Уязвимость функций ncm_set_alt() и ncm_disable() в модуле drivers/usb/gadget/function/f_ncm.c драйвера USB gadget ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-06
BDU:2024-03645
Уязвимость функции sun8i_ce_cipher_do_one() в модуле drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c драйвера Allwinner Crypto Engine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03668
Уязвимость функции cifs_debug_files_proc_show() в модуле fs/smb/client/cifs_debug.c подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03671
Уязвимость функции mac802154_llsec_key_del() в модуле net/mac802154/llsec.c подсистемы беспроводной связи ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и целостность защищаемой информации, или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03703
Уязвимость функции inet_frag_reasm_prepare() в модуле net/ipv4/inet_fragment.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03712
Уязвимость функции kfd_ioctl_get_process_apertures_new() в модуле drivers/gpu/drm/amd/amdkfd/kfd_chardev.c драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03747
Уязвимость функции run_spu_dma() в модуле sound/sh/aica.c звуковой подсистемы (ALSA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03771
Уязвимость функции nf_tables_unbind_set() в модуле net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03932
Уязвимость функции ovs_ct_limit_exit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03933
Уязвимость функции gtp_dellink() реализации протокола туннелирования GPRS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2024-03934
Уязвимость функции packet_buffer_get() драйвера IEEE 1394 (FireWire) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-29
BDU:2024-03935
Уязвимость функции amdgpu_bo_move() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2024-03936
Уязвимость функции l2cap_chan_timeout() подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2024-03937
Уязвимость функции sco_sock_timeout() подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2024-03939
Уязвимость функции xennet_alloc_one_rx_buffer() ядра операционной системы Linux, позволяющая нарушителю вызвыать отказ в обслуживании
Modified: 2024-08-26
BDU:2024-04215
Уязвимость функции raid1_write_request() драйвера raid1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-04216
Уязвимость функции check_kprobe_address_safe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-08-26
BDU:2024-04217
Уязвимость функции ax25_dev_device_down() реализации протокола Amateur Radio X.25 PLP (Rose) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-23
BDU:2024-04218
Уязвимость функции smb2_reconnect_server() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04219
Уязвимость функции cifs_stats_proc_write() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04220
Уязвимость функции cifs_stats_proc_show() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04221
Уязвимость функции cifs_dump_full_key() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-04222
Уязвимость функции smb2_is_valid_oplock_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04223
Уязвимость функции smb2_is_valid_lease_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04224
Уязвимость функции is_valid_oplock_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04225
Уязвимость функции smb2_is_network_name_deleted() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04226
Уязвимость функции cifs_signal_cifsd_for_reconnect() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04227
Уязвимость функции mlxsw_sp_acl_tcam_ventry_activity_get() драйвера Mellanox Technologies Switch ASICs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04228
Уязвимость функции mlxsw_sp_acl_tcam_vregion_rehash() драйвера Mellanox Technologies Switch ASICs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-12
BDU:2024-04229
Уязвимость функции brcmf_notify_escan_complete() драйвера Broadcom FullMAC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-15
BDU:2024-04230
Уязвимость функции generic_ops_supported() драйвера EFI (Extensible Firmware Interface) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-15
BDU:2024-04231
Уязвимость функции rk_hash_run() криптографического драйвера Rockchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-04232
Уязвимость функции sev_mem_enc_register_region() компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-04233
Уязвимость функции optee_register_device() драйвера Trusted Execution Environment (TEE) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04369
Уязвимость функции nf_tables_abort() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-29
BDU:2024-04540
Уязвимость функции hci_le_big_sync_established_evt() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-04541
Уязвимость функции msft_do_close() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-04542
Уязвимость функции register_device() драйвера символьных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2024-04543
Уязвимость функции malidp_mw_connector_reset() драйвера ARM Mali Display Processor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2024-04544
Уязвимость функции l2cap_connect() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04546
Уязвимость функции do_setvfinfo() реализации стека протоколов TCP/IP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-29
BDU:2024-04547
Уязвимость функции op_remap() драйвера Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-29
BDU:2024-04548
Уязвимость функции regcache_maple_drop() драйвера regmap ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-04549
Уязвимость функции orangefs_mount() файловой системы orangefs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04551
Уязвимость функции net_alloc_generic() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2024-04552
Уязвимость функции tipc_buf_append() реализации протокола Transparent Inter Process Communication (TIPC) ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-04553
Уязвимость функции mas_empty_area_rev() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-04554
Уязвимость функции gpio_chrdev_release() драйвера gpio ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04555
Уязвимость функции ip6_output() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04556
Уязвимость функции __fib6_rule_action() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-04557
Уязвимость функции tcp_twsk_unique() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-04559
Уязвимость функции __spi_sync() драйвера Serial Peripheral Interface (SPI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-04561
Уязвимость функции sk_psock_verdict_data_ready() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04563
Уязвимость функции queue_oob() реализации сокетов AF_UNIX ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-04564
Уязвимость функции setup_dsc_config() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-08
BDU:2024-04565
Уязвимость функции l2cap_le_flowctl_init() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-04580
Уязвимость функций disable_{show,store}() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04581
Уязвимость функции interface_authorized_store() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-04582
Уязвимость функции br_nf_local_in() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-06
BDU:2024-04584
Уязвимость функции dup_mmap() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04585
Уязвимость функции __dst_negative_advice() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04587
Уязвимость функции nft_expr_type_get() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-04589
Уязвимость функции scp_ipi_init() драйвера сопроцессоров ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-04590
Уязвимость функции erofs_kill_sb() файловой системы EROFS (Enhanced Read-Only File System) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04591
Уязвимость функции tpm2_key_encode() подсистемы Trusted Platform Module (TPM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04680
Уязвимость функции multiq_tune компонента sch_multiq ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-04-30
BDU:2024-04808
Уязвимость функции idxd_wq_del_cdev () файла drivers/dma/idxd/cdev.c ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2024-04895
Уязвимость функции alauda_init_media() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-04910
Уязвимость функции del_timer() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
Modified: 2025-04-30
BDU:2024-05048
Уязвимость компонента ASoC: mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-05057
Уязвимость функции btrfs_set_item_key_safe() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-10-24
BDU:2024-05829
Уязвимость функции kfree_sensitive ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-10-24
BDU:2024-05830
Уязвимость функции copy_to_user компонента s390 ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-09-12
BDU:2024-06042
Уязвимость функции tpm_tis_spi_init() драйвера Trusted Platform Module (TPM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-23
BDU:2024-06043
Уязвимость функции smb2_get_data_area_len() реализации сервера протокола SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-06044
Уязвимость функции gp_aux_bus_probe() драйвера Microchip PCI1XXXX ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06045
Уязвимость функции tpm2_key_encode() подсистемы Trusted Platform Module (TPM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06047
Уязвимость функции __dwc3_stop_active_transfer() драйвера DesignWare USB3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-06048
Уязвимость функции taprio_parse_mqprio_opt() подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-02-05
BDU:2024-06049
Уязвимость функции zynqmp_dpsub_probe() драйвера ZynqMP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-05
BDU:2024-06050
Уязвимость функций sbi_cpu_start() и cpu_update_secondary_bootdata() ядра операционной системы Linux на процессорах с архитектурой RISC-V, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06051
Уязвимость функции do_map_benchmark() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-06052
Уязвимость функции gfx_v9_4_3_init_microcode() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-29
BDU:2024-06054
Уязвимость функции parse_btf_field() подсистемы трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06055
Уязвимость функции sync_print_obj() драйвера dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06056
Уязвимость функции register_winch_irq() драйвера подсистемы User-Mode Linux (UML) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-06057
Уязвимость функции may_update_sockmap() подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
Modified: 2025-08-19
BDU:2024-06058
Уязвимость функции br_mst_set_state() реализации протокола IEEE 802.1D ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-06059
Уязвимость функции irq_find_at_or_after() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06060
Уязвимость функции stm_register_device() драйвера трассировки System Trace Module (STM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-06061
Уязвимость функции eventfs_find_events() файловой системы tracefs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06062
Уязвимость функции amdgpu_mes_remove_ring() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2024-06063
Уязвимость функции bond_option_arp_ip_targets_set() сетевой компоненты ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-06065
Уязвимость функции sof_ipc4_get_input_pin_audio_fmt() звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06066
Уязвимость функции vm_area_alloc_pages() менеджера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06069
Уязвимость функции netpoll_owner_active() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06071
Уязвимость функции btrfs_load_zone_info() файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-06072
Уязвимость функции gb_interface_release() драйвера Greybus ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2024-06073
Уязвимость функции ima_collect_measurement() компонента IMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-06080
Уязвимость функции drm_file_update_pid() видео драйвера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-06081
Уязвимость функции __v4l2_async_nf_unregister() видео драйвера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-06082
Уязвимость структуры davinci_mmcsd_driver драйвера MMC/SD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06083
Уязвимость функции media_pipeline_explore_next_link() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06084
Уязвимость функции kdb_read() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-06085
Уязвимость функции i915_hwmon_register() драйвера Intel 8xx/9xx/G3x/G4x/HD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-06088
Уязвимость функции raid5d() драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06089
Уязвимость функции savagefb_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06488
Уязвимость функции ip_route_use_hint() в компоненте ipv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06497
Уязвимость функции i2c_hid_xfer() в компоненте i2c-hid ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06498
Уязвимость компонента xilinx_dpdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06499
Уязвимость компонента smbus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06500
Уязвимость компонента batman-adv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06501
Уязвимость функции hci_req_sync_complete() в компоненте Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06502
Уязвимость функции __nft_obj_type_get() в компоненте nf_tables ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-08-19
BDU:2024-06503
Уязвимость компонента tun ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06521
Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06522
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-06524
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2024-06715
Уязвимость функции virt_to_physt компонента s390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06716
Уязвимость функции dispose_list в компоненте vfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06732
Уязвимость функции gtp_dev_xmit() модуля drivers/net/gtp.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-09
BDU:2024-06733
Уязвимость функций select_local_address() и select_signal_address компонента mptcp ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-06745
Уязвимость функции dequeue_rx() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06751
Уязвимость функции ip6_xmit() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2024-06753
Уязвимость функции ip6_finish_output2 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06759
Уязвимость функции tcp_sk_exit_batch() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06857
Уязвимость компонента thermal/drivers/tsens ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06858
Уязвимость компонента net/mlx5 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-04-30
BDU:2024-06859
Уязвимость компонента ssh_css ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-06860
Уязвимость компонента vc4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06861
Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-04-30
BDU:2024-06894
Уязвимость компонента block/blk-cgroup.c ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06989
Уязвимость компонента arch/x86/kernel/fpu/xstate.c ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-07049
Уязвимость функции unix_release_sock/unix_stream_sendmsg компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-07094
Уязвимость библиотеки lib/xarray.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07389
Уязвимость функции rb_get_reader_page компонента kernel/trace/ring_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-06
BDU:2024-07403
Уязвимость компонента HCI_AMP ядра операционной системы Linux, позволяющая нарушителю, вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-07405
Уязвимость функции shmem_is_huge() подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-07483
Уязвимость функции fcntl_setlk() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-07636
Уязвимость компонента RDMA/hns ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2025-05-06
BDU:2024-07637
Уязвимость компонента RDMA/hns ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07638
Уязвимость функции nilfs_segctor_notify() файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-07639
Уязвимость компонента drm/mediatek ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-07640
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2026-01-20
BDU:2024-07641
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-07692
Уязвимость функции tcf_ct_act() подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07741
Уязвимость функции amdgpu_vce_ring_parse_cs() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07744
Уязвимость функции mt76_connac_mcu_add_nested_tlv() драйвера MediaTek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07745
Уязвимость функции mv88e6xxx_default_mdio_bus() драйвера устройств Marvell 88E6xxx ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07746
Уязвимость макроопределения BPF_CORE_READ_BITFIELD компонента bpf ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07747
Уязвимость функции f2fs_build_fault_attr() файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07748
Уязвимость функции mpi3mr_sas_port_add() драйвера устройств Broadcom MPI3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07751
Уязвимость функции ea_get() файловой системы jfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-07757
Уязвимость функции gfs2_glock_free() файловой системы gfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-07758
Уязвимость функции show_rcu_tasks_trace_gp_kthread() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-07925
Уязвимость компонента sqpoll операционной системы Linux, связанная с ошибкой освобождения памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07926
Уязвимость функции add_ra_bio_pages() файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-07927
Уязвимость функции msi_capability_init() в модуле drivers/pci/msi/msi.c драйвера Message Signaled Interrupts (MSI and MSI-X) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-07928
Уязвимость функции v9fs_dentry_release() в модуле fs/9p/vfs_dentry.c файловой системы 9p ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-05-06
BDU:2024-07937
Уязвимость функции cachefiles_withdraw_volumes() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-07961
Уязвимость функции max_vclocks_store() (drivers/ptp/ptp_sysfs.c) реализации протокола Precision Time Protocol (PTP) ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-10-24
BDU:2024-07965
Уязвимость функции blkpg_do_ioctl() (block/ioctl.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-07983
Уязвимость функции ata_host_alloc() (drivers/ata/libata-core.c) драйвера ATA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-07984
Уязвимость функции i915_vma_revoke_fence() (drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c) драйвера видеокарт Intel 8xx/9xx/G3x/G4x/HD ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2026-04-20
BDU:2024-07985
Уязвимость функции swap_endian() подсистемы WireGuard ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-07986
Уязвимость структуры tcp_metrics_nl_policy реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08070
Уязвимость функции sanity_check_extent_cache() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08071
Уязвимость функции seqpacket_allow() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08072
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-08075
Уязвимость функции dasd_ese_needs_format() ядра операционной системы Linux на платформе s390, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08077
Уязвимость функции ila_xlat_exit_net() реализации Identifier Locator Addressing (ILA) протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-08078
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-02
BDU:2024-08080
Уязвимость функции BUG_ON() компонента userfaultfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08082
Уязвимость функции cdrom_ioctl_timed_media_change() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08083
Уязвимость функции vmci_resource_remove() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08084
Уязвимость функции of_irq_parse_one() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08085
Уязвимость функции adc128_in_store() драйвера hwmon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-01
BDU:2024-08086
Уязвимость функции queued_spin_lock_slowpath() компонента qspinlock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08087
Уязвимость функции amdgpu_ring_init() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-01
BDU:2024-08132
Уязвимость функции fastrpc_req_mmap() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08133
Уязвимость функции amdgpu_cgs_get_firmware_info() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08135
Уязвимость функции df_v1_7_get_hbm_channel_number() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08139
Уязвимость функции snd_pcm_suspend_all() компонента dapm ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2024-08162
Уязвимость функции cougar_report_fixup() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08164
Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-08165
Уязвимость функции mlx5_function_teardown() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08183
Уязвимость функции pca953x_irq_bus_sync_unlock() драйвера GPIO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08184
Уязвимость функции binder_transaction() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08186
Уязвимость функции netem_dequeue() подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-01
BDU:2024-08187
Уязвимость компонента tracing/osnoise ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-08188
Уязвимость компонента tcp_bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2024-08189
Уязвимость компонента mcp251x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08227
Уязвимость функции sk_common_release() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-08228
Уязвимость функции mtk_wed_setup_tc_block() драйвера сетевых устройств MediaTek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08229
Уязвимость функции do_hardware_base_addr() драйвера параллельного порта ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08230
Уязвимость структуры bnx2x_fw_stats_req драйвера QLogic ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08231
Уязвимость функции squashfs_read_inode() файловой системы squashfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08234
Уязвимость функции setup_one_line() ядра операционной системы Linux в режиме User-mode-Linux (UML), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2024-08235
Уязвимость функции atomctrl_retrieve_ac_timing() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-08295
Уязвимость функции fscache_exit() файловой системы netfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08296
Уязвимость функции amdtp_hid_remove() драйвера AMD Sensor Fusion Hub ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-02
BDU:2024-08298
Уязвимость функции vcap_api_encode_rule_test() драйвера сетевых адаптеров Microchip ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-02
BDU:2024-08299
Уязвимость функции tlat_var_reset() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-08300
Уязвимость функции iio_gts_build_avail_time_table() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08302
Уязвимость функции irq_process_work_list() драйвера DMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08303
Уязвимость функции kvm_spapr_tce_attach_iommu_group() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux на платформе PowerPC, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08304
Уязвимость функции get_net_ns() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08305
Уязвимость функций __jfs_getxattr() и jfs_listxattr() файловой системы jfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-08306
Уязвимость функции posix_lock_inode() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08307
Уязвимость функции ltq_etop_free_channel() драйвера Ethernet ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08308
Уязвимость функции ftrace_location() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08310
Уязвимость функции check_rstbl() файловой системы NTFS3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08311
Уязвимость функции rtw89_sta_info_get_iter() драйвера беспроводных адаптеров Realtek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08312
Уязвимость функции fcntl_setlk() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08314
Уязвимость функции cachefiles_withdraw_volumes() файловой системы cachefiles ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2024-08315
Уязвимость функции nvme_cleanup_cmd() драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08316
Уязвимость функции ctnetlink_del_expect() компонентa netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-08317
Уязвимость функции kcm_sendmsg() реализации KCM (Kernel Connection Multiplexor) сокетов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-08318
Уязвимость функции log_replay() файловой системы NTFS3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08319
Уязвимость функции hns3_pmu_validate_event_group() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08320
Уязвимость функции fuse_notify_store() файловой системы fuse ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-05-06
BDU:2024-08321
Уязвимость функции hisi_pcie_pmu_validate_event_group() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08322
Уязвимость функции update_xps() драйвера сетевых адаптеров Freescale DPAA2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-08324
Уязвимость структуры moschip7840_4port_device драйвера USB для последовательных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-08325
Уязвимость функции entry_SYSCALL_compat() ядра операционной системы Linux на платформе x86, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08326
Уязвимость функции ceph_monc_stop() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08327
Уязвимость функции usb_string_copy() драйвера USB gadget ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08328
Уязвимость функции amdgpu_atombios_init_mc_reg_table() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08329
Уязвимость функции hfsplus_listxattr() файловой системы HFS+ ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08330
Уязвимость функции sdma_v4_0_process_trap_irq() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08331
Уязвимость функции iucv_cpu_down_prep() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08333
Уязвимость функции st_dwc3_probe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08334
Уязвимость функции gc_data_segment() файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08335
Уязвимость функции nilfs_check_folio() файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08346
Уязвимость функции proc_cpuset_show() (kernel/cgroup/cpuset.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08520
Уязвимость функции ast_udc_getstatus() драйвера usb gadget ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08523
Уязвимость макроопределения ARCH_DMA_MINALIGN ядра операционной системы Linux на платформе PA-RISC, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08525
Уязвимость функций read() и write() драйвера amdpgu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08526
Уязвимость функции dcn302_fpu_update_bw_bounding_box() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08528
Уязвимость функции hdmi_14_process_transaction() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08529
Уязвимость функции dal_gpio_service_lock() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08530
Уязвимость функции navi10_is_support_fine_grained_dpm() драйвера amdpgu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08531
Уязвимость функции aac_init_adapter() драйвера Adaptec AACRAID ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08532
Уязвимость функции gue_gro_receive() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08533
Уязвимость функции diSync() файловой системы jfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08534
Уязвимость функции tipc_udp_addr2str() реализации протокола TIPC (Transparent Inter Process Communication) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08535
Уязвимость функции hfcmulti_tx() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08539
Уязвимость функции iucv_sever_path() драйвера IUCV ядра операционной системы Linux на платформе s/390, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08540
Уязвимость функции ta_if_load_debugfs_write() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-30
BDU:2024-08730
Уязвимость функций crst_table_free() и base_crst_free() подсистемы управления памятью ядра операционной системы Linux на платформе s390, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08731
Уязвимость функции cs_dsp_load() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08737
Уязвимость функции cs_dsp_load() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08738
Уязвимость функции BPF_CALL_1() компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-08739
Уязвимость функции ma35d1serial_probe() драйвера Nuvoton MA35D1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08915
Уязвимость функции cs_dsp_dbg() (drivers/firmware/cirrus/cs_dsp.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08979
Уязвимость определения массивов dmub_callback и dmub_thread_offload ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08984
Уязвимость функции smack_inet_conn_request() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-09000
Уязвимость функции l2cap_sock_recv_cb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-09001
Уязвимость функции hns_roce_cq_event() драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-09028
Уязвимость ядра операционной системы Linux, связанная с недостаточной нейтрализацией специальных элементов в запросе, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09183
Уязвимость компонентов vfio/pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09203
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании(DoS)
Modified: 2025-05-06
BDU:2024-09204
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09205
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании(DoS)
Modified: 2025-08-19
BDU:2024-09206
Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09321
Уязвимость компонента sysfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-09322
Уязвимость компонента speakup ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09326
Уязвимость компонентов serial/pmac_zilog ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09328
Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09329
Уязвимость компонента vmk80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09330
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09332
Уязвимость компонента drm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09339
Уязвимость компонентов s390/cio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09340
Уязвимость компонента binder ядра операционной системы Linux, позволяющая нарушителю выполнять произвольный код
Modified: 2025-05-06
BDU:2024-09343
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09346
Уязвимость компонента netdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09347
Уязвимость компонента tmpfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09352
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-04-29
BDU:2024-09355
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09366
Уязвимость компонента imx8-isi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09367
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09368
Уязвимость компонентов nouveau/dmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09369
Уязвимость компонентов kprobes/x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09370
Уязвимость компонентов mm/memory-failure ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09371
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю оказать влияние на доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-09372
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю оказать влияние на доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-09373
Уязвимость компонента dwc3-am62 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09374
Уязвимость компонента btnxpuart ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09393
Уязвимость компонента qla2xxx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09394
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-09396
Уязвимость компонентов drm/i915/gt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09397
Уязвимость компонента wireguard ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09398
Уязвимость компонента wireguard ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09399
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09400
Уязвимость функции pci_iounmap() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09401
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09403
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-08-19
BDU:2024-09405
Уязвимость компонента fat ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-01-20
BDU:2024-09406
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09409
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09410
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09411
Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09412
Уязвимость компонента xhci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09414
Уязвимость компонентов s390/zcrypt ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09415
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09524
Уязвимость функций nf_flow_offload_inet_hook() и nf_flow_skb_encap_protocol() компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-09526
Уязвимость функции ip6_send_skb() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-01
BDU:2024-09527
Уязвимость функции br_multicast_del_port() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-01
BDU:2024-09529
Уязвимость функции btrfs_submit_chunk() файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-09716
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09721
Уязвимость компонентов fs/aio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09768
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09770
Уязвимость компонента qbman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09771
Уязвимость компонента dm snapshot ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09772
Уязвимость компонента x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09776
Уязвимость функции vdec_close() драйвера Qualcomm Venus V4L2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-09777
Уязвимость функции iw_destroy_cm_id() драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-04-29
BDU:2024-09803
Уязвимость компонента drm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09805
Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09806
Уязвимость компонента fbmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09808
Уязвимость компонента sysv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09810
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09814
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09838
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2024-09859
Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09861
Уязвимость функции bprm_fill_uid() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-09865
Уязвимость компонентов net/rds ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09866
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09883
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09884
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09885
Уязвимость компонента sockmap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09886
Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09887
Уязвимость компонентов pstore/zone ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09888
Уязвимость компонента gro ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09892
Уязвимость компонента ath11k ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09893
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09894
Уязвимость компонента send ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-09895
Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09896
Уязвимость компонента iwlwifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09897
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09898
Уязвимость компонента mlxbf_gige ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09913
Уязвимость компонента btintel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09915
Уязвимость компонента ncm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09917
Уязвимость компонента vt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09933
Уязвимость компонента udc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09938
Уязвимость компонента ubifs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09939
Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09940
Уязвимость компонента cachestat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09941
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-03-21
BDU:2024-09942
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09956
Уязвимость компонентов md/md-bitmap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09958
Уязвимость компонентов drm/nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09959
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-03-21
BDU:2024-09960
Уязвимость компонента ohci ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-03-21
BDU:2024-09961
Уязвимость компонента micrel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09963
Уязвимость компонента tls ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09964
Уязвимость компонента t7xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09965
Уязвимость компонентов s390/bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09966
Уязвимость компонента vcodec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09967
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2024-09968
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09969
Уязвимость компонента qbman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09971
Уязвимость компонента dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09972
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09973
Уязвимость компонента nci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09974
Уязвимость компонента swiotlb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09975
Уязвимость компонента vcodec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09976
Уязвимость компонента vcodec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании(DoS)
Modified: 2025-03-21
BDU:2024-09977
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09978
Уязвимость в компонентов x86/bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09979
Уязвимость компонента mana ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09980
Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09981
Уязвимость компонента lis3lv02d_i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09988
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09989
Уязвимость компонентов PCI/PM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09997
Уязвимость компонентов x86/mmu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09998
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10001
Уязвимость компонента hibernate ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10002
Уязвимость компонента init ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10004
Уязвимость компонента nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10037
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10038
Уязвимость компонента sg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10039
Уязвимость компонентов accel/ivpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10040
Уязвимость компонентов drm/ast ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10041
Уязвимость компонента mchp-pci1xxx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10042
Уязвимость компонента SUNRPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10043
Уязвимость компонентов io_uring/kbuf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10044
Уязвимость компонента bcmasp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10046
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10047
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10048
Уязвимость компонента erspan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10050
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10052
Уязвимость компонента mlxbf_gige ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10053
Уязвимость компонента udp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10055
Уязвимость компонента dynamic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10057
Уязвимость компонентов mm/secretmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10059
Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10061
Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10062
Уязвимость компонентов drm/client ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-08-19
BDU:2024-10063
Уязвимость компонента dyndbg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10064
Уязвимость компонента VMCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10065
Уязвимость компонентов x86/mm/pat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10066
Уязвимость компонента icmp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10067
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-10068
Уязвимость компонента at24 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10069
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-10070
Уязвимость компонента ena ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10071
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10072
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10086
Уязвимость функции pci_bridge_wait_for_secondary_bus() драйвера шины PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2024-10375
Уязвимость функции mmap_mutex ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность
Modified: 2026-01-20
BDU:2024-10511
Уязвимость компонентов irqchip/gic-v3-its ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10512
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2024-10513
Уязвимость компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10588
Уязвимость функции __key_instantiate_and_link() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-10589
Уязвимость функций disable_show() и disable_store() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-10596
Уязвимость функции clk_dvp_probe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10601
Уязвимость структуры GUID файловой системы ntfs3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10602
Уязвимость функции seg6_init() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10603
Уязвимость функции of_modalias() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-10659
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10674
Уязвимость компонента qibfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10675
Уязвимость компонента phonet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10678
Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10679
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10680
Уязвимость компонента nfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-10681
Уязвимость компонента xdp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-10682
Уязвимость функций bnad_debugfs_write_regrd() и bnad_debugfs_write_regwr() в модуле drivers/net/ethernet/brocade/bna/bnad_debugfs.c компонента bna ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-10683
Уязвимость компонента nsh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10684
Уязвимость компонентов s390/cio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10686
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-10687
Уязвимость компонентов s390/qeth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10688
Уязвимость компонента bnx2fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-10690
Уязвимость функции iocg_kick_delay() в модуле block/blk-iocost.c компонента blk-iocost ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10691
Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10693
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10694
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10696
Уязвимость компонента sdhci-msm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10697
Уязвимость компонента h6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10698
Уязвимость компонента qla2xxx ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-04
BDU:2024-10699
Уязвимость компонента n_gsm ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2024-10700
Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-10701
Уязвимость компонентов powerpc/pseries/iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10702
Уязвимость компонента swiotlb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10703
Уязвимость компонента uvc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10704
Уязвимость компонента f_fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10705
Уязвимость компонентов mm/slab ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10707
Уязвимость компонента workqueue ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10709
Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10711
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании (DoS)
Modified: 2025-05-06
BDU:2024-10726
Уязвимость компонентjd mm/hugetlb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10732
Уязвимость компонента cppc_cpufreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10733
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10734
Уязвимость компонента ecryptfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10735
Уязвимость компонента epoll ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10738
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10741
Уязвимость компонента bfa ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10742
Уязвимость компонента qedf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10743
Уязвимость компонента openvswitch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10744
Уязвимость компонента kirkwood ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10746
Уязвимость компонента cdns-mhdp8546 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10747
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10749
Уязвимость компонента devicetree ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-10751
Уязвимость компонента octeontx2-af ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код с повышенными привилегиями
Modified: 2025-08-19
BDU:2024-10752
Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10754
Уязвимость компонента vgic-v2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10756
Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-08-19
BDU:2024-10759
Уязвимость компонента r8169 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10761
Уязвимость компонента ohci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10762
Уязвимость компонента hda ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10764
Уязвимость компонента carl9170 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10765
Уязвимость компонента ar5523 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10916
Уязвимость компонента sock_map ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10917
Уязвимость компонента vmci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-10918
Уязвимость компонента cs35l56 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10920
Уязвимость компонента asm-bug ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-10921
Уязвимость компонента sr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10930
Уязвимость компонентов genirq/cpuhotplug ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10932
Уязвимость функции cyapa_suspend() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10975
Уязвимость компонента libstub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10976
Уязвимость компонента qmi_wwan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10979
Уязвимость компонента ionic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-10980
Уязвимость компонента nft_inner ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10986
Уязвимость компонента ipset ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-10999
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11001
Уязвимость компонента mpt3sas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11002
Уязвимость компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-04-30
BDU:2024-11003
Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11004
Уязвимость компонентов drm/komeda ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11005
Уязвимость компонента liquidio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-11069
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11355
Уязвимость компонента cdc-wdm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11356
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11405
Уязвимость функции ieee80211_sta_ps_deliver_wakeup() компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11407
Уязвимость модуля fs/cachefiles/ondemand.c файловой системы cachefiles ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11473
Уязвимость файловой системы tracefs ядра операционной системы Linux, позволяющая нарушителю получить доступ на чтение, изменение или удаление данных
Modified: 2025-04-30
BDU:2024-11518
Уязвимость компонентов io_uring/rsrc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11519
Уязвимость функции vmxnet3_rq_destroy_all_rxdataring() компонента vmxnet3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11521
Уязвимость компонента bnxt_en ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-11523
Уязвимость компонентов mm/huge_memory ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11524
Уязвимость функции cfg80211_get_station() в модуле net/wireless/util.c компонента cfg80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2024-11526
Уязвимость компонентов fs/9p ядра операционной системы Linux, позволяющая нарушителю читать и манипулировать данными
Modified: 2025-10-24
BDU:2024-11542
Уязвимость компонента cpufreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11543
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-11544
Уязвимость компонентов drivers/virt/acrn ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-11545
Уязвимость компонента m68k ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11546
Уязвимость компонентов macintosh/via-macii ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-11547
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-11548
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11549
Уязвимость компонента jffs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11550
Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11552
Уязвимость компонента sungem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11566
Уязвимость компонента micrel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11567
Уязвимость компонентов tools/nolibc/stdlib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11568
Уязвимость компонента icssg_prueth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11569
Уязвимость компонента rcu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-11570
Уязвимость компонента pcie ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11571
Уязвимость компонента ath12k ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11572
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-11573
Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11574
Уязвимость компонентов RDMA/cma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11576
Уязвимость компонентов kunit/fortify ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11577
Уязвимость компонента openrisc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11578
Уязвимость компонента carl9170 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-11579
Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-11580
Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-11669
Уязвимость функции btree_iter компонента bcache ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00022
Уязвимость функции bpf_ringbuf_reserve() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00024
Уязвимость компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-03-21
BDU:2025-00026
Уязвимость функции rcu_nocb_bypass_lock механизма синхронизации Read-copy-update (RCU) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00133
Уязвимость функции kunit_try_catch_run() фреймворка KUnit (lib/kunit/try-catch.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2025-00776
Уязвимость компонента drivers/net/dsa/mv88e6xxx/global1_atu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00839
Уязвимость функции nv17_tv_get_ld_modes() модуля drivers/gpu/drm/nouveau/dispnv04/tvnv17.c драйвера DRM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-00868
Уязвимость функций blk_flush_complete_seq() и flush_end_io() компонента block (block/blk-flush.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00872
Уязвимость функции fsl_asoc_card_probe() (sound/soc/fsl/fsl-asoc-card.c) компонента AsoC ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00879
Уязвимость функции davinci_gpio_probe() компонента gpio ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00881
Уязвимость функции btrfs_quota_disable() компонента btrfs ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00882
Уязвимость функции ila_output() компонента ila ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00885
Уязвимость функции nv17_tv_get_hd_modes() драйвера DRM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00922
Уязвимость функции br_dev_xmit() в модуле net/bridge/br_device.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2025-00926
Уязвимость функции i915_gem_object_is_shrinkable() драйвера DRM (drivers/gpu/drm/i915/gem/i915_gem_object.h) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00933
Уязвимость функции nilfs_segctor_prepare_write() в модуле fs/nilfs2/segment.c файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-00934
Уязвимость функций bonding_init() и bonding_exit() в модуле drivers/net/bonding/bond_main.cдрайвера bonding ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-00935
Уязвимость функции me_huge_page() модуля mm/memory-failure.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2025-00936
Уязвимость функции of_pci_prop_intr_map() модуля drivers/pci/of_property.c драйвера PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00937
Уязвимость функции rt6_probe() модуля net/ipv6/route.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00981
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00982
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00983
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00984
Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00985
Уязвимость компонента x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00986
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00987
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00989
Уязвимость компонентов drm/nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00990
Уязвимость компонентов mm/writeback ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-10-24
BDU:2025-00992
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00993
Уязвимость компонента inet_diag ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-00994
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-00995
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00996
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00997
Уязвимость компонента jffs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00998
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-00999
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01000
Уязвимость компонента powerpc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01001
Уязвимость компонентов drm/lima ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01003
Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-04-30
BDU:2025-01004
Уязвимость компонентов bluetooth/hci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01005
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01006
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01007
Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01035
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2025-01046
Уязвимость компонента dw-axi-dmac ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01047
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01048
Уязвимость компонентов powerpc/pseries ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01049
Уязвимость компонентов drm/lima ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2025-01050
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01051
Уязвимость компонента drop_monitor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01052
Уязвимость компонента batman-adv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01053
Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01054
Уязвимость компонента ACPICA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01055
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01056
Уязвимость компонентов drm/radeon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01057
Уязвимость компонентов RDMA/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01058
Уязвимость компонентов RDMA/rxe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01060
Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01061
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01062
Уязвимость компонента tracing ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01063
Уязвимость компонента netrom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-01064
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-01090
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2025-01091
Уязвимость компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01092
Уязвимость компонентов s390/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01158
Уязвимость функции ocfs2_abort_trigger() модуля fs/ocfs2/journal.c компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01322
Уязвимость функции i40e_xdp_setup() (drivers/net/ethernet/intel/i40e/i40e_main.c) драйвера i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01332
Уязвимость функций ppp_read() и ppp_write() (drivers/net/ppp/ppp_generic.c) драйвера ppp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-01333
Уязвимость функций nf_tables_rule_release(), nft_chain_validate(), nft_chain_validate_hooks() и nft_validate_register_store() (net/netfilter/nf_tables_api.c) компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01334
Уязвимость функция sock_set_flag() и spin_unlock() (net/ipv4/udp.c) компонента udp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01335
Уязвимость функций cs_dsp_coeff_parse_string(), cs_dsp_coeff_parse_int(), cs_dsp_coeff_parse_coeff() и cs_dsp_parse_coeff() (drivers/firmware/cirrus/cs_dsp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-01336
Уязвимость функции usb_parse_endpoint() (drivers/usb/core/config.c) драйвера USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01337
Уязвимость функции nilfs_dotdot() файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01338
Уязвимость драйвера toshiba_acpi (drivers/platform/x86/toshiba_acpi.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-01339
Уязвимость функции sclp_init() (drivers/s390/char/sclp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-01340
Уязвимость функции alloc_dispatch_log_kmem_cache() (arch/powerpc/platforms/pseries/setup.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-01341
Уязвимость функции hci_unregister_dev() (net/bluetooth/hci_core.c) драйвера Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-01342
Уязвимость функции radeon_gem_va_update_vm() (drivers/gpu/drm/radeon/radeon_gem.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-01-20
BDU:2025-01404
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01406
Уязвимость компонента amdtp-stream ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01407
Уязвимость компонента nvme-pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01408
Уязвимость компонента iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01411
Уязвимость компонентов riscv/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01412
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01414
Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01416
Уязвимость компонентов drm/i915/gem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2025-01417
Уязвимость компонента apparmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01418
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01419
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2025-01420
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01421
Уязвимость компонента udf ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2025-01423
Уязвимость компонентов drm/gma500 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01424
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01425
Уязвимость компонентов IB/core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01426
Уязвимость компонента nvmet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01427
Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01428
Уязвимость компонентов media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01429
Уязвимость компонента sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01430
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01431
Уязвимость компонентов drm/gma500 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01432
Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01434
Уязвимость компонентов fs/file ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01436
Уязвимость компонента fair ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01437
Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01444
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01445
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01446
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01447
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01448
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю повысить привилегии
Modified: 2025-10-24
BDU:2025-01449
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01450
Уязвимость компонентов irqchip/imx-irqsteer ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01451
Уязвимость компонента kobject_uevent ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01452
Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01453
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01454
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01455
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01456
Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01457
Уязвимость компонентов fs/ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01469
Уязвимость функций cs_dsp_coeff_parse_alg() и cs_dsp_coeff_parse_coeff() (drivers/firmware/cirrus/cs_dsp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01470
Уязвимость функции pfn_section_valid() модуля include/linux/mmzone.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-04-30
BDU:2025-01572
Уязвимость функции cachefiles_ondemand_send_req() (fs/cachefiles/ondemand.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-04-30
BDU:2025-01573
Уязвимость функции sk_msg_recvmsg() (net/core/skmsg.c) компонента skmsg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-01574
Уязвимость функции eeh_pe_bus_get() (arch/powerpc/kernel/eeh_pe.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-04-30
BDU:2025-01575
Уязвимость функции userfaultfd_api() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01651
Уязвимость компонента staging ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01652
Уязвимость компонента i3c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01653
Уязвимость компонента spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01654
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01655
Уязвимость компонента rtmutex ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01656
Уязвимость компонента sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01657
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01658
Уязвимость компонентов drm/bridge ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01659
Уязвимость компонентов drm/amd/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01660
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01661
Уязвимость компонента can ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01662
Уязвимость компонента udf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01663
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01664
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01665
Уязвимость компонента fou ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01666
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01667
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01668
Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01669
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01670
Уязвимость компонента fsnotify ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01671
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01672
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01673
Уязвимость компонентов pci/hotplug/pnv_php ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01674
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2025-01675
Уязвимость компонента hwmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01676
Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01677
Уязвимость компонента MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01678
Уязвимость компонентов lib/generic-radix-tree.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-02
BDU:2025-01703
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01713
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-01714
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01715
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01716
Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01717
Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2025-01718
Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01719
Уязвимость компонента udf ядра операционной системы Linux, связанная с использованием неинициализированного ресурса, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01720
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01721
Уязвимость компонента lib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01722
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01723
Уязвимость компонента xdp ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-08-19
BDU:2025-01724
Уязвимость компонента leds ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01725
Уязвимость компонентов drm/qxl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01726
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01727
Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01728
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01729
Уязвимость компонентов mm/mglru ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-04-30
BDU:2025-01730
Уязвимость компонента sysctl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01731
Уязвимость компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01732
Уязвимость компонентов drm/nouveau ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-05-06
BDU:2025-01733
Уязвимость компонента remoteproc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01734
Уязвимость компонента dma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01735
Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01736
Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01737
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01738
Уязвимость компонента bna ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01739
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-01743
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01744
Уязвимость компонента uio_hv_generic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01745
Уязвимость компонента ublk_drv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01747
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01750
Уязвимость компонента apparmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01751
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01752
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01763
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01764
Уязвимость компонента tty ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01765
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01766
Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01767
Уязвимость компонентов smb/client ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01768
Уязвимость компонента pinctrl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01769
Уязвимость компонента ethtool ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01770
Уязвимость компонента gtp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01781
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01782
Уязвимость компонента mmc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01783
Уязвимость функции close_range() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01784
Уязвимость функции memcg_write_event_control() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-01
BDU:2025-01785
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01786
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01787
Уязвимость компонентов nouveau/firmware ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01805
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01806
Уязвимость функции input_mt_init_slots() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-01807
Уязвимость компонентов rtla/osnoise ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01808
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01813
Уязвимость компонента vsock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01854
Уязвимость функций input_action_end_dx4() и input_action_end_dx6() модуля net/ipv6/seg6_local.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-01905
Уязвимость компонента bonding ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01906
Уязвимость компонентов drm/msm/dpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01907
Уязвимость компонентов s390/sclp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01908
Уязвимость компонента binfmt_flat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01909
Уязвимость компонентов x86/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01910
Уязвимость компонентов sched/smt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01911
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01912
Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01913
Уязвимость компонента sctp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01914
Уязвимость компонентов md/raid ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01915
Уязвимость компонентов drm/amdgpu/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01916
Уязвимость компонента char ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01917
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01918
Уязвимость компонента igb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01919
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01920
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01921
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01923
Уязвимость компонентов drm/client ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-01924
Уязвимость компонента memcg ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2025-01926
Уязвимость компонента tracing ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01927
Уязвимость компонента padata ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01929
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01930
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01931
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01932
Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01933
Уязвимость компонента devres ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01934
Уязвимость компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01935
Уязвимость компонента Input ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2025-01938
Уязвимость компонента thunderbolt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01939
Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01940
Уязвимость компонента firmware ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01941
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01942
Уязвимость компонента nfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01943
Уязвимость компонента netem ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2025-01944
Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01945
Уязвимость компонента xhci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01946
Уязвимость компонентов mm/vmalloc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01947
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01948
Уязвимость компонента bonding ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01949
Уязвимость компонента bnxt_en ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01950
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01953
Уязвимость компонентов drm/mgag200 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2025-01954
Уязвимость компонентов x86/mtrr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01955
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01956
Уязвимость компонента char ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01957
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01963
Уязвимость компонентов fs/netfs/fscache_cookie ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01964
Уязвимость компонентов drm/amdgpu/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01965
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01968
Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01971
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01972
Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01973
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-01977
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01983
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02069
Уязвимость функций amdgpu_vkms_prepare_fb() и amdgpu_vkms_cleanup_fb() (drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-02071
Уязвимость функции dev_kfree_skb_any() (drivers/net/ethernet/google/gve/gve_rx_dqo.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-02073
Уязвимость функции ext4_mb_find_good_group_avg_frag_lists() файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02074
Уязвимость функции __cvmx_pcie_build_config_addr() компонента mips ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02530
Уязвимость функций rdma_restrack_init() и type2str() драйвера Infiniband (drivers/infiniband/core/restrack.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02531
Уязвимость функции cfg80211_wext_siwscan() (net/wireless/scan.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02532
Уязвимость функции null_validate_conf() (drivers/block/null_blk/main.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-02533
Уязвимость функции create_pinctrl() (drivers/pinctrl/core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-02534
Уязвимость функции j1939_xtp_rx_rts_session_new() (net/can/j1939/transport.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-02535
Уязвимость функций nft_lookup_init(), nf_tables_fill_setelem() и nft_validate_register_store() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-02536
Уязвимость функции ata_host_release() драйвера портов ATA (drivers/ata/libata-core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2025-02538
Уязвимость функции __xdp_reg_mem_model() (net/core/xdp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-02539
Уязвимость функции cxacru_bind() драйвера USB (drivers/usb/atm/cxacru.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-02541
Уязвимость функций MODULE_ALIAS() и j1939_send_one() (net/can/j1939/main.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-02549
Уязвимость функции ftruncate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-02552
Уязвимость функций ocfs2_extend_trans() и ocfs2_dio_end_io_write() кластерной файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-02553
Уязвимость функций bme680_compensate_temp(), bme680_compensate_press() и bme680_compensate_humid() драйвера IIO (drivers/iio/chemical/bme680_core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-02554
Уязвимость функций dwc3_suspend_common() и dwc3_resume_common() драйвера USB (drivers/usb/dwc3/core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02555
Уязвимость функций ili9881c_prepare() и ili9881c_unprepare() драйвера (drivers/gpu/drm/panel/panel-ilitek-ili9881c.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02920
Уязвимость функции mtk_clk_simple_probe() модуля drivers/clk/mediatek/clk-mtk.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-02927
Уязвимость функции gpiochip_get_desc() модуля drivers/gpio/gpiolib.c драйвера GPIO ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-10-24
BDU:2025-02928
Уязвимость функции mlx5e_arfs_enable() модуля drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-02943
Уязвимость функции instance_destroy_rcu() модуля net/netfilter/nfnetlink_queue.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-02944
Уязвимость функции nf_tproxy_laddr4() модуля net/ipv4/netfilter/nf_tproxy_ipv4.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-02945
Уязвимость функции svdm_consume_identity() модуля drivers/usb/typec/tcpm/tcpm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-02946
Уязвимость функции tls_ctx_create() модуля net/tls/tls_main.c реализации протокола TLS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02948
Уязвимость функции free_ep_fback() модуля drivers/usb/gadget/function/u_audio.c драйвера USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02949
Уязвимость функции bpf_ctx_narrow_access_offset() модуля include/linux/filter.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02962
Уязвимость функции ks_pcie_setup_rc_app_regs() модуля drivers/pci/controller/dwc/pci-keystone.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02970
Уязвимость функции dasd_copy_pair_store() модуля drivers/s390/block/dasd_devmap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-02976
Уязвимость функции exfat_get_dentry_set() модуля fs/exfat/dir.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02979
Уязвимость функции lvts_probe() модуля drivers/thermal/mediatek/lvts_thermal.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02989
Уязвимость функции __vhost_worker_flush() модуля drivers/vhost/vhost.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02997
Уязвимость функции snd_acp_resume() модуля sound/soc/amd/acp/acp-pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-02998
Уязвимость функции gfs2_jindex_free() модуля fs/gfs2/super.c файловой системы GFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-02999
Уязвимость функции add_adev() модуля drivers/net/ethernet/microsoft/mana/mana_en.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03000
Уязвимость функции bpf_int_jit_compile() модуля arch/arm/net/bpf_jit_32.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03003
Уязвимость функции PROG_NAME() модуля kernel/bpf/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03004
Уязвимость функции drm_fb_helper_alloc_info() модуля drivers/gpu/drm/drm_fb_helper.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03005
Уязвимость функции mcp251xfd_open() модуля drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03011
Уязвимость функции nfs4_set_security_label() модуля fs/nfs/nfs4proc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03013
Уязвимость функции ibmvnic_xmit() модуля drivers/net/ethernet/ibm/ibmvnic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03014
Уязвимость функции __cxl_dpa_to_region() модуля drivers/cxl/core/region.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03015
Уязвимость функции hda_dai_suspend() модуля sound/soc/sof/intel/hda-dai.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03016
Уязвимость функции ufshcd_abort_one() модуля drivers/ufs/core/ufshcd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03018
Уязвимость функции ks8851_irq() модуля drivers/net/ethernet/micrel/ks8851_common.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03019
Уязвимость функции ufshcd_mcq_req_to_hwq() модуля drivers/ufs/core/ufs-mcq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03020
Уязвимость функции fastrpc_init_create_static_process() модуля drivers/misc/fastrpc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03021
Уязвимость функции amd_pstate_epp_cpu_exit() модуля drivers/cpufreq/amd-pstate.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03022
Уязвимость функции mt7921_mac_reset_work() модуля drivers/net/wireless/mediatek/mt76/mt7921/mac.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-03023
Уязвимость функции mtk_vcodec_fw_scp_init() модуля drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_scp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03024
Уязвимость функции ext4_xattr_set_entry() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03027
Уязвимость функции iommu_aux_get_pasid() модуля include/linux/iommu.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03028
Уязвимость функции ax25_accept() модуля net/ax25/af_ax25.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03029
Уязвимость функции f2fs_handle_critical_error() модуля fs/f2fs/super.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03032
Уязвимость функции max3100_probe() модуля drivers/tty/serial/max3100.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03033
Уязвимость функции lmh_probe() модуля drivers/thermal/qcom/lmh.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03035
Уязвимость функции p9_fcall_init() модуля net/9p/client.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03041
Уязвимость функции ax25_addr_ax25dev() модуля net/ax25/ax25_dev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03042
Уязвимость функции gem_interrupt() модуля drivers/net/ethernet/sun/sungem.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03044
Уязвимость функции ntfs_get_block_vbo() модуля fs/ntfs3/inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03046
Уязвимость функции mlx5_eswitch_offloads_single_fdb_add_one() модуля drivers/net/ethernet/mellanox/mlx5/core/eswitch.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03047
Уязвимость функции ax25_dev_device_down() модуля net/ax25/ax25_dev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03048
Уязвимость функции fec_set_mac_address() модуля drivers/net/ethernet/freescale/fec_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03049
Уязвимость функции dmirror_device_evict_chunk() модуля lib/test_hmm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03050
Уязвимость функции a6xx_gpu_init() модуля drivers/gpu/drm/msm/adreno/a6xx_gpu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03051
Уязвимость функции fpga_mgr_register() модуля Documentation/driver-api/fpga/fpga-mgr.rst ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-08
BDU:2025-03052
Уязвимость функции lpfc_els_retry_delay() модуля drivers/scsi/lpfc/lpfc_els.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03055
Уязвимость функции userfaultfd_release() модуля fs/userfaultfd.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03056
Уязвимость функции fpga_bridge_register() модуля Documentation/driver-api/fpga/fpga-bridge.rst ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-03058
Уязвимость функции __ip6_make_skb() модуля net/ipv6/ip6_output.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03059
Уязвимость функции rx_create() модуля drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_fs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03062
Уязвимость функции cifs_pick_channel() модуля fs/smb/client/transport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03063
Уязвимость функции ice_reset_vf() модуля drivers/net/ethernet/intel/ice/ice_vf_lib.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03064
Уязвимость функции perf_event_cpu_offline() модуля drivers/dma/idxd/perfmon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03065
Уязвимость функции cifs_sync_mid_result() модуля fs/smb/client/transport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03066
Уязвимость функции comphy_gbe_phy_init() модуля drivers/phy/marvell/phy-mvebu-a3700-comphy.c драйвера PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03067
Уязвимость функции mlxsw_sp_acl_tcam_vregion_rehash_work() модуля drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03068
Уязвимость функции tusb1210_remove_charger_detect() модуля drivers/phy/ti/phy-tusb1210.c драйвера PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03069
Уязвимость функции avg_vruntime() модуля kernel/sched/fair.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03071
Уязвимость функции virtnet_get_rxfh() модуля drivers/net/virtio_net.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03072
Уязвимость функции get_trans_granule() модуля arch/arm64/include/asm/tlbflush.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03073
Уязвимость функции otx2_qos_read_txschq_cfg_tl() модуля drivers/net/ethernet/marvell/octeontx2/nic/qos.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03074
Уязвимость функции geneve_xmit_skb() модуля drivers/net/geneve.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03075
Уязвимость функции bnxt_rdma_aux_device_init() модуля drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03077
Уязвимость функции rtw89_ops_bss_info_changed() модуля drivers/net/wireless/realtek/rtw89/mac80211.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03082
Уязвимость функции init_sel_fs() модуля security/selinux/selinuxfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03083
Уязвимость функции phy_sfp_probe() модуля drivers/net/phy/phy_device.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03084
Уязвимость функции fiemap_process_hole() модуля fs/btrfs/extent_io.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03086
Уязвимость функции nvkm_client_new() модуля drivers/gpu/drm/nouveau/nvkm/core/client.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03095
Уязвимость функции ta_if_invoke_debugfs_write() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03097
Уязвимость функции __nl80211_set_channel() модуля net/wireless/nl80211.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03152
Уязвимость функции dbDiscardAG() файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03153
Уязвимость функции dtInsert() файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03200
Уязвимость функции hex2bitmap() модуля drivers/s390/crypto/ap_bus.c - драйвера поддержки криптографии на платформе S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-02-17
BDU:2025-03222
Уязвимость функции pm8001_phy_control() драйвера SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03256
Уязвимость функции load_elf_binary() файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03257
Уязвимость функции aqua_vanjaram_switch_partition_mode() драйвера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03282
Уязвимость функции rxe_comp_queue_pkt() модуля drivers/infiniband/sw/rxe/rxe_comp.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании.
Modified: 2026-01-20
BDU:2025-03379
Уязвимость компонента Landlock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03392
Уязвимость компонентов selinux и smack ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03397
Уязвимость функции mptcp_stream_connect() компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03398
Уязвимость функции cachefiles_daemon_open() компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-06-09
BDU:2025-03399
Уязвимость компонентов cxl/region ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03400
Уязвимость функции ipc_devlink_create_region() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03401
Уязвимость функции mlx5_lag_create_port_sel_table() компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03402
Уязвимость функции iwl_mvm_mfu_assert_dump_notif() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03403
Уязвимость компонентов mm/page_table_check ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03404
Уязвимость компонента xhci ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-06-09
BDU:2025-03405
Уязвимость функции ethtool_get_phy_stats_ethtool() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03406
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03407
Уязвимость функции ext4_xattr_block_cache_find() компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03408
Уязвимость компонента blk-cgroup ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03409
Уязвимость функции fib6_nh_init() компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03410
Уязвимость функции cs35l41_hda_unbind() компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03411
Уязвимость функции imx_uart_console_write() компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03412
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03427
Уязвимость функции vidi_get_modes() компонентов drm/exynos/vidi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03428
Уязвимость функции logi_dj_recv_switch_to_dj_mode() компонента HID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03429
Уязвимость функции mesh_path_discard_frame() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03430
Уязвимость функции __ocfs2_change_file_space() компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03431
Уязвимость компонентов x86/kexec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03432
Уязвимость функции smack_post_notification() компонента ima ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-08-19
BDU:2025-03433
Уязвимость функции xfrm6_get_saddr() компонента xfrm6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-07
BDU:2025-03434
Уязвимость функции io_ring_buffer_select() компонента io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03435
Уязвимость функции nilfs_empty_dir() компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03436
Уязвимость компонента fpga ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03437
Уязвимость компонента smb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03438
Уязвимость функции btrfs_submit_chunk() компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03439
Уязвимость функции bcm6358_quirks() компонента mips ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03440
Уязвимость компонентов drm/shmem-helper ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03442
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03445
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03446
Уязвимость компонента ACPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03447
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03448
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03450
Уязвимость функции raspberrypi_discover_clocks() компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03451
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03452
Уязвимость функции sanity_check_inode() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03453
Уязвимость функции ocfs2_journal_dirty() компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03535
Уязвимость функции amdgpu_job_prepare_job() драйвера (drivers/gpu/drm/amd/amdgpu/amdgpu_job.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03537
Уязвимость функции ps_cancel_timer() драйвера Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03585
Уязвимость функции mana_destroy_txq() драйвера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03586
Уязвимость функции construct_phy() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03614
Уязвимость функции path_init() модуля drivers/interconnect/core.c - драйвера поддержки межсоединений ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-03686
Уязвимость функции dm_update_mst_vcpi_slots_for_dsc() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03689
Уязвимость функции nvmet_tcp_install_queue() модуля drivers/nvme/target/tcp.c драйвера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-03690
Уязвимость функции configure_lttpr_mode_non_transparent() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03691
Уязвимость функции dcn_bw_update_from_pplib_fclks() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03692
Уязвимость функции amdgpu_device_gpu_recover() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03699
Уязвимость функции mlx5e_handle_rx_cqe_mpwrq_shampo() драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03700
Уязвимость функции irqfd_wakeup() драйверов Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03751
Уязвимость функции mptcp_pm_nl_rm_addr_or_subflow() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03756
Уязвимость функции dpu_encoder_virt_atomic_mode_set() драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03760
Уязвимость функции bond_ipsec_add_sa() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03905
Уязвимость компонента spectrum_acl_tcam.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03906
Уязвимость компонента nft_chain_filter.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03913
Уязвимость компонента i40e_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03914
Уязвимость компонента pgtable.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03916
Уязвимость компонента dma-mapping ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03919
Уязвимость функций reserve_compress_blocks/release_compress_blocks компонента fs/f2fs/file.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03921
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2025-08-19
BDU:2025-03922
Уязвимость компонента ipvlan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-04173
Уязвимость компонента tun.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04175
Уязвимость компонента landlock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04181
Уязвимость компонента enic_main.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04182
Уязвимость компонента light.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04183
Уязвимость компонента data.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04184
Уязвимость компонента cadence_master.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04185
Уязвимость компонента max3100.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04186
Уязвимость компонента fslog.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04187
Уязвимость компонента stk1160-video.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04188
Уязвимость компонента sound/pci/hda/hda_cs_dsp_ctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-04189
Уязвимость компонента tcp_dctcp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-04193
Уязвимость компонента tap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04349
Уязвимость функции lgdt3306a_probe() модуля drivers/media/dvb-frontends/lgdt3306a.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04380
Уязвимость функции iwl_mvm_mld_rm_sta() модуля drivers/net/wireless/intel/iwlwifi/mvm/mld-sta.c - драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-04475
Уязвимость функции dce110_disable_stream() модуля drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04527
Уязвимость функции xsk_setsockopt() модуля net/xdp/xsk.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и целостность защищаемой информации
Modified: 2025-10-24
BDU:2025-04529
Уязвимость функции hv_uio_cleanup() модуля drivers/uio/uio_hv_generic.c - драйвера поддержки пользовательского ввода-вывода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04549
Уязвимость функции dfx_regs_uninit() драйвера drivers/crypto/hisilicon/debugfs.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-04639
Уязвимость функции stm32_cryp_irq_thread() - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04641
Уязвимость функции hisi_spi_probe() драйвера устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04658
Уязвимость функции iio_read_channel_info() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-07-01
BDU:2025-05879
Уязвимость функции adl_get_hybrid_cpu_type() модуля arch/x86/events/intel/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05913
Уязвимость функции btnxpuart_close() драйвера поддержки устройств Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-05914
Уязвимость функции create_lease_buf() подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-05915
Уязвимость функции ice_vsi_free() драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05916
Уязвимость функции irqfd_shutdown() поддержки драйверов Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05917
Уязвимость функции rtw_usb_init_rx() драйвера поддержки адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-07-01
BDU:2025-05921
Уязвимость функции ice_prepare_for_reset() драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05928
Уязвимость функции debug_event_write_work_handler() модуля drivers/gpu/drm/amd/amdkfd/kfd_debug.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-05930
Уязвимость функции resource_build_bit_depth_reduction_params() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05932
Уязвимость функции iwl_mvm_rcu_dereference_vif_id() драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05935
Уязвимость функции ufshcd_remove() драйвера UFS (Universal Flash Storage) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05976
Уязвимость функции gfx_v11_0_hw_init() драйвера поддержки инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05977
Уязвимость функции ath12k_station_assoc() драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-06023
Уязвимость модуля drivers/gpu/drm/vmwgfx/vmwgfx_kms.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-06971
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-06991
Уязвимость функции __vmbus_establish_gpadl() модуля drivers/hv/channel.c - драйвера поддержки гостевого режима Microsoft Hyper-V ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-06992
Уязвимость функции xbc_init() модуля include/linux/bootconfig.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07001
Уязвимость функции ModeSupportAndSystemConfiguration() драйвера drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07002
Уязвимость функции kvm_arch_vcpu_ioctl() модуля arch/x86/kvm/x86.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-07414
Уязвимость функции cifs_get_tcon_super() модуля fs/smb/client/cifsproto.h поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-16
BDU:2025-07455
Уязвимость функции vmbus_connect() модуля drivers/hv/connection.c - драйвера поддержки гостевого режима Microsoft Hyper-V ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-16
BDU:2025-07500
Уязвимость функции iocg_pay_debt() модуля block/blk-iocost.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07529
Уязвимость компонента microchip-core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08020
Уязвимость компонента fs/tracefs/event_inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08022
Уязвимость компонента net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08023
Уязвимость компонента altera-msgdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08027
Уязвимость компонента drivers/net/ethernet/mellanox/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08029
Уязвимость компонента s390/uv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08031
Уязвимость компонента ipvs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08032
Уязвимость компонента flow_dissector ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08036
Уязвимость компонента ntb_netdev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08038
Уязвимость компонентов core.c, fabrics-cmd-auth.c, fabrics-cmd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08039
Уязвимость компонента ondemand.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08040
Уязвимость компонента ondemand.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08041
Уязвимость компонента soc-topology.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08043
Уязвимость компонента SPARC. A ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08044
Уязвимость компонента smb2pdu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08056
Уязвимость компонентов vgic-init.c, vgic-mmio-v3.c, vgic.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08058
Уязвимость компонентов tty_ldisc.c, vt.c, tty_driver.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08059
Уязвимость компонента pageattr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08062
Уязвимость компонентов cmd.c, driver.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08063
Уязвимость компонента qplib_fp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08066
Уязвимость компонентов mpi3mr_app.c, scsi_bsg_mpi3mr.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08067
Уязвимость компонентов bloom_filter.c, bloom_filter_map.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08068
Уязвимость компонента ioctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-08
BDU:2025-08069
Уязвимость компонента llcp_sock.c ядра операционной системы Linux, позволяющая нарушителю а также вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08071
Уязвимость компонента amdgpu_dm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08072
Уязвимость компонента channel.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2026-03-19
BDU:2025-08073
Уязвимость компонентов hclge_main.c, hclgevf_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08074
Уязвимость компонента gpiolib-cdev.c ядра операционной системы Linux, позволяющая нарушителю а также вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08075
Уязвимость компонентов sch_taprio.c, taprio.json ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08076
Уязвимость компонента af_ax25.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08077
Уязвимость компонента hugetlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08079
Уязвимость компонентов page-flags.h, mmflags.h, vmcore_info.c, hugetlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08080
Уязвимость компонентов cdev.c, debugfs.c, device.c, idxd.h, init.c, irq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08081
Уязвимость компонентов page.h, init.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08083
Уязвимость компонентов inode.c, ioctl.c, root-tree.c, root-tree.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08085
Уязвимость компонента omap_prm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-08086
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2025-10-24
BDU:2025-08539
Уязвимость ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09671
Уязвимость модуля drivers/bluetooth/btnxpuart.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-11885
Уязвимость компонента fs/squashfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11956
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11996
Уязвимость компонентов ipv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12050
Уязвимость компонента drivers/media/i2c/et8ek8/et8ek8 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12228
Уязвимость компонента displayport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13349
Уязвимость компонентов x86/efistub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13350
Уязвимость компонента LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13353
Уязвимость компонентов drm/vc4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13354
Уязвимость компонентов x86/coco ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13356
Уязвимость компонентов drm/i915/bios ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13357
Уязвимость компонента dma-direct ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2025-13364
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13365
Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14134
Уязвимость функции of_modalias() модуля drivers/of/module.c - драйвера поддержки дерева устройств и открытой прошивки ядра операционной системы Linux, позволяющая удаленному нарушителю вызвать отказ в обслуживании
BDU:2025-14298
Уязвимость функции optc32_disable_crtc() модуля drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15047
Уязвимость функции mfill_atomic() модуля mm/userfaultfd.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15085
Уязвимость функции vdec_av1_slice_free_working_buffer() модуля drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15107
Уязвимость функции cros_ec_uart_probe() модуля drivers/platform/chrome/cros_ec_uart.c поддержки платформы оборудования Chrome OS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01327
Уязвимость функции flush_cache_all_local() модуля arch/parisc/include/asm/cacheflush.h поддержки архитектуры PA-RISC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
BDU:2026-01446
Уязвимость функции __ext4_fill_super() модуля fs/ext4/super.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01448
Уязвимость функции iwl_txq_reclaim() модуля drivers/net/wireless/intel/iwlwifi/queue/tx.c драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01449
Уязвимость функции free_netvsc_device() модуля drivers/net/hyperv/netvsc.c драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01450
Уязвимость определения структуры imx8mp_blk_ctrl_domain_data{} модуля drivers/pmdomain/imx/imx8mp-blk-ctrl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01451
Уязвимость функции ucsi_read_message_in() модуля drivers/usb/typec/ucsi/ucsi.c драйвера поддержки интерфейса системного программного обеспечения разъема USB Type- C (UCSI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02205
Уязвимость функции load_firmware_cb() драйвера тюнеров XCeive xc2028/xc3028 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03248
Уязвимость функции an30259a_probe() модуля drivers/leds/leds-an30259a.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03318
Уязвимость функции create_io_worker() модуля io_uring/io-wq.c интерфейса асинхронного ввода/вывода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03498
Уязвимость функции __sync_icache_dcache() модуля arch/arm/mm/flush.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03501
Уязвимость функции skb_frag_ref() модуля include/linux/skbuff.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03508
Уязвимость функции panfrost_mmu_map_fault_addr() модуля drivers/gpu/drm/panfrost/panfrost_mmu.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03509
Уязвимость функции mlx5_init_one_devl_locked() модуля drivers/net/ethernet/mellanox/mlx5/core/main.c драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03638
Уязвимость функции bpf_prog_attach_check_attach_type() модуля kernel/bpf/syscall.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04263
Уязвимость функции __bio_release_pages() модуля block/bio.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04272
Уязвимость функции blkcg_css_online() модуля block/blk-cgroup.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04273
Уязвимость функции ks8851_rx_pkts() модуля drivers/net/ethernet/micrel/ks8851_common.c драйвера поддержки сетевых адаптеров Ethernet Micrel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04385
Уязвимость функции bpf_link_inc() модуля kernel/bpf/syscall.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04541
Уязвимость функции do_sync_mmap_readahead() модуля mm/filemap.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06104
Уязвимость функции kgd2kfd_suspend() модуля drivers/gpu/drm/amd/amdkfd/kfd_device.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2022-48772
In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[ 29.612820] Call Trace:
[ 29.613030]
- https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea
- https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87
- https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0
- https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115
- https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4
- https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d
- https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676
- https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea
- https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87
- https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0
- https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115
- https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4
- https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d
- https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676
Modified: 2025-09-18
CVE-2023-52647
In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Check whether crossbar pad is non-NULL before access When translating source to sink streams in the crossbar subdev, the driver tries to locate the remote subdev connected to the sink pad. The remote pad may be NULL, if userspace tries to enable a stream that ends at an unconnected crossbar sink. When that occurs, the driver dereferences the NULL pad, leading to a crash. Prevent the crash by checking if the pad is NULL before using it, and return an error if it is.
- https://git.kernel.org/stable/c/91c8ce42fcde09f1da24acab9013b3e19cb88a4e
- https://git.kernel.org/stable/c/c4bd29bf5b7f67925bc1abd16069f22dadf5f061
- https://git.kernel.org/stable/c/c95318607fbe8fdd44991a8dad2e44118e6b8812
- https://git.kernel.org/stable/c/eb2f932100288dbb881eadfed02e1459c6b9504c
- https://git.kernel.org/stable/c/91c8ce42fcde09f1da24acab9013b3e19cb88a4e
- https://git.kernel.org/stable/c/c4bd29bf5b7f67925bc1abd16069f22dadf5f061
- https://git.kernel.org/stable/c/c95318607fbe8fdd44991a8dad2e44118e6b8812
- https://git.kernel.org/stable/c/eb2f932100288dbb881eadfed02e1459c6b9504c
Modified: 2025-09-18
CVE-2023-52648
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Unmap the surface before resetting it on a plane state
Switch to a new plane state requires unreferencing of all held surfaces.
In the work required for mob cursors the mapped surfaces started being
cached but the variable indicating whether the surface is currently
mapped was not being reset. This leads to crashes as the duplicated
state, incorrectly, indicates the that surface is mapped even when
no surface is present. That's because after unreferencing the surface
it's perfectly possible for the plane to be backed by a bo instead of a
surface.
Reset the surface mapped flag when unreferencing the plane state surface
to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600
RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920
R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000
R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00
FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0
Call Trace:
- https://git.kernel.org/stable/c/0a23f95af7f28dae7c0f7c82578ca5e1a239d461
- https://git.kernel.org/stable/c/105f72cc48c4c93f4578fcc61e06276471858e92
- https://git.kernel.org/stable/c/27571c64f1855881753e6f33c3186573afbab7ba
- https://git.kernel.org/stable/c/75baad63c033b3b900d822bffbc96c9d3649bc75
- https://git.kernel.org/stable/c/0a23f95af7f28dae7c0f7c82578ca5e1a239d461
- https://git.kernel.org/stable/c/105f72cc48c4c93f4578fcc61e06276471858e92
- https://git.kernel.org/stable/c/27571c64f1855881753e6f33c3186573afbab7ba
- https://git.kernel.org/stable/c/75baad63c033b3b900d822bffbc96c9d3649bc75
Modified: 2025-09-25
CVE-2023-52671
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix hang/underflow when transitioning to ODM4:1 [Why] Under some circumstances, disabling an OPTC and attempting to reclaim its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs not being properly disconnected from the disabled OPTC. [How] Ensure that all OPPs are unassigned from an OPTC when it gets disabled.
- https://git.kernel.org/stable/c/4b6b479b2da6badff099b2e3abf0248936eefbf5
- https://git.kernel.org/stable/c/ae62f1dde66a6f0eee98defc4c7a346bd5acd239
- https://git.kernel.org/stable/c/e7b2b108cdeab76a7e7324459e50b0c1214c0386
- https://git.kernel.org/stable/c/4b6b479b2da6badff099b2e3abf0248936eefbf5
- https://git.kernel.org/stable/c/ae62f1dde66a6f0eee98defc4c7a346bd5acd239
- https://git.kernel.org/stable/c/e7b2b108cdeab76a7e7324459e50b0c1214c0386
Modified: 2025-04-04
CVE-2023-52699
In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).
- https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76
- https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f
- https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09
- https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1
- https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac
- https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3
- https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e
- https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927
- https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76
- https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f
- https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09
- https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1
- https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac
- https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3
- https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e
- https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2026-01-22
CVE-2023-52882
In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.
- https://git.kernel.org/stable/c/0b82eb134d2942ecc669e2ab2be3f0a58d79428a
- https://git.kernel.org/stable/c/70f64cb29014e4c4f1fabd3265feebd80590d069
- https://git.kernel.org/stable/c/7e91ed763dc07437777bd012af7a2bd4493731ff
- https://git.kernel.org/stable/c/9708e5081cfc4f085690294163389bcf82655f90
- https://git.kernel.org/stable/c/bfc78b4628497eb6df09a6b5bba9dd31616ee175
- https://git.kernel.org/stable/c/f1fa9a9816204ac4b118b2e613d3a7c981355019
- https://git.kernel.org/stable/c/fe11826ffa200e1a7a826e745163cb2f47875f66
- https://git.kernel.org/stable/c/0b82eb134d2942ecc669e2ab2be3f0a58d79428a
- https://git.kernel.org/stable/c/70f64cb29014e4c4f1fabd3265feebd80590d069
- https://git.kernel.org/stable/c/7e91ed763dc07437777bd012af7a2bd4493731ff
- https://git.kernel.org/stable/c/9708e5081cfc4f085690294163389bcf82655f90
- https://git.kernel.org/stable/c/bfc78b4628497eb6df09a6b5bba9dd31616ee175
- https://git.kernel.org/stable/c/f1fa9a9816204ac4b118b2e613d3a7c981355019
- https://git.kernel.org/stable/c/fe11826ffa200e1a7a826e745163cb2f47875f66
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://security.netapp.com/advisory/ntap-20240912-0010/
Modified: 2025-03-24
CVE-2023-52884
In the Linux kernel, the following vulnerability has been resolved: Input: cyapa - add missing input core locking to suspend/resume functions Grab input->mutex during suspend/resume functions like it is done in other input drivers. This fixes the following warning during system suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6
- https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7
- https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd
- https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc
- https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75
- https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6
- https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7
- https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd
- https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc
- https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75
Modified: 2025-11-03
CVE-2023-52887
In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done
- https://git.kernel.org/stable/c/0bc0a7416ea73f79f915c9a05ac0858dff65cfed
- https://git.kernel.org/stable/c/1762ca80c2b72dd1b5821c5e347713ae696276ea
- https://git.kernel.org/stable/c/177e33b655d35d72866b50aec84307119dc5f3d4
- https://git.kernel.org/stable/c/26b18dd30e63d4fd777be429148e8e4ed66f60b2
- https://git.kernel.org/stable/c/d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb
- https://git.kernel.org/stable/c/ed581989d7ea9df6f8646beba2341e32cd49a1f9
- https://git.kernel.org/stable/c/f6c839e717901dbd6b1c1ca807b6210222eb70f6
- https://git.kernel.org/stable/c/0bc0a7416ea73f79f915c9a05ac0858dff65cfed
- https://git.kernel.org/stable/c/1762ca80c2b72dd1b5821c5e347713ae696276ea
- https://git.kernel.org/stable/c/177e33b655d35d72866b50aec84307119dc5f3d4
- https://git.kernel.org/stable/c/26b18dd30e63d4fd777be429148e8e4ed66f60b2
- https://git.kernel.org/stable/c/d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb
- https://git.kernel.org/stable/c/ed581989d7ea9df6f8646beba2341e32cd49a1f9
- https://git.kernel.org/stable/c/f6c839e717901dbd6b1c1ca807b6210222eb70f6
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-07
CVE-2023-52888
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Only free buffer VA that is not NULL In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings.
- https://git.kernel.org/stable/c/303d01082edaf817ee2df53a40dca9da637a2c04
- https://git.kernel.org/stable/c/5c217253c76c94f76d1df31d0bbdcb88dc07be91
- https://git.kernel.org/stable/c/eb005c801ec70ff4307727bd3bd6e8280169ef32
- https://git.kernel.org/stable/c/303d01082edaf817ee2df53a40dca9da637a2c04
- https://git.kernel.org/stable/c/5c217253c76c94f76d1df31d0bbdcb88dc07be91
- https://git.kernel.org/stable/c/eb005c801ec70ff4307727bd3bd6e8280169ef32
Modified: 2025-11-03
CVE-2023-52889
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix null pointer deref when receiving skb during sock creation
The panic below is observed when receiving ICMP packets with secmark set
while an ICMP raw socket is being created. SK_CTX(sk)->label is updated
in apparmor_socket_post_create(), but the packet is delivered to the
socket before that, causing the null pointer dereference.
Drop the packet if label context is not set.
BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/0abe35bc48d4ec80424b1f4b3560c0e082cbd5c1
- https://git.kernel.org/stable/c/290a6b88e8c19b6636ed1acc733d1458206f7697
- https://git.kernel.org/stable/c/347dcb84a4874b5fb375092c08d8cc4069b94f81
- https://git.kernel.org/stable/c/46c17ead5b7389e22e7dc9903fd0ba865d05bda2
- https://git.kernel.org/stable/c/6c920754f62cefc63fccdc38a062c7c3452e2961
- https://git.kernel.org/stable/c/ead2ad1d9f045f26fdce3ef1644913b3a6cd38f2
- https://git.kernel.org/stable/c/fce09ea314505a52f2436397608fa0a5d0934fb1
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2023-52918
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.
- https://git.kernel.org/stable/c/06ee04a907d64ee3910fecedd05d7f1be4b1b70e
- https://git.kernel.org/stable/c/15126b916e39b0cb67026b0af3c014bfeb1f76b3
- https://git.kernel.org/stable/c/199a42fc4c45e8b7f19efeb15dbc36889a599ac2
- https://git.kernel.org/stable/c/8e31b096e2e1949bc8f0be019c9ae70d414404c6
- https://git.kernel.org/stable/c/a5f1d30c51c485cec7a7de60205667c3ff86c303
- https://git.kernel.org/stable/c/b1397fb4a779fca560c43d2acf6702d41b4a495b
- https://git.kernel.org/stable/c/e7385510e2550a9f8b6f3d5f33c5b894ab9ba976
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-01-22
CVE-2024-23307
Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.
Modified: 2025-03-05
CVE-2024-24857
A race condition was found in the Linux kernel's net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.
- https://bugzilla.openanolis.cn/show_bug.cgi?id=8155
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://bugzilla.openanolis.cn/show_bug.cgi?id=8155
- 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-05
CVE-2024-24858
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.
- https://bugzilla.openanolis.cn/show_bug.cgi?id=8154
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://bugzilla.openanolis.cn/show_bug.cgi?id=8154
- 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-16
CVE-2024-26621
In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: don't force huge page alignment on 32 bit commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/
- https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d
- https://git.kernel.org/stable/c/6ea9aa8d97e6563676094cb35755884173269555
- https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47
- https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe
- http://www.openwall.com/lists/oss-security/2024/07/08/3
- http://www.openwall.com/lists/oss-security/2024/07/08/4
- http://www.openwall.com/lists/oss-security/2024/07/08/5
- http://www.openwall.com/lists/oss-security/2024/07/08/6
- http://www.openwall.com/lists/oss-security/2024/07/08/7
- http://www.openwall.com/lists/oss-security/2024/07/08/8
- http://www.openwall.com/lists/oss-security/2024/07/09/1
- http://www.openwall.com/lists/oss-security/2024/07/10/5
- http://www.openwall.com/lists/oss-security/2024/07/10/7
- http://www.openwall.com/lists/oss-security/2024/07/10/8
- http://www.openwall.com/lists/oss-security/2024/07/11/4
- http://www.openwall.com/lists/oss-security/2024/07/11/5
- http://www.openwall.com/lists/oss-security/2024/07/11/7
- http://www.openwall.com/lists/oss-security/2024/07/12/3
- http://www.openwall.com/lists/oss-security/2024/07/13/2
- http://www.openwall.com/lists/oss-security/2024/07/13/7
- http://www.openwall.com/lists/oss-security/2024/07/15/1
- http://www.openwall.com/lists/oss-security/2024/07/15/2
- http://www.openwall.com/lists/oss-security/2024/07/16/1
- http://www.openwall.com/lists/oss-security/2024/07/16/2
- http://www.openwall.com/lists/oss-security/2024/07/29/2
- http://www.openwall.com/lists/oss-security/2024/07/30/2
- https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d
- https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47
- https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe
- https://zolutal.github.io/aslrnt/
Modified: 2025-03-13
CVE-2024-26642
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this. Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
- https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1
- https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a
- https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199
- https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7
- https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12
- https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9
- https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f
- https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351
- https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1
- https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a
- https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199
- https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7
- https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12
- https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9
- https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f
- https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-13
CVE-2024-26643
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.
- https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363
- https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163
- https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8
- https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36
- https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1
- https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033
- https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c
- https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf
- https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363
- https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163
- https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8
- https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36
- https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1
- https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033
- https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c
- https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-03
CVE-2024-26654
In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below: (Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | ... | run_spu_dma() //worker | mod_timer() flush_work() | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() | run_spu_dma() //worker ... | dreamcastcard->channel-> //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.
- https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457
- https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04
- https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2
- https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901
- https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5
- https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046
- https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845
- https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3
- https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2
- https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457
- https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04
- https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2
- https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901
- https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5
- https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046
- https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845
- https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3
- https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26810
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows.
- https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf
- https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651
- https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42
- https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3
- https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5
- https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40
- https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7
- https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6
- https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf
- https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651
- https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42
- https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3
- https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5
- https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40
- https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7
- https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-18
CVE-2024-26812
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Create persistent INTx handler A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending. Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace. As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.
- https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034
- https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d
- https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897
- https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834
- https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c
- https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e
- https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3
- https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899
- https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034
- https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d
- https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897
- https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834
- https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c
- https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e
- https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3
- https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-20
CVE-2024-26813
In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index.
- https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e
- https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5
- https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29
- https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086
- https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375
- https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362
- https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a
- https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f
- https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e
- https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5
- https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29
- https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086
- https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375
- https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362
- https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a
- https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-27
CVE-2024-26814
In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.
- https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417
- https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d
- https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9
- https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012
- https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede
- https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d
- https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267
- https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417
- https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d
- https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9
- https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012
- https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede
- https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d
- https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2024-26817
In the Linux kernel, the following vulnerability has been resolved: amdkfd: use calloc instead of kzalloc to avoid integer overflow This uses calloc instead of doing the multiplication which might overflow.
- https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a
- https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7
- https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29
- https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0
- https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad
- https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751
- https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a
- https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91
- https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a
- https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7
- https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29
- https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0
- https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad
- https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751
- https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a
- https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/P3TH6JK7ZZMSXSVHOJKIMSSOC6EQM4WV/
Modified: 2025-11-03
CVE-2024-26921
In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.
- https://git.kernel.org/stable/c/18685451fc4e546fc0e718580d32df3c0e5c8272
- https://git.kernel.org/stable/c/1b6de5e6575b56502665c65cf93b0ae6aa0f51ab
- https://git.kernel.org/stable/c/4318608dc28ef184158b4045896740716bea23f0
- https://git.kernel.org/stable/c/7d0567842b78390dd9b60f00f1d8f838d540e325
- https://git.kernel.org/stable/c/9705f447bf9a6cd088300ad2c407b5e1c6591091
- https://git.kernel.org/stable/c/e09cbe017311508c21e0739e97198a8388b98981
- https://git.kernel.org/stable/c/f4877225313d474659ee53150ccc3d553a978727
- https://git.kernel.org/stable/c/18685451fc4e546fc0e718580d32df3c0e5c8272
- https://git.kernel.org/stable/c/7d0567842b78390dd9b60f00f1d8f838d540e325
- https://git.kernel.org/stable/c/e09cbe017311508c21e0739e97198a8388b98981
- https://git.kernel.org/stable/c/f4877225313d474659ee53150ccc3d553a978727
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-12-23
CVE-2024-26922
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate the parameters of bo mapping operations more clearly Verify the parameters of amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
- https://git.kernel.org/stable/c/1fd7db5c16028dc07b2ceec190f2e895dddb532d
- https://git.kernel.org/stable/c/212e3baccdb1939606420d88f7f52d346b49a284
- https://git.kernel.org/stable/c/6fef2d4c00b5b8561ad68dd2b68173f5c6af1e75
- https://git.kernel.org/stable/c/8b12fc7b032633539acdf7864888b0ebd49e90f2
- https://git.kernel.org/stable/c/b1f04b9b1c5317f562a455384c5f7473e46bdbaa
- https://git.kernel.org/stable/c/d4da6b084f1c5625937d49bb6722c5b4aef11b8d
- https://git.kernel.org/stable/c/ef13eeca7c79136bc38e21eb67322c1cbd5c40ee
- https://git.kernel.org/stable/c/f68039375d4d6d67303674c0ab2d06b7295c0ec9
- https://git.kernel.org/stable/c/1fd7db5c16028dc07b2ceec190f2e895dddb532d
- https://git.kernel.org/stable/c/212e3baccdb1939606420d88f7f52d346b49a284
- https://git.kernel.org/stable/c/6fef2d4c00b5b8561ad68dd2b68173f5c6af1e75
- https://git.kernel.org/stable/c/8b12fc7b032633539acdf7864888b0ebd49e90f2
- https://git.kernel.org/stable/c/b1f04b9b1c5317f562a455384c5f7473e46bdbaa
- https://git.kernel.org/stable/c/d4da6b084f1c5625937d49bb6722c5b4aef11b8d
- https://git.kernel.org/stable/c/ef13eeca7c79136bc38e21eb67322c1cbd5c40ee
- https://git.kernel.org/stable/c/f68039375d4d6d67303674c0ab2d06b7295c0ec9
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26923
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix garbage collector racing against connect() Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCM_RIGHTS, two consecutive passes of scan_children() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gc_inflight_list. sockets are AF_UNIX/SOCK_STREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc() ---------------- ------------------------- ----------- NS = unix_create1() skb1 = sock_wmalloc(NS) L = unix_find_other(addr) unix_state_lock(L) unix_peer(S) = NS // V count=1 inflight=0 NS = unix_peer(S) skb2 = sock_alloc() skb_queue_tail(NS, skb2[V]) // V became in-flight // V count=2 inflight=1 close(V) // V count=1 inflight=1 // GC candidate condition met for u in gc_inflight_list: if (total_refs == inflight_refs) add u to gc_candidates // gc_candidates={L, V} for u in gc_candidates: scan_children(u, dec_inflight) // embryo (skb1) was not // reachable from L yet, so V's // inflight remains unchanged __skb_queue_tail(L, skb1) unix_state_unlock(L) for u in gc_candidates: if (u.inflight) scan_children(u, inc_inflight_move_tail) // V count=1 inflight=2 (!) If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCM_RIGHTS. At this point, unix_inflight() can not happen because unix_gc_lock is already taken. Inflight graph remains unaffected.
- https://git.kernel.org/stable/c/2e2a03787f4f0abc0072350654ab0ef3324d9db3
- https://git.kernel.org/stable/c/343c5372d5e17b306db5f8f3c895539b06e3177f
- https://git.kernel.org/stable/c/47d8ac011fe1c9251070e1bd64cb10b48193ec51
- https://git.kernel.org/stable/c/507cc232ffe53a352847893f8177d276c3b532a9
- https://git.kernel.org/stable/c/a36ae0ec2353015f0f6762e59f4c2dbc0c906423
- https://git.kernel.org/stable/c/b75722be422c276b699200de90527d01c602ea7c
- https://git.kernel.org/stable/c/dbdf7bec5c920200077d693193f989cb1513f009
- https://git.kernel.org/stable/c/e76c2678228f6aec74b305ae30c9374cc2f28a51
- https://git.kernel.org/stable/c/2e2a03787f4f0abc0072350654ab0ef3324d9db3
- https://git.kernel.org/stable/c/343c5372d5e17b306db5f8f3c895539b06e3177f
- https://git.kernel.org/stable/c/47d8ac011fe1c9251070e1bd64cb10b48193ec51
- https://git.kernel.org/stable/c/507cc232ffe53a352847893f8177d276c3b532a9
- https://git.kernel.org/stable/c/a36ae0ec2353015f0f6762e59f4c2dbc0c906423
- https://git.kernel.org/stable/c/b75722be422c276b699200de90527d01c602ea7c
- https://git.kernel.org/stable/c/dbdf7bec5c920200077d693193f989cb1513f009
- https://git.kernel.org/stable/c/e76c2678228f6aec74b305ae30c9374cc2f28a51
- 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-26924
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)
- https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487
- https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc
- https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644
- https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46
- https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2
- https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a
- https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487
- https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc
- https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644
- https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46
- https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2
- https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26925
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence. nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called.
- https://git.kernel.org/stable/c/0d459e2ffb541841714839e8228b845458ed3b27
- https://git.kernel.org/stable/c/2cee2ff7f8cce12a63a0a23ffe27f08d99541494
- https://git.kernel.org/stable/c/61ac7284346c32f9a8c8ceac56102f7914060428
- https://git.kernel.org/stable/c/8038ee3c3e5b59bcd78467686db5270c68544e30
- https://git.kernel.org/stable/c/8d3a58af50e46167b6f1db47adadad03c0045dae
- https://git.kernel.org/stable/c/a34ba4bdeec0c3b629160497594908dc820110f1
- https://git.kernel.org/stable/c/eb769ff4e281f751adcaf4f4445cbf30817be139
- https://git.kernel.org/stable/c/0d459e2ffb541841714839e8228b845458ed3b27
- https://git.kernel.org/stable/c/2cee2ff7f8cce12a63a0a23ffe27f08d99541494
- https://git.kernel.org/stable/c/61ac7284346c32f9a8c8ceac56102f7914060428
- https://git.kernel.org/stable/c/8038ee3c3e5b59bcd78467686db5270c68544e30
- https://git.kernel.org/stable/c/8d3a58af50e46167b6f1db47adadad03c0045dae
- https://git.kernel.org/stable/c/a34ba4bdeec0c3b629160497594908dc820110f1
- https://git.kernel.org/stable/c/eb769ff4e281f751adcaf4f4445cbf30817be139
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-26926
In the Linux kernel, the following vulnerability has been resolved: binder: check offset alignment in binder_get_object() Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binder_alloc_copy_from_buffer() -> check_buffer(). These calls were replaced in binder_get_object() with copy_from_user(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder. It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time.
- https://git.kernel.org/stable/c/1d7f1049035b2060342f11eff957cf567d810bdc
- https://git.kernel.org/stable/c/48a1f83ca9c68518b1a783c62e6a8223144fa9fc
- https://git.kernel.org/stable/c/68a28f551e4690db2b27b3db716c7395f6fada12
- https://git.kernel.org/stable/c/a2fd6dbc98be1105a1d8e9e31575da8873ef115c
- https://git.kernel.org/stable/c/a6d2a8b211c874971ee4cf3ddd167408177f6e76
- https://git.kernel.org/stable/c/aaef73821a3b0194a01bd23ca77774f704a04d40
- https://git.kernel.org/stable/c/f01d6619045704d78613b14e2e0420bfdb7f1c15
- https://git.kernel.org/stable/c/1d7f1049035b2060342f11eff957cf567d810bdc
- https://git.kernel.org/stable/c/48a1f83ca9c68518b1a783c62e6a8223144fa9fc
- https://git.kernel.org/stable/c/68a28f551e4690db2b27b3db716c7395f6fada12
- https://git.kernel.org/stable/c/a2fd6dbc98be1105a1d8e9e31575da8873ef115c
- https://git.kernel.org/stable/c/a6d2a8b211c874971ee4cf3ddd167408177f6e76
- https://git.kernel.org/stable/c/aaef73821a3b0194a01bd23ca77774f704a04d40
- https://git.kernel.org/stable/c/f01d6619045704d78613b14e2e0420bfdb7f1c15
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-01
CVE-2024-26928
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88
- https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1
- https://git.kernel.org/stable/c/8f8718afd446cd4ea3b62bacc3eec09f8aae85ee
- https://git.kernel.org/stable/c/a140224bcf87eb98a87b67ff4c6826c57e47b704
- https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d
- https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502
- https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88
- https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1
- https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d
- https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-03-07
CVE-2024-26930
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of the ha->vp_map pointer Coverity scan reported potential risk of double free of the pointer ha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freed in function qla2x00_mem_free(ha). Assign NULL to vp_map and kfree take care of NULL.
- https://git.kernel.org/stable/c/825d63164a2e6bacb059a9afb5605425b485413f
- https://git.kernel.org/stable/c/b7deb675d674f44e0ddbab87fee8f9f098925e73
- https://git.kernel.org/stable/c/e288285d47784fdcf7c81be56df7d65c6f10c58b
- https://git.kernel.org/stable/c/f14cee7a882cb79528f17a2335f53e9fd1848467
- https://git.kernel.org/stable/c/825d63164a2e6bacb059a9afb5605425b485413f
- https://git.kernel.org/stable/c/b7deb675d674f44e0ddbab87fee8f9f098925e73
- https://git.kernel.org/stable/c/e288285d47784fdcf7c81be56df7d65c6f10c58b
- https://git.kernel.org/stable/c/f14cee7a882cb79528f17a2335f53e9fd1848467
Modified: 2025-03-04
CVE-2024-26931
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix command flush on cable pull System crash due to command failed to flush back to SCSI layer. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200. ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0 ? __switch_to+0x10c/0x450 ? process_one_work+0x1a7/0x360 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201. ? worker_thread+0x1ce/0x390 ? create_worker+0x1a0/0x1a0 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70 ? kthread+0x10a/0x120 qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8 ? set_kthread_struct+0x40/0x40 qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed. ? ret_from_fork+0x1f/0x40 qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout The system was under memory stress where driver was not able to allocate an SRB to carry out error recovery of cable pull. The failure to flush causes upper layer to start modifying scsi_cmnd. When the system frees up some memory, the subsequent cable pull trigger another command flush. At this point the driver access a null pointer when attempting to DMA unmap the SGL. Add a check to make sure commands are flush back on session tear down to prevent the null pointer access.
- https://git.kernel.org/stable/c/09c0ac18cac206ed1218b1fe6c1a0918e5ea9211
- https://git.kernel.org/stable/c/67b2d35853c2da25a8ca1c4190a5e96d3083c2ac
- https://git.kernel.org/stable/c/8de1584ec4fe0ebea33c273036e7e0a05e65c81d
- https://git.kernel.org/stable/c/8f0d32004e3a572bb77e6c11c2797c87f8c9703d
- https://git.kernel.org/stable/c/a27d4d0e7de305def8a5098a614053be208d1aa1
- https://git.kernel.org/stable/c/a859f6a8f4234b8ef62862bf7a92f1af5f8cd47a
- https://git.kernel.org/stable/c/b73377124f56d2fec154737c2f8d2e839c237d5a
- https://git.kernel.org/stable/c/d7a68eee87b05d4e29419e6f151aef99314970a9
- https://git.kernel.org/stable/c/ec7587eef003cab15a13446d67c3adb88146a150
- https://git.kernel.org/stable/c/09c0ac18cac206ed1218b1fe6c1a0918e5ea9211
- https://git.kernel.org/stable/c/67b2d35853c2da25a8ca1c4190a5e96d3083c2ac
- https://git.kernel.org/stable/c/8de1584ec4fe0ebea33c273036e7e0a05e65c81d
- https://git.kernel.org/stable/c/8f0d32004e3a572bb77e6c11c2797c87f8c9703d
- https://git.kernel.org/stable/c/a27d4d0e7de305def8a5098a614053be208d1aa1
- https://git.kernel.org/stable/c/a859f6a8f4234b8ef62862bf7a92f1af5f8cd47a
- https://git.kernel.org/stable/c/b73377124f56d2fec154737c2f8d2e839c237d5a
- https://git.kernel.org/stable/c/d7a68eee87b05d4e29419e6f151aef99314970a9
- https://git.kernel.org/stable/c/ec7587eef003cab15a13446d67c3adb88146a150
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-07
CVE-2024-26933
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in port "disable" sysfs attribute The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration: Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and device_del() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then. But the disable_show() or disable_store() routine can't return until after it has acquired the lock. The resulting deadlock can be avoided by calling sysfs_break_active_protection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hub_get().
- https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7
- https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e
- https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05
- https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1
- https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c
- https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7
- https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e
- https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05
- https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1
- https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c
Modified: 2024-11-21
CVE-2024-26934
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface's parent
USB device.
The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected. As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete. But usb_deauthorize_interface() can't complete
until the device lock has been released, and the lock won't be
released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.
Reported-and-tested by: Yue Sun
- https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6
- https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384
- https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947
- https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a
- https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5
- https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f
- https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5
- https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057
- https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9
- https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6
- https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384
- https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947
- https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a
- https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5
- https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f
- https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5
- https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057
- https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-26935
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix unremoved procfs host directory regression Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example. Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure): usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case. This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.
- https://git.kernel.org/stable/c/0053f15d50d50c9312d8ab9c11e2e405812dfcac
- https://git.kernel.org/stable/c/3678cf67ff7136db1dd3bf63c361650db5d92889
- https://git.kernel.org/stable/c/5c2386ba80e779a92ec3bb64ccadbedd88f779b1
- https://git.kernel.org/stable/c/cea234bb214b17d004dfdccce4491e6ff57c96ee
- https://git.kernel.org/stable/c/d4c34782b6d7b1e68d18d9549451b19433bd4c6c
- https://git.kernel.org/stable/c/e293c773c13b830cdc251f155df2254981abc320
- https://git.kernel.org/stable/c/f23a4d6e07570826fe95023ca1aa96a011fa9f84
- https://git.kernel.org/stable/c/f4ff08fab66eb5c0b97e1a24edac052fb40bf5d7
- https://git.kernel.org/stable/c/0053f15d50d50c9312d8ab9c11e2e405812dfcac
- https://git.kernel.org/stable/c/3678cf67ff7136db1dd3bf63c361650db5d92889
- https://git.kernel.org/stable/c/5c2386ba80e779a92ec3bb64ccadbedd88f779b1
- https://git.kernel.org/stable/c/cea234bb214b17d004dfdccce4491e6ff57c96ee
- https://git.kernel.org/stable/c/d4c34782b6d7b1e68d18d9549451b19433bd4c6c
- https://git.kernel.org/stable/c/e293c773c13b830cdc251f155df2254981abc320
- https://git.kernel.org/stable/c/f23a4d6e07570826fe95023ca1aa96a011fa9f84
- https://git.kernel.org/stable/c/f4ff08fab66eb5c0b97e1a24edac052fb40bf5d7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-26936
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate request buffer size in smb2_allocate_rsp_buf() The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.
- https://git.kernel.org/stable/c/17cf0c2794bdb6f39671265aa18aea5c22ee8c4a
- https://git.kernel.org/stable/c/21ff9d7d223c5c19cb4334009e4c0c83a2f4d674
- https://git.kernel.org/stable/c/2c27a64a2bc47d9bfc7c3cf8be14be53b1ee7cb6
- https://git.kernel.org/stable/c/5c20b242d4fed73a93591e48bfd9772e2322fb11
- https://git.kernel.org/stable/c/8f3d0bf1d0c62b539d54c5b9108a845cff619b99
- https://git.kernel.org/stable/c/17cf0c2794bdb6f39671265aa18aea5c22ee8c4a
- https://git.kernel.org/stable/c/21ff9d7d223c5c19cb4334009e4c0c83a2f4d674
- https://git.kernel.org/stable/c/2c27a64a2bc47d9bfc7c3cf8be14be53b1ee7cb6
- https://git.kernel.org/stable/c/5c20b242d4fed73a93591e48bfd9772e2322fb11
- https://git.kernel.org/stable/c/8f3d0bf1d0c62b539d54c5b9108a845cff619b99
Modified: 2025-12-23
CVE-2024-26937
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Reset queue_priority_hint on parking
Originally, with strict in order execution, we could complete execution
only when the queue was empty. Preempt-to-busy allows replacement of an
active request that may complete before the preemption is processed by
HW. If that happens, the request is retired from the queue, but the
queue_priority_hint remains set, preventing direct submission until
after the next CS interrupt is processed.
This preempt-to-busy race can be triggered by the heartbeat, which will
also act as the power-management barrier and upon completion allow us to
idle the HW. We may process the completion of the heartbeat, and begin
parking the engine before the CS event that restores the
queue_priority_hint, causing us to fail the assertion that it is MIN.
<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
<0>[ 166.210781] Dumping ftrace buffer:
<0>[ 166.210795] ---------------------------------
...
<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646
<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40
<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }
<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
<0>[ 167.303534]
- https://git.kernel.org/stable/c/3b031e4fcb2740988143c303f81f69f18ce86325
- https://git.kernel.org/stable/c/4a3859ea5240365d21f6053ee219bb240d520895
- https://git.kernel.org/stable/c/67944e6db656bf1e986aa2a359f866f851091f8a
- https://git.kernel.org/stable/c/7eab7b021835ae422c38b968d5cc60e99408fb62
- https://git.kernel.org/stable/c/8fd9b0ce8c26533fe4d5d15ea15bbf7b904b611c
- https://git.kernel.org/stable/c/ac9b6b3e8d1237136c8ebf0fa1ce037dd7e2948f
- https://git.kernel.org/stable/c/aed034866a08bb7e6e34d50a5629a4d23fe83703
- https://git.kernel.org/stable/c/fe34587acc995e7b1d7a5d3444a0736721ec32b3
- https://git.kernel.org/stable/c/3b031e4fcb2740988143c303f81f69f18ce86325
- https://git.kernel.org/stable/c/4a3859ea5240365d21f6053ee219bb240d520895
- https://git.kernel.org/stable/c/67944e6db656bf1e986aa2a359f866f851091f8a
- https://git.kernel.org/stable/c/7eab7b021835ae422c38b968d5cc60e99408fb62
- https://git.kernel.org/stable/c/8fd9b0ce8c26533fe4d5d15ea15bbf7b904b611c
- https://git.kernel.org/stable/c/ac9b6b3e8d1237136c8ebf0fa1ce037dd7e2948f
- https://git.kernel.org/stable/c/aed034866a08bb7e6e34d50a5629a4d23fe83703
- https://git.kernel.org/stable/c/fe34587acc995e7b1d7a5d3444a0736721ec32b3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-01-05
CVE-2024-26938
In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() If we have no VBT, or the VBT didn't declare the encoder in question, we won't have the 'devdata' for the encoder. Instead of oopsing just bail early. We won't be able to tell whether the port is DP++ or not, but so be it. (cherry picked from commit 26410896206342c8a80d2b027923e9ee7d33b733)
- https://git.kernel.org/stable/c/32e39bab59934bfd3f37097d4dd85ac5eb0fd549
- https://git.kernel.org/stable/c/94cf2fb6feccd625e5b4e23e1b70f39a206f82ac
- https://git.kernel.org/stable/c/a891add409e3bc381f4f68c2ce9d953f1865cb1f
- https://git.kernel.org/stable/c/f4bbac954d8f9ab214ea1d4f385de4fa6bd92dd0
- https://git.kernel.org/stable/c/32e39bab59934bfd3f37097d4dd85ac5eb0fd549
- https://git.kernel.org/stable/c/72e4d3fb72e9f0f016946158a7d95304832768e6
- https://git.kernel.org/stable/c/94cf2fb6feccd625e5b4e23e1b70f39a206f82ac
- https://git.kernel.org/stable/c/a891add409e3bc381f4f68c2ce9d953f1865cb1f
- https://git.kernel.org/stable/c/f4bbac954d8f9ab214ea1d4f385de4fa6bd92dd0
Modified: 2025-04-08
CVE-2024-26939
In the Linux kernel, the following vulnerability has been resolved: drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 ... [161.361347] debug_object_free+0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] release_references+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] [161.363129] __gt_park+0x121/0x230 [i915] [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915] That has been tracked down to be happening when another thread is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool. We could prevent from that race by serializing i915_active_fini() with __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from __gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and the GT parked. I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915_active_fini() from a dropped i915_vma_release(), called on last put of the removed VMA kref, to i915_vma_parked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation"). A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation. Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since __i915_vma_retire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed. v7: Add inline comments with justifications for: - using untracked variants of intel_gt_pm_get/put() (Nirmoy), - using async variant of _put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since __i915_vma_active/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915_vma is not safe, and there is no other good place for that. Use untracked variants of intel_gt_pm_get/put_async(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---
- https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e
- https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f
- https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5
- https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190
- https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e
- https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f
- https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5
- https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190
Modified: 2025-03-20
CVE-2024-26940
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the corresponding ttm_resource_manager is not allocated. This leads to a crash when trying to read from this file. Add a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file only when the corresponding ttm_resource_manager is allocated. crash> bt PID: 3133409 TASK: ffff8fe4834a5000 CPU: 3 COMMAND: "grep" #0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a #2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1 #4 [ffffb954506b3c70] no_context at ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887 #7 [ffffb954506b3d40] page_fault at ffffffffb360116e [exception RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb954506b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: 00007ffdbba9e9f8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 0000000000000003 RBP: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b
- https://git.kernel.org/stable/c/016119154981d81c9e8f2ea3f56b9e2b4ea14500
- https://git.kernel.org/stable/c/042ef0afc40fa1a22b3608f22915b91ce39d128f
- https://git.kernel.org/stable/c/25e3ce59c1200f1f0563e39de151f34962ab0fe1
- https://git.kernel.org/stable/c/4be9075fec0a639384ed19975634b662bfab938f
- https://git.kernel.org/stable/c/eb08db0fc5354fa17b7ed66dab3c503332423451
- https://git.kernel.org/stable/c/016119154981d81c9e8f2ea3f56b9e2b4ea14500
- https://git.kernel.org/stable/c/042ef0afc40fa1a22b3608f22915b91ce39d128f
- https://git.kernel.org/stable/c/25e3ce59c1200f1f0563e39de151f34962ab0fe1
- https://git.kernel.org/stable/c/4be9075fec0a639384ed19975634b662bfab938f
- https://git.kernel.org/stable/c/eb08db0fc5354fa17b7ed66dab3c503332423451
Modified: 2025-03-04
CVE-2024-26943
In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations.
- https://git.kernel.org/stable/c/16e87fe23d4af6df920406494ced5c0f4354567b
- https://git.kernel.org/stable/c/2a84744a037b8a511d6a9055f3defddc28ff4a4d
- https://git.kernel.org/stable/c/3e82f7383e0b82a835e6b6b06a348b2bc4e2c2ee
- https://git.kernel.org/stable/c/5e81773757a95fc298e96cfd6d4700f07b6192a2
- https://git.kernel.org/stable/c/9acfd8b083a0ffbd387566800d89f55058a68af2
- https://git.kernel.org/stable/c/16e87fe23d4af6df920406494ced5c0f4354567b
- https://git.kernel.org/stable/c/2a84744a037b8a511d6a9055f3defddc28ff4a4d
- https://git.kernel.org/stable/c/3e82f7383e0b82a835e6b6b06a348b2bc4e2c2ee
- https://git.kernel.org/stable/c/5e81773757a95fc298e96cfd6d4700f07b6192a2
- https://git.kernel.org/stable/c/9acfd8b083a0ffbd387566800d89f55058a68af2
Modified: 2025-09-18
CVE-2024-26946
In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ]
- https://git.kernel.org/stable/c/20fdb21eabaeb8f78f8f701f56d14ea0836ec861
- https://git.kernel.org/stable/c/4e51653d5d871f40f1bd5cf95cc7f2d8b33d063b
- https://git.kernel.org/stable/c/6417684315087904fffe8966d27ca74398c57dd6
- https://git.kernel.org/stable/c/b69f577308f1070004cafac106dd1a44099e5483
- https://git.kernel.org/stable/c/f13edd1871d4fb4ab829aff629d47914e251bae3
- https://git.kernel.org/stable/c/20fdb21eabaeb8f78f8f701f56d14ea0836ec861
- https://git.kernel.org/stable/c/4e51653d5d871f40f1bd5cf95cc7f2d8b33d063b
- https://git.kernel.org/stable/c/6417684315087904fffe8966d27ca74398c57dd6
- https://git.kernel.org/stable/c/b69f577308f1070004cafac106dd1a44099e5483
- https://git.kernel.org/stable/c/f13edd1871d4fb4ab829aff629d47914e251bae3
Modified: 2025-09-18
CVE-2024-26947
In the Linux kernel, the following vulnerability has been resolved: ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is:0xc0900000, 0x100000 the crash backtrace like: Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception So check if PG_reserved was set to solve this issue. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/
- https://git.kernel.org/stable/c/0c027c2bad7f5111c51a358b5d392e1a695dabff
- https://git.kernel.org/stable/c/0c66c6f4e21cb22220cbd8821c5c73fc157d20dc
- https://git.kernel.org/stable/c/9f7ddc222cae8254e93d5c169a8ae11a49d912a7
- https://git.kernel.org/stable/c/fb3a122a978626b33de3367ee1762da934c0f512
- https://git.kernel.org/stable/c/0c027c2bad7f5111c51a358b5d392e1a695dabff
- https://git.kernel.org/stable/c/0c66c6f4e21cb22220cbd8821c5c73fc157d20dc
- https://git.kernel.org/stable/c/9f7ddc222cae8254e93d5c169a8ae11a49d912a7
- https://git.kernel.org/stable/c/fb3a122a978626b33de3367ee1762da934c0f512
Modified: 2025-03-20
CVE-2024-26950
In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.
- https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5
- https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068
- https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5
- https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f
- https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996
- https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37
- https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47
- https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5
- https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068
- https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5
- https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f
- https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996
- https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37
- https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-26951
In the Linux kernel, the following vulnerability has been resolved:
wireguard: netlink: check for dangling peer via is_dead instead of empty list
If all peers are removed via wg_peer_remove_all(), rather than setting
peer_list to empty, the peer is added to a temporary list with a head on
the stack of wg_peer_remove_all(). If a netlink dump is resumed and the
cursored peer is one that has been removed via wg_peer_remove_all(), it
will iterate from that peer and then attempt to dump freed peers.
Fix this by instead checking peer->is_dead, which was explictly created
for this purpose. Also move up the device_update_lock lockdep assertion,
since reading is_dead relies on that.
It can be reproduced by a small script like:
echo "Setting config..."
ip link add dev wg0 type wireguard
wg setconf wg0 /big-config
(
while true; do
echo "Showing config..."
wg showconf wg0 > /dev/null
done
) &
sleep 4
wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n")
Resulting in:
BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20
Read of size 8 at addr ffff88811956ec70 by task wg/59
CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5
Call Trace:
- https://git.kernel.org/stable/c/13d107794304306164481d31ce33f8fdb25a9c04
- https://git.kernel.org/stable/c/302b2dfc013baca3dea7ceda383930d9297d231d
- https://git.kernel.org/stable/c/55b6c738673871c9b0edae05d0c97995c1ff08c4
- https://git.kernel.org/stable/c/710a177f347282eea162aec8712beb1f42d5ad87
- https://git.kernel.org/stable/c/7bedfe4cfa38771840a355970e4437cd52d4046b
- https://git.kernel.org/stable/c/b7cea3a9af0853fdbb1b16633a458f991dde6aac
- https://git.kernel.org/stable/c/f52be46e3e6ecefc2539119784324f0cbc09620a
- https://git.kernel.org/stable/c/13d107794304306164481d31ce33f8fdb25a9c04
- https://git.kernel.org/stable/c/302b2dfc013baca3dea7ceda383930d9297d231d
- https://git.kernel.org/stable/c/55b6c738673871c9b0edae05d0c97995c1ff08c4
- https://git.kernel.org/stable/c/710a177f347282eea162aec8712beb1f42d5ad87
- https://git.kernel.org/stable/c/7bedfe4cfa38771840a355970e4437cd52d4046b
- https://git.kernel.org/stable/c/b7cea3a9af0853fdbb1b16633a458f991dde6aac
- https://git.kernel.org/stable/c/f52be46e3e6ecefc2539119784324f0cbc09620a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-03
CVE-2024-26952
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial out-of-bounds when buffer offset is invalid I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.
- https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5
- https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63
- https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e
- https://git.kernel.org/stable/c/480469f145e5abf83361e608734e421b7d99693d
- https://git.kernel.org/stable/c/ad6480c9a5d884e2704adc51d69895d93339176c
- https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da
- https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5
- https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63
- https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e
- https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-18
CVE-2024-26953
In the Linux kernel, the following vulnerability has been resolved:
net: esp: fix bad handling of pages from page_pool
When the skb is reorganized during esp_output (!esp->inline), the pages
coming from the original skb fragments are supposed to be released back
to the system through put_page. But if the skb fragment pages are
originating from a page_pool, calling put_page on them will trigger a
page_pool leak which will eventually result in a crash.
This leak can be easily observed when using CONFIG_DEBUG_VM and doing
ipsec + gre (non offloaded) forwarding:
BUG: Bad page state in process ksoftirqd/16 pfn:1451b6
page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6
flags: 0x200000000000000(node=0|zone=2)
page_type: 0xffffffff()
raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000
raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000
page dumped because: page_pool leak
Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core]
CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1abb20a5f4b02fb3020f88456fc1e6069b3cdc45
- https://git.kernel.org/stable/c/8291b4eac429c480386669444c6377573f5d8664
- https://git.kernel.org/stable/c/c3198822c6cb9fb588e446540485669cc81c5d34
- https://git.kernel.org/stable/c/f278ff9db67264715d0d50e3e75044f8b78990f4
- https://git.kernel.org/stable/c/1abb20a5f4b02fb3020f88456fc1e6069b3cdc45
- https://git.kernel.org/stable/c/8291b4eac429c480386669444c6377573f5d8664
- https://git.kernel.org/stable/c/c3198822c6cb9fb588e446540485669cc81c5d34
- https://git.kernel.org/stable/c/f278ff9db67264715d0d50e3e75044f8b78990f4
Modified: 2025-12-23
CVE-2024-26955
In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent kernel bug at submit_bh_wbc() Fix a bug where nilfs_get_block() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead. This prevents callers such as __block_write_begin_int() from requesting a read into a buffer that is not mapped, which would cause the BUG_ON check for the BH_Mapped flag in submit_bh_wbc() to fail.
- https://git.kernel.org/stable/c/0c8aa4cfda4e4adb15d5b6536d155eca9c9cd44c
- https://git.kernel.org/stable/c/192e9f9078c96be30b31c4b44d6294b24520fce5
- https://git.kernel.org/stable/c/269cdf353b5bdd15f1a079671b0f889113865f20
- https://git.kernel.org/stable/c/32eaee72e96590a75445c8a6c7c1057673b47e07
- https://git.kernel.org/stable/c/48d443d200237782dc82e6b60663ec414ef02e39
- https://git.kernel.org/stable/c/76ffbe911e2798c7296968f5fd72f7bf67207a8d
- https://git.kernel.org/stable/c/91e4c4595fae5e87069e44687ae879091783c183
- https://git.kernel.org/stable/c/ca581d237f3b8539c044205bb003de71d75d227c
- https://git.kernel.org/stable/c/f0fe7ad5aff4f0fcf988913313c497de85f1e186
- https://git.kernel.org/stable/c/0c8aa4cfda4e4adb15d5b6536d155eca9c9cd44c
- https://git.kernel.org/stable/c/192e9f9078c96be30b31c4b44d6294b24520fce5
- https://git.kernel.org/stable/c/269cdf353b5bdd15f1a079671b0f889113865f20
- https://git.kernel.org/stable/c/32eaee72e96590a75445c8a6c7c1057673b47e07
- https://git.kernel.org/stable/c/48d443d200237782dc82e6b60663ec414ef02e39
- https://git.kernel.org/stable/c/76ffbe911e2798c7296968f5fd72f7bf67207a8d
- https://git.kernel.org/stable/c/91e4c4595fae5e87069e44687ae879091783c183
- https://git.kernel.org/stable/c/ca581d237f3b8539c044205bb003de71d75d227c
- https://git.kernel.org/stable/c/f0fe7ad5aff4f0fcf988913313c497de85f1e186
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-26956
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix failure to detect DAT corruption in btree and direct mappings Patch series "nilfs2: fix kernel bug at submit_bh_wbc()". This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch. The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such. This patch (of 2): Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted. There are two flaws involved in this issue. The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently. The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing. This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.
- https://git.kernel.org/stable/c/2e2619ff5d0def4bb6c2037a32a6eaa28dd95c84
- https://git.kernel.org/stable/c/46b832e09d43b394ac0f6d9485d2b1a06593f0b7
- https://git.kernel.org/stable/c/82827ca21e7c8a91384c5baa656f78a5adfa4ab4
- https://git.kernel.org/stable/c/9cbe1ad5f4354f4df1445e5f4883983328cd6d8e
- https://git.kernel.org/stable/c/a8e4d098de1c0f4c5c1f2ed4633a860f0da6d713
- https://git.kernel.org/stable/c/b67189690eb4b7ecc84ae16fa1e880e0123eaa35
- https://git.kernel.org/stable/c/c3b5c5c31e723b568f83d8cafab8629d9d830ffb
- https://git.kernel.org/stable/c/f2f26b4a84a0ef41791bd2d70861c8eac748f4ba
- https://git.kernel.org/stable/c/f69e81396aea66304d214f175aa371f1b5578862
- https://git.kernel.org/stable/c/2e2619ff5d0def4bb6c2037a32a6eaa28dd95c84
- https://git.kernel.org/stable/c/46b832e09d43b394ac0f6d9485d2b1a06593f0b7
- https://git.kernel.org/stable/c/82827ca21e7c8a91384c5baa656f78a5adfa4ab4
- https://git.kernel.org/stable/c/9cbe1ad5f4354f4df1445e5f4883983328cd6d8e
- https://git.kernel.org/stable/c/a8e4d098de1c0f4c5c1f2ed4633a860f0da6d713
- https://git.kernel.org/stable/c/b67189690eb4b7ecc84ae16fa1e880e0123eaa35
- https://git.kernel.org/stable/c/c3b5c5c31e723b568f83d8cafab8629d9d830ffb
- https://git.kernel.org/stable/c/f2f26b4a84a0ef41791bd2d70861c8eac748f4ba
- https://git.kernel.org/stable/c/f69e81396aea66304d214f175aa371f1b5578862
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-20
CVE-2024-26957
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix reference counting on zcrypt card objects Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use. This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated---
- https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484
- https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c
- https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd
- https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058
- https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55
- https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6
- https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca
- https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d
- https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000
- https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484
- https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c
- https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd
- https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058
- https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55
- https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6
- https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca
- https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d
- https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-08-28
CVE-2024-26958
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af
- https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab
- https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3
- https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5
- https://git.kernel.org/stable/c/6cd3f13aaa62970b5169d990e936b2e96943bc6a
- https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f
- https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95
- https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605
- https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af
- https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab
- https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3
- https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5
- https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f
- https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95
- https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-26959
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix btnxpuart_close Fix scheduling while atomic BUG in btnxpuart_close(), properly purge the transmit queue and free the receive skb. [ 10.973809] BUG: scheduling while atomic: kworker/u9:0/80/0x00000002 ... [ 10.980740] CPU: 3 PID: 80 Comm: kworker/u9:0 Not tainted 6.8.0-rc7-0.0.0-devel-00005-g61fdfceacf09 #1 [ 10.980751] Hardware name: Toradex Verdin AM62 WB on Dahlia Board (DT) [ 10.980760] Workqueue: hci0 hci_power_off [bluetooth] [ 10.981169] Call trace: ... [ 10.981363] uart_update_mctrl+0x58/0x78 [ 10.981373] uart_dtr_rts+0x104/0x114 [ 10.981381] tty_port_shutdown+0xd4/0xdc [ 10.981396] tty_port_close+0x40/0xbc [ 10.981407] uart_close+0x34/0x9c [ 10.981414] ttyport_close+0x50/0x94 [ 10.981430] serdev_device_close+0x40/0x50 [ 10.981442] btnxpuart_close+0x24/0x98 [btnxpuart] [ 10.981469] hci_dev_close_sync+0x2d8/0x718 [bluetooth] [ 10.981728] hci_dev_do_close+0x2c/0x70 [bluetooth] [ 10.981862] hci_power_off+0x20/0x64 [bluetooth]
- https://git.kernel.org/stable/c/586e099c93fe26b7bd40593979532f507ed9f6a4
- https://git.kernel.org/stable/c/664130c0b0309b360bc5bdd40a30604a9387bde8
- https://git.kernel.org/stable/c/74bcf708775c405f7fb6ed776ccd3e1957f38a52
- https://git.kernel.org/stable/c/d4e2365b07f1ae1f811a915b514caef5b2d6581e
- https://git.kernel.org/stable/c/586e099c93fe26b7bd40593979532f507ed9f6a4
- https://git.kernel.org/stable/c/664130c0b0309b360bc5bdd40a30604a9387bde8
- https://git.kernel.org/stable/c/74bcf708775c405f7fb6ed776ccd3e1957f38a52
- https://git.kernel.org/stable/c/d4e2365b07f1ae1f811a915b514caef5b2d6581e
Modified: 2025-03-20
CVE-2024-26960
In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8<----- __swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8<-----
- https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a
- https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a
- https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e
- https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b
- https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39
- https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e
- https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d
- https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a
- https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a
- https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e
- https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b
- https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39
- https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e
- https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-26961
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without
following the RCU rules for waiting before the end of a grace period. This
may lead to use-after-free in case llsec_lookup_key() is traversing the
list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
Modules linked in:
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
Call Trace:
- https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531
- https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d
- https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1
- https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88
- https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821
- https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f
- https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40
- https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531
- https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d
- https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1
- https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88
- https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821
- https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f
- https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-26963
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3-am62: fix module unload/reload behavior As runtime PM is enabled, the module can be runtime suspended when .remove() is called. Do a pm_runtime_get_sync() to make sure module is active before doing any register operations. Doing a pm_runtime_put_sync() should disable the refclk so no need to disable it again. Fixes the below warning at module removel. [ 39.705310] ------------[ cut here ]------------ [ 39.710004] clk:162:3 already disabled [ 39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 We called of_platform_populate() in .probe() so call the cleanup function of_platform_depopulate() in .remove(). Get rid of the now unnnecessary dwc3_ti_remove_core(). Without this, module re-load doesn't work properly.
- https://git.kernel.org/stable/c/3895780fabd120d0fbd54354014e85207b25687c
- https://git.kernel.org/stable/c/629b534c42d04f0797980f2d1ed105fdb8906975
- https://git.kernel.org/stable/c/6661befe41009c210efa2c1bcd16a5cc4cff8a06
- https://git.kernel.org/stable/c/6c6a45645a2e6a272dfde14eddbb6706de63c25d
- https://git.kernel.org/stable/c/7dfed9855397d0df4c6f748d1f66547ab3bad766
- https://git.kernel.org/stable/c/3895780fabd120d0fbd54354014e85207b25687c
- https://git.kernel.org/stable/c/629b534c42d04f0797980f2d1ed105fdb8906975
- https://git.kernel.org/stable/c/6661befe41009c210efa2c1bcd16a5cc4cff8a06
- https://git.kernel.org/stable/c/6c6a45645a2e6a272dfde14eddbb6706de63c25d
- https://git.kernel.org/stable/c/7dfed9855397d0df4c6f748d1f66547ab3bad766
Modified: 2024-12-23
CVE-2024-26964
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer.
- https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd
- https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4
- https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757
- https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d
- https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea
- https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052
- https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd
- https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4
- https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757
- https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d
- https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea
- https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052
Modified: 2025-12-23
CVE-2024-26965
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/3ff4a0f6a8f0ad4b4ee9e908bdfc3cacb7be4060
- https://git.kernel.org/stable/c/537040c257ab4cd0673fbae048f3940c8ea2e589
- https://git.kernel.org/stable/c/7e9926fef71e514b4a8ea9d11d5a84d52b181362
- https://git.kernel.org/stable/c/86bf75d9158f511db7530bc82a84b19a5134d089
- https://git.kernel.org/stable/c/8f562f3b25177c2055b20fd8cf000496f6fa9194
- https://git.kernel.org/stable/c/99740c4791dc8019b0d758c5389ca6d1c0604d95
- https://git.kernel.org/stable/c/ae99e199037c580b7350bfa3596f447a53bcf01f
- https://git.kernel.org/stable/c/ca2cf98d46748373e830a13d85d215d64a2d9bf2
- https://git.kernel.org/stable/c/e2c02a85bf53ae86d79b5fccf0a75ac0b78e0c96
- https://git.kernel.org/stable/c/3ff4a0f6a8f0ad4b4ee9e908bdfc3cacb7be4060
- https://git.kernel.org/stable/c/537040c257ab4cd0673fbae048f3940c8ea2e589
- https://git.kernel.org/stable/c/7e9926fef71e514b4a8ea9d11d5a84d52b181362
- https://git.kernel.org/stable/c/86bf75d9158f511db7530bc82a84b19a5134d089
- https://git.kernel.org/stable/c/8f562f3b25177c2055b20fd8cf000496f6fa9194
- https://git.kernel.org/stable/c/99740c4791dc8019b0d758c5389ca6d1c0604d95
- https://git.kernel.org/stable/c/ae99e199037c580b7350bfa3596f447a53bcf01f
- https://git.kernel.org/stable/c/ca2cf98d46748373e830a13d85d215d64a2d9bf2
- https://git.kernel.org/stable/c/e2c02a85bf53ae86d79b5fccf0a75ac0b78e0c96
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-26966
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99
- https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9
- https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2
- https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8
- https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38
- https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03
- https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f
- https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d
- https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0
- https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99
- https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9
- https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2
- https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8
- https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38
- https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03
- https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f
- https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d
- https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-26968
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq9574: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/0204247cf3669b6021fb745c3b7f37ae392ab19c
- https://git.kernel.org/stable/c/1723629fea8a4e75333196866e10d395463dca72
- https://git.kernel.org/stable/c/604f2d7c46727c5e24fc7faddc980bc1cc0b1011
- https://git.kernel.org/stable/c/bd2b6395671d823caa38d8e4d752de2448ae61e1
- https://git.kernel.org/stable/c/0204247cf3669b6021fb745c3b7f37ae392ab19c
- https://git.kernel.org/stable/c/1723629fea8a4e75333196866e10d395463dca72
- https://git.kernel.org/stable/c/604f2d7c46727c5e24fc7faddc980bc1cc0b1011
- https://git.kernel.org/stable/c/bd2b6395671d823caa38d8e4d752de2448ae61e1
Modified: 2024-12-23
CVE-2024-26969
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429
- https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94
- https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe
- https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f
- https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d
- https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566
- https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255
- https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27
- https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9
- https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429
- https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94
- https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe
- https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f
- https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d
- https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566
- https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255
- https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27
- https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-20
CVE-2024-26970
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.
- https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52
- https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb
- https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6
- https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b
- https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d
- https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d
- https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198
- https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52
- https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb
- https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6
- https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b
- https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d
- https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d
- https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26971
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq5018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
- https://git.kernel.org/stable/c/50c3acd460551cdf9d8ac6fe0c04f2de0e8e0872
- https://git.kernel.org/stable/c/90ad946fff70f312b8d23226afc38c13ddd88c4b
- https://git.kernel.org/stable/c/b0cf3d200e8a72b6d28e6e088c062b4a98cb5eaf
- https://git.kernel.org/stable/c/c8f4bef0667947b826848db1c45a645f751357c1
- https://git.kernel.org/stable/c/50c3acd460551cdf9d8ac6fe0c04f2de0e8e0872
- https://git.kernel.org/stable/c/90ad946fff70f312b8d23226afc38c13ddd88c4b
- https://git.kernel.org/stable/c/b0cf3d200e8a72b6d28e6e088c062b4a98cb5eaf
- https://git.kernel.org/stable/c/c8f4bef0667947b826848db1c45a645f751357c1
Modified: 2025-03-04
CVE-2024-26973
In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length.
- https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb
- https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3386c688
- https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63
- https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6
- https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee
- https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375
- https://git.kernel.org/stable/c/cdd33d54e789d229d6d5007cbf3f53965ca1a5c6
- https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f
- https://git.kernel.org/stable/c/fde2497d2bc3a063d8af88b258dbadc86bd7b57c
- https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb
- https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3386c688
- https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63
- https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6
- https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee
- https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375
- https://git.kernel.org/stable/c/cdd33d54e789d229d6d5007cbf3f53965ca1a5c6
- https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f
- https://git.kernel.org/stable/c/fde2497d2bc3a063d8af88b258dbadc86bd7b57c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-26974
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.
- https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be
- https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7
- https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f
- https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c
- https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc
- https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81
- https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828
- https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71
- https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7
- https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be
- https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7
- https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f
- https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c
- https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc
- https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81
- https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828
- https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71
- https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-26975
In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix a NULL pointer dereference A NULL pointer dereference is triggered when probing the MMIO RAPL driver on platforms with CPU ID not listed in intel_rapl_common CPU model list. This is because the intel_rapl_common module still probes on such platforms even if 'defaults_msr' is not set after commit 1488ac990ac8 ("powercap: intel_rapl: Allow probing without CPUID match"). Thus the MMIO RAPL rp->priv->defaults is NULL when registering to RAPL framework. Fix the problem by adding sanity check to ensure rp->priv->rapl_defaults is always valid.
- https://git.kernel.org/stable/c/0641908b906a133f1494c312a71f9fecbe2b6c78
- https://git.kernel.org/stable/c/2d1f5006ff95770da502f8cee2a224a1ff83866e
- https://git.kernel.org/stable/c/2f73cf2ae5e0f4e629db5be3a4380ff7807148e6
- https://git.kernel.org/stable/c/9b254feb249981b66ccdb1dae54e757789a15ba1
- https://git.kernel.org/stable/c/0641908b906a133f1494c312a71f9fecbe2b6c78
- https://git.kernel.org/stable/c/2d1f5006ff95770da502f8cee2a224a1ff83866e
- https://git.kernel.org/stable/c/2f73cf2ae5e0f4e629db5be3a4380ff7807148e6
- https://git.kernel.org/stable/c/9b254feb249981b66ccdb1dae54e757789a15ba1
Modified: 2025-04-08
CVE-2024-26976
In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
KVM must ensure that none of its workqueue callbacks is running when the
last reference to the KVM _module_ is put. Gifting a reference to the
associated VM prevents the workqueue callback from dereferencing freed
vCPU/VM memory, but does not prevent the KVM module from being unloaded
before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
result in deadlock. async_pf_execute() can't return until kvm_put_kvm()
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: events async_pf_execute [kvm]
RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
Call Trace:
- https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157
- https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750
- https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb
- https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac
- https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98
- https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5
- https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff
- https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b
- https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264
- https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157
- https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750
- https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb
- https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac
- https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98
- https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5
- https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff
- https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b
- https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-18
CVE-2024-26977
In the Linux kernel, the following vulnerability has been resolved: pci_iounmap(): Fix MMIO mapping leak The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(), which means MMIO mappings are leaked. Move the guard so we call iounmap() for MMIO mappings.
- https://git.kernel.org/stable/c/5e4b23e7a7b33a1e56bfa3e5598138a2234d55b6
- https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8
- https://git.kernel.org/stable/c/7626913652cc786c238e2dd7d8740b17d41b2637
- https://git.kernel.org/stable/c/af280e137e273935f2e09f4d73169998298792ed
- https://git.kernel.org/stable/c/b5d40f02e7222da032c2042aebcf2a07de9b342f
- https://git.kernel.org/stable/c/f3749345a9b7295dd071d0ed589634cb46364f77
- https://git.kernel.org/stable/c/5e4b23e7a7b33a1e56bfa3e5598138a2234d55b6
- https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8
- https://git.kernel.org/stable/c/7626913652cc786c238e2dd7d8740b17d41b2637
- https://git.kernel.org/stable/c/af280e137e273935f2e09f4d73169998298792ed
- https://git.kernel.org/stable/c/b5d40f02e7222da032c2042aebcf2a07de9b342f
- https://git.kernel.org/stable/c/f3749345a9b7295dd071d0ed589634cb46364f77
Modified: 2024-11-21
CVE-2024-26978
In the Linux kernel, the following vulnerability has been resolved: serial: max310x: fix NULL pointer dereference in I2C instantiation When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message.
- https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110
- https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3
- https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a
- https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a
- https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0
- https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733
- https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735
- https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110
- https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3
- https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a
- https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a
- https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0
- https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733
- https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2024-26980
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf().
- https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085
- https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1
- https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248
- https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20
- https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325
- https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085
- https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1
- https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248
- https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20
- https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26981
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.
- https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243
- https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9
- https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1
- https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611
- https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f
- https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8
- https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0
- https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16
- https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243
- https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9
- https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1
- https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611
- https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f
- https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8
- https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0
- https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26982
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix]
- https://git.kernel.org/stable/c/32c114a58236fe67141634774559f21f1dc96fd7
- https://git.kernel.org/stable/c/4a1b6f89825e267e156ccaeba3d235edcac77f94
- https://git.kernel.org/stable/c/5b99dea79650b50909c50aba24fbae00f203f013
- https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5
- https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395
- https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e
- https://git.kernel.org/stable/c/cf46f88b92cfc0e32bd8a21ba1273cff13b8745f
- https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5
- https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395
- https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26983
In the Linux kernel, the following vulnerability has been resolved:
bootconfig: use memblock_free_late to free xbc memory to buddy
On the time to free xbc memory in xbc_exit(), memblock may has handed
over memory to buddy allocator. So it doesn't make sense to free memory
back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs
on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86.
Following KASAN logs shows this case.
This patch fixes the xbc memory free problem by calling memblock_free()
in early xbc init error rewind path and calling memblock_free_late() in
xbc exit path to free memory to buddy allocator.
[ 9.410890] ==================================================================
[ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260
[ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1
[ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5
[ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023
[ 9.460789] Call Trace:
[ 9.463518]
- https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918
- https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35
- https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0
- https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7
- https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918
- https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35
- https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0
- https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26984
In the Linux kernel, the following vulnerability has been resolved: nouveau: fix instmem race condition around ptr stores Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb.
- https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716
- https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7
- https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52
- https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572
- https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525
- https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039
- https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9
- https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce
- https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716
- https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7
- https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52
- https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572
- https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525
- https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039
- https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9
- https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26986
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix memory leak in create_process failure Fix memory leak due to a leaked mmget reference on an error handling code path that is triggered when attempting to create KFD processes while a GPU reset is in progress.
- https://git.kernel.org/stable/c/0dcd876411644da98a6b4d5a18d32ca94c15bdb5
- https://git.kernel.org/stable/c/18921b205012568b45760753ad3146ddb9e2d4e2
- https://git.kernel.org/stable/c/aa02d43367a9adf8c85fb382fea4171fb266c8d0
- https://git.kernel.org/stable/c/0dcd876411644da98a6b4d5a18d32ca94c15bdb5
- https://git.kernel.org/stable/c/18921b205012568b45760753ad3146ddb9e2d4e2
- https://git.kernel.org/stable/c/aa02d43367a9adf8c85fb382fea4171fb266c8d0
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26987
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-11409-gf6cef5f8c37f #1 Not tainted
------------------------------------------------------
bash/46904 is trying to acquire lock:
ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock:
ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770
page_alloc_cpu_online+0x3c/0x70
cpuhp_invoke_callback+0x397/0x5f0
__cpuhp_invoke_callback_range+0x71/0xe0
_cpu_up+0xeb/0x210
cpu_up+0x91/0xe0
cpuhp_bringup_mask+0x49/0xb0
bringup_nonboot_cpus+0xb7/0xe0
smp_init+0x25/0xa0
kernel_init_freeable+0x15f/0x3e0
kernel_init+0x15/0x1b0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock);
lock(cpu_hotplug_lock);
lock(pcp_batch_high_lock);
rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904:
#0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace:
CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1983184c22dd84a4d95a71e5c6775c2638557dc7
- https://git.kernel.org/stable/c/49955b24002dc16a0ae2e83a57a2a6c863a1845c
- https://git.kernel.org/stable/c/5ef7ba2799a3b5ed292b8f6407376e2c25ef002e
- https://git.kernel.org/stable/c/882e1180c83f5b75bae03d0ccc31ccedfe5159de
- https://git.kernel.org/stable/c/1983184c22dd84a4d95a71e5c6775c2638557dc7
- https://git.kernel.org/stable/c/49955b24002dc16a0ae2e83a57a2a6c863a1845c
- https://git.kernel.org/stable/c/5ef7ba2799a3b5ed292b8f6407376e2c25ef002e
- https://git.kernel.org/stable/c/882e1180c83f5b75bae03d0ccc31ccedfe5159de
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26988
In the Linux kernel, the following vulnerability has been resolved: init/main.c: Fix potential static_command_line memory overflow We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_line are extra_command_line and command_line, rather than extra_command_line and boot_command_line. When strlen(command_line) > strlen(boot_command_line), static_command_line will overflow. This patch just recovers strlen(command_line) which was miss-consolidated with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()")
- https://git.kernel.org/stable/c/0dc727a4e05400205358a22c3d01ccad2c8e1fe4
- https://git.kernel.org/stable/c/2ef607ea103616aec0289f1b65d103d499fa903a
- https://git.kernel.org/stable/c/46dad3c1e57897ab9228332f03e1c14798d2d3b9
- https://git.kernel.org/stable/c/76c2f4d426a5358fced5d5990744d46f10a4ccea
- https://git.kernel.org/stable/c/81cf85ae4f2dd5fa3e43021782aa72c4c85558e8
- https://git.kernel.org/stable/c/936a02b5a9630c5beb0353c3085cc49d86c57034
- https://git.kernel.org/stable/c/0dc727a4e05400205358a22c3d01ccad2c8e1fe4
- https://git.kernel.org/stable/c/2ef607ea103616aec0289f1b65d103d499fa903a
- https://git.kernel.org/stable/c/46dad3c1e57897ab9228332f03e1c14798d2d3b9
- https://git.kernel.org/stable/c/76c2f4d426a5358fced5d5990744d46f10a4ccea
- https://git.kernel.org/stable/c/81cf85ae4f2dd5fa3e43021782aa72c4c85558e8
- https://git.kernel.org/stable/c/936a02b5a9630c5beb0353c3085cc49d86c57034
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26989
In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Fix level3 translation fault in swsusp_save() On arm64 machines, swsusp_save() faults if it attempts to access MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n: Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsusp_save+0x280/0x538 lr : swsusp_save+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 hibernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24 The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable() -> kernel_page_present() assuming that a page is always present when can_set_direct_map() is false (all of rodata_full, debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false), irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions should not be saved during hibernation. This problem was introduced by changes to the pfn_valid() logic in commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify pfn_valid()"). Similar to other architectures, drop the !can_set_direct_map() check in kernel_page_present() so that page_is_savable() skips such pages. [catalin.marinas@arm.com: rework commit message]
- https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3
- https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4
- https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457
- https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069
- https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6
- https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3
- https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4
- https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457
- https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069
- https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26990
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status Check kvm_mmu_page_ad_need_write_protect() when deciding whether to write-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU accounts for any role-specific reasons for disabling D-bit dirty logging. Specifically, TDP MMU SPTEs must be write-protected when the TDP MMU is being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled. KVM always disables PML when running L2, even when L1 and L2 GPAs are in the some domain, so failing to write-protect TDP MMU SPTEs will cause writes made by L2 to not be reflected in the dirty log. [sean: massage shortlog and changelog, tweak ternary op formatting]
- https://git.kernel.org/stable/c/2673dfb591a359c75080dd5af3da484b89320d22
- https://git.kernel.org/stable/c/cdf811a937471af2d1facdf8ae80e5e68096f1ed
- https://git.kernel.org/stable/c/e20bff0f1b2de9cfe303dd35ff46470104a87404
- https://git.kernel.org/stable/c/2673dfb591a359c75080dd5af3da484b89320d22
- https://git.kernel.org/stable/c/cdf811a937471af2d1facdf8ae80e5e68096f1ed
- https://git.kernel.org/stable/c/e20bff0f1b2de9cfe303dd35ff46470104a87404
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26992
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/pmu: Disable support for adaptive PEBS Drop support for virtualizing adaptive PEBS, as KVM's implementation is architecturally broken without an obvious/easy path forward, and because exposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak host kernel addresses to the guest. Bug #1 is that KVM doesn't account for the upper 32 bits of IA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g fixed_ctrl_field() drops the upper bits, reprogram_fixed_counters() stores local variables as u8s and truncates the upper bits too, etc. Bug #2 is that, because KVM _always_ sets precise_ip to a non-zero value for PEBS events, perf will _always_ generate an adaptive record, even if the guest requested a basic record. Note, KVM will also enable adaptive PEBS in individual *counter*, even if adaptive PEBS isn't exposed to the guest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero, i.e. the guest will only ever see Basic records. Bug #3 is in perf. intel_pmu_disable_fixed() doesn't clear the upper bits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and intel_pmu_enable_fixed() effectively doesn't clear ICL_FIXED_0_ADAPTIVE either. I.e. perf _always_ enables ADAPTIVE counters, regardless of what KVM requests. Bug #4 is that adaptive PEBS *might* effectively bypass event filters set by the host, as "Updated Memory Access Info Group" records information that might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER. Bug #5 is that KVM doesn't ensure LBR MSRs hold guest values (or at least zeros) when entering a vCPU with adaptive PEBS, which allows the guest to read host LBRs, i.e. host RIPs/addresses, by enabling "LBR Entries" records. Disable adaptive PEBS support as an immediate fix due to the severity of the LBR leak in particular, and because fixing all of the bugs will be non-trivial, e.g. not suitable for backporting to stable kernels. Note! This will break live migration, but trying to make KVM play nice with live migration would be quite complicated, wouldn't be guaranteed to work (i.e. KVM might still kill/confuse the guest), and it's not clear that there are any publicly available VMMs that support adaptive PEBS, let alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn't support PEBS in any capacity.
- https://git.kernel.org/stable/c/037e48ceccf163899374b601afb6ae8d0bf1d2ac
- https://git.kernel.org/stable/c/0fb74c00d140a66128afc0003785dcc57e69d312
- https://git.kernel.org/stable/c/7a7650b3ac23e5fc8c990f00e94f787dc84e3175
- https://git.kernel.org/stable/c/9e985cbf2942a1bb8fcef9adc2a17d90fd7ca8ee
- https://git.kernel.org/stable/c/037e48ceccf163899374b601afb6ae8d0bf1d2ac
- https://git.kernel.org/stable/c/0fb74c00d140a66128afc0003785dcc57e69d312
- https://git.kernel.org/stable/c/7a7650b3ac23e5fc8c990f00e94f787dc84e3175
- https://git.kernel.org/stable/c/9e985cbf2942a1bb8fcef9adc2a17d90fd7ca8ee
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26993
In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL.
- https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c
- https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063
- https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b
- https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17
- https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4
- https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78
- https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957
- https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5
- https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c
- https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063
- https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b
- https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17
- https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4
- https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78
- https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957
- https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26994
In the Linux kernel, the following vulnerability has been resolved: speakup: Avoid crash on very long word In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.
- https://git.kernel.org/stable/c/0d130158db29f5e0b3893154908cf618896450a8
- https://git.kernel.org/stable/c/0efb15c14c493263cb3a5f65f5ddfd4603d19a76
- https://git.kernel.org/stable/c/6401038acfa24cba9c28cce410b7505efadd0222
- https://git.kernel.org/stable/c/756c5cb7c09e537b87b5d3acafcb101b2ccf394f
- https://git.kernel.org/stable/c/89af25bd4b4bf6a71295f07e07a8ae7dc03c6595
- https://git.kernel.org/stable/c/8defb1d22ba0395b81feb963b96e252b097ba76f
- https://git.kernel.org/stable/c/8f6b62125befe1675446923e4171eac2c012959c
- https://git.kernel.org/stable/c/c8d2f34ea96ea3bce6ba2535f867f0d4ee3b22e1
- https://git.kernel.org/stable/c/0d130158db29f5e0b3893154908cf618896450a8
- https://git.kernel.org/stable/c/0efb15c14c493263cb3a5f65f5ddfd4603d19a76
- https://git.kernel.org/stable/c/6401038acfa24cba9c28cce410b7505efadd0222
- https://git.kernel.org/stable/c/756c5cb7c09e537b87b5d3acafcb101b2ccf394f
- https://git.kernel.org/stable/c/89af25bd4b4bf6a71295f07e07a8ae7dc03c6595
- https://git.kernel.org/stable/c/8defb1d22ba0395b81feb963b96e252b097ba76f
- https://git.kernel.org/stable/c/8f6b62125befe1675446923e4171eac2c012959c
- https://git.kernel.org/stable/c/c8d2f34ea96ea3bce6ba2535f867f0d4ee3b22e1
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26996
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.
- https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93
- https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e
- https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7
- https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca
- https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3
- https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93
- https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e
- https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7
- https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca
- https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26999
In the Linux kernel, the following vulnerability has been resolved: serial/pmac_zilog: Remove flawed mitigation for rx irq flood The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console: ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0 That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port. Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below. A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.
- https://git.kernel.org/stable/c/1be3226445362bfbf461c92a5bcdb1723f2e4907
- https://git.kernel.org/stable/c/52aaf1ff14622a04148dbb9ccce6d9de5d534ea7
- https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce
- https://git.kernel.org/stable/c/7a3bbe41efa55323b6ea3c35fa15941d4dbecdef
- https://git.kernel.org/stable/c/ab86cf6f8d24e63e9aca23da5108af1aa5483928
- https://git.kernel.org/stable/c/bbaafbb4651fede8d3c3881601ecaa4f834f9d3f
- https://git.kernel.org/stable/c/ca09dfc3cfdf89e6af3ac24e1c6c0be5c575a729
- https://git.kernel.org/stable/c/d679c816929d62af51c8e6d7fc0e165c9412d2f3
- https://git.kernel.org/stable/c/1be3226445362bfbf461c92a5bcdb1723f2e4907
- https://git.kernel.org/stable/c/52aaf1ff14622a04148dbb9ccce6d9de5d534ea7
- https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce
- https://git.kernel.org/stable/c/7a3bbe41efa55323b6ea3c35fa15941d4dbecdef
- https://git.kernel.org/stable/c/ab86cf6f8d24e63e9aca23da5108af1aa5483928
- https://git.kernel.org/stable/c/bbaafbb4651fede8d3c3881601ecaa4f834f9d3f
- https://git.kernel.org/stable/c/ca09dfc3cfdf89e6af3ac24e1c6c0be5c575a729
- https://git.kernel.org/stable/c/d679c816929d62af51c8e6d7fc0e165c9412d2f3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27000
In the Linux kernel, the following vulnerability has been resolved: serial: mxs-auart: add spinlock around changing cts state The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...)
- https://git.kernel.org/stable/c/0dc0637e6b16158af85945425821bfd0151adb37
- https://git.kernel.org/stable/c/21535ef0ac1945080198fe3e4347ea498205c99a
- https://git.kernel.org/stable/c/2c9b943e9924cf1269e44289bc5e60e51b0f5270
- https://git.kernel.org/stable/c/479244d68f5d94f3903eced52b093c1e01ddb495
- https://git.kernel.org/stable/c/54c4ec5f8c471b7c1137a1f769648549c423c026
- https://git.kernel.org/stable/c/56434e295bd446142025913bfdf1587f5e1970ad
- https://git.kernel.org/stable/c/5f40fd6ca2cf0bfbc5a5c9e403dfce8ca899ba37
- https://git.kernel.org/stable/c/94b0e65c75f4af888ab2dd6c90f060f762924e86
- https://git.kernel.org/stable/c/0dc0637e6b16158af85945425821bfd0151adb37
- https://git.kernel.org/stable/c/21535ef0ac1945080198fe3e4347ea498205c99a
- https://git.kernel.org/stable/c/2c9b943e9924cf1269e44289bc5e60e51b0f5270
- https://git.kernel.org/stable/c/479244d68f5d94f3903eced52b093c1e01ddb495
- https://git.kernel.org/stable/c/54c4ec5f8c471b7c1137a1f769648549c423c026
- https://git.kernel.org/stable/c/56434e295bd446142025913bfdf1587f5e1970ad
- https://git.kernel.org/stable/c/5f40fd6ca2cf0bfbc5a5c9e403dfce8ca899ba37
- https://git.kernel.org/stable/c/94b0e65c75f4af888ab2dd6c90f060f762924e86
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27001
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things
can fall through the cracks. Depending on the hardware model,
URBs can have either bulk or interrupt type, and current version
of vmk80xx_find_usb_endpoints() function does not take that fully
into account. While this warning does not seem to be too harmful,
at the very least it will crash systems with 'panic_on_warn' set on
them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the
endpoint checking process with usb_find_common_endpoints() and
ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
Call Trace:
- https://git.kernel.org/stable/c/3a63ae0348d990e137cca04eced5b08379969ea9
- https://git.kernel.org/stable/c/59f33af9796160f851641d960bd93937f282c696
- https://git.kernel.org/stable/c/6ec3514a7d35ad9cfab600187612c29f669069d2
- https://git.kernel.org/stable/c/a3b8ae7e9297dd453f2977b011c5bc75eb20e71b
- https://git.kernel.org/stable/c/ac882d6b21bffecb57bcc4486701239eef5aa67b
- https://git.kernel.org/stable/c/b0b268eeb087e324ef3ea71f8e6cabd07630517f
- https://git.kernel.org/stable/c/d1718530e3f640b7d5f0050e725216eab57a85d8
- https://git.kernel.org/stable/c/f15370e315976198f338b41611f37ce82af6cf54
- https://git.kernel.org/stable/c/3a63ae0348d990e137cca04eced5b08379969ea9
- https://git.kernel.org/stable/c/59f33af9796160f851641d960bd93937f282c696
- https://git.kernel.org/stable/c/6ec3514a7d35ad9cfab600187612c29f669069d2
- https://git.kernel.org/stable/c/a3b8ae7e9297dd453f2977b011c5bc75eb20e71b
- https://git.kernel.org/stable/c/ac882d6b21bffecb57bcc4486701239eef5aa67b
- https://git.kernel.org/stable/c/b0b268eeb087e324ef3ea71f8e6cabd07630517f
- https://git.kernel.org/stable/c/d1718530e3f640b7d5f0050e725216eab57a85d8
- https://git.kernel.org/stable/c/f15370e315976198f338b41611f37ce82af6cf54
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27002
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Do a runtime PM get on controllers during probe mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack: CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock() CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock() Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression. Verified on MT8183 and MT8192 Chromebooks.
- https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8
- https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3
- https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5
- https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc
- https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8
- https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3
- https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5
- https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27003
In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree for clk_summary Similar to the previous commit, we should make sure that all devices are runtime resumed before printing the clk_summary through debugfs. Failure to do so would result in a deadlock if the thread is resuming a device to print clk state and that device is also runtime resuming in another thread, e.g the screen is turning on and the display driver is starting up. We remove the calls to clk_pm_runtime_{get,put}() in this path because they're superfluous now that we know the devices are runtime resumed. This also squashes a bug where the return value of clk_pm_runtime_get() wasn't checked, leading to an RPM count underflow on error paths.
- https://git.kernel.org/stable/c/2c077fdfd09dffb31a890e5095c8ab205138a42e
- https://git.kernel.org/stable/c/83ada89e4a86e2b28ea2b5113c76d6dc7560a4d0
- https://git.kernel.org/stable/c/9d1e795f754db1ac3344528b7af0b17b8146f321
- https://git.kernel.org/stable/c/b457105309d388e4081c716cf7b81d517ff74db4
- https://git.kernel.org/stable/c/2c077fdfd09dffb31a890e5095c8ab205138a42e
- https://git.kernel.org/stable/c/83ada89e4a86e2b28ea2b5113c76d6dc7560a4d0
- https://git.kernel.org/stable/c/9d1e795f754db1ac3344528b7af0b17b8146f321
- https://git.kernel.org/stable/c/b457105309d388e4081c716cf7b81d517ff74db4
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27004
In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree during disable_unused Doug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20 The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread. This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again. Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---
- https://git.kernel.org/stable/c/115554862294397590088ba02f11f2aba6d5016c
- https://git.kernel.org/stable/c/253ab38d1ee652a596942156978a233970d185ba
- https://git.kernel.org/stable/c/4af115f1a20a3d9093586079206ee37c2ac55123
- https://git.kernel.org/stable/c/60ff482c4205a5aac3b0595ab794cfd62295dab5
- https://git.kernel.org/stable/c/a29ec0465dce0b871003698698ac6fa92c9a5034
- https://git.kernel.org/stable/c/a424e713e0cc33d4b969cfda25b9f46df4d7b5bc
- https://git.kernel.org/stable/c/e581cf5d216289ef292d1a4036d53ce90e122469
- https://git.kernel.org/stable/c/115554862294397590088ba02f11f2aba6d5016c
- https://git.kernel.org/stable/c/253ab38d1ee652a596942156978a233970d185ba
- https://git.kernel.org/stable/c/4af115f1a20a3d9093586079206ee37c2ac55123
- https://git.kernel.org/stable/c/60ff482c4205a5aac3b0595ab794cfd62295dab5
- https://git.kernel.org/stable/c/a29ec0465dce0b871003698698ac6fa92c9a5034
- https://git.kernel.org/stable/c/a424e713e0cc33d4b969cfda25b9f46df4d7b5bc
- https://git.kernel.org/stable/c/e581cf5d216289ef292d1a4036d53ce90e122469
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27005
In the Linux kernel, the following vulnerability has been resolved:
interconnect: Don't access req_list while it's being manipulated
The icc_lock mutex was split into separate icc_lock and icc_bw_lock
mutexes in [1] to avoid lockdep splats. However, this didn't adequately
protect access to icc_node::req_list.
The icc_set_bw() function will eventually iterate over req_list while
only holding icc_bw_lock, but req_list can be modified while only
holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),
and icc_put().
Example A:
CPU0 CPU1
---- ----
icc_set_bw(path_a)
mutex_lock(&icc_bw_lock);
icc_put(path_b)
mutex_lock(&icc_lock);
aggregate_requests()
hlist_for_each_entry(r, ...
hlist_del(...
- https://git.kernel.org/stable/c/19ec82b3cad1abef2a929262b8c1528f4e0c192d
- https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6
- https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42
- https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1
- https://git.kernel.org/stable/c/fe549d8e976300d0dd75bd904eb216bed8b145e0
- https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6
- https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42
- https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-01
CVE-2024-27008
In the Linux kernel, the following vulnerability has been resolved: drm: nv04: Fix out of bounds access When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value. Utilize macros from 'enum nouveau_or' in calls instead of hardcoding. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/097c7918fcfa1dee233acfd1f3029f00c3bc8062
- https://git.kernel.org/stable/c/26212da39ee14a52c76a202c6ae5153a84f579a5
- https://git.kernel.org/stable/c/5050ae879a828d752b439e3827aac126709da6d1
- https://git.kernel.org/stable/c/5fd4b090304e450aa0e7cc9cc2b4873285c6face
- https://git.kernel.org/stable/c/6690cc2732e2a8d0eaca44dcbac032a4b0148042
- https://git.kernel.org/stable/c/c2b97f26f081ceec3298151481687071075a25cb
- https://git.kernel.org/stable/c/cf92bb778eda7830e79452c6917efa8474a30c1e
- https://git.kernel.org/stable/c/df0991da7db846f7fa4ec6740350f743d3b69b04
- https://git.kernel.org/stable/c/097c7918fcfa1dee233acfd1f3029f00c3bc8062
- https://git.kernel.org/stable/c/26212da39ee14a52c76a202c6ae5153a84f579a5
- https://git.kernel.org/stable/c/5050ae879a828d752b439e3827aac126709da6d1
- https://git.kernel.org/stable/c/5fd4b090304e450aa0e7cc9cc2b4873285c6face
- https://git.kernel.org/stable/c/6690cc2732e2a8d0eaca44dcbac032a4b0148042
- https://git.kernel.org/stable/c/c2b97f26f081ceec3298151481687071075a25cb
- https://git.kernel.org/stable/c/cf92bb778eda7830e79452c6917efa8474a30c1e
- https://git.kernel.org/stable/c/df0991da7db846f7fa4ec6740350f743d3b69b04
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27009
In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix race condition during online processing A race condition exists in ccw_device_set_online() that can cause the online process to fail, leaving the affected device in an inconsistent state. As a result, subsequent attempts to set that device online fail with return code ENODEV. The problem occurs when a path verification request arrives after a wait for final device state completed, but before the result state is evaluated. Fix this by ensuring that the CCW-device lock is held between determining final state and checking result state. Note that since: commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers") path verification requests are much more likely to occur during boot, resulting in an increased chance of this race condition occurring.
- https://git.kernel.org/stable/c/2d8527f2f911fab84aec04df4788c0c23af3df48
- https://git.kernel.org/stable/c/2df56f4ea769ff81e51bbb05699989603bde9c49
- https://git.kernel.org/stable/c/3076b3c38a704e10df5e143c213653309d532538
- https://git.kernel.org/stable/c/559f3a6333397ab6cd4a696edd65a70b6be62c6e
- https://git.kernel.org/stable/c/a4234decd0fe429832ca81c4637be7248b88b49e
- https://git.kernel.org/stable/c/2d8527f2f911fab84aec04df4788c0c23af3df48
- https://git.kernel.org/stable/c/2df56f4ea769ff81e51bbb05699989603bde9c49
- https://git.kernel.org/stable/c/3076b3c38a704e10df5e143c213653309d532538
- https://git.kernel.org/stable/c/559f3a6333397ab6cd4a696edd65a70b6be62c6e
- https://git.kernel.org/stable/c/a4234decd0fe429832ca81c4637be7248b88b49e
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27013
In the Linux kernel, the following vulnerability has been resolved: tun: limit printing rate when illegal packet received by tun dev vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f
- https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421
- https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad
- https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3
- https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa
- https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713
- https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588
- https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb
- https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540
- https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421
- https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad
- https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3
- https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa
- https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713
- https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588
- https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb
- https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27014
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the `priv->state_lock`, any scheduled
aRFS works are canceled using the `cancel_work_sync` function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the `state_lock` which is already acquired.
The worker acquires the lock to delete the rules if the state
is down, which is not the worker's responsibility since
disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is
enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
------------------------------------------------------
ethtool/386089 is trying to acquire lock:
ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock:
ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}:
__mutex_lock+0x80/0xc90
arfs_handle_work+0x4b/0x3b0 [mlx5_core]
process_one_work+0x1dc/0x4a0
worker_thread+0x1bf/0x3c0
kthread+0xd7/0x100
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:
__lock_acquire+0x17b4/0x2c80
lock_acquire+0xd0/0x2b0
__flush_work+0x7a/0x4e0
__cancel_work_timer+0x131/0x1c0
arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0
ethnl_default_set_doit+0xec/0x240
genl_family_rcv_msg_doit+0xd0/0x120
genl_rcv_msg+0x188/0x2c0
netlink_rcv_skb+0x54/0x100
genl_rcv+0x24/0x40
netlink_unicast+0x1a1/0x270
netlink_sendmsg+0x214/0x460
__sock_sendmsg+0x38/0x60
__sys_sendto+0x113/0x170
__x64_sys_sendto+0x20/0x30
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089:
#0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
#1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
#2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace:
CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc
- https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b
- https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b
- https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693
- https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc
- https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b
- https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b
- https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27015
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path.
- https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d
- https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27
- https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d
- https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56
- https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2
- https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d
- https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27
- https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d
- https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56
- https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27016
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate pppoe header Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field.
- https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf
- https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7
- https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9
- https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163
- https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433
- https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf
- https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7
- https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9
- https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163
- https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27018
In the Linux kernel, the following vulnerability has been resolved:
netfilter: br_netfilter: skip conntrack input hook for promisc packets
For historical reasons, when bridge device is in promisc mode, packets
that are directed to the taps follow bridge input hook path. This patch
adds a workaround to reset conntrack for these packets.
Jianbo Liu reports warning splats in their test infrastructure where
cloned packets reach the br_netfilter input hook to confirm the
conntrack object.
Scratch one bit from BR_INPUT_SKB_CB to annotate that this packet has
reached the input hook because it is passed up to the bridge device to
reach the taps.
[ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]
[ 57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core
[ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19
[ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]
[ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1
[ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202
[ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000
[ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000
[ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003
[ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000
[ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800
[ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000
[ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0
[ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 57.585440] Call Trace:
[ 57.585721]
- https://git.kernel.org/stable/c/3f59ac29dea0921637053908fe99268d157bbb9d
- https://git.kernel.org/stable/c/43193174510ea4f3ce09b796e559a2fd9f148615
- https://git.kernel.org/stable/c/751de2012eafa4d46d8081056761fa0e9cc8a178
- https://git.kernel.org/stable/c/b13db0d16bc7b2a52abcf5cb71334f63faa5dbd6
- https://git.kernel.org/stable/c/dceb683ab87ca3666a9bb5c0158528b646faedc4
- https://git.kernel.org/stable/c/3f59ac29dea0921637053908fe99268d157bbb9d
- https://git.kernel.org/stable/c/43193174510ea4f3ce09b796e559a2fd9f148615
- https://git.kernel.org/stable/c/751de2012eafa4d46d8081056761fa0e9cc8a178
- https://git.kernel.org/stable/c/b13db0d16bc7b2a52abcf5cb71334f63faa5dbd6
- https://git.kernel.org/stable/c/dceb683ab87ca3666a9bb5c0158528b646faedc4
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27019
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.
- https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920
- https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73
- https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e
- https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88
- https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484
- https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349
- https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920
- https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73
- https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e
- https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88
- https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484
- https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27020
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process.
- https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f
- https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907
- https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5
- https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05
- https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a
- https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b
- https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c
- https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf
- https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f
- https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907
- https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5
- https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05
- https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a
- https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b
- https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c
- https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf
- 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/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2026-04-11
CVE-2024-27022
In the Linux kernel, the following vulnerability has been resolved: fork: defer linking file vma until vma is fully initialized Thorvald reported a WARNING [1]. And the root cause is below race: CPU 1 CPU 2 fork hugetlbfs_fallocate dup_mmap hugetlbfs_punch_hole i_mmap_lock_write(mapping); vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. i_mmap_unlock_write(mapping); hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! i_mmap_lock_write(mapping); hugetlb_vmdelete_list vma_interval_tree_foreach hugetlb_vma_trylock_write -- Vma_lock is cleared. tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! hugetlb_vma_unlock_write -- Vma_lock is assigned!!! i_mmap_unlock_write(mapping); hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside i_mmap_rwsem lock while vma lock can be used in the same time. Fix this by deferring linking file vma until vma is fully initialized. Those vmas should be initialized first before they can be used.
- https://git.kernel.org/stable/c/2e5cbab8ccbfc7d4a3d8a21d3c2a1f2c1aa29b5b
- https://git.kernel.org/stable/c/35e351780fa9d8240dd6f7e4f245f9ea37e96c19
- https://git.kernel.org/stable/c/abdb88dd272bbeb93efe01d8e0b7b17e24af3a34
- https://git.kernel.org/stable/c/04b0c41912349aff11a1bbaef6a722bd7fbb90ac
- https://git.kernel.org/stable/c/0c42f7e039aba3de6d7dbf92da708e2b2ecba557
- https://git.kernel.org/stable/c/35e351780fa9d8240dd6f7e4f245f9ea37e96c19
- https://git.kernel.org/stable/c/abdb88dd272bbeb93efe01d8e0b7b17e24af3a34
- https://git.kernel.org/stable/c/cec11fa2eb512ebe3a459c185f4aca1d44059bbf
- https://git.kernel.org/stable/c/dd782da470761077f4d1120e191f1a35787cda6e
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-04-08
CVE-2024-27058
In the Linux kernel, the following vulnerability has been resolved: tmpfs: fix race on handling dquot rbtree A syzkaller reproducer found a race while attempting to remove dquot information from the rb tree. Fetching the rb_tree root node must also be protected by the dqopt->dqio_sem, otherwise, giving the right timing, shmem_release_dquot() will trigger a warning because it couldn't find a node in the tree, when the real reason was the root node changing before the search starts: Thread 1 Thread 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - fetch ROOT - Fetch ROOT - acquire dqio_sem - wait dqio_sem - do something, triger a tree rebalance - release dqio_sem - acquire dqio_sem - start searching for the node, but from the wrong location, missing the node, and triggering a warning.
- https://git.kernel.org/stable/c/0a69b6b3a026543bc215ccc866d0aea5579e6ce2
- https://git.kernel.org/stable/c/617d55b90e73c7b4aa2733ca6cc3f9b72d1124bb
- https://git.kernel.org/stable/c/c7077f43f30d817d10a9f8245e51576ac114b2f0
- https://git.kernel.org/stable/c/f82f184874d2761ebaa60dccf577921a0dbb3810
- https://git.kernel.org/stable/c/0a69b6b3a026543bc215ccc866d0aea5579e6ce2
- https://git.kernel.org/stable/c/617d55b90e73c7b4aa2733ca6cc3f9b72d1124bb
- https://git.kernel.org/stable/c/c7077f43f30d817d10a9f8245e51576ac114b2f0
- https://git.kernel.org/stable/c/f82f184874d2761ebaa60dccf577921a0dbb3810
Modified: 2025-03-05
CVE-2024-27061
In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Fix use after free in unprepare sun8i_ce_cipher_unprepare should be called before crypto_finalize_skcipher_request, because client callbacks may immediately free memory, that isn't needed anymore. But it will be used by unprepare after free. Before removing prepare/unprepare callbacks it was handled by crypto engine in crypto_finalize_request. Usually that results in a pointer dereference problem during a in crypto selftest. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000004716d000 [0000000000000030] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP This problem is detected by KASAN as well. ================================================================== BUG: KASAN: slab-use-after-free in sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] Read of size 8 at addr ffff00000dcdc040 by task 1c15000.crypto-/373 Hardware name: Pine64 PinePhone (1.2) (DT) Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_load8+0x9c/0xc0 sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] crypto_pump_work+0x354/0x620 [crypto_engine] kthread_worker_fn+0x244/0x498 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x38 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x74/0x1d0 alg_test_skcipher+0x90/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Freed by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x60 __kasan_slab_free+0x100/0x170 slab_free_freelist_hook+0xd4/0x1e8 __kmem_cache_free+0x15c/0x290 kfree+0x74/0x100 kfree_sensitive+0x80/0xb0 alg_test_skcipher+0x12c/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 The buggy address belongs to the object at ffff00000dcdc000 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff00000dcdc000, ffff00000dcdc100)
- https://git.kernel.org/stable/c/183420038444547c149a0fc5f58e792c2752860c
- https://git.kernel.org/stable/c/51a7d338c212e0640b1aca52ba6590d5bea49879
- https://git.kernel.org/stable/c/dc60b25540c82fc4baa95d1458ae96ead21859e0
- https://git.kernel.org/stable/c/183420038444547c149a0fc5f58e792c2752860c
- https://git.kernel.org/stable/c/51a7d338c212e0640b1aca52ba6590d5bea49879
- https://git.kernel.org/stable/c/dc60b25540c82fc4baa95d1458ae96ead21859e0
Modified: 2025-04-08
CVE-2024-27062
In the Linux kernel, the following vulnerability has been resolved:
nouveau: lock the client object tree.
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI
[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]
[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe
[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206
[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58
[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400
[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000
[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0
[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007
[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000
[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0
[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4562.099544] Call Trace:
[ 4562.099555]
- https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7
- https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589
- https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135
- https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7
- https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589
- https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135
Modified: 2025-09-18
CVE-2024-27063
In the Linux kernel, the following vulnerability has been resolved: leds: trigger: netdev: Fix kernel panic on interface rename trig notify Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") in the various changes, reworked the way to set the LINKUP mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function. This changed the logic where, in the previous implementation the dev from the trigger event was used to check if the carrier was ok, but in the new implementation with the generic function, the dev in trigger_data is used instead. This is problematic and cause a possible kernel panic due to the fact that the dev in the trigger_data still reference the old one as the new one (passed from the trigger event) still has to be hold and saved in the trigger_data struct (done in the NETDEV_REGISTER case). On calling of get_device_state(), an invalid net_dev is used and this cause a kernel panic. To handle this correctly, move the call to get_device_state() after the new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER case) and correctly parse the new dev.
- https://git.kernel.org/stable/c/10f2af1af8ab8a7064f193446abd5579d3def7e3
- https://git.kernel.org/stable/c/3f360227cb46edb2cd2494128e1e06ed5768a62e
- https://git.kernel.org/stable/c/415798bc07dd1c1ae3a656aa026580816e0b9fe8
- https://git.kernel.org/stable/c/acd025c7a7d151261533016a6ca2d38f2de04e87
- https://git.kernel.org/stable/c/10f2af1af8ab8a7064f193446abd5579d3def7e3
- https://git.kernel.org/stable/c/3f360227cb46edb2cd2494128e1e06ed5768a62e
- https://git.kernel.org/stable/c/415798bc07dd1c1ae3a656aa026580816e0b9fe8
- https://git.kernel.org/stable/c/acd025c7a7d151261533016a6ca2d38f2de04e87
Modified: 2025-04-08
CVE-2024-27393
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks").
- https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f
- https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629
- https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1
- https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6
- https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4
- http://www.openwall.com/lists/oss-security/2024/05/08/4
- http://xenbits.xen.org/xsa/advisory-457.html
- https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f
- https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629
- https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1
- https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6
- https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4
Modified: 2025-01-14
CVE-2024-27395
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.
- https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994
- https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3
- https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424
- https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2
- https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4
- https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1
- https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137
- https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865
- https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994
- https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3
- https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424
- https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2
- https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4
- https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1
- https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137
- https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-27396
In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.
- https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58
- https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd
- https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29
- https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6
- https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07
- https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7
- https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474
- https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64
- https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58
- https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd
- https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29
- https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6
- https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07
- https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7
- https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474
- https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2026-01-22
CVE-2024-27398
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
When the sco connection is established and then, the sco socket
is releasing, timeout_work will be scheduled to judge whether
the sco disconnection is timeout. The sock will be deallocated
later, but it is dereferenced again in sco_sock_timeout. As a
result, the use-after-free bugs will happen. The root cause is
shown below:
Cleanup Thread | Worker Thread
sco_sock_release |
sco_sock_close |
__sco_sock_close |
sco_sock_set_timer |
schedule_delayed_work |
sco_sock_kill | (wait a time)
sock_put(sk) //FREE | sco_sock_timeout
| sock_hold(sk) //USE
The KASAN report triggered by POC is shown below:
[ 95.890016] ==================================================================
[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
...
[ 95.890755] Workqueue: events sco_sock_timeout
[ 95.890755] Call Trace:
[ 95.890755]
- https://git.kernel.org/stable/c/012363cb1bec5f33a7b94629ab2c1086f30280f2
- https://git.kernel.org/stable/c/1b33d55fb7355e27f8c82cd4ecd560f162469249
- https://git.kernel.org/stable/c/3212afd00e3cda790fd0583cb3eaef8f9575a014
- https://git.kernel.org/stable/c/33a6e92161a78c1073d90e27abe28d746feb0a53
- https://git.kernel.org/stable/c/483bc08181827fc475643272ffb69c533007e546
- https://git.kernel.org/stable/c/50c2037fc28df870ef29d9728c770c8955d32178
- https://git.kernel.org/stable/c/6a18eeb1b3bbc67c20d9609c31dca6a69b4bcde5
- https://git.kernel.org/stable/c/bfab2c1f7940a232cd519e82fff137e308abfd93
- http://www.openwall.com/lists/oss-security/2024/11/29/1
- http://www.openwall.com/lists/oss-security/2024/11/30/1
- http://www.openwall.com/lists/oss-security/2024/11/30/2
- https://git.kernel.org/stable/c/012363cb1bec5f33a7b94629ab2c1086f30280f2
- https://git.kernel.org/stable/c/1b33d55fb7355e27f8c82cd4ecd560f162469249
- https://git.kernel.org/stable/c/3212afd00e3cda790fd0583cb3eaef8f9575a014
- https://git.kernel.org/stable/c/33a6e92161a78c1073d90e27abe28d746feb0a53
- https://git.kernel.org/stable/c/483bc08181827fc475643272ffb69c533007e546
- https://git.kernel.org/stable/c/50c2037fc28df870ef29d9728c770c8955d32178
- https://git.kernel.org/stable/c/6a18eeb1b3bbc67c20d9609c31dca6a69b4bcde5
- https://git.kernel.org/stable/c/bfab2c1f7940a232cd519e82fff137e308abfd93
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
- https://security.netapp.com/advisory/ntap-20240912-0012/
Modified: 2026-01-22
CVE-2024-27399
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
There is a race condition between l2cap_chan_timeout() and
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
channel, the chan->conn will be set to null. But the conn could
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
As a result the null pointer dereference bug will happen. The
KASAN report triggered by POC is shown below:
[ 472.074580] ==================================================================
[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
[ 472.075308]
[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
[ 472.075308] Workqueue: events l2cap_chan_timeout
[ 472.075308] Call Trace:
[ 472.075308]
- https://git.kernel.org/stable/c/06acb75e7ed600d0bbf7bff5628aa8f24a97978c
- https://git.kernel.org/stable/c/6466ee65e5b27161c846c73ef407f49dfa1bd1d9
- https://git.kernel.org/stable/c/8960ff650aec70485b40771cd8e6e8c4cb467d33
- https://git.kernel.org/stable/c/955b5b6c54d95b5e7444dfc81c95c8e013f27ac0
- https://git.kernel.org/stable/c/adf0398cee86643b8eacde95f17d073d022f782c
- https://git.kernel.org/stable/c/e137e2ba96e51902dc2878131823a96bf8e638ae
- https://git.kernel.org/stable/c/e97e16433eb4533083b096a3824b93a5ca3aee79
- https://git.kernel.org/stable/c/eb86f955488c39526534211f2610e48a5cf8ead4
- https://git.kernel.org/stable/c/06acb75e7ed600d0bbf7bff5628aa8f24a97978c
- https://git.kernel.org/stable/c/6466ee65e5b27161c846c73ef407f49dfa1bd1d9
- https://git.kernel.org/stable/c/8960ff650aec70485b40771cd8e6e8c4cb467d33
- https://git.kernel.org/stable/c/955b5b6c54d95b5e7444dfc81c95c8e013f27ac0
- https://git.kernel.org/stable/c/adf0398cee86643b8eacde95f17d073d022f782c
- https://git.kernel.org/stable/c/e137e2ba96e51902dc2878131823a96bf8e638ae
- https://git.kernel.org/stable/c/e97e16433eb4533083b096a3824b93a5ca3aee79
- https://git.kernel.org/stable/c/eb86f955488c39526534211f2610e48a5cf8ead4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
- https://security.netapp.com/advisory/ntap-20240926-0001/
Modified: 2025-12-23
CVE-2024-27400
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2 This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap. The basic problem here is that after the move the old location is simply not available any more. Some fixes were suggested, but essentially we should call the move notification before actually moving things because only this way we have the correct order for DMA-buf and VM move notifications as well. Also rework the statistic handling so that we don't update the eviction counter before the move. v2: add missing NULL check
- https://git.kernel.org/stable/c/0c7ed3ed35eec9138b88d42217b5a6b9a62bda4d
- https://git.kernel.org/stable/c/5c25b169f9a0b34ee410891a96bc9d7b9ed6f9be
- https://git.kernel.org/stable/c/9a4f6e138720b6e9adf7b82a71d0292f3f276480
- https://git.kernel.org/stable/c/d3a9331a6591e9df64791e076f6591f440af51c3
- https://git.kernel.org/stable/c/0c7ed3ed35eec9138b88d42217b5a6b9a62bda4d
- https://git.kernel.org/stable/c/5c25b169f9a0b34ee410891a96bc9d7b9ed6f9be
- https://git.kernel.org/stable/c/9a4f6e138720b6e9adf7b82a71d0292f3f276480
- https://git.kernel.org/stable/c/d3a9331a6591e9df64791e076f6591f440af51c3
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
Modified: 2026-01-22
CVE-2024-27401
In the Linux kernel, the following vulnerability has been resolved: firewire: nosy: ensure user_length is taken into account when fetching packet contents Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.
- https://git.kernel.org/stable/c/1fe60ee709436550f8cfbab01295936b868d5baa
- https://git.kernel.org/stable/c/38762a0763c10c24a4915feee722d7aa6e73eb98
- https://git.kernel.org/stable/c/4ee0941da10e8fdcdb34756b877efd3282594c1f
- https://git.kernel.org/stable/c/539d51ac48bcfcfa1b3d4a85f8df92fa22c1d41c
- https://git.kernel.org/stable/c/67f34f093c0f7bf33f5b4ae64d3d695a3b978285
- https://git.kernel.org/stable/c/79f988d3ffc1aa778fc5181bdfab312e57956c6b
- https://git.kernel.org/stable/c/7b8c7bd2296e95b38a6ff346242356a2e7190239
- https://git.kernel.org/stable/c/cca330c59c54207567a648357835f59df9a286bb
- https://git.kernel.org/stable/c/1fe60ee709436550f8cfbab01295936b868d5baa
- https://git.kernel.org/stable/c/38762a0763c10c24a4915feee722d7aa6e73eb98
- https://git.kernel.org/stable/c/4ee0941da10e8fdcdb34756b877efd3282594c1f
- https://git.kernel.org/stable/c/539d51ac48bcfcfa1b3d4a85f8df92fa22c1d41c
- https://git.kernel.org/stable/c/67f34f093c0f7bf33f5b4ae64d3d695a3b978285
- https://git.kernel.org/stable/c/79f988d3ffc1aa778fc5181bdfab312e57956c6b
- https://git.kernel.org/stable/c/7b8c7bd2296e95b38a6ff346242356a2e7190239
- https://git.kernel.org/stable/c/cca330c59c54207567a648357835f59df9a286bb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DW2MIOIMOFUSNLHLRYX23AFR36BMKD65/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
Modified: 2025-03-27
CVE-2024-27437
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.
- https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060
- https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351
- https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2
- https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda
- https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5
- https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438
- https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec
- https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43
- https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060
- https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351
- https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2
- https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda
- https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5
- https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438
- https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec
- https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2024-31076
In the Linux kernel, the following vulnerability has been resolved: genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU. When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU. Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors. However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU. In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vector to 0. As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak. To address this issue, move the invocation of irq_force_complete_move() before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the interrupt is currently or used to be affine to the outgoing CPU. Additionally, reclaim the vector in __vector_schedule_cleanup() as well, following a warning message, although theoretically it should never see apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.
- https://git.kernel.org/stable/c/59f86a2908380d09cdc726461c0fbb8d8579c99f
- https://git.kernel.org/stable/c/6752dfcfff3ac3e16625ebd3f0ad9630900e7e76
- https://git.kernel.org/stable/c/9eeda3e0071a329af1eba15f4e57dc39576bb420
- https://git.kernel.org/stable/c/a40209d355afe4ed6d533507838c9e5cd70a76d8
- https://git.kernel.org/stable/c/a6c11c0a5235fb144a65e0cb2ffd360ddc1f6c32
- https://git.kernel.org/stable/c/e9c96d01d520498b169ce734a8ad1142bef86a30
- https://git.kernel.org/stable/c/ebfb16fc057a016abb46a9720a54abf0d4f6abe1
- https://git.kernel.org/stable/c/f5f4675960609d8c5ee95f027fbf6ce380f98372
- https://git.kernel.org/stable/c/59f86a2908380d09cdc726461c0fbb8d8579c99f
- https://git.kernel.org/stable/c/6752dfcfff3ac3e16625ebd3f0ad9630900e7e76
- https://git.kernel.org/stable/c/9eeda3e0071a329af1eba15f4e57dc39576bb420
- https://git.kernel.org/stable/c/a40209d355afe4ed6d533507838c9e5cd70a76d8
- https://git.kernel.org/stable/c/a6c11c0a5235fb144a65e0cb2ffd360ddc1f6c32
- https://git.kernel.org/stable/c/e9c96d01d520498b169ce734a8ad1142bef86a30
- https://git.kernel.org/stable/c/ebfb16fc057a016abb46a9720a54abf0d4f6abe1
- https://git.kernel.org/stable/c/f5f4675960609d8c5ee95f027fbf6ce380f98372
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-05
CVE-2024-33619
In the Linux kernel, the following vulnerability has been resolved: efi: libstub: only free priv.runtime_map when allocated priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.
- https://git.kernel.org/stable/c/4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974
- https://git.kernel.org/stable/c/6ca67a5fe1c606d1fbe24c30a9fc0bdc43a18554
- https://git.kernel.org/stable/c/9dce01f386c9ce6990c0a83fa14b1c95330b037e
- https://git.kernel.org/stable/c/b8938d6f570f010a1dcdbfed3e5b5d3258c2a908
- https://git.kernel.org/stable/c/4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974
- https://git.kernel.org/stable/c/6ca67a5fe1c606d1fbe24c30a9fc0bdc43a18554
- https://git.kernel.org/stable/c/9dce01f386c9ce6990c0a83fa14b1c95330b037e
- https://git.kernel.org/stable/c/b8938d6f570f010a1dcdbfed3e5b5d3258c2a908
Modified: 2025-11-04
CVE-2024-33621
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will
hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70
Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper
CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:sk_mc_loop+0x2d/0x70
Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c
RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212
RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000
RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00
R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000
R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000
FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0049a623dfbbb49888de7f0c2f33a582b5ead989
- https://git.kernel.org/stable/c/13c4543db34e0da5a7d2f550b6262d860f248381
- https://git.kernel.org/stable/c/183c4b416454b9983dc1b8aa0022b748911adc48
- https://git.kernel.org/stable/c/1abbf079da59ef559d0ab4219d2a0302f7970761
- https://git.kernel.org/stable/c/54213c09801e0bd2549ac42961093be36f65a7d0
- https://git.kernel.org/stable/c/54768bacfde60e8e4757968d79f8726711dd2cf5
- https://git.kernel.org/stable/c/b3dc6e8003b500861fa307e9a3400c52e78e4d3a
- https://git.kernel.org/stable/c/cb53706a3403ba67f4040b2a82d9cf79e11b1a48
- https://git.kernel.org/stable/c/0049a623dfbbb49888de7f0c2f33a582b5ead989
- https://git.kernel.org/stable/c/13c4543db34e0da5a7d2f550b6262d860f248381
- https://git.kernel.org/stable/c/183c4b416454b9983dc1b8aa0022b748911adc48
- https://git.kernel.org/stable/c/1abbf079da59ef559d0ab4219d2a0302f7970761
- https://git.kernel.org/stable/c/54213c09801e0bd2549ac42961093be36f65a7d0
- https://git.kernel.org/stable/c/54768bacfde60e8e4757968d79f8726711dd2cf5
- https://git.kernel.org/stable/c/b3dc6e8003b500861fa307e9a3400c52e78e4d3a
- https://git.kernel.org/stable/c/cb53706a3403ba67f4040b2a82d9cf79e11b1a48
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-10-01
CVE-2024-33847
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: don't allow unaligned truncation on released compress inode f2fs image may be corrupted after below testcase: - mkfs.f2fs -O extra_attr,compression -f /dev/vdb - mount /dev/vdb /mnt/f2fs - touch /mnt/f2fs/file - f2fs_io setflags compression /mnt/f2fs/file - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4 - f2fs_io release_cblocks /mnt/f2fs/file - truncate -s 8192 /mnt/f2fs/file - umount /mnt/f2fs - fsck.f2fs /dev/vdb [ASSERT] (fsck_chk_inode_blk:1256) --> ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks [FSCK] valid_block_count matching with CP [Fail] [0x4, 0x5] [FSCK] other corrupted bugs [Fail] The reason is: partial truncation assume compressed inode has reserved blocks, after partial truncation, valid block count may change w/o .i_blocks and .total_valid_block_count update, result in corruption. This patch only allow cluster size aligned truncation on released compress inode for fixing.
- https://git.kernel.org/stable/c/29ed2b5dd521ce7c5d8466cd70bf0cc9d07afeee
- https://git.kernel.org/stable/c/3ccf5210dc941a7aa0180596ac021568be4d35ec
- https://git.kernel.org/stable/c/5268241b41b1c5d0acca75e9b97d4fd719251c8c
- https://git.kernel.org/stable/c/8acae047215024d1ac499b3c8337ef1b952f160b
- https://git.kernel.org/stable/c/9f9341064a9b5246a32a7fe56b9f80c6f7f3c62d
- https://git.kernel.org/stable/c/b8962cf98595d1ec62f40f23667de830567ec8bc
- https://git.kernel.org/stable/c/29ed2b5dd521ce7c5d8466cd70bf0cc9d07afeee
- https://git.kernel.org/stable/c/3ccf5210dc941a7aa0180596ac021568be4d35ec
- https://git.kernel.org/stable/c/5268241b41b1c5d0acca75e9b97d4fd719251c8c
- https://git.kernel.org/stable/c/8acae047215024d1ac499b3c8337ef1b952f160b
- https://git.kernel.org/stable/c/9f9341064a9b5246a32a7fe56b9f80c6f7f3c62d
- https://git.kernel.org/stable/c/b8962cf98595d1ec62f40f23667de830567ec8bc
Modified: 2025-03-24
CVE-2024-34027
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case.
- https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019
- https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b
- https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f
- https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4
- https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b
- https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182
- https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019
- https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b
- https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f
- https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4
- https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b
- https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182
Modified: 2025-03-24
CVE-2024-34030
In the Linux kernel, the following vulnerability has been resolved: PCI: of_property: Return error for int_map allocation failure Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a NULL pointer dereference in this case. [bhelgaas: commit log]
- https://git.kernel.org/stable/c/598e4a37a2f8da9144ba1fab04320c32169b6d0d
- https://git.kernel.org/stable/c/b5f31d1470c4fdfae368feeb389768ba8d24fb34
- https://git.kernel.org/stable/c/e6f7d27df5d208b50cae817a91d128fb434bb12c
- https://git.kernel.org/stable/c/598e4a37a2f8da9144ba1fab04320c32169b6d0d
- https://git.kernel.org/stable/c/b5f31d1470c4fdfae368feeb389768ba8d24fb34
- https://git.kernel.org/stable/c/e6f7d27df5d208b50cae817a91d128fb434bb12c
Modified: 2025-09-17
CVE-2024-34777
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: fix node id validation
While validating node ids in map_benchmark_ioctl(), node_possible() may
be provided with invalid argument outside of [0,MAX_NUMNODES-1] range
leading to:
BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971
CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
- https://git.kernel.org/stable/c/1ff05e723f7ca30644b8ec3fb093f16312e408ad
- https://git.kernel.org/stable/c/34a816d8735f3924b74be8e5bf766ade1f3bd10b
- https://git.kernel.org/stable/c/35d31c8bd4722b107f5a2f5ddddce839de04b936
- https://git.kernel.org/stable/c/63e7e05a48a35308aeddd7ecccb68363a5988e87
- https://git.kernel.org/stable/c/c57874265a3c5206d7aece3793bb2fc9abcd7570
- https://git.kernel.org/stable/c/1ff05e723f7ca30644b8ec3fb093f16312e408ad
- https://git.kernel.org/stable/c/34a816d8735f3924b74be8e5bf766ade1f3bd10b
- https://git.kernel.org/stable/c/35d31c8bd4722b107f5a2f5ddddce839de04b936
- https://git.kernel.org/stable/c/63e7e05a48a35308aeddd7ecccb68363a5988e87
- https://git.kernel.org/stable/c/c57874265a3c5206d7aece3793bb2fc9abcd7570
Modified: 2025-02-03
CVE-2024-35247
In the Linux kernel, the following vulnerability has been resolved: fpga: region: add owner module and take its refcount The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga region.
- https://git.kernel.org/stable/c/2279c09c36165ccded4d506d11a7714e13b56019
- https://git.kernel.org/stable/c/26e6e25d742e29885cf44274fcf6b744366c4702
- https://git.kernel.org/stable/c/4d7d12b643c00e7eea51b49a60a2ead182633ec8
- https://git.kernel.org/stable/c/75a001914a8d2ccdcbe4b8cc7e94ac71d0e66093
- https://git.kernel.org/stable/c/9b4eee8572dcf82b2ed17d9a328c7fb87df2f0e8
- https://git.kernel.org/stable/c/b7c0e1ecee403a43abc89eb3e75672b01ff2ece9
- https://git.kernel.org/stable/c/2279c09c36165ccded4d506d11a7714e13b56019
- https://git.kernel.org/stable/c/26e6e25d742e29885cf44274fcf6b744366c4702
- https://git.kernel.org/stable/c/4d7d12b643c00e7eea51b49a60a2ead182633ec8
- https://git.kernel.org/stable/c/75a001914a8d2ccdcbe4b8cc7e94ac71d0e66093
- https://git.kernel.org/stable/c/9b4eee8572dcf82b2ed17d9a328c7fb87df2f0e8
- https://git.kernel.org/stable/c/b7c0e1ecee403a43abc89eb3e75672b01ff2ece9
Modified: 2025-01-10
CVE-2024-35784
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase.
- https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b
- https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd
- https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf
- https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b
- https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd
- https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf
Modified: 2026-01-22
CVE-2024-35785
In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix kernel panic caused by incorrect error handling The error path while failing to register devices on the TEE bus has a bug leading to kernel panic as follows: [ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c [ 15.406913] Mem abort info: [ 15.409722] ESR = 0x0000000096000005 [ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.418814] SET = 0, FnV = 0 [ 15.421878] EA = 0, S1PTW = 0 [ 15.425031] FSC = 0x05: level 1 translation fault [ 15.429922] Data abort info: [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000 [ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000 [ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration") lead to the introduction of this bug. So fix it appropriately.
- https://git.kernel.org/stable/c/4b12ff5edd141926d49c9ace4791adf3a4902fe7
- https://git.kernel.org/stable/c/520f79c110ff712b391b3d87fcacf03c74bc56ee
- https://git.kernel.org/stable/c/95915ba4b987cf2b222b0f251280228a1ff977ac
- https://git.kernel.org/stable/c/bc40ded92af55760d12bec8222d4108de725dbe4
- https://git.kernel.org/stable/c/bfa344afbe472a9be08f78551fa2190c1a07d7d3
- https://git.kernel.org/stable/c/e5b5948c769aa1ebf962dddfb972f87d8f166f95
- https://git.kernel.org/stable/c/4b12ff5edd141926d49c9ace4791adf3a4902fe7
- https://git.kernel.org/stable/c/520f79c110ff712b391b3d87fcacf03c74bc56ee
- https://git.kernel.org/stable/c/95915ba4b987cf2b222b0f251280228a1ff977ac
- https://git.kernel.org/stable/c/bc40ded92af55760d12bec8222d4108de725dbe4
- https://git.kernel.org/stable/c/bfa344afbe472a9be08f78551fa2190c1a07d7d3
- https://git.kernel.org/stable/c/e5b5948c769aa1ebf962dddfb972f87d8f166f95
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-10
CVE-2024-35786
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf If VM_BIND is enabled on the client the legacy submission ioctl can't be used, however if a client tries to do so regardless it will return an error. In this case the clients mutex remained unlocked leading to a deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.
- https://git.kernel.org/stable/c/b466416bdd6ecbde15ce987226ea633a0268fbb1
- https://git.kernel.org/stable/c/c288a61a48ddb77ec097e11ab81b81027cd4e197
- https://git.kernel.org/stable/c/daf8739c3322a762ce84f240f50e0c39181a41ab
- https://git.kernel.org/stable/c/b466416bdd6ecbde15ce987226ea633a0268fbb1
- https://git.kernel.org/stable/c/c288a61a48ddb77ec097e11ab81b81027cd4e197
- https://git.kernel.org/stable/c/daf8739c3322a762ce84f240f50e0c39181a41ab
Modified: 2025-09-26
CVE-2024-35787
In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix incorrect usage for sb_index Commit d7038f951828 ("md-bitmap: don't use ->index for pages backing the bitmap file") removed page->index from bitmap code, but left wrong code logic for clustered-md. current code never set slot offset for cluster nodes, will sometimes cause crash in clustered env. Call trace (partly): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_mod] md_submit_bio+0x80/0xf8 [md_mod] __submit_bio+0x178/0x300 submit_bio_noacct_nocheck+0x11c/0x338 submit_bio_noacct+0x134/0x614 submit_bio+0x28/0xdc submit_bh_wbc+0x130/0x1cc submit_bh+0x1c/0x28
- https://git.kernel.org/stable/c/55e55eb65fd5e09faf5a0e49ffcdd37905aaf4da
- https://git.kernel.org/stable/c/5a95815b17428ce2f56ec18da5e0d1b2a1a15240
- https://git.kernel.org/stable/c/736ad6c577a367834118f57417038d45bb5e0a31
- https://git.kernel.org/stable/c/ecbd8ebb51bf7e4939d83b9e6022a55cac44ef06
- https://git.kernel.org/stable/c/55e55eb65fd5e09faf5a0e49ffcdd37905aaf4da
- https://git.kernel.org/stable/c/5a95815b17428ce2f56ec18da5e0d1b2a1a15240
- https://git.kernel.org/stable/c/736ad6c577a367834118f57417038d45bb5e0a31
- https://git.kernel.org/stable/c/ecbd8ebb51bf7e4939d83b9e6022a55cac44ef06
Modified: 2025-12-23
CVE-2024-35789
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change.
- https://git.kernel.org/stable/c/2884a50f52313a7a911de3afcad065ddbb3d78fc
- https://git.kernel.org/stable/c/4f2bdb3c5e3189297e156b3ff84b140423d64685
- https://git.kernel.org/stable/c/6b948b54c8bd620725e0c906e44b10c0b13087a7
- https://git.kernel.org/stable/c/7eeabcea79b67cc29563e6a9a5c81f9e2c664d5b
- https://git.kernel.org/stable/c/be1dd9254fc115321d6fbee042026d42afc8d931
- https://git.kernel.org/stable/c/c8bddbd91bc8e42c961a5e2cec20ab879f21100f
- https://git.kernel.org/stable/c/e8678551c0243f799b4859448781cbec1bd6f1cb
- https://git.kernel.org/stable/c/e8b067c4058c0121ac8ca71559df8e2e08ff1a7e
- https://git.kernel.org/stable/c/ea9a0cfc07a7d3601cc680718d9cff0d6927a921
- https://git.kernel.org/stable/c/2884a50f52313a7a911de3afcad065ddbb3d78fc
- https://git.kernel.org/stable/c/4f2bdb3c5e3189297e156b3ff84b140423d64685
- https://git.kernel.org/stable/c/6b948b54c8bd620725e0c906e44b10c0b13087a7
- https://git.kernel.org/stable/c/7eeabcea79b67cc29563e6a9a5c81f9e2c664d5b
- https://git.kernel.org/stable/c/be1dd9254fc115321d6fbee042026d42afc8d931
- https://git.kernel.org/stable/c/c8bddbd91bc8e42c961a5e2cec20ab879f21100f
- https://git.kernel.org/stable/c/e8678551c0243f799b4859448781cbec1bd6f1cb
- https://git.kernel.org/stable/c/e8b067c4058c0121ac8ca71559df8e2e08ff1a7e
- https://git.kernel.org/stable/c/ea9a0cfc07a7d3601cc680718d9cff0d6927a921
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-35790
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI.
- https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9
- https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531
- https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0
- https://git.kernel.org/stable/c/6b989ea1c479533ab8dbfbeb1704c94b1d3320da
- https://git.kernel.org/stable/c/9794ffd9d0c39ee070fbd733f862bbe89b28ba33
- https://git.kernel.org/stable/c/f1c5ddaef506e3517dce338c08a60663b1521920
- https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9
- https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531
- https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-23
CVE-2024-35791
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has __unregister_enc_region_locked() already queued up for the region. Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed. Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory.
- https://git.kernel.org/stable/c/12f8e32a5a389a5d58afc67728c76e61beee1ad4
- https://git.kernel.org/stable/c/2d13b79640b147bd77c34a5998533b2021a4122d
- https://git.kernel.org/stable/c/4868c0ecdb6cfde7c70cf478c46e06bb9c7e5865
- https://git.kernel.org/stable/c/5ef1d8c1ddbf696e47b226e11888eaf8d9e8e807
- https://git.kernel.org/stable/c/e126b508ed2e616d679d85fca2fbe77bb48bbdd7
- https://git.kernel.org/stable/c/f6d53d8a2617dd58c89171a6b9610c470ebda38a
- https://git.kernel.org/stable/c/12f8e32a5a389a5d58afc67728c76e61beee1ad4
- https://git.kernel.org/stable/c/2d13b79640b147bd77c34a5998533b2021a4122d
- https://git.kernel.org/stable/c/4868c0ecdb6cfde7c70cf478c46e06bb9c7e5865
- https://git.kernel.org/stable/c/5ef1d8c1ddbf696e47b226e11888eaf8d9e8e807
- https://git.kernel.org/stable/c/e126b508ed2e616d679d85fca2fbe77bb48bbdd7
- https://git.kernel.org/stable/c/f6d53d8a2617dd58c89171a6b9610c470ebda38a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-05
CVE-2024-35792
In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - Fix use after free in unprepare The unprepare call must be carried out before the finalize call as the latter can free the request.
- https://git.kernel.org/stable/c/48dd260fdb728eda4a246f635d1325e82f0d3555
- https://git.kernel.org/stable/c/c0afb6b88fbbc177fa322a835f874be217bffe45
- https://git.kernel.org/stable/c/eb2a41a8ae8c8c4f68aef3bd94665c0cf23e04be
- https://git.kernel.org/stable/c/48dd260fdb728eda4a246f635d1325e82f0d3555
- https://git.kernel.org/stable/c/c0afb6b88fbbc177fa322a835f874be217bffe45
- https://git.kernel.org/stable/c/eb2a41a8ae8c8c4f68aef3bd94665c0cf23e04be
Modified: 2025-01-10
CVE-2024-35795
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix deadlock while reading mqd from debugfs An errant disk backup on my desktop got into debugfs and triggered the following deadlock scenario in the amdgpu debugfs files. The machine also hard-resets immediately after those lines are printed (although I wasn't able to reproduce that part when reading by hand): [ 1318.016074][ T1082] ====================================================== [ 1318.016607][ T1082] WARNING: possible circular locking dependency detected [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted [ 1318.017598][ T1082] ------------------------------------------------------ [ 1318.018096][ T1082] tar/1082 is trying to acquire lock: [ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80 [ 1318.019084][ T1082] [ 1318.019084][ T1082] but task is already holding lock: [ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] which lock already depends on the new lock. [ 1318.020607][ T1082] [ 1318.022081][ T1082] [ 1318.022081][ T1082] the existing dependency chain (in reverse order) is: [ 1318.023083][ T1082] [ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0 [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90 [ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330 [ 1318.025683][ T1082] do_one_initcall+0x6a/0x350 [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1082] ret_from_fork+0x2c/0x40 [ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.028281][ T1082] [ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}: [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330 [ 1318.029790][ T1082] do_one_initcall+0x6a/0x350 [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.030722][ T1082] kernel_init+0x15/0x1a0 [ 1318.031168][ T1082] ret_from_fork+0x2c/0x40 [ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680 [ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0 [ 1318.033487][ T1082] __might_fault+0x58/0x80 [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu] [ 1318.034181][ T1082] full_proxy_read+0x55/0x80 [ 1318.034487][ T1082] vfs_read+0xa7/0x360 [ 1318.034788][ T1082] ksys_read+0x70/0xf0 [ 1318.035085][ T1082] do_syscall_64+0x94/0x180 [ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 1318.035664][ T1082] [ 1318.035664][ T1082] other info that might help us debug this: [ 1318.035664][ T1082] [ 1318.036487][ T1082] Chain exists of: [ 1318.036487][ T1082] &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [ 1318.036487][ T1082] [ 1318.037310][ T1082] Possible unsafe locking scenario: [ 1318.037310][ T1082] [ 1318.037838][ T1082] CPU0 CPU1 [ 1318.038101][ T1082] ---- ---- [ 1318.038350][ T1082] lock(reservation_ww_class_mutex); [ 1318.038590][ T1082] lock(reservation_ww_class_acquire); [ 1318.038839][ T1082] lock(reservation_ww_class_mutex); [ 1318.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][ T1082] [ 1318.040029][ T1082] 1 lock held by tar/1082: [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.040560][ T1082] [ 1318.040560][ T1082] stack backtrace: [ ---truncated---
- https://git.kernel.org/stable/c/197f6d6987c55860f6eea1c93e4f800c59078874
- https://git.kernel.org/stable/c/4687e3c6ee877ee25e57b984eca00be53b9a8db5
- https://git.kernel.org/stable/c/8678b1060ae2b75feb60b87e5b75e17374e3c1c5
- https://git.kernel.org/stable/c/8b03556da6e576c62664b6cd01809e4a09d53b5b
- https://git.kernel.org/stable/c/197f6d6987c55860f6eea1c93e4f800c59078874
- https://git.kernel.org/stable/c/4687e3c6ee877ee25e57b984eca00be53b9a8db5
- https://git.kernel.org/stable/c/8678b1060ae2b75feb60b87e5b75e17374e3c1c5
- https://git.kernel.org/stable/c/8b03556da6e576c62664b6cd01809e4a09d53b5b
Modified: 2025-12-23
CVE-2024-35796
In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: platform_get_resource replaced by wrong function The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name. This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name)) It should have been replaced with devm_platform_ioremap_resource.
- https://git.kernel.org/stable/c/3a38a829c8bc27d78552c28e582eb1d885d07d11
- https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3
- https://git.kernel.org/stable/c/476eed5f1c22034774902a980aa48dc4662cb39a
- https://git.kernel.org/stable/c/553d294db94b5f139378022df480a9fb6c3ae39e
- https://git.kernel.org/stable/c/6d9395ba7f85bdb7af0b93272e537484ecbeff48
- https://git.kernel.org/stable/c/7e9edb569fd9f688d887e36db8170f6e22bafbc8
- https://git.kernel.org/stable/c/92c0c29f667870f17c0b764544bdf22ce0e886a1
- https://git.kernel.org/stable/c/3a38a829c8bc27d78552c28e582eb1d885d07d11
- https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3
- https://git.kernel.org/stable/c/476eed5f1c22034774902a980aa48dc4662cb39a
- https://git.kernel.org/stable/c/553d294db94b5f139378022df480a9fb6c3ae39e
- https://git.kernel.org/stable/c/6d9395ba7f85bdb7af0b93272e537484ecbeff48
- https://git.kernel.org/stable/c/7e9edb569fd9f688d887e36db8170f6e22bafbc8
- https://git.kernel.org/stable/c/92c0c29f667870f17c0b764544bdf22ce0e886a1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-19
CVE-2024-35797
In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix two shmem bugs When cachestat on shmem races with swapping and invalidation, there are two possible bugs: 1) A swapin error can have resulted in a poisoned swap entry in the shmem inode's xarray. Calling get_shadow_from_swap_cache() on it will result in an out-of-bounds access to swapper_spaces[]. Validate the entry with non_swap_entry() before going further. 2) When we find a valid swap entry in the shmem's inode, the shadow entry in the swapcache might not exist yet: swap IO is still in progress and we're before __remove_mapping; swapin, invalidation, or swapoff have removed the shadow from swapcache after we saw the shmem swap entry. This will send a NULL to workingset_test_recent(). The latter purely operates on pointer bits, so it won't crash - node 0, memcg ID 0, eviction timestamp 0, etc. are all valid inputs - but it's a bogus test. In theory that could result in a false "recently evicted" count. Such a false positive wouldn't be the end of the world. But for code clarity and (future) robustness, be explicit about this case. Bail on get_shadow_from_swap_cache() returning NULL.
- https://git.kernel.org/stable/c/24a0e73d544439bb9329fbbafac44299e548a677
- https://git.kernel.org/stable/c/b79f9e1ff27c994a4c452235ba09e672ec698e23
- https://git.kernel.org/stable/c/d5d39c707a4cf0bcc84680178677b97aa2cb2627
- https://git.kernel.org/stable/c/d962f6c583458037dc7e529659b2b02b9dd3d94b
- https://git.kernel.org/stable/c/24a0e73d544439bb9329fbbafac44299e548a677
- https://git.kernel.org/stable/c/b79f9e1ff27c994a4c452235ba09e672ec698e23
- https://git.kernel.org/stable/c/d5d39c707a4cf0bcc84680178677b97aa2cb2627
- https://git.kernel.org/stable/c/d962f6c583458037dc7e529659b2b02b9dd3d94b
Modified: 2025-09-19
CVE-2024-35798
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race in read_extent_buffer_pages() There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there's a race when reading an extent buffer the uptodate status can be missed. To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done; At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving: Thread A | Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified: BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360] Fix it by testing UPTODATE again after setting the READING bit, and if it's been set, skip the unnecessary read. [ minor update of changelog ]
- https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052
- https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1
- https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80
- https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215
- https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052
- https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1
- https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80
- https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215
Modified: 2025-09-19
CVE-2024-35799
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Prevent crash when disable stream [Why] Disabling stream encoder invokes a function that no longer exists. [How] Check if the function declaration is NULL in disable stream encoder.
- https://git.kernel.org/stable/c/2b17133a0a2e0e111803124dad09e803718d4a48
- https://git.kernel.org/stable/c/4356a2c3f296503c8b420ae8adece053960a9f06
- https://git.kernel.org/stable/c/59772327d439874095516673b4b30c48bd83ca38
- https://git.kernel.org/stable/c/72d72e8fddbcd6c98e1b02d32cf6f2b04e10bd1c
- https://git.kernel.org/stable/c/2b17133a0a2e0e111803124dad09e803718d4a48
- https://git.kernel.org/stable/c/4356a2c3f296503c8b420ae8adece053960a9f06
- https://git.kernel.org/stable/c/59772327d439874095516673b4b30c48bd83ca38
- https://git.kernel.org/stable/c/72d72e8fddbcd6c98e1b02d32cf6f2b04e10bd1c
Modified: 2025-09-19
CVE-2024-35800
In the Linux kernel, the following vulnerability has been resolved: efi: fix panic in kdump kernel Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware.
- https://git.kernel.org/stable/c/090d2b4515ade379cd592fbc8931344945978210
- https://git.kernel.org/stable/c/62b71cd73d41ddac6b1760402bbe8c4932e23531
- https://git.kernel.org/stable/c/7784135f134c13af17d9ffb39a57db8500bc60ff
- https://git.kernel.org/stable/c/9114ba9987506bcfbb454f6e68558d68cb1abbde
- https://git.kernel.org/stable/c/b9d103aca85f082a343b222493f3cab1219aaaf4
- https://git.kernel.org/stable/c/090d2b4515ade379cd592fbc8931344945978210
- https://git.kernel.org/stable/c/62b71cd73d41ddac6b1760402bbe8c4932e23531
- https://git.kernel.org/stable/c/7784135f134c13af17d9ffb39a57db8500bc60ff
- https://git.kernel.org/stable/c/9114ba9987506bcfbb454f6e68558d68cb1abbde
- https://git.kernel.org/stable/c/b9d103aca85f082a343b222493f3cab1219aaaf4
Modified: 2025-09-19
CVE-2024-35801
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.
- https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422
- https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd
- https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d
- https://git.kernel.org/stable/c/92b0f04e937665bde5768f3fcc622dcce44413d8
- https://git.kernel.org/stable/c/b61e3b7055ac6edee4be071c52f48c26472d2624
- https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422
- https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd
- https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d
- https://git.kernel.org/stable/c/92b0f04e937665bde5768f3fcc622dcce44413d8
- https://git.kernel.org/stable/c/b61e3b7055ac6edee4be071c52f48c26472d2624
Modified: 2025-09-26
CVE-2024-35803
In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made.
- https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926
- https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc
- https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31
- https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02
- https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d
- https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926
- https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc
- https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31
- https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02
- https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d
Modified: 2025-09-19
CVE-2024-35804
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Mark target gfn of emulated atomic instruction as dirty When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty. Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase. Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit. Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging. base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64
- https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71
- https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06
- https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902
- https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551
- https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66
- https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71
- https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06
- https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902
- https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551
- https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66
Modified: 2025-12-23
CVE-2024-35805
In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.
- https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7
- https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1
- https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683
- https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc
- https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c
- https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2
- https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e
- https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366
- https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7
- https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1
- https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683
- https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc
- https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c
- https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2
- https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e
- https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-10
CVE-2024-35806
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Always disable interrupts when taking cgr_lock smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.
- https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397
- https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f
- https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3
- https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a
- https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03
- https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd
- https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9
- https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec
- https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430
- https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397
- https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f
- https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3
- https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a
- https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03
- https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd
- https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9
- https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec
- https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-35807
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix corruption during on-line resize
We observed a corruption during on-line resize of a file system that is
larger than 16 TiB with 4k block size. With having more then 2^32 blocks
resize_inode is turned off by default by mke2fs. The issue can be
reproduced on a smaller file system for convenience by explicitly
turning off resize_inode. An on-line resize across an 8 GiB boundary (the
size of a meta block group in this setup) then leads to a corruption:
dev=/dev/
- https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6
- https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5
- https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd
- https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1
- https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc
- https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c
- https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a
- https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c
- https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df
- https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6
- https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5
- https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd
- https://git.kernel.org/stable/c/75cc31c2e7193b69f5d25650bda5bb42ed92f8a1
- https://git.kernel.org/stable/c/a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc
- https://git.kernel.org/stable/c/b461910af8ba3bed80f48c2bf852686d05c6fc5c
- https://git.kernel.org/stable/c/e8e8b197317228b5089ed9e7802dadf3ccaa027a
- https://git.kernel.org/stable/c/ee4e9c1976147a850f6085a13fca95bcaa00d84c
- https://git.kernel.org/stable/c/fb1088d51bbaa0faec5a55d4f5818a9ab79e24df
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35809
In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks.
- https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1
- https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627bdc6970
- https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674
- https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b
- https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6
- https://git.kernel.org/stable/c/9d5286d4e7f68beab450deddbb6a32edd5ecf4bf
- https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491
- https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5
- https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989
- https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1
- https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627bdc6970
- https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674
- https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b
- https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6
- https://git.kernel.org/stable/c/9d5286d4e7f68beab450deddbb6a32edd5ecf4bf
- https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491
- https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5
- https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-26
CVE-2024-35810
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix the lifetime of the bo cursor memory The cleanup can be dispatched while the atomic update is still active, which means that the memory acquired in the atomic update needs to not be invalidated by the cleanup. The buffer objects in vmw_plane_state instead of using the builtin map_and_cache were trying to handle the lifetime of the mapped memory themselves, leading to crashes. Use the map_and_cache instead of trying to manage the lifetime of the buffer objects held by the vmw_plane_state. Fixes kernel oops'es in IGT's kms_cursor_legacy forked-bo.
- https://git.kernel.org/stable/c/104a5b2772bc7c0715ae7355ccf9d294a472765c
- https://git.kernel.org/stable/c/86cb706a40b7e6b2221ee49a298a65ad9b46c02d
- https://git.kernel.org/stable/c/9a9e8a7159ca09af9b1a300a6c8e8b6ff7501c76
- https://git.kernel.org/stable/c/ed381800ea6d9a4c7f199235a471c0c48100f0ae
- https://git.kernel.org/stable/c/104a5b2772bc7c0715ae7355ccf9d294a472765c
- https://git.kernel.org/stable/c/86cb706a40b7e6b2221ee49a298a65ad9b46c02d
- https://git.kernel.org/stable/c/9a9e8a7159ca09af9b1a300a6c8e8b6ff7501c76
- https://git.kernel.org/stable/c/ed381800ea6d9a4c7f199235a471c0c48100f0ae
Modified: 2025-01-14
CVE-2024-35811
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
- https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb
- https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744
- https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78
- https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a
- https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169
- https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a
- https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731
- https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1
- https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa
- https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb
- https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744
- https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78
- https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a
- https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169
- https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a
- https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731
- https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1
- https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-16
CVE-2024-35813
In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid negative index with array access Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns prev_idata = idatas[i - 1], but doesn't check that the iterator i is greater than zero. Let's fix this by adding a check.
- https://git.kernel.org/stable/c/064db53f9023a2d5877a2d12de6bc27995f6ca56
- https://git.kernel.org/stable/c/2b539c88940e22494da80a93ee1c5a28bbad10f6
- https://git.kernel.org/stable/c/4466677dcabe2d70de6aa3d4bd4a4fafa94a71f2
- https://git.kernel.org/stable/c/7d0e8a6147550aa058fa6ade8583ad252aa61304
- https://git.kernel.org/stable/c/81b8645feca08a54c7c4bf36e7b176f4983b2f28
- https://git.kernel.org/stable/c/ad9cc5e9e53ab94aa0c7ac65d43be7eb208dcb55
- https://git.kernel.org/stable/c/b9a7339ae403035ffe7fc37cb034b36947910f68
- https://git.kernel.org/stable/c/cf55a7acd1ed38afe43bba1c8a0935b51d1dc014
- https://git.kernel.org/stable/c/064db53f9023a2d5877a2d12de6bc27995f6ca56
- https://git.kernel.org/stable/c/2b539c88940e22494da80a93ee1c5a28bbad10f6
- https://git.kernel.org/stable/c/4466677dcabe2d70de6aa3d4bd4a4fafa94a71f2
- https://git.kernel.org/stable/c/7d0e8a6147550aa058fa6ade8583ad252aa61304
- https://git.kernel.org/stable/c/81b8645feca08a54c7c4bf36e7b176f4983b2f28
- https://git.kernel.org/stable/c/ad9cc5e9e53ab94aa0c7ac65d43be7eb208dcb55
- https://git.kernel.org/stable/c/b9a7339ae403035ffe7fc37cb034b36947910f68
- https://git.kernel.org/stable/c/cf55a7acd1ed38afe43bba1c8a0935b51d1dc014
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-19
CVE-2024-35814
In the Linux kernel, the following vulnerability has been resolved: swiotlb: Fix double-allocation of slots due to broken alignment handling Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool. When virtio allocates the virtqueues for the vsock device using dma_alloc_coherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer: # Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800) This ends badly (typically buffer corruption and/or a hang) because swiotlb_alloc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page. Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page. This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and resulting in alignment requirements exceeding swiotlb_max_mapping_size().
- https://git.kernel.org/stable/c/04867a7a33324c9c562ee7949dbcaab7aaad1fb4
- https://git.kernel.org/stable/c/3e7acd6e25ba77dde48c3b721c54c89cd6a10534
- https://git.kernel.org/stable/c/777391743771040e12cc40d3d0d178f70c616491
- https://git.kernel.org/stable/c/c88668aa6c1da240ea3eb4d128b7906e740d3cb8
- https://git.kernel.org/stable/c/04867a7a33324c9c562ee7949dbcaab7aaad1fb4
- https://git.kernel.org/stable/c/3e7acd6e25ba77dde48c3b721c54c89cd6a10534
- https://git.kernel.org/stable/c/777391743771040e12cc40d3d0d178f70c616491
- https://git.kernel.org/stable/c/c88668aa6c1da240ea3eb4d128b7906e740d3cb8
Modified: 2025-12-16
CVE-2024-35815
In the Linux kernel, the following vulnerability has been resolved: fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first.
- https://git.kernel.org/stable/c/10ca82aff58434e122c7c757cf0497c335f993f3
- https://git.kernel.org/stable/c/18d5fc3c16cc317bd0e5f5dabe0660df415cadb7
- https://git.kernel.org/stable/c/396dbbc18963648e9d1a4edbb55cfe08fa374d50
- https://git.kernel.org/stable/c/5c43d0041e3a05c6c41c318b759fff16d2384596
- https://git.kernel.org/stable/c/94eb0293703ced580f05dfbe5a57da5931e9aee2
- https://git.kernel.org/stable/c/961ebd120565cb60cebe21cb634fbc456022db4a
- https://git.kernel.org/stable/c/a71cba07783abc76b547568b6452cd1dd9981410
- https://git.kernel.org/stable/c/c01ed748847fe8b810d86efc229b9e6c7fafa01e
- https://git.kernel.org/stable/c/10ca82aff58434e122c7c757cf0497c335f993f3
- https://git.kernel.org/stable/c/18d5fc3c16cc317bd0e5f5dabe0660df415cadb7
- https://git.kernel.org/stable/c/396dbbc18963648e9d1a4edbb55cfe08fa374d50
- https://git.kernel.org/stable/c/5c43d0041e3a05c6c41c318b759fff16d2384596
- https://git.kernel.org/stable/c/94eb0293703ced580f05dfbe5a57da5931e9aee2
- https://git.kernel.org/stable/c/961ebd120565cb60cebe21cb634fbc456022db4a
- https://git.kernel.org/stable/c/a71cba07783abc76b547568b6452cd1dd9981410
- https://git.kernel.org/stable/c/c01ed748847fe8b810d86efc229b9e6c7fafa01e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-26
CVE-2024-35816
In the Linux kernel, the following vulnerability has been resolved: firewire: ohci: prevent leak of left-over IRQ on unbind Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") also removed the call to free_irq() in pci_remove(), leading to a leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove() when unbinding the driver from the device remove_proc_entry: removing non-empty directory 'irq/136', leaking at least 'firewire_ohci' Call Trace: ? remove_proc_entry+0x19c/0x1c0 ? __warn+0x81/0x130 ? remove_proc_entry+0x19c/0x1c0 ? report_bug+0x171/0x1a0 ? console_unlock+0x78/0x120 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? remove_proc_entry+0x19c/0x1c0 unregister_irq_proc+0xf4/0x120 free_desc+0x3d/0xe0 ? kfree+0x29f/0x2f0 irq_free_descs+0x47/0x70 msi_domain_free_locked.part.0+0x19d/0x1d0 msi_domain_free_irqs_all_locked+0x81/0xc0 pci_free_msi_irqs+0x12/0x40 pci_disable_msi+0x4c/0x60 pci_remove+0x9d/0xc0 [firewire_ohci 01b483699bebf9cb07a3d69df0aa2bee71db1b26] pci_device_remove+0x37/0xa0 device_release_driver_internal+0x19f/0x200 unbind_store+0xa1/0xb0 remove irq with devm_free_irq() before pci_disable_msi() also remove it in fail_msi: of pci_probe() as this would lead to an identical leak
- https://git.kernel.org/stable/c/318f6d53dd425c400e35f1a9b7af682c2c6a66d6
- https://git.kernel.org/stable/c/43c70cbc2502cf2557105c662eeed6a15d082b88
- https://git.kernel.org/stable/c/575801663c7dc38f826212b39e3b91a4a8661c33
- https://git.kernel.org/stable/c/318f6d53dd425c400e35f1a9b7af682c2c6a66d6
- https://git.kernel.org/stable/c/43c70cbc2502cf2557105c662eeed6a15d082b88
- https://git.kernel.org/stable/c/575801663c7dc38f826212b39e3b91a4a8661c33
Modified: 2025-09-26
CVE-2024-35817
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue.
- https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe
- https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d
- https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb
- https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3
- https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3
- https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6
- https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe
- https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d
- https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb
- https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3
- https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3
- https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6
Modified: 2025-09-26
CVE-2024-35818
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition. Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch: radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
- https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0
- https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167
- https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb
- https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd
- https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d
- https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0
- https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167
- https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb
- https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd
- https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d
Modified: 2025-12-17
CVE-2024-35819
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Use raw spinlock for cgr_lock smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task. Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.
- https://git.kernel.org/stable/c/2b3fede8225133671ce837c0d284804aa3bc7a02
- https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1
- https://git.kernel.org/stable/c/54d26adf64c04f186098b39dba86b86037084baa
- https://git.kernel.org/stable/c/9a3ca8292ce9fdcce122706c28c3f07bc857fe5e
- https://git.kernel.org/stable/c/cd53a8ae5aacb4ecd25088486dea1cd02e74b506
- https://git.kernel.org/stable/c/d6b5aac451c9cc12e43ab7308e0e2ddc52c62c14
- https://git.kernel.org/stable/c/f39d36b7540cf0088ed7ce2de2794f2aa237f6df
- https://git.kernel.org/stable/c/fbec4e7fed89b579f2483041fabf9650fb0dd6bc
- https://git.kernel.org/stable/c/ff50716b7d5b7985979a5b21163cd79fb3d21d59
- https://git.kernel.org/stable/c/2b3fede8225133671ce837c0d284804aa3bc7a02
- https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1
- https://git.kernel.org/stable/c/54d26adf64c04f186098b39dba86b86037084baa
- https://git.kernel.org/stable/c/9a3ca8292ce9fdcce122706c28c3f07bc857fe5e
- https://git.kernel.org/stable/c/cd53a8ae5aacb4ecd25088486dea1cd02e74b506
- https://git.kernel.org/stable/c/d6b5aac451c9cc12e43ab7308e0e2ddc52c62c14
- https://git.kernel.org/stable/c/f39d36b7540cf0088ed7ce2de2794f2aa237f6df
- https://git.kernel.org/stable/c/fbec4e7fed89b579f2483041fabf9650fb0dd6bc
- https://git.kernel.org/stable/c/ff50716b7d5b7985979a5b21163cd79fb3d21d59
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35821
In the Linux kernel, the following vulnerability has been resolved: ubifs: Set page uptodate in the correct place Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page.
- https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3
- https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566
- https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e
- https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e
- https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f
- https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310
- https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f
- https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3
- https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f
- https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3
- https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566
- https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e
- https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e
- https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f
- https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310
- https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f
- https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3
- https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-35822
In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().
- https://git.kernel.org/stable/c/2a587a035214fa1b5ef598aea0b81848c5b72e5e
- https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8
- https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f02577a10252
- https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c
- https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a
- https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c
- https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290
- https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf
- https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf
- https://git.kernel.org/stable/c/2a587a035214fa1b5ef598aea0b81848c5b72e5e
- https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8
- https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f02577a10252
- https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c
- https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a
- https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c
- https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290
- https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf
- https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35823
In the Linux kernel, the following vulnerability has been resolved: vt: fix unicode buffer corruption when deleting characters This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.
- https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f
- https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d
- https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90
- https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1
- https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda
- https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51
- https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d
- https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a
- https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f
- https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d
- https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90
- https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1
- https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda
- https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51
- https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d
- https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-26
CVE-2024-35824
In the Linux kernel, the following vulnerability has been resolved: misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume When not configured for wakeup lis3lv02d_i2c_suspend() will call lis3lv02d_poweroff() even if the device has already been turned off by the runtime-suspend handler and if configured for wakeup and the device is runtime-suspended at this point then it is not turned back on to serve as a wakeup source. Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable the regulators which as a side effect made calling poweroff() twice ok. Now that poweroff() correctly disables the regulators, doing this twice triggers a WARN() in the regulator core: unbalanced disables for regulator-dummy WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable ... Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if already runtime-suspended and add a poweron() call when necessary to make wakeup work. lis3lv02d_i2c_resume() has similar issues, with an added weirness that it always powers on the device if it is runtime suspended, after which the first runtime-resume will call poweron() again, causing the enabled count for the regulator to increase by 1 every suspend/resume. These unbalanced regulator_enable() calls cause the regulator to never be turned off and trigger the following WARN() on driver unbind: WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put Fix this by making lis3lv02d_i2c_resume() mirror the new suspend().
- https://git.kernel.org/stable/c/4154e767354140db7804207117e7238fb337b0e7
- https://git.kernel.org/stable/c/997ca415384612c8df76d99d9a768e0b3f42b325
- https://git.kernel.org/stable/c/ac3e0384073b2408d6cb0d972fee9fcc3776053d
- https://git.kernel.org/stable/c/f6df761182fc953907b18aba5049fc2a044ecb45
- https://git.kernel.org/stable/c/4154e767354140db7804207117e7238fb337b0e7
- https://git.kernel.org/stable/c/997ca415384612c8df76d99d9a768e0b3f42b325
- https://git.kernel.org/stable/c/ac3e0384073b2408d6cb0d972fee9fcc3776053d
- https://git.kernel.org/stable/c/f6df761182fc953907b18aba5049fc2a044ecb45
Modified: 2025-12-17
CVE-2024-35825
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Fix handling of zero block length packets While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.
- https://git.kernel.org/stable/c/6b2c73111a252263807b7598682663dc33aa4b4c
- https://git.kernel.org/stable/c/7664ee8bd80309b90d53488b619764f0a057f2b7
- https://git.kernel.org/stable/c/92b051b87658df7649ffcdef522593f21a2b296b
- https://git.kernel.org/stable/c/a0f77b5d6067285b8eca0ee3bd1e448a6258026f
- https://git.kernel.org/stable/c/a766761d206e7c36d7526e0ae749949d17ca582c
- https://git.kernel.org/stable/c/e2dbfea520e60d58e0c498ba41bde10452257779
- https://git.kernel.org/stable/c/ef846cdbd100f7f9dc045e8bcd7fe4b3a3713c03
- https://git.kernel.org/stable/c/f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70
- https://git.kernel.org/stable/c/6b2c73111a252263807b7598682663dc33aa4b4c
- https://git.kernel.org/stable/c/7664ee8bd80309b90d53488b619764f0a057f2b7
- https://git.kernel.org/stable/c/92b051b87658df7649ffcdef522593f21a2b296b
- https://git.kernel.org/stable/c/a0f77b5d6067285b8eca0ee3bd1e448a6258026f
- https://git.kernel.org/stable/c/a766761d206e7c36d7526e0ae749949d17ca582c
- https://git.kernel.org/stable/c/e2dbfea520e60d58e0c498ba41bde10452257779
- https://git.kernel.org/stable/c/ef846cdbd100f7f9dc045e8bcd7fe4b3a3713c03
- https://git.kernel.org/stable/c/f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-26
CVE-2024-35826
In the Linux kernel, the following vulnerability has been resolved: block: Fix page refcounts for unaligned buffers in __bio_release_pages() Fix an incorrect number of pages being released for buffers that do not start at the beginning of a page.
- https://git.kernel.org/stable/c/242006996d15f5ca62e22f8c7de077d9c4a8f367
- https://git.kernel.org/stable/c/38b43539d64b2fa020b3b9a752a986769f87f7a6
- https://git.kernel.org/stable/c/7d3765550374f71248c55e6206ea1d6fd4537e65
- https://git.kernel.org/stable/c/c9d3d2fbde9b8197bce88abcbe8ee8e713ffe7c2
- https://git.kernel.org/stable/c/ecbd9ced84dd655a8f4cd49d2aad0e80dbf6bf35
- https://git.kernel.org/stable/c/242006996d15f5ca62e22f8c7de077d9c4a8f367
- https://git.kernel.org/stable/c/38b43539d64b2fa020b3b9a752a986769f87f7a6
- https://git.kernel.org/stable/c/7d3765550374f71248c55e6206ea1d6fd4537e65
- https://git.kernel.org/stable/c/c9d3d2fbde9b8197bce88abcbe8ee8e713ffe7c2
- https://git.kernel.org/stable/c/ecbd9ced84dd655a8f4cd49d2aad0e80dbf6bf35
Modified: 2024-12-30
CVE-2024-35847
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ]
- https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792
- https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137
- https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438
- https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52
- https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662
- https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91
- https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9
- https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae
- https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792
- https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137
- https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438
- https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52
- https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662
- https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91
- https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9
- https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35848
In the Linux kernel, the following vulnerability has been resolved: eeprom: at24: fix memory corruption race condition If the eeprom is not accessible, an nvmem device will be registered, the read will fail, and the device will be torn down. If another driver accesses the nvmem device after the teardown, it will reference invalid memory. Move the failure point before registering the nvmem device.
- https://git.kernel.org/stable/c/26d32bec4c6d255a03762f33c637bfa3718be15a
- https://git.kernel.org/stable/c/2af84c46b9b8f2d6c0f88d09ee5c849ae1734676
- https://git.kernel.org/stable/c/6d8b56ec0c8f30d5657382f47344a32569f7a9bc
- https://git.kernel.org/stable/c/c43e5028f5a35331eb25017f5ff6cc21735005c6
- https://git.kernel.org/stable/c/c850f71fca09ea41800ed55905980063d17e01da
- https://git.kernel.org/stable/c/f42c97027fb75776e2e9358d16bf4a99aeb04cf2
- https://git.kernel.org/stable/c/26d32bec4c6d255a03762f33c637bfa3718be15a
- https://git.kernel.org/stable/c/2af84c46b9b8f2d6c0f88d09ee5c849ae1734676
- https://git.kernel.org/stable/c/6d8b56ec0c8f30d5657382f47344a32569f7a9bc
- https://git.kernel.org/stable/c/c43e5028f5a35331eb25017f5ff6cc21735005c6
- https://git.kernel.org/stable/c/c850f71fca09ea41800ed55905980063d17e01da
- https://git.kernel.org/stable/c/f42c97027fb75776e2e9358d16bf4a99aeb04cf2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-02-03
CVE-2024-35849
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix information leak in btrfs_ioctl_logical_to_ino() Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000 This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory. Fix this by using kvzalloc() which zeroes out the memory on allocation.
- https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf
- https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6
- https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc
- https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772
- https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86
- https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6
- https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d
- https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54
- https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf
- https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6
- https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc
- https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772
- https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86
- https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6
- https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d
- https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-30
CVE-2024-35850
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev setup Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when setup() is called for a non-serdev controller.
- https://git.kernel.org/stable/c/67459f1a707aae6d590454de07956c2752e21ea4
- https://git.kernel.org/stable/c/7ddb9de6af0f1c71147785b12fd7c8ec3f06cc86
- https://git.kernel.org/stable/c/bec4d4c6fa5c6526409f582e4f31144e20c86c21
- https://git.kernel.org/stable/c/67459f1a707aae6d590454de07956c2752e21ea4
- https://git.kernel.org/stable/c/7ddb9de6af0f1c71147785b12fd7c8ec3f06cc86
- https://git.kernel.org/stable/c/bec4d4c6fa5c6526409f582e4f31144e20c86c21
Modified: 2024-12-30
CVE-2024-35851
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev suspend Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time.
- https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489
- https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88
- https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371
- https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189
- https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d
- https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489
- https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88
- https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371
- https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189
- https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d
Modified: 2024-12-30
CVE-2024-35852
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work The rehash delayed work is rescheduled with a delay if the number of credits at end of the work is not negative as supposedly it means that the migration ended. Otherwise, it is rescheduled immediately. After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" the above is no longer accurate as a non-negative number of credits is no longer indicative of the migration being done. It can also happen if the work encountered an error in which case the migration will resume the next time the work is scheduled. The significance of the above is that it is possible for the work to be pending and associated with hints that were allocated when the migration started. This leads to the hints being leaked [1] when the work is canceled while pending as part of ACL region dismantle. Fix by freeing the hints if hints are associated with a work that was canceled while pending. Blame the original commit since the reliance on not having a pending work associated with hints is fragile. [1] unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30
- https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758
- https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04
- https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f
- https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d
- https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d
- https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab
- https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5
- https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758
- https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04
- https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f
- https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d
- https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d
- https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab
- https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2024-35853
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
The rehash delayed work migrates filters from one region to another.
This is done by iterating over all chunks (all the filters with the same
priority) in the region and in each chunk iterating over all the
filters.
If the migration fails, the code tries to migrate the filters back to
the old region. However, the rollback itself can also fail in which case
another migration will be erroneously performed. Besides the fact that
this ping pong is not a very good idea, it also creates a problem.
Each virtual chunk references two chunks: The currently used one
('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the
first holds the chunk we want to migrate filters to and the second holds
the chunk we are migrating filters from.
The code currently assumes - but does not verify - that the backup chunk
does not exist (NULL) if the currently used chunk does not reference the
target region. This assumption breaks when we are trying to rollback a
rollback, resulting in the backup chunk being overwritten and leaked
[1].
Fix by not rolling back a failed rollback and add a warning to avoid
future cases.
[1]
WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20
Modules linked in:
CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:parman_destroy+0x17/0x20
[...]
Call Trace:
- https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf
- https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e
- https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1
- https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977
- https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d
- https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76
- https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76
- https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf
- https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e
- https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1
- https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977
- https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d
- https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76
- https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2024-35854
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
The rehash delayed work migrates filters from one region to another
according to the number of available credits.
The migrated from region is destroyed at the end of the work if the
number of credits is non-negative as the assumption is that this is
indicative of migration being complete. This assumption is incorrect as
a non-negative number of credits can also be the result of a failed
migration.
The destruction of a region that still has filters referencing it can
result in a use-after-free [1].
Fix by not destroying the region if migration failed.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
Call Trace:
- https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049
- https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121
- https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519
- https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887
- https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1
- https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1
- https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388
- https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049
- https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121
- https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519
- https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887
- https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1
- https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1
- https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-30
CVE-2024-35855
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
The rule activity update delayed work periodically traverses the list of
configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry->entry',
but this entry can be changed concurrently by the rehash delayed work,
leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the
'vregion->lock' mutex.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
Call Trace:
- https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0
- https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4
- https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770
- https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a
- https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758
- https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef
- https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4
- https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0
- https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4
- https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770
- https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a
- https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758
- https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef
- https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-30
CVE-2024-35856
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Fix double free of skb in coredump
hci_devcd_append() would free the skb on error so the caller don't
have to free it again otherwise it would cause the double free of skb.
Reported-by : Dan Carpenter
- https://git.kernel.org/stable/c/18bdb386a1a30e7a3d7732a98e45e69cf6b5710d
- https://git.kernel.org/stable/c/80dfef128cb9f1b1ef67c0fe8c8deb4ea7ad30c1
- https://git.kernel.org/stable/c/e20093c741d8da9f6390dd45d75b779861547035
- https://git.kernel.org/stable/c/18bdb386a1a30e7a3d7732a98e45e69cf6b5710d
- https://git.kernel.org/stable/c/80dfef128cb9f1b1ef67c0fe8c8deb4ea7ad30c1
- https://git.kernel.org/stable/c/e20093c741d8da9f6390dd45d75b779861547035
Modified: 2025-04-07
CVE-2024-35857
In the Linux kernel, the following vulnerability has been resolved:
icmp: prevent possible NULL dereferences from icmp_build_probe()
First problem is a double call to __in_dev_get_rcu(), because
the second one could return NULL.
if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)
Second problem is a read from dev->ip6_ptr with no NULL check:
if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))
Use the correct RCU API to fix these.
v2: add missing include
- https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401
- https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767
- https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270
- https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941
- https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350
- https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401
- https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767
- https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270
- https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941
- https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350
Modified: 2024-12-30
CVE-2024-35858
In the Linux kernel, the following vulnerability has been resolved: net: bcmasp: fix memory leak when bringing down interface When bringing down the TX rings we flush the rings but forget to reclaimed the flushed packets. This leads to a memory leak since we do not free the dma mapped buffers. This also leads to tx control block corruption when bringing down the interface for power management.
- https://git.kernel.org/stable/c/09040baf8779ad880e0e0d0ea10e57aa929ef3ab
- https://git.kernel.org/stable/c/2389ad1990163d29cba5480d693b4c2e31cc545c
- https://git.kernel.org/stable/c/9f898fc2c31fbf0ac5ecd289f528a716464cb005
- https://git.kernel.org/stable/c/09040baf8779ad880e0e0d0ea10e57aa929ef3ab
- https://git.kernel.org/stable/c/2389ad1990163d29cba5480d693b4c2e31cc545c
- https://git.kernel.org/stable/c/9f898fc2c31fbf0ac5ecd289f528a716464cb005
Modified: 2025-09-26
CVE-2024-35860
In the Linux kernel, the following vulnerability has been resolved: bpf: support deferring bpf_link dealloc to after RCU grace period BPF link for some program types is passed as a "context" which can be used by those BPF programs to look up additional information. E.g., for multi-kprobes and multi-uprobes, link is used to fetch BPF cookie values. Because of this runtime dependency, when bpf_link refcnt drops to zero there could still be active BPF programs running accessing link data. This patch adds generic support to defer bpf_link dealloc callback to after RCU GP, if requested. This is done by exposing two different deallocation callbacks, one synchronous and one deferred. If deferred one is provided, bpf_link_free() will schedule dealloc_deferred() callback to happen after RCU GP. BPF is using two flavors of RCU: "classic" non-sleepable one and RCU tasks trace one. The latter is used when sleepable BPF programs are used. bpf_link_free() accommodates that by checking underlying BPF program's sleepable flag, and goes either through normal RCU GP only for non-sleepable, or through RCU tasks trace GP *and* then normal RCU GP (taking into account rcu_trace_implies_rcu_gp() optimization), if BPF program is sleepable. We use this for multi-kprobe and multi-uprobe links, which dereference link during program run. We also preventively switch raw_tp link to use deferred dealloc callback, as upcoming changes in bpf-next tree expose raw_tp link data (specifically, cookie value) to BPF program at runtime as well.
- https://git.kernel.org/stable/c/1a80dbcb2dbaf6e4c216e62e30fa7d3daa8001ce
- https://git.kernel.org/stable/c/5d8d447777564b35f67000e7838e7ccb64d525c8
- https://git.kernel.org/stable/c/876941f533e7b47fc69977fc4551c02f2d18af97
- https://git.kernel.org/stable/c/1a80dbcb2dbaf6e4c216e62e30fa7d3daa8001ce
- https://git.kernel.org/stable/c/5d8d447777564b35f67000e7838e7ccb64d525c8
- https://git.kernel.org/stable/c/876941f533e7b47fc69977fc4551c02f2d18af97
Modified: 2026-03-24
CVE-2024-35861
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1
- https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4
- https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f
- https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d
- https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1
- https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4
- https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f
- https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d
Modified: 2026-03-25
CVE-2024-35862
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_network_name_deleted() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d
- https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01
- https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645
- https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c
- https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d
- https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01
- https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645
- https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c
Modified: 2026-03-24
CVE-2024-35863
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2
- https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825
- https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac
- https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29
- https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2
- https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825
- https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac
- https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29
Modified: 2024-12-30
CVE-2024-35864
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1
- https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb
- https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5
- https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4
- https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1
- https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb
- https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5
- https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4
Modified: 2025-04-07
CVE-2024-35865
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd
- https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4
- https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628
- https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7
- https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd
- https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4
- https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628
- https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7
Modified: 2026-04-21
CVE-2024-35866
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_dump_full_key() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/10e17ca4000ec34737bde002a13435c38ace2682
- https://git.kernel.org/stable/c/3103163ccd3be4adcfa37e15608fb497be044113
- https://git.kernel.org/stable/c/58acd1f497162e7d282077f816faa519487be045
- https://git.kernel.org/stable/c/d798fd98e3563027c5162259ead517057d6fa794
- https://git.kernel.org/stable/c/f4a60d360d9114b5085701a3702a0102b0d6d846
- https://git.kernel.org/stable/c/10e17ca4000ec34737bde002a13435c38ace2682
- https://git.kernel.org/stable/c/3103163ccd3be4adcfa37e15608fb497be044113
- https://git.kernel.org/stable/c/58acd1f497162e7d282077f816faa519487be045
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-23
CVE-2024-35867
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65
- https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49
- https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7
- https://git.kernel.org/stable/c/838ec01ea8d3deb5d123e8ed9022e8162dc3f503
- https://git.kernel.org/stable/c/bb6570085826291dc392005f9fec16ea5da3c8ad
- https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39
- http://www.openwall.com/lists/oss-security/2024/05/29/2
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65
- https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49
- https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7
- https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2024-12-30
CVE-2024-35868
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_write() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.
- https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b
- https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72
- https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7
- https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a
- https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b
- https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72
- https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7
- https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a
Modified: 2025-11-18
CVE-2024-35869
In the Linux kernel, the following vulnerability has been resolved: smb: client: guarantee refcounted children from parent session Avoid potential use-after-free bugs when walking DFS referrals, mounting and performing DFS failover by ensuring that all children from parent @tcon->ses are also refcounted. They're all needed across the entire DFS mount. Get rid of @tcon->dfs_ses_list while we're at it, too.
- https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a
- https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc
- https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79
- https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a
- https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc
- https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79
Modified: 2025-11-03
CVE-2024-35870
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that
is already being teared down by another thread that is executing
__cifs_put_smb_ses(). This can happen when (a) the client has
connection to the server but no session or (b) another thread ends up
setting @ses->ses_status again to something different than
SES_EXITING.
To fix this, we need to make sure to unconditionally set
@ses->ses_status to SES_EXITING and prevent any other threads from
setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after
the ipc is freed in __cifs_put_smb_ses() - which will give
smb2_reconnect_server() worker a chance to run and then accessing
@ses->ipc:
kinit ...
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
[disconnect srv]
ls /mnt/1 &>/dev/null
sleep 30
kdestroy
[reconnect srv]
sleep 10
umount /mnt/1
...
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
04/01/2014
Workqueue: cifsiod smb2_reconnect_server [cifs]
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa
- https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5
- https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0
- https://git.kernel.org/stable/c/755fe68cd4b59e1d2a2dd3286177fd4404f57fed
- https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa
- https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5
- https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2026-01-22
CVE-2024-35871
In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means. [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec. childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways: 1. kernel_execve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel __global_pointer$, all other integer registers zeroed by the memset in the patch comment. This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch. 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries. 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for user_mode_helpers before the exec completes, but gp is not one of the registers it returns. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to write exploit code. 5. Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers.
- https://git.kernel.org/stable/c/00effef72c98294edb1efa87ffa0f6cfb61b36a4
- https://git.kernel.org/stable/c/9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5
- https://git.kernel.org/stable/c/d14fa1fcf69db9d070e75f1c4425211fa619dfc8
- https://git.kernel.org/stable/c/d8dcba0691b8e42bddb61aab201e4d918a08e5d9
- https://git.kernel.org/stable/c/dff6072124f6df77bfd36951fbd88565746980ef
- https://git.kernel.org/stable/c/f6583444d7e78dae750798552b65a2519ff3ca84
- https://git.kernel.org/stable/c/00effef72c98294edb1efa87ffa0f6cfb61b36a4
- https://git.kernel.org/stable/c/9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5
- https://git.kernel.org/stable/c/d14fa1fcf69db9d070e75f1c4425211fa619dfc8
- https://git.kernel.org/stable/c/d8dcba0691b8e42bddb61aab201e4d918a08e5d9
- https://git.kernel.org/stable/c/dff6072124f6df77bfd36951fbd88565746980ef
- https://git.kernel.org/stable/c/f6583444d7e78dae750798552b65a2519ff3ca84
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-24
CVE-2024-35872
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check.
- https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5
- https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8
- https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706
- https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e
- https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48
- https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5
- https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8
- https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706
- https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e
- https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48
Modified: 2025-09-24
CVE-2024-35875
In the Linux kernel, the following vulnerability has been resolved: x86/coco: Require seeding RNG with RDRAND on CoCo systems There are few uses of CoCo that don't rely on working cryptography and hence a working RNG. Unfortunately, the CoCo threat model means that the VM host cannot be trusted and may actively work against guests to extract secrets or manipulate computation. Since a malicious host can modify or observe nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole is meant to gracefully continue on gathering entropy from other sources, but since there aren't other sources on CoCo, this is catastrophic. This is mostly a concern at boot time when initially seeding the RNG, as after that the consequences of a broken RDRAND are much more theoretical. So, try at boot to seed the RNG using 256 bits of RDRAND output. If this fails, panic(). This will also trigger if the system is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 driver feature" and not part of the RNG itself. Many device drivers and platforms have some desire to contribute something to the RNG, and add_device_randomness() is specifically meant for this purpose. Any driver can call it with seed data of any quality, or even garbage quality, and it can only possibly make the quality of the RNG better or have no effect, but can never make it worse. Rather than trying to build something into the core of the RNG, consider the particular CoCo issue just a CoCo issue, and therefore separate it all out into driver (well, arch/platform) code. [ bp: Massage commit message. ]
- https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e
- https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374
- https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5
- https://git.kernel.org/stable/c/99485c4c026f024e7cb82da84c7951dbe3deb584
- https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e
- https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374
- https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5
- https://git.kernel.org/stable/c/99485c4c026f024e7cb82da84c7951dbe3deb584
Modified: 2025-12-23
CVE-2024-35877
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or,
in fact, all PTEs) can be replaced during write faults to point at anon
folios. Reliably recovering the correct PFN and cachemode using
follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon
folio (which is very wrong), or fail on swap/nonswap entries, failing
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call
it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we
don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if
the first page was replaced by an anon folio, though: we'd have to store
the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that
case: it would have failed in the past with swap/nonswap entries already,
and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer --->
#include
- https://git.kernel.org/stable/c/04c35ab3bdae7fefbd7c7a7355f29fa03a035221
- https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173
- https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd32f2abc6
- https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec
- https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a
- https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f
- https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4
- https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b
- https://git.kernel.org/stable/c/04c35ab3bdae7fefbd7c7a7355f29fa03a035221
- https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173
- https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd32f2abc6
- https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec
- https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a
- https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f
- https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4
- https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35878
In the Linux kernel, the following vulnerability has been resolved: of: module: prevent NULL pointer dereference in vsnprintf() In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
- https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898
- https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987
- https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b
- https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898
- https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987
- https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b
Modified: 2025-12-23
CVE-2024-35879
In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, of_node_put() will be called but wrongly too late from the workqueue job. In order to be sure that any ongoing devlink removals are done before the of_node destruction, synchronize the of_changeset_destroy() with the devlink removals.
- https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a
- https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c
- https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951
- https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82
- https://git.kernel.org/stable/c/8917e7385346bd6584890ed362985c219fe6ae84
- https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b17411db6f5c
- https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a
- https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c
- https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951
- https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82
- https://git.kernel.org/stable/c/8917e7385346bd6584890ed362985c219fe6ae84
- https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b17411db6f5c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-24
CVE-2024-35880
In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: hold io_buffer_list reference over mmap If we look up the kbuf, ensure that it doesn't get unregistered until after we're done with it. Since we're inside mmap, we cannot safely use the io_uring lock. Rely on the fact that we can lookup the buffer list under RCU now and grab a reference to it, preventing it from being unregistered until we're done with it. The lookup returns the io_buffer_list directly with it referenced.
- https://git.kernel.org/stable/c/561e4f9451d65fc2f7eef564e0064373e3019793
- https://git.kernel.org/stable/c/5fd8e2359498043e0b5329a05f02d10a9eb91eb9
- https://git.kernel.org/stable/c/65938e81df2197203bda4b9a0c477e7987218d66
- https://git.kernel.org/stable/c/561e4f9451d65fc2f7eef564e0064373e3019793
- https://git.kernel.org/stable/c/5fd8e2359498043e0b5329a05f02d10a9eb91eb9
- https://git.kernel.org/stable/c/65938e81df2197203bda4b9a0c477e7987218d66
Modified: 2025-03-05
CVE-2024-35882
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP Jan Schunk reports that his small NFS servers suffer from memory exhaustion after just a few days. A bisect shows that commit e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single sock_sendmsg() call") is the first bad commit. That commit assumed that sock_sendmsg() releases all the pages in the underlying bio_vec array, but the reality is that it doesn't. svc_xprt_release() releases the rqst's response pages, but the record marker page fragment isn't one of those, so it is never released. This is a narrow fix that can be applied to stable kernels. A more extensive fix is in the works.
- https://git.kernel.org/stable/c/05258a0a69b3c5d2c003f818702c0a52b6fea861
- https://git.kernel.org/stable/c/1ba1291172f935e6b6fe703161a948f3347400b8
- https://git.kernel.org/stable/c/a2ebedf7bcd17a1194a0a18122c885eb578ee882
- https://git.kernel.org/stable/c/05258a0a69b3c5d2c003f818702c0a52b6fea861
- https://git.kernel.org/stable/c/1ba1291172f935e6b6fe703161a948f3347400b8
- https://git.kernel.org/stable/c/a2ebedf7bcd17a1194a0a18122c885eb578ee882
Modified: 2025-01-07
CVE-2024-35883
In the Linux kernel, the following vulnerability has been resolved: spi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probe In function pci1xxxx_spi_probe, there is a potential null pointer that may be caused by a failed memory allocation by the function devm_kzalloc. Hence, a null pointer check needs to be added to prevent null pointer dereferencing later in the code. To fix this issue, spi_bus->spi_int[iter] should be checked. The memory allocated by devm_kzalloc will be automatically released, so just directly return -ENOMEM without worrying about memory leaks.
- https://git.kernel.org/stable/c/1f886a7bfb3faf4c1021e73f045538008ce7634e
- https://git.kernel.org/stable/c/4b31a226097cf8cc3c9de5e855d97757fdb2bf06
- https://git.kernel.org/stable/c/95e5d9eb26705a9a76d2ef8bcba9ee2e195d653d
- https://git.kernel.org/stable/c/1f886a7bfb3faf4c1021e73f045538008ce7634e
- https://git.kernel.org/stable/c/4b31a226097cf8cc3c9de5e855d97757fdb2bf06
- https://git.kernel.org/stable/c/95e5d9eb26705a9a76d2ef8bcba9ee2e195d653d
Modified: 2025-12-23
CVE-2024-35884
In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the current logic there as it should cover most cases but we also need to make sure we handle tunnel packets being GROed too early. This is done by extending the checks in udp_unexpected_gso: GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must be segmented. [1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560
- https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19
- https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8
- https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4
- https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f
- https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd
- https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670
- https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19
- https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8
- https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4
- https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f
- https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd
- https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-03
CVE-2024-35885
In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: stop interface during shutdown The mlxbf_gige driver intermittantly encounters a NULL pointer exception while the system is shutting down via "reboot" command. The mlxbf_driver will experience an exception right after executing its shutdown() method. One example of this exception is: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000 [0000000000000070] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] SMP CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] sp : ffff8000080d3c10 x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58 x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008 x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128 x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7 x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101 x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404 x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080 x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20 Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002) ---[ end trace 7cc3941aa0d8e6a4 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x4ce722520000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x000005c1,a3330e5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- During system shutdown, the mlxbf_gige driver's shutdown() is always executed. However, the driver's stop() method will only execute if networking interface configuration logic within the Linux distribution has been setup to do so. If shutdown() executes but stop() does not execute, NAPI remains enabled and this can lead to an exception if NAPI is scheduled while the hardware interface has only been partially deinitialized. The networking interface managed by the mlxbf_gige driver must be properly stopped during system shutdown so that IFF_UP is cleared, the hardware interface is put into a clean state, and NAPI is fully deinitialized.
- https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6
- https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4
- https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971
- https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4
- https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5
- https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6
- https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4
- https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971
- https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4
- https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5
Modified: 2025-12-23
CVE-2024-35886
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during
netlink socket destruction. [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
the response was generated. The following recvmmsg() resumed the dump
for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
to the fault injection. [0]
12:01:34 executing program 3:
r0 = socket$nl_route(0x10, 0x3, 0x0)
sendmsg$nl_route(r0, ... snip ...)
recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call
of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped
receiving the response halfway through, and finally netlink_sock_destruct()
called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it
is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by
nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling
itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/167d4b47a9bdcb01541dfa29e9f3cbb8edd3dfd2
- https://git.kernel.org/stable/c/40a344b2ddc06c1a2caa7208a43911f39c662778
- https://git.kernel.org/stable/c/4a7c465a5dcd657d59d25bf4815e19ac05c13061
- https://git.kernel.org/stable/c/9472d07cd095cbd3294ac54c42f304a38fbe9bfe
- https://git.kernel.org/stable/c/9c5258196182c25b55c33167cd72fdd9bbf08985
- https://git.kernel.org/stable/c/d21d40605bca7bd5fc23ef03d4c1ca1f48bc2cae
- https://git.kernel.org/stable/c/f2dd75e57285f49e34af1a5b6cd8945c08243776
- https://git.kernel.org/stable/c/fd307f2d91d40fa7bc55df3e2cd1253fabf8a2d6
- https://git.kernel.org/stable/c/167d4b47a9bdcb01541dfa29e9f3cbb8edd3dfd2
- https://git.kernel.org/stable/c/40a344b2ddc06c1a2caa7208a43911f39c662778
- https://git.kernel.org/stable/c/4a7c465a5dcd657d59d25bf4815e19ac05c13061
- https://git.kernel.org/stable/c/9472d07cd095cbd3294ac54c42f304a38fbe9bfe
- https://git.kernel.org/stable/c/9c5258196182c25b55c33167cd72fdd9bbf08985
- https://git.kernel.org/stable/c/d21d40605bca7bd5fc23ef03d4c1ca1f48bc2cae
- https://git.kernel.org/stable/c/f2dd75e57285f49e34af1a5b6cd8945c08243776
- https://git.kernel.org/stable/c/fd307f2d91d40fa7bc55df3e2cd1253fabf8a2d6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-31
CVE-2024-35887
In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.
- https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b
- https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9
- https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89
- https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b
- https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9
- https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89
Modified: 2025-04-07
CVE-2024-35888
In the Linux kernel, the following vulnerability has been resolved: erspan: make sure erspan_base_hdr is present in skb->head syzbot reported a problem in ip6erspan_rcv() [1] Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it. Add the missing pskb_may_pull() calls. v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed. [1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0
- https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac
- https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446
- https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0
- https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d
- https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d
- https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85
- https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5
- https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7
- https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac
- https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446
- https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0
- https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d
- https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d
- https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85
- https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5
- https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-24
CVE-2024-35890
In the Linux kernel, the following vulnerability has been resolved: gro: fix ownership transfer If packets are GROed with fraglist they might be segmented later on and continue their journey in the stack. In skb_segment_list those skbs can be reused as-is. This is an issue as their destructor was removed in skb_gro_receive_list but not the reference to their socket, and then they can't be orphaned. Fix this by also removing the reference to the socket. For example this could be observed, kernel BUG at include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Call Trace: ipv6_list_rcv+0x250/0x3f0 __netif_receive_skb_list_core+0x49d/0x8f0 netif_receive_skb_list_internal+0x634/0xd40 napi_complete_done+0x1d2/0x7d0 gro_cell_poll+0x118/0x1f0 A similar construction is found in skb_gro_receive, apply the same change there.
- https://git.kernel.org/stable/c/2eeab8c47c3c0276e0746bc382f405c9a236a5ad
- https://git.kernel.org/stable/c/5b3b67f731296027cceb3efad881ae281213f86f
- https://git.kernel.org/stable/c/d225b0ac96dc40d7e8ae2bc227eb2c56e130975f
- https://git.kernel.org/stable/c/ed4cccef64c1d0d5b91e69f7a8a6697c3a865486
- https://git.kernel.org/stable/c/fc126c1d51e9552eacd2d717b9ffe9262a8a4cd6
- https://git.kernel.org/stable/c/2eeab8c47c3c0276e0746bc382f405c9a236a5ad
- https://git.kernel.org/stable/c/5b3b67f731296027cceb3efad881ae281213f86f
- https://git.kernel.org/stable/c/d225b0ac96dc40d7e8ae2bc227eb2c56e130975f
- https://git.kernel.org/stable/c/ed4cccef64c1d0d5b91e69f7a8a6697c3a865486
- https://git.kernel.org/stable/c/fc126c1d51e9552eacd2d717b9ffe9262a8a4cd6
- https://security.netapp.com/advisory/ntap-20250509-0008/
Modified: 2024-12-30
CVE-2024-35891
In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Fix potential null pointer dereference In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may return NULL as ptp_header due to abnormal packet type or corrupted packet. Fix this bug by adding ptp_header check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/10608161696c2768f53426642f78a42bcaaa53e8
- https://git.kernel.org/stable/c/49767b0df276f12e3e7184601e09ee7430e252dc
- https://git.kernel.org/stable/c/95c1016a2d92c4c28a9d1b6d09859c00b19c0ea4
- https://git.kernel.org/stable/c/96c155943a703f0655c0c4cab540f67055960e91
- https://git.kernel.org/stable/c/10608161696c2768f53426642f78a42bcaaa53e8
- https://git.kernel.org/stable/c/49767b0df276f12e3e7184601e09ee7430e252dc
- https://git.kernel.org/stable/c/95c1016a2d92c4c28a9d1b6d09859c00b19c0ea4
- https://git.kernel.org/stable/c/96c155943a703f0655c0c4cab540f67055960e91
Modified: 2025-09-19
CVE-2024-35892
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix lockdep splat in qdisc_tree_reduce_backlog()
qdisc_tree_reduce_backlog() is called with the qdisc lock held,
not RTNL.
We must use qdisc_lookup_rcu() instead of qdisc_lookup()
syzbot reported:
WARNING: suspicious RCU usage
6.1.74-syzkaller #0 Not tainted
-----------------------------
net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by udevd/1142:
#0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]
#0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]
#0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282
#1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]
#1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297
#2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]
#2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]
#2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792
stack backtrace:
CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
- https://git.kernel.org/stable/c/07696415526bee0607e495017369c7303a4792e1
- https://git.kernel.org/stable/c/7eb322360b0266481e560d1807ee79e0cef5742b
- https://git.kernel.org/stable/c/b7d1ce2cc7192e8a037faa3f5d3ba72c25976460
- https://git.kernel.org/stable/c/c040b99461a5bfc14c2d0cbb1780fcc3a4706c7e
- https://git.kernel.org/stable/c/07696415526bee0607e495017369c7303a4792e1
- https://git.kernel.org/stable/c/7eb322360b0266481e560d1807ee79e0cef5742b
- https://git.kernel.org/stable/c/b7d1ce2cc7192e8a037faa3f5d3ba72c25976460
- https://git.kernel.org/stable/c/c040b99461a5bfc14c2d0cbb1780fcc3a4706c7e
Modified: 2025-12-23
CVE-2024-35893
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: prevent kernel-infoleak syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1]. The issue here is that 'struct tc_skbmod' has a four bytes hole. We need to clear the structure before filling fields. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli ---truncated---
- https://git.kernel.org/stable/c/55d3fe7b2b7bc354e7cbc1f7b8f98a29ccd5a366
- https://git.kernel.org/stable/c/5e45dc4408857305f4685abfd7a528a1e58b51b5
- https://git.kernel.org/stable/c/729ad2ac2a2cdc9f4a4bdfd40bfd276e6bc33924
- https://git.kernel.org/stable/c/7bb2c7103d8c13b06a57bf997b8cdbe93cd7283c
- https://git.kernel.org/stable/c/a097fc199ab5f4b5392c5144034c0d2148b55a14
- https://git.kernel.org/stable/c/d313eb8b77557a6d5855f42d2234bd592c7b50dd
- https://git.kernel.org/stable/c/f190a4aa03cbd518bd9c62a66e1233984f5fd2ec
- https://git.kernel.org/stable/c/f356eb2fb567e0931143ac1769ac802d3b3e2077
- https://git.kernel.org/stable/c/55d3fe7b2b7bc354e7cbc1f7b8f98a29ccd5a366
- https://git.kernel.org/stable/c/5e45dc4408857305f4685abfd7a528a1e58b51b5
- https://git.kernel.org/stable/c/729ad2ac2a2cdc9f4a4bdfd40bfd276e6bc33924
- https://git.kernel.org/stable/c/7bb2c7103d8c13b06a57bf997b8cdbe93cd7283c
- https://git.kernel.org/stable/c/a097fc199ab5f4b5392c5144034c0d2148b55a14
- https://git.kernel.org/stable/c/d313eb8b77557a6d5855f42d2234bd592c7b50dd
- https://git.kernel.org/stable/c/f190a4aa03cbd518bd9c62a66e1233984f5fd2ec
- https://git.kernel.org/stable/c/f356eb2fb567e0931143ac1769ac802d3b3e2077
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-30
CVE-2024-35895
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes
elements from a sockmap/sockhash map. Because BPF tracing programs can be
invoked from any interrupt context, locks taken during a map_delete_elem
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock);
local_irq_disable();
lock(&host->lock);
lock(&htab->buckets[i].lock);
- https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86
- https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd
- https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5
- https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec
- https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75
- https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058
- https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48
- https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86
- https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd
- https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5
- https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec
- https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75
- https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058
- https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-21
CVE-2024-35896
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account
before copying data.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
- https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc
- https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6
- https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5
- https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b
- https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018
- https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525
- https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc
- https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6
- https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5
- https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b
- https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018
- https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20250321-0004/
Modified: 2025-12-17
CVE-2024-35897
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: discard table flag update with pending basechain deletion Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.
- https://git.kernel.org/stable/c/1bc83a019bbe268be3526406245ec28c2458a518
- https://git.kernel.org/stable/c/2aeb805a1bcd5f27c8c0d1a9d4d653f16d1506f4
- https://git.kernel.org/stable/c/6cbbe1ba76ee7e674a86abd43009b083a45838cb
- https://git.kernel.org/stable/c/7f609f630951b624348373cef99991ce08831927
- https://git.kernel.org/stable/c/9627fd0c6ea1c446741a33e67bc5709c59923827
- https://git.kernel.org/stable/c/9a3b90904d8a072287480eed4c3ece4b99d64f78
- https://git.kernel.org/stable/c/b58d0ac35f6d75ec1db8650a29dfd6f292c11362
- https://git.kernel.org/stable/c/e75faf01e22ec7dc671640fa0e0968964fafd2fc
- https://git.kernel.org/stable/c/1bc83a019bbe268be3526406245ec28c2458a518
- https://git.kernel.org/stable/c/2aeb805a1bcd5f27c8c0d1a9d4d653f16d1506f4
- https://git.kernel.org/stable/c/6cbbe1ba76ee7e674a86abd43009b083a45838cb
- https://git.kernel.org/stable/c/7f609f630951b624348373cef99991ce08831927
- https://git.kernel.org/stable/c/9627fd0c6ea1c446741a33e67bc5709c59923827
- https://git.kernel.org/stable/c/9a3b90904d8a072287480eed4c3ece4b99d64f78
- https://git.kernel.org/stable/c/b58d0ac35f6d75ec1db8650a29dfd6f292c11362
- https://git.kernel.org/stable/c/e75faf01e22ec7dc671640fa0e0968964fafd2fc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2024-35898
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.
- https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304
- https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8
- https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007
- https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df
- https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331
- https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b
- https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77
- https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859
- https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304
- https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8
- https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007
- https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df
- https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331
- https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b
- https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77
- https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35899
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: flush pending destroy work before exit_net release
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy
work before netlink notifier") to address a race between exit_net and
the destroy workqueue.
The trace below shows an element to be released via destroy workqueue
while exit_net path (triggered via module removal) has already released
the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465
[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359
[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
[ 1360.547984] Call Trace:
[ 1360.547991]
- https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2
- https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7
- https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31
- https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e
- https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6
- https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86
- https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49
- https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2
- https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7
- https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31
- https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e
- https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6
- https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86
- https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-35900
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject new basechain after table flag update
When dormant flag is toggled, hooks are disabled in the commit phase by
iterating over current chains in table (existing and new).
The following configuration allows for an inconsistent state:
add table x
add chain x y { type filter hook input priority 0; }
add table x { flags dormant; }
add chain x w { type filter hook input priority 1; }
which triggers the following warning when trying to unregister chain w
which is already unregistered.
[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260
[...]
[ 127.322519] Call Trace:
[ 127.322521]
- https://git.kernel.org/stable/c/41bad13c0e8a5a2b47a7472cced922555372daab
- https://git.kernel.org/stable/c/420132bee3d0136b7fba253a597b098fe15493a7
- https://git.kernel.org/stable/c/6d12f21f8bbe23fde25b77c2bf5973c136b8bef8
- https://git.kernel.org/stable/c/745cf6a843896cdac8766c74379300ed73c78830
- https://git.kernel.org/stable/c/7b6fba6918714afee3e17796113ccab636255c7b
- https://git.kernel.org/stable/c/8ba81dca416adf82fc5a2a23abc1a8cc02ad32fb
- https://git.kernel.org/stable/c/994209ddf4f430946f6247616b2e33d179243769
- https://git.kernel.org/stable/c/e95bb4cba94c018be24b11f017d1c55dd6cda31a
- https://git.kernel.org/stable/c/41bad13c0e8a5a2b47a7472cced922555372daab
- https://git.kernel.org/stable/c/420132bee3d0136b7fba253a597b098fe15493a7
- https://git.kernel.org/stable/c/6d12f21f8bbe23fde25b77c2bf5973c136b8bef8
- https://git.kernel.org/stable/c/745cf6a843896cdac8766c74379300ed73c78830
- https://git.kernel.org/stable/c/7b6fba6918714afee3e17796113ccab636255c7b
- https://git.kernel.org/stable/c/8ba81dca416adf82fc5a2a23abc1a8cc02ad32fb
- https://git.kernel.org/stable/c/994209ddf4f430946f6247616b2e33d179243769
- https://git.kernel.org/stable/c/e95bb4cba94c018be24b11f017d1c55dd6cda31a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-23
CVE-2024-35901
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix Rx DMA datasize and skb_over_panic
mana_get_rxbuf_cfg() aligns the RX buffer's DMA datasize to be
multiple of 64. So a packet slightly bigger than mtu+14, say 1536,
can be received and cause skb_over_panic.
Sample dmesg:
[ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:
- https://git.kernel.org/stable/c/05cb7c41fa1a7a7b2c2a6b81bbe7c67f5c11932b
- https://git.kernel.org/stable/c/c0de6ab920aafb56feab56058e46b688e694a246
- https://git.kernel.org/stable/c/ca58927b00385005f488b6a9905ced7a4f719aad
- https://git.kernel.org/stable/c/05cb7c41fa1a7a7b2c2a6b81bbe7c67f5c11932b
- https://git.kernel.org/stable/c/c0de6ab920aafb56feab56058e46b688e694a246
- https://git.kernel.org/stable/c/ca58927b00385005f488b6a9905ced7a4f719aad
Modified: 2024-12-30
CVE-2024-35902
In the Linux kernel, the following vulnerability has been resolved: net/rds: fix possible cp null dereference cp might be null, calling cp->cp_conn would produce null dereference [Simon Horman adds:] Analysis: * cp is a parameter of __rds_rdma_map and is not reassigned. * The following call-sites pass a NULL cp argument to __rds_rdma_map() - rds_get_mr() - rds_get_mr_for_dest * Prior to the code above, the following assumes that cp may be NULL (which is indicative, but could itself be unnecessary) trans_private = rs->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED); * The code modified by this patch is guarded by IS_ERR(trans_private), where trans_private is assigned as per the previous point in this analysis. The only implementation of get_mr that I could locate is rds_ib_get_mr() which can return an ERR_PTR if the conn (4th) argument is NULL. * ret is set to PTR_ERR(trans_private). rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute. Conclusion: * cp may be NULL at the point where this patch adds a check; this patch does seem to address a possible bug
- https://git.kernel.org/stable/c/62fc3357e079a07a22465b9b6ef71bb6ea75ee4b
- https://git.kernel.org/stable/c/6794090c742008c53b344b35b021d4a3093dc50a
- https://git.kernel.org/stable/c/92309bed3c5fbe2ccd4c45056efd42edbd06162d
- https://git.kernel.org/stable/c/bcd46782e2ec3825d10c1552fcb674d491cc09f9
- https://git.kernel.org/stable/c/cbaac2e5488ed54833897264a5ffb2a341a9f196
- https://git.kernel.org/stable/c/cfb786b03b03c5ff38882bee38525eb9987e4d14
- https://git.kernel.org/stable/c/d275de8ea7be3a453629fddae41d4156762e814c
- https://git.kernel.org/stable/c/d49fac38479bfdaec52b3ea274d290c47a294029
- https://git.kernel.org/stable/c/62fc3357e079a07a22465b9b6ef71bb6ea75ee4b
- https://git.kernel.org/stable/c/6794090c742008c53b344b35b021d4a3093dc50a
- https://git.kernel.org/stable/c/92309bed3c5fbe2ccd4c45056efd42edbd06162d
- https://git.kernel.org/stable/c/bcd46782e2ec3825d10c1552fcb674d491cc09f9
- https://git.kernel.org/stable/c/cbaac2e5488ed54833897264a5ffb2a341a9f196
- https://git.kernel.org/stable/c/cfb786b03b03c5ff38882bee38525eb9987e4d14
- https://git.kernel.org/stable/c/d275de8ea7be3a453629fddae41d4156762e814c
- https://git.kernel.org/stable/c/d49fac38479bfdaec52b3ea274d290c47a294029
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-24
CVE-2024-35903
In the Linux kernel, the following vulnerability has been resolved: x86/bpf: Fix IP after emitting call depth accounting Adjust the IP passed to `emit_patch` so it calculates the correct offset for the CALL instruction if `x86_call_depth_emit_accounting` emits code. Otherwise we will skip some instructions and most likely crash.
- https://git.kernel.org/stable/c/3f9d57c771656bfd651e22edcfdb5f60e62542d4
- https://git.kernel.org/stable/c/81166178cf0a0062a22b1b3b5368183d39577028
- https://git.kernel.org/stable/c/9d98aa088386aee3db1b7b60b800c0fde0654a4a
- https://git.kernel.org/stable/c/3f9d57c771656bfd651e22edcfdb5f60e62542d4
- https://git.kernel.org/stable/c/81166178cf0a0062a22b1b3b5368183d39577028
- https://git.kernel.org/stable/c/9d98aa088386aee3db1b7b60b800c0fde0654a4a
Modified: 2025-02-03
CVE-2024-35904
In the Linux kernel, the following vulnerability has been resolved: selinux: avoid dereference of garbage after mount failure In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer. While on it drop the never read static variable selinuxfs_mount.
- https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b
- https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e
- https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b
- https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e
- https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c
Modified: 2024-12-30
CVE-2024-35905
In the Linux kernel, the following vulnerability has been resolved: bpf: Protect against int overflow for stack access size This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail. This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7.
- https://git.kernel.org/stable/c/203a68151e8eeb331d4a64ab78303f3a15faf103
- https://git.kernel.org/stable/c/37dc1718dc0c4392dbfcb9adec22a776e745dd69
- https://git.kernel.org/stable/c/3f0784b2f1eb9147973d8c43ba085c5fdf44ff69
- https://git.kernel.org/stable/c/98cdac206b112bec63852e94802791e316acc2c1
- https://git.kernel.org/stable/c/9970e059af471478455f9534e8c3db82f8c5496d
- https://git.kernel.org/stable/c/ecc6a2101840177e57c925c102d2d29f260d37c8
- https://git.kernel.org/stable/c/203a68151e8eeb331d4a64ab78303f3a15faf103
- https://git.kernel.org/stable/c/37dc1718dc0c4392dbfcb9adec22a776e745dd69
- https://git.kernel.org/stable/c/3f0784b2f1eb9147973d8c43ba085c5fdf44ff69
- https://git.kernel.org/stable/c/98cdac206b112bec63852e94802791e316acc2c1
- https://git.kernel.org/stable/c/9970e059af471478455f9534e8c3db82f8c5496d
- https://git.kernel.org/stable/c/ecc6a2101840177e57c925c102d2d29f260d37c8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-30
CVE-2024-35907
In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: call request_irq() after NAPI initialized The mlxbf_gige driver encounters a NULL pointer exception in mlxbf_gige_open() when kdump is enabled. The sequence to reproduce the exception is as follows: a) enable kdump b) trigger kdump via "echo c > /proc/sysrq-trigger" c) kdump kernel executes d) kdump kernel loads mlxbf_gige module e) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought up f) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] SMP CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000 x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398 x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2 x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238 Call trace: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x20/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 [mlxbf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink+0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg+0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x30/0xac el0_svc+0x48/0x160 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Code: bad PC value ---[ end trace 7d1c3f3bf9d81885 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x2870a7a00000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0,000005c1,a3332a5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- The exception happens because there is a pending RX interrupt before the call to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires immediately after this request_irq() completes. The ---truncated---
- https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab
- https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e
- https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52
- https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3
- https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc
- https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab
- https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e
- https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52
- https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3
- https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc
Modified: 2025-09-24
CVE-2024-35908
In the Linux kernel, the following vulnerability has been resolved: tls: get psock ref after taking rxlock to avoid leak At the start of tls_sw_recvmsg, we take a reference on the psock, and then call tls_rx_reader_lock. If that fails, we return directly without releasing the reference. Instead of adding a new label, just take the reference after locking has succeeded, since we don't need it before.
- https://git.kernel.org/stable/c/30fabe50a7ace3e9d57cf7f9288f33ea408491c8
- https://git.kernel.org/stable/c/417e91e856099e9b8a42a2520e2255e6afe024be
- https://git.kernel.org/stable/c/b565d294e3d5aa809566a4d819835da11997d8b3
- https://git.kernel.org/stable/c/f1b7f14130d782433bc98c1e1e41ce6b4d4c3096
- https://git.kernel.org/stable/c/30fabe50a7ace3e9d57cf7f9288f33ea408491c8
- https://git.kernel.org/stable/c/417e91e856099e9b8a42a2520e2255e6afe024be
- https://git.kernel.org/stable/c/b565d294e3d5aa809566a4d819835da11997d8b3
- https://git.kernel.org/stable/c/f1b7f14130d782433bc98c1e1e41ce6b4d4c3096
Modified: 2025-09-24
CVE-2024-35909
In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Split 64bit accesses to fix alignment issues Some of the registers are aligned on a 32bit boundary, causing alignment faults on 64bit platforms. Unable to handle kernel paging request at virtual address ffffffc084a1d004 Mem abort info: ESR = 0x0000000096000061 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment fault Data abort info: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Internal error: Oops: 0000000096000061 [#1] SMP Modules linked in: mtk_t7xx(+) qcserial pppoe ppp_async option nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) iwlwifi(O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm cdc_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 geniv des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys trusted CPU: 3 PID: 5266 Comm: kworker/u9:1 Tainted: G O 6.6.22 #0 Hardware name: Bananapi BPI-R4 (DT) Workqueue: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr : t7xx_cldma_start+0xac/0x13c [mtk_t7xx] sp : ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 0000000000000001 x19: ffffff80c814b080 x18: 0000000000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffffff80ca1ef6b4 x7 : ffffff80c814b818 x6 : 0000000000000018 x5 : 0000000000000870 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000010a947000 x1 : ffffffc084a1d004 x0 : ffffffc084a1d004 Call trace: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] process_one_work+0x154/0x2a0 worker_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Code: f9400800 91001000 8b214001 d50332bf (f9000022) ---[ end trace 0000000000000000 ]--- The inclusion of io-64-nonatomic-lo-hi.h indicates that all 64bit accesses can be replaced by pairs of nonatomic 32bit access. Fix alignment by forcing all accesses to be 32bit on 64bit platforms.
- https://git.kernel.org/stable/c/2e22c9cb618716b8e557fe17c3d4958171288082
- https://git.kernel.org/stable/c/7d5a7dd5a35876f0ecc286f3602a88887a788217
- https://git.kernel.org/stable/c/b4fdb3c197e35f655b2d9b6759ce29440eacdfda
- https://git.kernel.org/stable/c/beaf0e7996b79e06ccc2bdcb4442fbaeccc31200
- https://git.kernel.org/stable/c/2e22c9cb618716b8e557fe17c3d4958171288082
- https://git.kernel.org/stable/c/7d5a7dd5a35876f0ecc286f3602a88887a788217
- https://git.kernel.org/stable/c/b4fdb3c197e35f655b2d9b6759ce29440eacdfda
- https://git.kernel.org/stable/c/beaf0e7996b79e06ccc2bdcb4442fbaeccc31200
Modified: 2025-12-17
CVE-2024-35910
In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns. For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns. This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler. Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held. It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code) We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.
- https://git.kernel.org/stable/c/151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada
- https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4
- https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f
- https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08837a35a
- https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de
- https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50
- https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87
- https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810
- https://git.kernel.org/stable/c/151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada
- https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4
- https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f
- https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08837a35a
- https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de
- https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50
- https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87
- https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-23
CVE-2024-35911
In the Linux kernel, the following vulnerability has been resolved:
ice: fix memory corruption bug with suspend and rebuild
The ice driver would previously panic after suspend. This is caused
from the driver *only* calling the ice_vsi_free_q_vectors() function by
itself, when it is suspending. Since commit b3e7b3a6ee92 ("ice: prevent
NULL pointer deref during reload") the driver has zeroed out
num_q_vectors, and only restored it in ice_vsi_cfg_def().
This further causes the ice_rebuild() function to allocate a zero length
buffer, after which num_q_vectors is updated, and then the new value of
num_q_vectors is used to index into the zero length buffer, which
corrupts memory.
The fix entails making sure all the code referencing num_q_vectors only
does so after it has been reset via ice_vsi_cfg_def().
I didn't perform a full bisect, but I was able to test against 6.1.77
kernel and that ice driver works fine for suspend/resume with no panic,
so sometime since then, this problem was introduced.
Also clean up an un-needed init of a local variable in the function
being modified.
PANIC from 6.8.0-rc1:
[1026674.915596] PM: suspend exit
[1026675.664697] ice 0000:17:00.1: PTP reset successful
[1026675.664707] ice 0000:17:00.1: 2755 msecs passed between update to cached PHC time
[1026675.667660] ice 0000:b1:00.0: PTP reset successful
[1026675.675944] ice 0000:b1:00.0: 2832 msecs passed between update to cached PHC time
[1026677.137733] ixgbe 0000:31:00.0 ens787: NIC Link is Up 1 Gbps, Flow Control: None
[1026677.190201] BUG: kernel NULL pointer dereference, address: 0000000000000010
[1026677.192753] ice 0000:17:00.0: PTP reset successful
[1026677.192764] ice 0000:17:00.0: 4548 msecs passed between update to cached PHC time
[1026677.197928] #PF: supervisor read access in kernel mode
[1026677.197933] #PF: error_code(0x0000) - not-present page
[1026677.197937] PGD 1557a7067 P4D 0
[1026677.212133] ice 0000:b1:00.1: PTP reset successful
[1026677.212143] ice 0000:b1:00.1: 4344 msecs passed between update to cached PHC time
[1026677.212575]
[1026677.243142] Oops: 0000 [#1] PREEMPT SMP NOPTI
[1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: loaded Tainted: G W 6.8.0-rc1+ #1
[1026677.257989] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022
[1026677.269367] Workqueue: ice ice_service_task [ice]
[1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]
[1026677.281421] Code: 0f 84 3a ff ff ff 41 0f b7 74 ec 02 66 89 b0 22 02 00 00 81 e6 ff 1f 00 00 e8 ec fd ff ff e9 35 ff ff ff 48 8b 43 30 49 63 ed <41> 0f b7 34 24 41 83 c5 01 48 8b 3c e8 66 89 b7 aa 02 00 00 81 e6
[1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 00010202
[1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000
[1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828
[1026677.321730] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010
[1026677.336896] R13: 0000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0
[1026677.344472] FS: 0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000
[1026677.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0
[1026677.366779] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[1026677.381952] PKRU: 55555554
[1026677.385116] Call Trace:
[1026677.388023]
- https://git.kernel.org/stable/c/11ff8392943e08a35cb0aa19d638b02db745f170
- https://git.kernel.org/stable/c/1cb7fdb1dfde1aab66780b4ba44dba6402172111
- https://git.kernel.org/stable/c/e40a02f06ceb0e0b0183e0b973ac5dbf8f75edec
- https://git.kernel.org/stable/c/11ff8392943e08a35cb0aa19d638b02db745f170
- https://git.kernel.org/stable/c/1cb7fdb1dfde1aab66780b4ba44dba6402172111
- https://git.kernel.org/stable/c/e40a02f06ceb0e0b0183e0b973ac5dbf8f75edec
Modified: 2025-09-23
CVE-2024-35912
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential response leaks If the rx payload length check fails, or if kmemdup() fails, we still need to free the command response. Fix that.
- https://git.kernel.org/stable/c/06a093807eb7b5c5b29b6cff49f8174a4e702341
- https://git.kernel.org/stable/c/28db0ae86cb91a4ab0e855cff779daead936b7d5
- https://git.kernel.org/stable/c/99a75d75007421d8e08ba139e24f77395cd08f62
- https://git.kernel.org/stable/c/c0a40f2f8eba07416f695ffe2011bf3f8b0b6dc8
- https://git.kernel.org/stable/c/f7f0e784894dfcb265f0f9fa499103b0ca7eabde
- https://git.kernel.org/stable/c/06a093807eb7b5c5b29b6cff49f8174a4e702341
- https://git.kernel.org/stable/c/28db0ae86cb91a4ab0e855cff779daead936b7d5
- https://git.kernel.org/stable/c/99a75d75007421d8e08ba139e24f77395cd08f62
- https://git.kernel.org/stable/c/c0a40f2f8eba07416f695ffe2011bf3f8b0b6dc8
- https://git.kernel.org/stable/c/f7f0e784894dfcb265f0f9fa499103b0ca7eabde
Modified: 2025-02-03
CVE-2024-35915
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes.
- https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff
- https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240
- https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c
- https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a
- https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a
- https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16
- https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7
- https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f
- https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff
- https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240
- https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c
- https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a
- https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a
- https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16
- https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7
- https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-35916
In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix NULL pointer dereference in sanitycheck() If due to a memory allocation failure mock_chain() returns NULL, it is passed to dma_fence_enable_sw_signaling() resulting in NULL pointer dereference there. Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/0336995512cdab0c65e99e4cdd47c4606debe14e
- https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c
- https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6
- https://git.kernel.org/stable/c/eabf131cba1db12005a68378305f13b9090a7a6b
- https://git.kernel.org/stable/c/0336995512cdab0c65e99e4cdd47c4606debe14e
- https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c
- https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6
- https://git.kernel.org/stable/c/eabf131cba1db12005a68378305f13b9090a7a6b
Modified: 2025-09-23
CVE-2024-35917
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_plt pointer arithmetic Kui-Feng Lee reported a crash on s390x triggered by the dummy_st_ops/dummy_init_ptr_arg test [1]: [<0000000000000002>] 0x2 [<00000000009d5cde>] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 This is caused by GCC moving memcpy() after assignments in bpf_jit_plt(), resulting in NULL pointers being written instead of the return and the target addresses. Looking at the GCC internals, the reordering is allowed because the alias analysis thinks that the memcpy() destination and the assignments' left-hand-sides are based on different objects: new_plt and bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot alias. This is in turn due to a violation of the C standard: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object ... From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects and cannot be subtracted. In the practical terms, doing so confuses the GCC's alias analysis. The code was written this way in order to let the C side know a few offsets defined in the assembly. While nice, this is by no means necessary. Fix the noncompliance by hardcoding these offsets. [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/
- https://git.kernel.org/stable/c/7ded842b356d151ece8ac4985940438e6d3998bb
- https://git.kernel.org/stable/c/c3062bdb859b6e2567e7f5c8cde20c0250bb130f
- https://git.kernel.org/stable/c/d3d74e45a060d218fe4b0c9174f0a77517509d8e
- https://git.kernel.org/stable/c/7ded842b356d151ece8ac4985940438e6d3998bb
- https://git.kernel.org/stable/c/c3062bdb859b6e2567e7f5c8cde20c0250bb130f
- https://git.kernel.org/stable/c/d3d74e45a060d218fe4b0c9174f0a77517509d8e
Modified: 2025-04-04
CVE-2024-35919
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: adding lock to protect encoder context list Add a lock for the ctx_list, to avoid accessing a NULL pointer within the 'vpu_enc_ipi_handler' function when the ctx_list has been deleted due to an unexpected behavior on the SCP IP block.
- https://git.kernel.org/stable/c/41671f0c0182b2bae74ca7e3b0f155559e3e2fc5
- https://git.kernel.org/stable/c/51c84a8aac6e3b59af2b0e92ba63cabe2e641a2d
- https://git.kernel.org/stable/c/afaaf3a0f647a24a7bf6a2145d8ade37baaf75ad
- https://git.kernel.org/stable/c/41671f0c0182b2bae74ca7e3b0f155559e3e2fc5
- https://git.kernel.org/stable/c/51c84a8aac6e3b59af2b0e92ba63cabe2e641a2d
- https://git.kernel.org/stable/c/afaaf3a0f647a24a7bf6a2145d8ade37baaf75ad
Modified: 2025-03-04
CVE-2024-35920
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: adding lock to protect decoder context list Add a lock for the ctx_list, to avoid accessing a NULL pointer within the 'vpu_dec_ipi_handler' function when the ctx_list has been deleted due to an unexpected behavior on the SCP IP block. Hardware name: Google juniper sku16 board (DT) pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--) pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec] lr : scp_ipi_handler+0xd0/0x194 [mtk_scp] sp : ffffffc0131dbbd0 x29: ffffffc0131dbbd0 x28: 0000000000000000 x27: ffffff9bb277f348 x26: ffffff9bb242ad00 x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4 x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0 x21: 0000000000000010 x20: ffffff9b050ea328 x19: ffffffc0131dbc08 x18: 0000000000001000 x17: 0000000000000000 x16: ffffffd2d461c6e0 x15: 0000000000000242 x14: 000000000000018f x13: 000000000000004d x12: 0000000000000000 x11: 0000000000000001 x10: fffffffffffffff0 x9 : ffffff9bb6e793a8 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : fffffffffffffff0 x3 : 0000000000000020 x2 : ffffff9bb6e79080 x1 : 0000000000000010 x0 : ffffffc0131dbc08 Call trace: vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)] scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)] mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)] scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)] irq_thread_fn+0x38/0x94 irq_thread+0x100/0x1c0 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Code: 54000088 f94ca50a eb14015f 54000060 (f9400108) ---[ end trace ace43ce36cbd5c93 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: 0x12c4000000 from 0xffffffc010000000 PHYS_OFFSET: 0xffffffe580000000 CPU features: 0x08240002,2188200c Memory Limit: none
- https://git.kernel.org/stable/c/0a2dc707aa42214f9c4827bd57e344e29a0841d6
- https://git.kernel.org/stable/c/23aaf824121055ba81b55f75444355bd83c8eb38
- https://git.kernel.org/stable/c/6467cda18c9f9b5f2f9a0aa1e2861c653e41f382
- https://git.kernel.org/stable/c/0a2dc707aa42214f9c4827bd57e344e29a0841d6
- https://git.kernel.org/stable/c/23aaf824121055ba81b55f75444355bd83c8eb38
- https://git.kernel.org/stable/c/6467cda18c9f9b5f2f9a0aa1e2861c653e41f382
Modified: 2024-12-30
CVE-2024-35921
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix oops when HEVC init fails The stateless HEVC decoder saves the instance pointer in the context regardless if the initialization worked or not. This caused a use after free, when the pointer is freed in case of a failure in the deinit function. Only store the instance pointer when the initialization was successful, to solve this issue. Hardware name: Acer Tomato (rev3 - 4) board (DT) pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec] lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec] sp : ffff80008750bc20 x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff80008750bc98 x22: 000000000000a003 x21: ffffd45c4cfae000 x20: 0000000000000010 x19: ffff1299fd668310 x18: 000000000000001a x17: 000000040044ffff x16: ffffd45cb15dc648 x15: 0000000000000000 x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80 x11: 0000000000000001 x10: 0000000000001b30 x9 : ffffd45c4d12b488 x8 : 1fffe25339380d81 x7 : 0000000000000001 x6 : ffff1299c9c06c00 x5 : 0000000000000132 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000010 x1 : ffff80008750bc98 x0 : 0000000000000000 Call trace: vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec] vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec] vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec] vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec] vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec] mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec] fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec] v4l2_release+0x7c/0x100 __fput+0x80/0x2d8 __fput_sync+0x58/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x38/0xd8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x1a8/0x1b0 Code: d503201f f9401660 b900127f b900227f (f9400400)
- https://git.kernel.org/stable/c/521ce0ea7418298d754494fe53263c23c4c78a8e
- https://git.kernel.org/stable/c/97c75ee5de060d271d80109b0c47cb6008439e5b
- https://git.kernel.org/stable/c/ec25fc3c2c1e8958a51abcfed614f81446d918c4
- https://git.kernel.org/stable/c/521ce0ea7418298d754494fe53263c23c4c78a8e
- https://git.kernel.org/stable/c/97c75ee5de060d271d80109b0c47cb6008439e5b
- https://git.kernel.org/stable/c/ec25fc3c2c1e8958a51abcfed614f81446d918c4
Modified: 2024-12-30
CVE-2024-35922
In the Linux kernel, the following vulnerability has been resolved: fbmon: prevent division by zero in fb_videomode_from_videomode() The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode(). Found by Linux Verification Center (linuxtesting.org) with Svace.
- https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4
- https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f
- https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33
- https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029
- https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971
- https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270
- https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0
- https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126
- https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4
- https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f
- https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33
- https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029
- https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971
- https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270
- https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0
- https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-24
CVE-2024-35924
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Limit read size on v1.2 Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.
- https://git.kernel.org/stable/c/0defcaa09d3b21e8387829ee3a652c43fa91e13f
- https://git.kernel.org/stable/c/266f403ec47573046dee4bcebda82777ce702c40
- https://git.kernel.org/stable/c/b3db266fb031fba88c423d4bb8983a73a3db6527
- https://git.kernel.org/stable/c/0defcaa09d3b21e8387829ee3a652c43fa91e13f
- https://git.kernel.org/stable/c/266f403ec47573046dee4bcebda82777ce702c40
- https://git.kernel.org/stable/c/b3db266fb031fba88c423d4bb8983a73a3db6527
Modified: 2024-12-31
CVE-2024-35925
In the Linux kernel, the following vulnerability has been resolved: block: prevent division by zero in blk_rq_stat_sum() The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero. Found by Linux Verification Center (linuxtesting.org) with Svace.
- https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8
- https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854
- https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe
- https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7
- https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02
- https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68
- https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c
- https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14
- https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8
- https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854
- https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe
- https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7
- https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02
- https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68
- https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c
- https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-24
CVE-2024-35927
In the Linux kernel, the following vulnerability has been resolved:
drm: Check output polling initialized before disabling
In drm_kms_helper_poll_disable() check if output polling
support is initialized before disabling polling. If not flag
this as a warning.
Additionally in drm_mode_config_helper_suspend() and
drm_mode_config_helper_resume() calls, that re the callers of these
functions, avoid invoking them if polling is not initialized.
For drivers like hyperv-drm, that do not initialize connector
polling, if suspend is called without this check, it leads to
suspend failure with following stack
[ 770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 770.720592] printk: Suspending console(s) (use no_console_suspend to debug)
[ 770.948823] ------------[ cut here ]------------
[ 770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230
[ 770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms_helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct10dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod
[ 770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep Not tainted 5.14.0-362.2.1.el9_3.x86_64 #1
[ 770.948865] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230
[ 770.948869] Code: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff <0f> 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 84 00
[ 770.948870] RSP: 0018:ffffaf4ac213fb10 EFLAGS: 00010246
[ 770.948871] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8c992857
[ 770.948872] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9aad82b00330
[ 770.948873] RBP: ffff9aad82b00330 R08: 0000000000000000 R09: ffff9aad87ee3d10
[ 770.948874] R10: 0000000000000200 R11: 0000000000000000 R12: ffff9aad82b00330
[ 770.948874] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
[ 770.948875] FS: 00007ff1b2f6bb40(0000) GS:ffff9aaf37d00000(0000) knlGS:0000000000000000
[ 770.948878] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 770.948878] CR2: 0000555f345cb666 CR3: 00000001462dc005 CR4: 0000000000370ee0
[ 770.948879] Call Trace:
[ 770.948880]
- https://git.kernel.org/stable/c/18451798f4a4e7418b9fad7e7dd313fe84b1f545
- https://git.kernel.org/stable/c/3d1b47e3a935abd4f258a945db87e7267ff4079c
- https://git.kernel.org/stable/c/5abffb66d12bcac84bf7b66389c571b8bb6e82bd
- https://git.kernel.org/stable/c/18451798f4a4e7418b9fad7e7dd313fe84b1f545
- https://git.kernel.org/stable/c/3d1b47e3a935abd4f258a945db87e7267ff4079c
- https://git.kernel.org/stable/c/4ad8d57d902fbc7c82507cfc1b031f3a07c3de6e
- https://git.kernel.org/stable/c/5abffb66d12bcac84bf7b66389c571b8bb6e82bd
- https://git.kernel.org/stable/c/786c27982a39d79cc753f84229eb5977ac8ef1c1
Modified: 2024-12-30
CVE-2024-35929
In the Linux kernel, the following vulnerability has been resolved: rcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock() For the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and CONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE() in the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions: CPU2 CPU11 kthread rcu_nocb_cb_kthread ksys_write rcu_do_batch vfs_write rcu_torture_timer_cb proc_sys_write __kmem_cache_free proc_sys_call_handler kmemleak_free drop_caches_sysctl_handler delete_object_full drop_slab __delete_object shrink_slab put_object lazy_rcu_shrink_scan call_rcu rcu_nocb_flush_bypass __call_rcu_commn rcu_nocb_bypass_lock raw_spin_trylock(&rdp->nocb_bypass_lock) fail atomic_inc(&rdp->nocb_lock_contended); rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id() != rdp->cpu); WARN_ON_ONCE(atomic_read(&rdp->nocb_lock_contended)) | |_ _ _ _ _ _ _ _ _ _same rdp and rdp->cpu != 11_ _ _ _ _ _ _ _ _ __| Reproduce this bug with "echo 3 > /proc/sys/vm/drop_caches". This commit therefore uses rcu_nocb_try_flush_bypass() instead of rcu_nocb_flush_bypass() in lazy_rcu_shrink_scan(). If the nocb_bypass queue is being flushed, then rcu_nocb_try_flush_bypass will return directly.
- https://git.kernel.org/stable/c/4d58c9fb45c70e62c19e8be3f3605889c47601bc
- https://git.kernel.org/stable/c/927d1f4f77e4784ab3944a9df86ab14d1cd3185a
- https://git.kernel.org/stable/c/dda98810b552fc6bf650f4270edeebdc2f28bd3f
- https://git.kernel.org/stable/c/4d58c9fb45c70e62c19e8be3f3605889c47601bc
- https://git.kernel.org/stable/c/927d1f4f77e4784ab3944a9df86ab14d1cd3185a
- https://git.kernel.org/stable/c/dda98810b552fc6bf650f4270edeebdc2f28bd3f
Modified: 2024-12-30
CVE-2024-35930
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.
- https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf
- https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b
- https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f
- https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7
- https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a
- https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8
- https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8
- https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f
- https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf
- https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b
- https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f
- https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7
- https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a
- https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8
- https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8
- https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-23
CVE-2024-35932
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: don't check if plane->state->fb == state->fb Currently, when using non-blocking commits, we can see the following kernel warning: [ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- This happens because, although `prepare_fb` and `cleanup_fb` are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The opposite can also be true. In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the `drm_atomic_get_new_plane_state()` helper function should be used. So, we could stick to this check, but using `drm_atomic_get_new_plane_state()`. But actually, this check is not re ---truncated---
- https://git.kernel.org/stable/c/48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
- https://git.kernel.org/stable/c/5343f724c912c77541029123f47ecd3d2ea63bdd
- https://git.kernel.org/stable/c/5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9
- https://git.kernel.org/stable/c/d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
- https://git.kernel.org/stable/c/48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
- https://git.kernel.org/stable/c/5343f724c912c77541029123f47ecd3d2ea63bdd
- https://git.kernel.org/stable/c/5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9
- https://git.kernel.org/stable/c/d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
Modified: 2026-01-05
CVE-2024-35933
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Fix null ptr deref in btintel_read_version If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue.
- https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e
- https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912
- https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645
- https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b
- https://git.kernel.org/stable/c/006936ecb4edfc3102464044f75858c714e34d28
- https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e
- https://git.kernel.org/stable/c/68a69bb2ecafaacdb998a87783068fb51736f43b
- https://git.kernel.org/stable/c/86e9b47e8a75c74b1bd83a479979b425c5dc8bd9
- https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912
- https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645
- https://git.kernel.org/stable/c/ec2049fb2b8be3e108fe2ef1f1040f91e72c9990
- https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-35934
In the Linux kernel, the following vulnerability has been resolved: net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list() Many syzbot reports show extreme rtnl pressure, and many of them hint that smc acquires rtnl in netns creation for no good reason [1] This patch returns early from smc_pnet_net_init() if there is no netdevice yet. I am not even sure why smc_pnet_create_pnetids_list() even exists, because smc_pnet_netdev_event() is also calling smc_pnet_add_base_pnetid() when handling NETDEV_UP event. [1] extract of typical syzbot reports 2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
- https://git.kernel.org/stable/c/00af2aa93b76b1bade471ad0d0525d4d29ca5cc0
- https://git.kernel.org/stable/c/6e920422e7104928f760fc0e12b6d65ab097a2e7
- https://git.kernel.org/stable/c/a2e6bffc0388526ed10406040279a693d62b36ec
- https://git.kernel.org/stable/c/b9117dc783c0ab0a3866812f70e07bf2ea071ac4
- https://git.kernel.org/stable/c/bc4d1ebca11b4f194e262326bd45938e857c59d2
- https://git.kernel.org/stable/c/d7ee3bf0caf599c14db0bf4af7aacd6206ef8a23
- https://git.kernel.org/stable/c/00af2aa93b76b1bade471ad0d0525d4d29ca5cc0
- https://git.kernel.org/stable/c/6e920422e7104928f760fc0e12b6d65ab097a2e7
- https://git.kernel.org/stable/c/a2e6bffc0388526ed10406040279a693d62b36ec
- https://git.kernel.org/stable/c/b9117dc783c0ab0a3866812f70e07bf2ea071ac4
- https://git.kernel.org/stable/c/bc4d1ebca11b4f194e262326bd45938e857c59d2
- https://git.kernel.org/stable/c/d7ee3bf0caf599c14db0bf4af7aacd6206ef8a23
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-35935
In the Linux kernel, the following vulnerability has been resolved: btrfs: send: handle path ref underflow in header iterate_inode_ref() Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.
- https://git.kernel.org/stable/c/024529c27c8b4b273325a169e078337c8279e229
- https://git.kernel.org/stable/c/03938619a1e718b6168ae4528e1b0f979293f1a5
- https://git.kernel.org/stable/c/2f6174fd4ccf403b42b3d5f0d1b6b496a0e5330a
- https://git.kernel.org/stable/c/3c6ee34c6f9cd12802326da26631232a61743501
- https://git.kernel.org/stable/c/4720d590c4cb5d9ffa0060b89743651cc7e995f9
- https://git.kernel.org/stable/c/9ae356c627b493323e1433dcb27a26917668c07c
- https://git.kernel.org/stable/c/be2b6bcc936ae17f42fff6494106a5660b35d8d3
- https://git.kernel.org/stable/c/c1363ed8867b81ea169fba2ccc14af96a85ed183
- https://git.kernel.org/stable/c/024529c27c8b4b273325a169e078337c8279e229
- https://git.kernel.org/stable/c/03938619a1e718b6168ae4528e1b0f979293f1a5
- https://git.kernel.org/stable/c/2f6174fd4ccf403b42b3d5f0d1b6b496a0e5330a
- https://git.kernel.org/stable/c/3c6ee34c6f9cd12802326da26631232a61743501
- https://git.kernel.org/stable/c/4720d590c4cb5d9ffa0060b89743651cc7e995f9
- https://git.kernel.org/stable/c/9ae356c627b493323e1433dcb27a26917668c07c
- https://git.kernel.org/stable/c/be2b6bcc936ae17f42fff6494106a5660b35d8d3
- https://git.kernel.org/stable/c/c1363ed8867b81ea169fba2ccc14af96a85ed183
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-35936
In the Linux kernel, the following vulnerability has been resolved: btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions: - at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1 - after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints
- https://git.kernel.org/stable/c/0d23b34c68c46cd225b55868bc8a269e3134816d
- https://git.kernel.org/stable/c/1f9212cdbd005bc55f2b7422e7b560d9c02bd1da
- https://git.kernel.org/stable/c/36c2a2863bc3896243eb724dc3fd4cf9aea633f2
- https://git.kernel.org/stable/c/576164bd01bd795f8b09fb194b493103506b33c9
- https://git.kernel.org/stable/c/7411055db5ce64f836aaffd422396af0075fdc99
- https://git.kernel.org/stable/c/87299cdaae757f3f41212146cfb5b3af416b8385
- https://git.kernel.org/stable/c/bebd9e0ff90034875c5dfe4bd514fd7055fc7a89
- https://git.kernel.org/stable/c/d1ffa4ae2d591fdd40471074e79954ec45f147f7
- https://git.kernel.org/stable/c/0d23b34c68c46cd225b55868bc8a269e3134816d
- https://git.kernel.org/stable/c/1f9212cdbd005bc55f2b7422e7b560d9c02bd1da
- https://git.kernel.org/stable/c/36c2a2863bc3896243eb724dc3fd4cf9aea633f2
- https://git.kernel.org/stable/c/576164bd01bd795f8b09fb194b493103506b33c9
- https://git.kernel.org/stable/c/7411055db5ce64f836aaffd422396af0075fdc99
- https://git.kernel.org/stable/c/87299cdaae757f3f41212146cfb5b3af416b8385
- https://git.kernel.org/stable/c/bebd9e0ff90034875c5dfe4bd514fd7055fc7a89
- https://git.kernel.org/stable/c/d1ffa4ae2d591fdd40471074e79954ec45f147f7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-35937
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: check A-MSDU format more carefully If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.
- https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544
- https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9
- https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc
- https://git.kernel.org/stable/c/9eb3bc0973d084423a6df21cf2c74692ff05647e
- https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544
- https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9
- https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-24
CVE-2024-35938
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: decrease MHI channel buffer length to 8KB
Currently buf_len field of ath11k_mhi_config_qca6390 is assigned
with 0, making MHI use a default size, 64KB, to allocate channel
buffers. This is likely to fail in some scenarios where system
memory is highly fragmented and memory compaction or reclaim is
not allowed.
There is a fail report which is caused by it:
kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb
Workqueue: events_unbound async_run_entry_fn
Call Trace:
- https://git.kernel.org/stable/c/138fdeac75fb7512a7f9f1c3b236cd2e754af793
- https://git.kernel.org/stable/c/1cca1bddf9ef080503c15378cecf4877f7510015
- https://git.kernel.org/stable/c/6597a6687af54e2cb58371cf8f6ee4dd85c537de
- https://git.kernel.org/stable/c/805a1cdde82fec00c7471a393f4bb437b2741559
- https://git.kernel.org/stable/c/ae5876b3b7b2243d874e2afa099e7926122087a1
- https://git.kernel.org/stable/c/138fdeac75fb7512a7f9f1c3b236cd2e754af793
- https://git.kernel.org/stable/c/1cca1bddf9ef080503c15378cecf4877f7510015
- https://git.kernel.org/stable/c/6597a6687af54e2cb58371cf8f6ee4dd85c537de
- https://git.kernel.org/stable/c/805a1cdde82fec00c7471a393f4bb437b2741559
- https://git.kernel.org/stable/c/ae5876b3b7b2243d874e2afa099e7926122087a1
Modified: 2025-09-24
CVE-2024-35939
In the Linux kernel, the following vulnerability has been resolved: dma-direct: Leak pages on dma_set_decrypted() failure On TDX it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. DMA could free decrypted/shared pages if dma_set_decrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them.
- https://git.kernel.org/stable/c/4031b72ca747a1e6e9ae4fa729e765b43363d66a
- https://git.kernel.org/stable/c/4e0cfb25d49da2e6261ad582f58ffa5b5dd8c8e9
- https://git.kernel.org/stable/c/b57326c96b7bc7638aa8c44e12afa2defe0c934c
- https://git.kernel.org/stable/c/b9fa16949d18e06bdf728a560f5c8af56d2bdcaf
- https://git.kernel.org/stable/c/4031b72ca747a1e6e9ae4fa729e765b43363d66a
- https://git.kernel.org/stable/c/4e0cfb25d49da2e6261ad582f58ffa5b5dd8c8e9
- https://git.kernel.org/stable/c/b57326c96b7bc7638aa8c44e12afa2defe0c934c
- https://git.kernel.org/stable/c/b9fa16949d18e06bdf728a560f5c8af56d2bdcaf
Modified: 2025-04-04
CVE-2024-35940
In the Linux kernel, the following vulnerability has been resolved: pstore/zone: Add a null pointer check to the psz_kmsg_read kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
- https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb
- https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682
- https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc
- https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8
- https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041
- https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70
- https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb
- https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682
- https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc
- https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8
- https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041
- https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-24
CVE-2024-35942
In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of hdmi rx verification IP that should not enable for HDMI TX. But actually if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and print the error logs: [CRTC:39:crtc-2] vblank wait timed out WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.
- https://git.kernel.org/stable/c/697624ee8ad557ab5417f985d2c804241a7ad30d
- https://git.kernel.org/stable/c/9d3f959b426635c4da50dfc7b1306afd84d23e7c
- https://git.kernel.org/stable/c/b13c0d871cd878ff53d25507ca535f59ed1f6a2a
- https://git.kernel.org/stable/c/697624ee8ad557ab5417f985d2c804241a7ad30d
- https://git.kernel.org/stable/c/9d3f959b426635c4da50dfc7b1306afd84d23e7c
- https://git.kernel.org/stable/c/b13c0d871cd878ff53d25507ca535f59ed1f6a2a
Modified: 2025-11-03
CVE-2024-35943
In the Linux kernel, the following vulnerability has been resolved: pmdomain: ti: Add a null pointer check to the omap_prm_domain_init devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
- https://git.kernel.org/stable/c/04f23510daa40f9010fadf309507564a34ad956f
- https://git.kernel.org/stable/c/5d7f58ee08434a33340f75ac7ac5071eea9673b3
- https://git.kernel.org/stable/c/984212fa6b4bc6d9ed58f5b0838e8d5af7679ce5
- https://git.kernel.org/stable/c/bc08f5ab11b1881b85371f0bd9c9a3d27f65cca8
- https://git.kernel.org/stable/c/ce666cecc09c0f92d5f86d89d8068ecfcf723a7e
- https://git.kernel.org/stable/c/e65f7eb117e1b44742212d65784236269085e736
- https://git.kernel.org/stable/c/04f23510daa40f9010fadf309507564a34ad956f
- https://git.kernel.org/stable/c/5d7f58ee08434a33340f75ac7ac5071eea9673b3
- https://git.kernel.org/stable/c/ce666cecc09c0f92d5f86d89d8068ecfcf723a7e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-12-17
CVE-2024-35944
In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() Syzkaller hit 'WARNING in dg_dispatch_as_host' bug. memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg" at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24) WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237 Some code commentry, based on my understanding: 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size) /// This is 24 + payload_size memcpy(&dg_info->msg, dg, dg_size); Destination = dg_info->msg ---> this is a 24 byte structure(struct vmci_datagram) Source = dg --> this is a 24 byte structure (struct vmci_datagram) Size = dg_size = 24 + payload_size {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32. 35 struct delayed_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg and msg_payload must be together. */ 40 struct vmci_datagram msg; 41 u8 msg_payload[]; 42 }; So those extra bytes of payload are copied into msg_payload[], a run time warning is seen while fuzzing with Syzkaller. One possible way to fix the warning is to split the memcpy() into two parts -- one -- direct assignment of msg and second taking care of payload. Gustavo quoted: "Under FORTIFY_SOURCE we should not copy data across multiple members in a structure."
- https://git.kernel.org/stable/c/130b0cd064874e0d0f58e18fb00e6f3993e90c74
- https://git.kernel.org/stable/c/19b070fefd0d024af3daa7329cbc0d00de5302ec
- https://git.kernel.org/stable/c/491a1eb07c2bd8841d63cb5263455e185be5866f
- https://git.kernel.org/stable/c/ad78c5047dc4076d0b3c4fad4f42ffe9c86e8100
- https://git.kernel.org/stable/c/dae70a57565686f16089737adb8ac64471570f73
- https://git.kernel.org/stable/c/e87bb99d2df6512d8ee37a5d63d2ca9a39a8c051
- https://git.kernel.org/stable/c/f15eca95138b3d4ec17b63c3c1937b0aa0d3624b
- https://git.kernel.org/stable/c/feacd430b42bbfa9ab3ed9e4f38b86c43e348c75
- https://git.kernel.org/stable/c/130b0cd064874e0d0f58e18fb00e6f3993e90c74
- https://git.kernel.org/stable/c/19b070fefd0d024af3daa7329cbc0d00de5302ec
- https://git.kernel.org/stable/c/491a1eb07c2bd8841d63cb5263455e185be5866f
- https://git.kernel.org/stable/c/ad78c5047dc4076d0b3c4fad4f42ffe9c86e8100
- https://git.kernel.org/stable/c/dae70a57565686f16089737adb8ac64471570f73
- https://git.kernel.org/stable/c/e87bb99d2df6512d8ee37a5d63d2ca9a39a8c051
- https://git.kernel.org/stable/c/f15eca95138b3d4ec17b63c3c1937b0aa0d3624b
- https://git.kernel.org/stable/c/feacd430b42bbfa9ab3ed9e4f38b86c43e348c75
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-31
CVE-2024-35945
In the Linux kernel, the following vulnerability has been resolved: net: phy: phy_device: Prevent nullptr exceptions on ISR If phydev->irq is set unconditionally, check for valid interrupt handler or fall back to polling mode to prevent nullptr exceptions in interrupt service routine.
- https://git.kernel.org/stable/c/3419ee39e3d3162ab2ec9942bb537613ed5b6311
- https://git.kernel.org/stable/c/61c81872815f46006982bb80460c0c80a949b35b
- https://git.kernel.org/stable/c/7a71f61ebf95cedd3f245db6da397822971d8db5
- https://git.kernel.org/stable/c/3419ee39e3d3162ab2ec9942bb537613ed5b6311
- https://git.kernel.org/stable/c/61c81872815f46006982bb80460c0c80a949b35b
- https://git.kernel.org/stable/c/7a71f61ebf95cedd3f245db6da397822971d8db5
Modified: 2025-01-31
CVE-2024-35946
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix null pointer access when abort scan During cancel scan we might use vif that weren't scanning. Fix this by using the actual scanning vif.
- https://git.kernel.org/stable/c/4f11c741908dab7dd48fa5a986b210d4fc74ca8d
- https://git.kernel.org/stable/c/7e11a2966f51695c0af0b1f976a32d64dee243b2
- https://git.kernel.org/stable/c/b34d64e9aa5505e3c84570aed5c757f1839573e8
- https://git.kernel.org/stable/c/4f11c741908dab7dd48fa5a986b210d4fc74ca8d
- https://git.kernel.org/stable/c/7e11a2966f51695c0af0b1f976a32d64dee243b2
- https://git.kernel.org/stable/c/b34d64e9aa5505e3c84570aed5c757f1839573e8
Modified: 2025-04-04
CVE-2024-35947
In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.
- https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c
- https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081
- https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38
- https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b
- https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0
- https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab
- https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc
- https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561
- https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c
- https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081
- https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38
- https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b
- https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0
- https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab
- https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc
- https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/
Modified: 2025-12-17
CVE-2024-35950
In the Linux kernel, the following vulnerability has been resolved: drm/client: Fully protect modes[] with dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.
- https://git.kernel.org/stable/c/04e018bd913d3d3336ab7d21c2ad31a9175fe984
- https://git.kernel.org/stable/c/18c8cc6680ce938d0458859b6a08b4d34f7d8055
- https://git.kernel.org/stable/c/3eadd887dbac1df8f25f701e5d404d1b90fd0fea
- https://git.kernel.org/stable/c/41586487769eede64ab1aa6c65c74cbf76c12ef0
- https://git.kernel.org/stable/c/5a2f957e3c4553bbb100504a1acfeaeb33f4ca4e
- https://git.kernel.org/stable/c/8ceb873d816786a7c8058f50d903574aff8d3764
- https://git.kernel.org/stable/c/d2dc6600d4e3e1453e3b1fb233e9f97e2a1ae949
- https://git.kernel.org/stable/c/04e018bd913d3d3336ab7d21c2ad31a9175fe984
- https://git.kernel.org/stable/c/18c8cc6680ce938d0458859b6a08b4d34f7d8055
- https://git.kernel.org/stable/c/3eadd887dbac1df8f25f701e5d404d1b90fd0fea
- https://git.kernel.org/stable/c/41586487769eede64ab1aa6c65c74cbf76c12ef0
- https://git.kernel.org/stable/c/5a2f957e3c4553bbb100504a1acfeaeb33f4ca4e
- https://git.kernel.org/stable/c/8ceb873d816786a7c8058f50d903574aff8d3764
- https://git.kernel.org/stable/c/d2dc6600d4e3e1453e3b1fb233e9f97e2a1ae949
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-24
CVE-2024-35951
In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.
- https://git.kernel.org/stable/c/1fc9af813b25e146d3607669247d0f970f5a87c3
- https://git.kernel.org/stable/c/31806711e8a4b75e09b1c43652f2a6420e6e1002
- https://git.kernel.org/stable/c/e18070c622c63f0cab170348e320454728c277aa
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/1fc9af813b25e146d3607669247d0f970f5a87c3
- https://git.kernel.org/stable/c/31806711e8a4b75e09b1c43652f2a6420e6e1002
- https://git.kernel.org/stable/c/e18070c622c63f0cab170348e320454728c277aa
Modified: 2025-09-23
CVE-2024-35952
In the Linux kernel, the following vulnerability has been resolved: drm/ast: Fix soft lockup There is a while-loop in ast_dp_set_on_off() that could lead to infinite-loop. This is because the register, VGACRI-Dx, checked in this API is a scratch register actually controlled by a MCU, named DPMCU, in BMC. These scratch registers are protected by scu-lock. If suc-lock is not off, DPMCU can not update these registers and then host will have soft lockup due to never updated status. DPMCU is used to control DP and relative registers to handshake with host's VGA driver. Even the most time-consuming task, DP's link training, is less than 100ms. 200ms should be enough.
- https://git.kernel.org/stable/c/35768baf0fdfc47ede42d899506bad78450e9294
- https://git.kernel.org/stable/c/8a6fea3fcb577a543ef67683ca7105bde49a38fb
- https://git.kernel.org/stable/c/a81b2acd43e24e419f65df97348c76a5a1496066
- https://git.kernel.org/stable/c/bc004f5038220b1891ef4107134ccae44be55109
- https://git.kernel.org/stable/c/35768baf0fdfc47ede42d899506bad78450e9294
- https://git.kernel.org/stable/c/8a6fea3fcb577a543ef67683ca7105bde49a38fb
- https://git.kernel.org/stable/c/a81b2acd43e24e419f65df97348c76a5a1496066
- https://git.kernel.org/stable/c/bc004f5038220b1891ef4107134ccae44be55109
Modified: 2025-01-10
CVE-2024-35953
In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix deadlock in context_xa ivpu_device->context_xa is locked both in kernel thread and IRQ context. It requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization otherwise the lock could be acquired from a thread and interrupted by an IRQ that locks it for the second time causing the deadlock. This deadlock was reported by lockdep and observed in internal tests.
- https://git.kernel.org/stable/c/d43e11d9c7fcb16f18bd46ab2556c2772ffc5775
- https://git.kernel.org/stable/c/e6011411147209bc0cc14628cbc155356837e52a
- https://git.kernel.org/stable/c/fd7726e75968b27fe98534ccbf47ccd6fef686f3
- https://git.kernel.org/stable/c/d43e11d9c7fcb16f18bd46ab2556c2772ffc5775
- https://git.kernel.org/stable/c/e6011411147209bc0cc14628cbc155356837e52a
- https://git.kernel.org/stable/c/fd7726e75968b27fe98534ccbf47ccd6fef686f3
Modified: 2025-03-04
CVE-2024-35954
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Avoid sg device teardown race sg_remove_sfp_usercontext() must not use sg_device_destroy() after calling scsi_device_put(). sg_device_destroy() is accessing the parent scsi_device request_queue which will already be set to NULL when the preceding call to scsi_device_put() removed the last reference to the parent scsi_device. The resulting NULL pointer exception will then crash the kernel.
- https://git.kernel.org/stable/c/27f58c04a8f438078583041468ec60597841284d
- https://git.kernel.org/stable/c/46af9047523e2517712ae8e71d984286c626e022
- https://git.kernel.org/stable/c/b0d1ebcc1a9560e494ea9b3ee808540db26c5086
- https://git.kernel.org/stable/c/27f58c04a8f438078583041468ec60597841284d
- https://git.kernel.org/stable/c/46af9047523e2517712ae8e71d984286c626e022
- https://git.kernel.org/stable/c/b0d1ebcc1a9560e494ea9b3ee808540db26c5086
Modified: 2025-04-04
CVE-2024-35955
In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix possible use-after-free issue on kprobe registration When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE.
- https://git.kernel.org/stable/c/2df2dd27066cdba8041e46a64362325626bdfb2e
- https://git.kernel.org/stable/c/325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8
- https://git.kernel.org/stable/c/36b57c7d2f8b7de224980f1a284432846ad71ca0
- https://git.kernel.org/stable/c/5062d1f4f07facbdade0f402d9a04a788f52e26d
- https://git.kernel.org/stable/c/62029bc9ff2c17a4e3a2478d83418ec575413808
- https://git.kernel.org/stable/c/93eb31e7c3399e326259f2caa17be1e821f5a412
- https://git.kernel.org/stable/c/b5808d40093403334d939e2c3c417144d12a6f33
- https://git.kernel.org/stable/c/d15023fb407337028a654237d8968fefdcf87c2f
- https://git.kernel.org/stable/c/2df2dd27066cdba8041e46a64362325626bdfb2e
- https://git.kernel.org/stable/c/325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8
- https://git.kernel.org/stable/c/36b57c7d2f8b7de224980f1a284432846ad71ca0
- https://git.kernel.org/stable/c/5062d1f4f07facbdade0f402d9a04a788f52e26d
- https://git.kernel.org/stable/c/62029bc9ff2c17a4e3a2478d83418ec575413808
- https://git.kernel.org/stable/c/93eb31e7c3399e326259f2caa17be1e821f5a412
- https://git.kernel.org/stable/c/b5808d40093403334d939e2c3c417144d12a6f33
- https://git.kernel.org/stable/c/d15023fb407337028a654237d8968fefdcf87c2f
- 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-03
CVE-2024-35956
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations Create subvolume, create snapshot and delete subvolume all use btrfs_subvolume_reserve_metadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via start_transaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction. However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling record_root_in_trans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. Ultimately, this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount for the leaked reservation. The fix is to ensure that every qgroup PREALLOC reservation observes the following properties: 1. any failure before record_root_in_trans is called successfully results in freeing the PREALLOC reservation. 2. after record_root_in_trans, we convert to PERTRANS, and now the transaction owns freeing the reservation. This patch enforces those properties on the three operations. Without it, generic/269 with squotas enabled at mkfs time would fail in ~5-10 runs on my system. With this patch, it ran successfully 1000 times in a row.
- https://git.kernel.org/stable/c/14431815a4ae4bcd7c7a68b6a64c66c7712d27c9
- https://git.kernel.org/stable/c/6c95336f5d8eb9ab79cd7306d71b6d0477363f8c
- https://git.kernel.org/stable/c/74e97958121aa1f5854da6effba70143f051b0cd
- https://git.kernel.org/stable/c/945559be6e282a812dc48f7bcd5adc60901ea4a0
- https://git.kernel.org/stable/c/14431815a4ae4bcd7c7a68b6a64c66c7712d27c9
- https://git.kernel.org/stable/c/6c95336f5d8eb9ab79cd7306d71b6d0477363f8c
- https://git.kernel.org/stable/c/74e97958121aa1f5854da6effba70143f051b0cd
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2025-12-17
CVE-2024-35958
In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix incorrect descriptor free behavior ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue. This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.
- https://git.kernel.org/stable/c/19ff8fed3338898b70b2aad831386c78564912e1
- https://git.kernel.org/stable/c/5c7f2240d9835a7823d87f7460d8eae9f4e504c7
- https://git.kernel.org/stable/c/b26aa765f7437e1bbe8db4c1641b12bd5dd378f0
- https://git.kernel.org/stable/c/bf02d9fe00632d22fa91d34749c7aacf397b6cde
- https://git.kernel.org/stable/c/c31baa07f01307b7ae05f3ce32b89d8e2ba0cc1d
- https://git.kernel.org/stable/c/fdfbf54d128ab6ab255db138488f9650485795a2
- https://git.kernel.org/stable/c/19ff8fed3338898b70b2aad831386c78564912e1
- https://git.kernel.org/stable/c/5c7f2240d9835a7823d87f7460d8eae9f4e504c7
- https://git.kernel.org/stable/c/b26aa765f7437e1bbe8db4c1641b12bd5dd378f0
- https://git.kernel.org/stable/c/bf02d9fe00632d22fa91d34749c7aacf397b6cde
- https://git.kernel.org/stable/c/c31baa07f01307b7ae05f3ce32b89d8e2ba0cc1d
- https://git.kernel.org/stable/c/fdfbf54d128ab6ab255db138488f9650485795a2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-23
CVE-2024-35959
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix mlx5e_priv_init() cleanup flow
When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which
calls mlx5e_selq_apply() that assures that the `priv->state_lock` is held using
lockdep_is_held().
Acquire the state_lock in mlx5e_selq_cleanup().
Kernel log:
=============================
WARNING: suspicious RCU usage
6.8.0-rc3_net_next_841a9b5 #1 Not tainted
-----------------------------
drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by systemd-modules/293:
#0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core]
#1: ffff8881096c65c0 (&device->client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core]
stack backtrace:
CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/6bd77865fda662913dcb5722a66a773840370aa7
- https://git.kernel.org/stable/c/ad26f26abd353113dea4e8d5ebadccdab9b61e76
- https://git.kernel.org/stable/c/ecb829459a841198e142f72fadab56424ae96519
- https://git.kernel.org/stable/c/f9ac93b6f3de34aa0bb983b9be4f69ca50fc70f3
- https://git.kernel.org/stable/c/6bd77865fda662913dcb5722a66a773840370aa7
- https://git.kernel.org/stable/c/ad26f26abd353113dea4e8d5ebadccdab9b61e76
- https://git.kernel.org/stable/c/ecb829459a841198e142f72fadab56424ae96519
- https://git.kernel.org/stable/c/f9ac93b6f3de34aa0bb983b9be4f69ca50fc70f3
Modified: 2025-04-04
CVE-2024-35960
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.
- https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423
- https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f
- https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801
- https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0
- https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64
- https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453
- https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d
- https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2
- https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423
- https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f
- https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801
- https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0
- https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64
- https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453
- https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d
- https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-24
CVE-2024-35961
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Register devlink first under devlink lock
In case device is having a non fatal FW error during probe, the
driver will report the error to user via devlink. This will trigger
a WARN_ON, since mlx5 is calling devlink_register() last.
In order to avoid the WARN_ON[1], change mlx5 to invoke devl_register()
first under devlink lock.
[1]
WARNING: CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0
CPU: 5 PID: 227 Comm: kworker/u16:3 Not tainted 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Workqueue: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core]
RIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0
Call Trace:
- https://git.kernel.org/stable/c/8c91c60858473731bcdaf04fda99fcbcf84420d4
- https://git.kernel.org/stable/c/967caa3d37c078e5b95a32094657e6a4cad145f0
- https://git.kernel.org/stable/c/c6e77aa9dd82bc18a89bf49418f8f7e961cfccc8
- https://git.kernel.org/stable/c/8c91c60858473731bcdaf04fda99fcbcf84420d4
- https://git.kernel.org/stable/c/967caa3d37c078e5b95a32094657e6a4cad145f0
- https://git.kernel.org/stable/c/c6e77aa9dd82bc18a89bf49418f8f7e961cfccc8
Modified: 2025-11-03
CVE-2024-35966
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064
- https://git.kernel.org/stable/c/00767fbd67af70d7a550caa5b12d9515fa978bab
- https://git.kernel.org/stable/c/4ea65e2095e9bd151d0469328dd7fc2858feb546
- https://git.kernel.org/stable/c/a97de7bff13b1cc825c1b1344eaed8d6c2d3e695
- https://git.kernel.org/stable/c/c3f787a3eafe519c93df9abbb0ca5145861c8d0f
- https://git.kernel.org/stable/c/d072ea24748189cd8f4a9c3f585ca9af073a0838
- https://git.kernel.org/stable/c/eea40d33bf936a5c7fb03c190e61e0cfee00e872
- https://git.kernel.org/stable/c/a97de7bff13b1cc825c1b1344eaed8d6c2d3e695
- https://git.kernel.org/stable/c/c3f787a3eafe519c93df9abbb0ca5145861c8d0f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-12-23
CVE-2024-35967
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578
- https://git.kernel.org/stable/c/2c2dc87cdebef3fe3b9d7a711a984c70e376e32e
- https://git.kernel.org/stable/c/419a0ffca7010216f0fc265b08558d7394fa0ba7
- https://git.kernel.org/stable/c/51eda36d33e43201e7a4fd35232e069b2c850b01
- https://git.kernel.org/stable/c/72473db90900da970a16ee50ad23c2c38d107d8c
- https://git.kernel.org/stable/c/7bc65d23ba20dcd7ecc094a12c181e594e5eb315
- https://git.kernel.org/stable/c/b0e30c37695b614bee69187f86eaf250e36606ce
- https://git.kernel.org/stable/c/419a0ffca7010216f0fc265b08558d7394fa0ba7
- https://git.kernel.org/stable/c/51eda36d33e43201e7a4fd35232e069b2c850b01
- https://git.kernel.org/stable/c/72473db90900da970a16ee50ad23c2c38d107d8c
- https://git.kernel.org/stable/c/7bc65d23ba20dcd7ecc094a12c181e594e5eb315
- https://git.kernel.org/stable/c/b0e30c37695b614bee69187f86eaf250e36606ce
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-35969
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
still means hlist_for_each_entry_rcu can return an item that got removed
from the list. The memory itself of such item is not freed thanks to RCU
but nothing guarantees the actual content of the memory is sane.
In particular, the reference count can be zero. This can happen if
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
timing, this can happen:
1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
2. Then, the whole ipv6_del_addr is executed for the given entry. The
reference count drops to zero and kfree_rcu is scheduled.
3. ipv6_get_ifaddr continues and tries to increments the reference count
(in6_ifa_hold).
4. The rcu is unlocked and the entry is freed.
5. The freed entry is returned.
Prevent increasing of the reference count in such case. The name
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
[ 41.506330] refcount_t: addition on 0; use-after-free.
[ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
[ 41.507413] Modules linked in: veth bridge stp llc
[ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
[ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
[ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
[ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
[ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
[ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
[ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
[ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
[ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
[ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
[ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
[ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 41.516799] Call Trace:
[ 41.517037]
- https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652
- https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70
- https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb
- https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f438bb83
- https://git.kernel.org/stable/c/7633c4da919ad51164acbf1aa322cc1a3ead6129
- https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1
- https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903
- https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb
- https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652
- https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70
- https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb
- https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f438bb83
- https://git.kernel.org/stable/c/7633c4da919ad51164acbf1aa322cc1a3ead6129
- https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1
- https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903
- https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-35970
In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.
- https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6
- https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf
- https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9
- https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e
- https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153
- https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6
- https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf
- https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9
- https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e
- https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153
Modified: 2025-09-24
CVE-2024-35971
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Handle softirqs at the end of IRQ thread to fix hang The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below: ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_with_stack call_with_stack from do_softirq do_softirq from __local_bh_enable_ip __local_bh_enable_ip from netif_rx netif_rx from ks8851_irq ks8851_irq from irq_thread_fn irq_thread_fn from irq_thread irq_thread from kthread kthread from ret_from_fork The hang happens because ks8851_irq() first locks a spinlock in ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) and with that spinlock locked, calls netif_rx(). Once the execution reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again which attempts to claim the already locked spinlock again, and the hang happens. Move the do_softirq() call outside of the spinlock protected section of ks8851_irq() by disabling BHs around the entire spinlock protected section of ks8851_irq() handler. Place local_bh_enable() outside of the spinlock protected section, so that it can trigger do_softirq() without the ks8851_par.c ks8851_lock_par() spinlock being held, and safely call ks8851_start_xmit_par() without attempting to lock the already locked spinlock. Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable() now, replace netif_rx() with __netif_rx() which is not duplicating the local_bh_disable()/local_bh_enable() calls.
- https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540
- https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b
- https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f
- https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540
- https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b
- https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f
- https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f
Modified: 2024-11-21
CVE-2024-35972
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init() If ulp = kzalloc() fails, the allocated edev will leak because it is not properly assigned and the cleanup path will not be able to free it. Fix it by assigning it properly immediately after allocation.
- https://git.kernel.org/stable/c/10a9d6a7513f93d7faffcb341af0aa42be8218fe
- https://git.kernel.org/stable/c/7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff
- https://git.kernel.org/stable/c/c60ed825530b8c0cc2b524efd39b1d696ec54004
- https://git.kernel.org/stable/c/10a9d6a7513f93d7faffcb341af0aa42be8218fe
- https://git.kernel.org/stable/c/7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff
- https://git.kernel.org/stable/c/c60ed825530b8c0cc2b524efd39b1d696ec54004
Modified: 2025-04-04
CVE-2024-35973
In the Linux kernel, the following vulnerability has been resolved: geneve: fix header validation in geneve[6]_xmit_skb syzbot is able to trigger an uninit-value in geneve_xmit() [1] Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb->protocol. If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol, pskb_inet_may_pull() does nothing at all. If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected. Add skb_vlan_inet_prepare() to perform a complete mac validation. Use this in geneve for the moment, I suspect we need to adopt this more broadly. v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types. v2,v3 - Addressed Sabrina comments on v1 and v2 [1] BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
- https://git.kernel.org/stable/c/10204df9beda4978bd1d0c2db0d8375bfb03b915
- https://git.kernel.org/stable/c/190d9efa5773f26d6f334b1b8be282c4fa13fd5e
- https://git.kernel.org/stable/c/357163fff3a6e48fe74745425a32071ec9caf852
- https://git.kernel.org/stable/c/3c1ae6de74e3d2d6333d29a2d3e13e6094596c79
- https://git.kernel.org/stable/c/43be590456e1f3566054ce78ae2dbb68cbe1a536
- https://git.kernel.org/stable/c/4a1b65d1e55d53b397cb27014208be1e04172670
- https://git.kernel.org/stable/c/d3adf11d7993518a39bd02b383cfe657ccc0023c
- https://git.kernel.org/stable/c/d8a6213d70accb403b82924a1c229e733433a5ef
- https://git.kernel.org/stable/c/10204df9beda4978bd1d0c2db0d8375bfb03b915
- https://git.kernel.org/stable/c/190d9efa5773f26d6f334b1b8be282c4fa13fd5e
- https://git.kernel.org/stable/c/357163fff3a6e48fe74745425a32071ec9caf852
- https://git.kernel.org/stable/c/3c1ae6de74e3d2d6333d29a2d3e13e6094596c79
- https://git.kernel.org/stable/c/43be590456e1f3566054ce78ae2dbb68cbe1a536
- https://git.kernel.org/stable/c/4a1b65d1e55d53b397cb27014208be1e04172670
- https://git.kernel.org/stable/c/d3adf11d7993518a39bd02b383cfe657ccc0023c
- https://git.kernel.org/stable/c/d8a6213d70accb403b82924a1c229e733433a5ef
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-35974
In the Linux kernel, the following vulnerability has been resolved: block: fix q->blkg_list corruption during disk rebind Multiple gendisk instances can allocated/added for single request queue in case of disk rebind. blkg may still stay in q->blkg_list when calling blkcg_init_disk() for rebind, then q->blkg_list becomes corrupted. Fix the list corruption issue by: - add blkg_init_queue() to initialize q->blkg_list & q->blkcg_mutex only - move calling blkg_init_queue() into blk_alloc_queue() The list corruption should be started since commit f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") which delays removing blkg from q->blkg_list into blkg_free_workfn().
- https://git.kernel.org/stable/c/083b58373463a6e5ee60ecb135269348f68ad7df
- https://git.kernel.org/stable/c/740ffad95ca8033bd6e080ed337655b13b4d38ac
- https://git.kernel.org/stable/c/858c489d81d659af17a4d11cfaad2afb42e47a76
- https://git.kernel.org/stable/c/8b8ace080319a866f5dfe9da8e665ae51d971c54
- https://git.kernel.org/stable/c/b5dae1cd0d8368b4338430ff93403df67f0b8bcc
- https://git.kernel.org/stable/c/740ffad95ca8033bd6e080ed337655b13b4d38ac
- https://git.kernel.org/stable/c/858c489d81d659af17a4d11cfaad2afb42e47a76
- https://git.kernel.org/stable/c/8b8ace080319a866f5dfe9da8e665ae51d971c54
Modified: 2025-01-14
CVE-2024-35975
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix transmit scheduler resource leak Inorder to support shaping and scheduling, Upon class creation Netdev driver allocates trasmit schedulers. The previous patch which added support for Round robin scheduling has a bug due to which driver is not freeing transmit schedulers post class deletion. This patch fixes the same.
- https://git.kernel.org/stable/c/7af5582ea67209a23e44be9a9612ba7897be1f47
- https://git.kernel.org/stable/c/b34fe77a1b18654233e4e54b334fcaeddf487100
- https://git.kernel.org/stable/c/bccb798e07f8bb8b91212fe8ed1e421685449076
- https://git.kernel.org/stable/c/7af5582ea67209a23e44be9a9612ba7897be1f47
- https://git.kernel.org/stable/c/b34fe77a1b18654233e4e54b334fcaeddf487100
- https://git.kernel.org/stable/c/bccb798e07f8bb8b91212fe8ed1e421685449076
Modified: 2025-11-04
CVE-2024-35976
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
- https://git.kernel.org/stable/c/0b45c25d60e38f5c2cb6823f886773a34323306d
- https://git.kernel.org/stable/c/237f3cf13b20db183d3706d997eedc3c49eacd44
- https://git.kernel.org/stable/c/2a523f14a3f53b46ff0e1fafd215b0bc5f6783aa
- https://git.kernel.org/stable/c/2eb979fbb2479bcd7e049f2f9978b6590dd8a0e6
- https://git.kernel.org/stable/c/a82984b3c6a7e8c7937dba6e857ddf829d149417
- https://git.kernel.org/stable/c/b143e19dc28c3211f050f7848d87d9b0a170e10c
- https://git.kernel.org/stable/c/beb99266830520e15fbc6ca8cc5a5240d76851fd
- https://git.kernel.org/stable/c/f0a068de65d5b7358e9aff792716afa9333f3922
- https://git.kernel.org/stable/c/0b45c25d60e38f5c2cb6823f886773a34323306d
- https://git.kernel.org/stable/c/237f3cf13b20db183d3706d997eedc3c49eacd44
- https://git.kernel.org/stable/c/2a523f14a3f53b46ff0e1fafd215b0bc5f6783aa
- https://git.kernel.org/stable/c/2eb979fbb2479bcd7e049f2f9978b6590dd8a0e6
- https://git.kernel.org/stable/c/a82984b3c6a7e8c7937dba6e857ddf829d149417
- https://git.kernel.org/stable/c/b143e19dc28c3211f050f7848d87d9b0a170e10c
- https://git.kernel.org/stable/c/beb99266830520e15fbc6ca8cc5a5240d76851fd
- https://git.kernel.org/stable/c/f0a068de65d5b7358e9aff792716afa9333f3922
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-35977
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_ec_uart: properly fix race condition
The cros_ec_uart_probe() function calls devm_serdev_device_open() before
it calls serdev_device_set_client_ops(). This can trigger a NULL pointer
dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
- https://git.kernel.org/stable/c/5e700b384ec13f5bcac9855cb28fcc674f1d3593
- https://git.kernel.org/stable/c/9e9bb74a93b7daa32313ccaefd0edc529d40daf8
- https://git.kernel.org/stable/c/cfd758041d8b79aa8c3f811b6bd6105379f2f702
- https://git.kernel.org/stable/c/5e700b384ec13f5bcac9855cb28fcc674f1d3593
- https://git.kernel.org/stable/c/9e9bb74a93b7daa32313ccaefd0edc529d40daf8
- https://git.kernel.org/stable/c/cfd758041d8b79aa8c3f811b6bd6105379f2f702
Modified: 2024-11-21
CVE-2024-35978
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix memory leak in hci_req_sync_complete() In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one.
- https://git.kernel.org/stable/c/45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810
- https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2
- https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8
- https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06
- https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0
- https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67
- https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76
- https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857ff0a9f5
- https://git.kernel.org/stable/c/45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810
- https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2
- https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8
- https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06
- https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0
- https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67
- https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76
- https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857ff0a9f5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-35979
In the Linux kernel, the following vulnerability has been resolved: raid1: fix use-after-free for original bio in raid1_write_request() r1_bio->bios[] is used to record new bios that will be issued to underlying disks, however, in raid1_write_request(), r1_bio->bios[] will set to the original bio temporarily. Meanwhile, if blocked rdev is set, free_r1bio() will be called causing that all r1_bio->bios[] to be freed: raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL for (i = 0; i < disks; i++) -> for each rdev in conf // first rdev is normal r1_bio->bios[0] = bio; -> set to original bio // second rdev is blocked if (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> original bio is freed Test scripts: mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \ -iodepth=128 -name=test -direct=1 echo blocked > /sys/block/md0/md/rd2/state Test result: BUG bio-264 (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e/0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 entry_SYSCALL_64_after_hwframe+0x6c/0x74 Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_request+0xadf/0x1150 md_handle_request+0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 Since that bios for underlying disks are not allocated yet, fix this problem by using mempool_free() directly to free the r1_bio.
- https://git.kernel.org/stable/c/3f28d49a328fe20926995d5fbdc92da665596268
- https://git.kernel.org/stable/c/f423f41b7679c09abb26d2bd54be5cbef23c9446
- https://git.kernel.org/stable/c/fcf3f7e2fc8a53a6140beee46ec782a4c88e4744
- https://git.kernel.org/stable/c/3f28d49a328fe20926995d5fbdc92da665596268
- https://git.kernel.org/stable/c/f423f41b7679c09abb26d2bd54be5cbef23c9446
- https://git.kernel.org/stable/c/fcf3f7e2fc8a53a6140beee46ec782a4c88e4744
Modified: 2025-01-16
CVE-2024-35980
In the Linux kernel, the following vulnerability has been resolved: arm64: tlb: Fix TLBI RANGE operand KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty pages are collected by VMM and the page table entries become write protected during live migration. Unfortunately, the operand passed to the TLBI RANGE instruction isn't correctly sorted out due to the commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()"). It leads to crash on the destination VM after live migration because TLBs aren't flushed completely and some of the dirty pages are missed. For example, I have a VM where 8GB memory is assigned, starting from 0x40000000 (1GB). Note that the host has 4KB as the base page size. In the middile of migration, kvm_tlb_flush_vmid_range() is executed to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to __kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3 and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop in the __flush_tlb_range_op() until the variable @scale underflows and becomes -9, 0xffff708000040000 is set as the operand. The operand is wrong since it's sorted out by __TLBI_VADDR_RANGE() according to invalid @scale and @num. Fix it by extending __TLBI_RANGE_NUM() to support the combination of SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from the macro, meaning the TLBs for 0x200000 pages in the above example can be flushed in one shoot with SCALE#3 and NUM#31. The macro TLBI_RANGE_MASK is dropped since no one uses it any more. The comments are also adjusted accordingly.
- https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07
- https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa
- https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685
- https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07
- https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa
- https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685
Modified: 2025-01-16
CVE-2024-35981
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device.
- https://git.kernel.org/stable/c/059a49aa2e25c58f90b50151f109dd3c4cdb3a47
- https://git.kernel.org/stable/c/28e9a64638cd16bc1ecac9ff74ffeacb9fb652de
- https://git.kernel.org/stable/c/43a71c1b4b3a6d4db857b1435d271540279fc7de
- https://git.kernel.org/stable/c/539a2b995a4ed93125cb0efae0f793b00ab2158b
- https://git.kernel.org/stable/c/059a49aa2e25c58f90b50151f109dd3c4cdb3a47
- https://git.kernel.org/stable/c/28e9a64638cd16bc1ecac9ff74ffeacb9fb652de
- https://git.kernel.org/stable/c/43a71c1b4b3a6d4db857b1435d271540279fc7de
- https://git.kernel.org/stable/c/539a2b995a4ed93125cb0efae0f793b00ab2158b
Modified: 2024-11-21
CVE-2024-35982
In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes. While this should be handled proactively when: * interface with too low MTU is added * VLAN is added * non-purgeable local mac is added * MTU of an attached interface is reduced * fragmentation setting gets disabled (which most likely requires dropping attached interfaces) not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.
- https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924
- https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259
- https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede562d91c2
- https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d
- https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f
- https://git.kernel.org/stable/c/b1f532a3b1e6d2e5559c7ace49322922637a28aa
- https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6
- https://git.kernel.org/stable/c/ca54e2671548616ad34885f90d4f26f7adb088f0
- https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924
- https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259
- https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede562d91c2
- https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d
- https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f
- https://git.kernel.org/stable/c/b1f532a3b1e6d2e5559c7ace49322922637a28aa
- https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6
- https://git.kernel.org/stable/c/ca54e2671548616ad34885f90d4f26f7adb088f0
- 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-35984
In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions]
- https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83
- https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d
- https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde
- https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620
- https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec
- https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f
- https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23
- https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85
- https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83
- https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d
- https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde
- https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620
- https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec
- https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f
- https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23
- https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85
- 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-16
CVE-2024-35985
In the Linux kernel, the following vulnerability has been resolved: sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf() It was possible to have pick_eevdf() return NULL, which then causes a NULL-deref. This turned out to be due to entity_eligible() returning falsely negative because of a s64 multiplcation overflow. Specifically, reweight_eevdf() computes the vlag without considering the limit placed upon vlag as update_entity_lag() does, and then the scaling multiplication (remember that weight is 20bit fixed point) can overflow. This then leads to the new vruntime being weird which then causes the above entity_eligible() to go side-ways and claim nothing is eligible. Thus limit the range of vlag accordingly. All this was quite rare, but fatal when it does happen.
- https://git.kernel.org/stable/c/06f27e6d7bf0abf54488259ef36bbf0e1fccb35c
- https://git.kernel.org/stable/c/1560d1f6eb6b398bddd80c16676776c0325fe5fe
- https://git.kernel.org/stable/c/470d347b14b0ecffa9b39cf8f644fa2351db3efb
- https://git.kernel.org/stable/c/06f27e6d7bf0abf54488259ef36bbf0e1fccb35c
- https://git.kernel.org/stable/c/1560d1f6eb6b398bddd80c16676776c0325fe5fe
- https://git.kernel.org/stable/c/470d347b14b0ecffa9b39cf8f644fa2351db3efb
Modified: 2025-04-04
CVE-2024-35986
In the Linux kernel, the following vulnerability has been resolved: phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered The power_supply frame-work is not really designed for there to be long living in kernel references to power_supply devices. Specifically unregistering a power_supply while some other code has a reference to it triggers a WARN in power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving the tusb1210 charger-detect code with a dangling reference, resulting in a crash the next time tusb1210_get_online() is called. Fix this by only holding the reference in tusb1210_get_online() freeing it at the end of the function. Note this still leaves a theoretical race window, but it avoids the issue when manually rmmod-ing the charger chip driver during development.
- https://git.kernel.org/stable/c/25b3498485ac281e5851700e33b97f12c9533fd8
- https://git.kernel.org/stable/c/73224a5d2180066c7fe05b4656647601ba08d588
- https://git.kernel.org/stable/c/9827caa5105fb16d1fae2e75c8d0e4662014b3ca
- https://git.kernel.org/stable/c/bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052
- https://git.kernel.org/stable/c/25b3498485ac281e5851700e33b97f12c9533fd8
- https://git.kernel.org/stable/c/73224a5d2180066c7fe05b4656647601ba08d588
- https://git.kernel.org/stable/c/9827caa5105fb16d1fae2e75c8d0e4662014b3ca
- https://git.kernel.org/stable/c/bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052
Modified: 2025-09-24
CVE-2024-35987
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix loading 64-bit NOMMU kernels past the start of RAM commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") added logic to allow using RAM below the kernel load address. However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the kernel load address. Since that range of memory corresponds to PFNs below ARCH_PFN_OFFSET, mm initialization runs off the beginning of mem_map and corrupts adjacent kernel memory. Fix this by restoring the previous behavior for NOMMU kernels.
- https://git.kernel.org/stable/c/aea702dde7e9876fb00571a2602f25130847bf0f
- https://git.kernel.org/stable/c/b008e327fa570aca210f98c817757649bae56694
- https://git.kernel.org/stable/c/ea6628e4e2353978af7e3b4ad4fdaab6149acf3d
- https://git.kernel.org/stable/c/aea702dde7e9876fb00571a2602f25130847bf0f
- https://git.kernel.org/stable/c/b008e327fa570aca210f98c817757649bae56694
- https://git.kernel.org/stable/c/ea6628e4e2353978af7e3b4ad4fdaab6149acf3d
Modified: 2025-12-17
CVE-2024-35988
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix TASK_SIZE on 64-bit NOMMU On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines.
- https://git.kernel.org/stable/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6
- https://git.kernel.org/stable/c/4201b8c8f2c32af321fb50867e68ac6c1cbed4be
- https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168b
- https://git.kernel.org/stable/c/6065e736f82c817c9a597a31ee67f0ce4628e948
- https://git.kernel.org/stable/c/a0f0dbbb1bc49fa0de18e92c36492ff6d804cdaa
- https://git.kernel.org/stable/c/efdcfa554b6eb228943ef1dd4d023c606be647d2
- https://git.kernel.org/stable/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6
- https://git.kernel.org/stable/c/4201b8c8f2c32af321fb50867e68ac6c1cbed4be
- https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168b
- https://git.kernel.org/stable/c/6065e736f82c817c9a597a31ee67f0ce4628e948
- https://git.kernel.org/stable/c/a0f0dbbb1bc49fa0de18e92c36492ff6d804cdaa
- https://git.kernel.org/stable/c/efdcfa554b6eb228943ef1dd4d023c606be647d2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-35989
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
During the removal of the idxd driver, registered offline callback is
invoked as part of the clean up process. However, on systems with only
one CPU online, no valid target is available to migrate the
perf context, resulting in a kernel oops:
BUG: unable to handle page fault for address: 000000000002a2b8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1470e1067 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
RIP: 0010:mutex_lock+0x2e/0x50
...
Call Trace:
- https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e
- https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb
- https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b
- https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be
- https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c
- https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e
- https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb
- https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b
- https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be
- https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c
Modified: 2024-11-21
CVE-2024-35990
In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan->lock or chan->vchan.lock was
not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------
[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.077953] Modules linked in:
[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98
[ 31.078102] Hardware name: xlnx,zynqmp (DT)
[ 31.078169] Workqueue: events_unbound deferred_probe_work_func
[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0
[ 31.078550] sp : ffffffc083bb2e10
[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168
[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480
[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000
[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000
[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001
[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def
[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516
[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff
[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000
[ 31.080307] Call trace:
[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120
[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac
[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c
[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684
[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0
[ 31.081139] commit_tail+0x234/0x294
[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210
[ 31.081363] drm_atomic_commit+0x100/0x140
[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384
[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c
[ 31.081725] drm_client_modeset_commit+0x34/0x5c
[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168
[ 31.081899] drm_fb_helper_set_par+0x50/0x70
[ 31.081971] fbcon_init+0x538/0xc48
[ 31.082047] visual_init+0x16c/0x23c
[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634
[ 31.082320] do_take_over_console+0x24c/0x33c
[ 31.082429] do_fbcon_takeover+0xbc/0x1b0
[ 31.082503] fbcon_fb_registered+0x2d0/0x34c
[ 31.082663] register_framebuffer+0x27c/0x38c
[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c
[ 31.082939] drm_fb_helper_initial_config+0x50/0x74
[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108
[ 31.083115] drm_client_register+0xa0/0xf4
[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc
[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0
[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0
[ 31.083616] platform_probe+0x8c/0x13c
[ 31.083713] really_probe+0x258/0x59c
[ 31.083793] __driver_probe_device+0xc4/0x224
[ 31.083878] driver_probe_device+0x70/0x1c0
[ 31.083961] __device_attach_driver+0x108/0x1e0
[ 31.084052] bus_for_each_drv+0x9c/0x100
[ 31.084125] __device_attach+0x100/0x298
[ 31.084207] device_initial_probe+0x14/0x20
[ 31.084292] bus_probe_device+0xd8/0xdc
[ 31.084368] deferred_probe_work_func+0x11c/0x180
[ 31.084451] process_one_work+0x3ac/0x988
[ 31.084643] worker_thread+0x398/0x694
[ 31.084752] kthread+0x1bc/0x1c0
[ 31.084848] ret_from_fork+0x10/0x20
[ 31.084932] irq event stamp: 64549
[ 31.084970] hardirqs last enabled at (64548): [
- https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076
- https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38
- https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11
- https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b
- https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557
- https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de
- https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076
- https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38
- https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11
- https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b
- https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557
- https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-24
CVE-2024-35991
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
drain_workqueue() cannot be called safely in a spinlocked context due to
possible task rescheduling. In the multi-task scenario, calling
queue_work() while drain_workqueue() will lead to a Call Trace as
pushing a work on a draining workqueue is not permitted in spinlocked
context.
Call Trace:
- https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098
- https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f
- https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44
- https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098
- https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f
- https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44
Modified: 2024-11-21
CVE-2024-35992
In the Linux kernel, the following vulnerability has been resolved: phy: marvell: a3700-comphy: Fix out of bounds read There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr' every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'. Make sure 'gbe_phy_init[addr]' is used when all elements of 'gbe_phy_init_fix' array are handled. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/40406dfbc060503d2e0a9e637e98493c54997b3d
- https://git.kernel.org/stable/c/610f175d2e16fb2436ba7974b990563002c20d07
- https://git.kernel.org/stable/c/976df695f579bbb2914114b4e9974fe4ed1eb813
- https://git.kernel.org/stable/c/e4308bc22b9d46cf33165c9dfaeebcf29cd56f04
- https://git.kernel.org/stable/c/40406dfbc060503d2e0a9e637e98493c54997b3d
- https://git.kernel.org/stable/c/610f175d2e16fb2436ba7974b990563002c20d07
- https://git.kernel.org/stable/c/976df695f579bbb2914114b4e9974fe4ed1eb813
- https://git.kernel.org/stable/c/e4308bc22b9d46cf33165c9dfaeebcf29cd56f04
Modified: 2025-09-24
CVE-2024-35993
In the Linux kernel, the following vulnerability has been resolved: mm: turn folio_test_hugetlb into a PageType The current folio_test_hugetlb() can be fooled by a concurrent folio split into returning true for a folio which has never belonged to hugetlbfs. This can't happen if the caller holds a refcount on it, but we have a few places (memory-failure, compaction, procfs) which do not and should not take a speculative reference. Since hugetlb pages do not use individual page mapcounts (they are always fully mapped and use the entire_mapcount field to record the number of mappings), the PageType field is available now that page_mapcount() ignores the value in this field. In compaction and with CONFIG_DEBUG_VM enabled, the current implementation can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks in the PageHuge() testing path. [willy@infradead.org: update vmcoreinfo]
- https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f
- https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32
- https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64
- https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f
- https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32
- https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64
Modified: 2025-09-24
CVE-2024-35995
In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. [ rjw: Subject and changelog edits, comment adjustments ]
- https://git.kernel.org/stable/c/01fc53be672acae37e611c80cc0b4f3939584de3
- https://git.kernel.org/stable/c/1b890ae474d19800a6be1696df7fb4d9a41676e4
- https://git.kernel.org/stable/c/2f4a4d63a193be6fd530d180bb13c3592052904c
- https://git.kernel.org/stable/c/6cb6b12b78dcd8867a3fdbb1b6d0ed1df2b208d1
- https://git.kernel.org/stable/c/01fc53be672acae37e611c80cc0b4f3939584de3
- https://git.kernel.org/stable/c/1b890ae474d19800a6be1696df7fb4d9a41676e4
- https://git.kernel.org/stable/c/2f4a4d63a193be6fd530d180bb13c3592052904c
- https://git.kernel.org/stable/c/4949affd5288b867cdf115f5b08d6166b2027f87
- https://git.kernel.org/stable/c/6cb6b12b78dcd8867a3fdbb1b6d0ed1df2b208d1
- https://git.kernel.org/stable/c/6dfd79ed04c578f1d9a9a41ba5b2015cf9f03fc3
- https://git.kernel.org/stable/c/b54c4632946ae42f2b39ed38abd909bbf78cbcc2
Modified: 2025-01-16
CVE-2024-35997
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that. More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop. Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up. Delete this unnecessary flag.
- https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1
- https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401
- https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722
- https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497
- https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22
- https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e
- https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8
- https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003
- https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1
- https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401
- https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722
- https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497
- https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22
- https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e
- https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8
- https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-10
CVE-2024-35998
In the Linux kernel, the following vulnerability has been resolved: smb3: fix lock ordering potential deadlock in cifs_sync_mid_result Coverity spotted that the cifs_sync_mid_result function could deadlock "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock" Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
- https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75
- https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc
- https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f
- https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66
- https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75
- https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc
- https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f
- https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66
Modified: 2025-04-04
CVE-2024-35999
In the Linux kernel, the following vulnerability has been resolved: smb3: missing lock when picking channel Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index. Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")
- https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e
- https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00
- https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887
- https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729
- https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e
- https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00
- https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887
- https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729
Modified: 2025-09-23
CVE-2024-36000
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix missing hugetlb_lock for resv uncharge There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held.
- https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc
- https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10
- https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2
- https://git.kernel.org/stable/c/f6c5d21db16a0910152ec8aa9d5a7aed72694505
- https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc
- https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10
- https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2
- https://git.kernel.org/stable/c/f6c5d21db16a0910152ec8aa9d5a7aed72694505
Modified: 2025-02-03
CVE-2024-36003
In the Linux kernel, the following vulnerability has been resolved:
ice: fix LAG and VF lock dependency in ice_reset_vf()
9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over
aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf().
The commit placed this lock acquisition just prior to the acquisition of
the VF configuration lock.
If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK
flag, this could deadlock with ice_vc_cfg_qs_msg() because it always
acquires the locks in the order of the VF configuration lock and then the
LAG mutex.
Lockdep reports this violation almost immediately on creating and then
removing 2 VF:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-rc6 #54 Tainted: G W O
------------------------------------------------------
kworker/60:3/6771 is trying to acquire lock:
ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]
but task is already holding lock:
ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&pf->lag_mutex){+.+.}-{3:3}:
__lock_acquire+0x4f8/0xb40
lock_acquire+0xd4/0x2d0
__mutex_lock+0x9b/0xbf0
ice_vc_cfg_qs_msg+0x45/0x690 [ice]
ice_vc_process_vf_msg+0x4f5/0x870 [ice]
__ice_clean_ctrlq+0x2b5/0x600 [ice]
ice_service_task+0x2c9/0x480 [ice]
process_one_work+0x1e9/0x4d0
worker_thread+0x1e1/0x3d0
kthread+0x104/0x140
ret_from_fork+0x31/0x50
ret_from_fork_asm+0x1b/0x30
-> #0 (&vf->cfg_lock){+.+.}-{3:3}:
check_prev_add+0xe2/0xc50
validate_chain+0x558/0x800
__lock_acquire+0x4f8/0xb40
lock_acquire+0xd4/0x2d0
__mutex_lock+0x9b/0xbf0
ice_reset_vf+0x22f/0x4d0 [ice]
ice_process_vflr_event+0x98/0xd0 [ice]
ice_service_task+0x1cc/0x480 [ice]
process_one_work+0x1e9/0x4d0
worker_thread+0x1e1/0x3d0
kthread+0x104/0x140
ret_from_fork+0x31/0x50
ret_from_fork_asm+0x1b/0x30
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&pf->lag_mutex);
lock(&vf->cfg_lock);
lock(&pf->lag_mutex);
lock(&vf->cfg_lock);
*** DEADLOCK ***
4 locks held by kworker/60:3/6771:
#0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0
#1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0
#2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]
#3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
stack backtrace:
CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54
Hardware name:
Workqueue: ice ice_service_task [ice]
Call Trace:
- https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c
- https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f
- https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6
- https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c
- https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f
- https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6
Modified: 2025-12-17
CVE-2024-36004
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
Issue reported by customer during SRIOV testing, call trace:
When both i40e and the i40iw driver are loaded, a warning
in check_flush_dependency is being triggered. This seems
to be because of the i40e driver workqueue is allocated with
the WQ_MEM_RECLAIM flag, and the i40iw one is not.
Similar error was encountered on ice too and it was fixed by
removing the flag. Do the same for i40e too.
[Feb 9 09:08] ------------[ cut here ]------------
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
flushing !WQ_MEM_RECLAIM infiniband:0x0
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
check_flush_dependency+0x10b/0x120
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
dm_region_hash dm_log dm_mod fuse
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
SE5C620.86B.02.01.0013.121520200651 12/15/2020
[ +0.000001] Workqueue: i40e i40e_service_task [i40e]
[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
0000000000000027
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
ffff94d47f620bc0
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
00000000ffff7fff
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
ffff94c5451ea180
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
ffff94c5f1330ab0
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)
knlGS:0000000000000000
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
00000000007706f0
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ +0.000001] PKRU: 55555554
[ +0.000001] Call Trace:
[ +0.000001]
- https://git.kernel.org/stable/c/09b54d29f05129b092f7c793a70b689ffb3c7b2c
- https://git.kernel.org/stable/c/152ed360cf2d273f88fc99a518b7eb868aae2939
- https://git.kernel.org/stable/c/1594dac8b1ed78f9e75c263327e198a2e5e25b0e
- https://git.kernel.org/stable/c/2cc7d150550cc981aceedf008f5459193282425c
- https://git.kernel.org/stable/c/546d0fe9d76e8229a67369f9cb61e961d99038bd
- https://git.kernel.org/stable/c/8d6105f637883c8c09825e962308c06e977de4f0
- https://git.kernel.org/stable/c/fbbb2404340dd6178e281bd427c271f7d5ec1d22
- https://git.kernel.org/stable/c/ff7431f898dd00892a545b7d0ce7adf5b926944f
- https://git.kernel.org/stable/c/09b54d29f05129b092f7c793a70b689ffb3c7b2c
- https://git.kernel.org/stable/c/152ed360cf2d273f88fc99a518b7eb868aae2939
- https://git.kernel.org/stable/c/1594dac8b1ed78f9e75c263327e198a2e5e25b0e
- https://git.kernel.org/stable/c/2cc7d150550cc981aceedf008f5459193282425c
- https://git.kernel.org/stable/c/546d0fe9d76e8229a67369f9cb61e961d99038bd
- https://git.kernel.org/stable/c/8d6105f637883c8c09825e962308c06e977de4f0
- https://git.kernel.org/stable/c/fbbb2404340dd6178e281bd427c271f7d5ec1d22
- https://git.kernel.org/stable/c/ff7431f898dd00892a545b7d0ce7adf5b926944f
- 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-36005
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: honor table dormant flag from netdev release event path
Check for table dormant flag otherwise netdev release event path tries
to unregister an already unregistered hook.
[524854.857999] ------------[ cut here ]------------
[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260
[...]
[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365
[524854.858869] Workqueue: netns cleanup_net
[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260
[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41
[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246
[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a
[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438
[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34
[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005
[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00
[524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000
[524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0
[524854.859000] Call Trace:
[524854.859006]
- https://git.kernel.org/stable/c/13ba94f6cc820fdea15efeaa17d4c722874eebf9
- https://git.kernel.org/stable/c/5c45feb3c288cf44a529e2657b36c259d86497d2
- https://git.kernel.org/stable/c/8260c980aee7d8d8a3db39faf19c391d2f898816
- https://git.kernel.org/stable/c/8e30abc9ace4f0add4cd761dfdbfaebae5632dd2
- https://git.kernel.org/stable/c/ca34c40d1c22c555fa7f4a21a1c807fea7290a0a
- https://git.kernel.org/stable/c/e4bb6da24de336a7899033a65490ed2d892efa5b
- https://git.kernel.org/stable/c/13ba94f6cc820fdea15efeaa17d4c722874eebf9
- https://git.kernel.org/stable/c/5c45feb3c288cf44a529e2657b36c259d86497d2
- https://git.kernel.org/stable/c/8260c980aee7d8d8a3db39faf19c391d2f898816
- https://git.kernel.org/stable/c/8e30abc9ace4f0add4cd761dfdbfaebae5632dd2
- https://git.kernel.org/stable/c/ca34c40d1c22c555fa7f4a21a1c807fea7290a0a
- https://git.kernel.org/stable/c/e4bb6da24de336a7899033a65490ed2d892efa5b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-36006
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
Both the function that migrates all the chunks within a region and the
function that migrates all the entries within a chunk call
list_first_entry() on the respective lists without checking that the
lists are not empty. This is incorrect usage of the API, which leads to
the following warning [1].
Fix by returning if the lists are empty as there is nothing to migrate
in this case.
[1]
WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>
Modules linked in:
CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
[...]
Call Trace:
- https://git.kernel.org/stable/c/09846c2309b150b8ce4e0ce96f058197598fc530
- https://git.kernel.org/stable/c/0b2c13b670b168e324e1cf109e67056a20fd610a
- https://git.kernel.org/stable/c/4526a56e02da3725db979358964df9cd9c567154
- https://git.kernel.org/stable/c/64435b64e43d8ee60faa46c0cd04e323e8b2a7b0
- https://git.kernel.org/stable/c/ab4ecfb627338e440ae11def004c524a00d93e40
- https://git.kernel.org/stable/c/af8b593c3dd9df82cb199be65863af004b09fd97
- https://git.kernel.org/stable/c/b377add0f0117409c418ddd6504bd682ebe0bf79
- https://git.kernel.org/stable/c/09846c2309b150b8ce4e0ce96f058197598fc530
- https://git.kernel.org/stable/c/0b2c13b670b168e324e1cf109e67056a20fd610a
- https://git.kernel.org/stable/c/4526a56e02da3725db979358964df9cd9c567154
- https://git.kernel.org/stable/c/64435b64e43d8ee60faa46c0cd04e323e8b2a7b0
- https://git.kernel.org/stable/c/ab4ecfb627338e440ae11def004c524a00d93e40
- https://git.kernel.org/stable/c/af8b593c3dd9df82cb199be65863af004b09fd97
- https://git.kernel.org/stable/c/b377add0f0117409c418ddd6504bd682ebe0bf79
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-36007
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix warning during rehash
As previously explained, the rehash delayed work migrates filters from
one region to another. This is done by iterating over all chunks (all
the filters with the same priority) in the region and in each chunk
iterating over all the filters.
When the work runs out of credits it stores the current chunk and entry
as markers in the per-work context so that it would know where to resume
the migration from the next time the work is scheduled.
Upon error, the chunk marker is reset to NULL, but without resetting the
entry markers despite being relative to it. This can result in migration
being resumed from an entry that does not belong to the chunk being
migrated. In turn, this will eventually lead to a chunk being iterated
over as if it is an entry. Because of how the two structures happen to
be defined, this does not lead to KASAN splats, but to warnings such as
[1].
Fix by creating a helper that resets all the markers and call it from
all the places the currently only reset the chunk marker. For good
measures also call it when starting a completely new rehash. Add a
warning to avoid future cases.
[1]
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
Modules linked in:
CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
[...]
Call Trace:
- https://git.kernel.org/stable/c/039992b6d2df097c65f480dcf269de3d2656f573
- https://git.kernel.org/stable/c/0b88631855026b55cad901ac28d081e0f358e596
- https://git.kernel.org/stable/c/17e9e0bbae652b9b2049e51699e93dfa60b2988d
- https://git.kernel.org/stable/c/1d76bd2a0034d0d08045c1c6adf2235d88982952
- https://git.kernel.org/stable/c/743edc8547a92b6192aa1f1b6bb78233fa21dc9b
- https://git.kernel.org/stable/c/751d352858108314efd33dddd5a9a2b6bf7d6916
- https://git.kernel.org/stable/c/e890456051fe8c57944b911defb3e6de91315861
- https://git.kernel.org/stable/c/039992b6d2df097c65f480dcf269de3d2656f573
- https://git.kernel.org/stable/c/0b88631855026b55cad901ac28d081e0f358e596
- https://git.kernel.org/stable/c/17e9e0bbae652b9b2049e51699e93dfa60b2988d
- https://git.kernel.org/stable/c/1d76bd2a0034d0d08045c1c6adf2235d88982952
- https://git.kernel.org/stable/c/743edc8547a92b6192aa1f1b6bb78233fa21dc9b
- https://git.kernel.org/stable/c/751d352858108314efd33dddd5a9a2b6bf7d6916
- https://git.kernel.org/stable/c/e890456051fe8c57944b911defb3e6de91315861
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-36008
In the Linux kernel, the following vulnerability has been resolved: ipv4: check for NULL idev in ip_route_use_hint() syzbot was able to trigger a NULL deref in fib_validate_source() in an old tree [1]. It appears the bug exists in latest trees. All calls to __in_dev_get_rcu() must be checked for a NULL result. [1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [inline] netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [inline] xdp_test_run_batch net/bpf/test_run.c:335 [inline] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199
- https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1
- https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1
- https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0
- https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4
- https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655
- https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295
- https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1
- https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1
- https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0
- https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4
- https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655
- https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-23
CVE-2024-36009
In the Linux kernel, the following vulnerability has been resolved: ax25: Fix netdev refcount issue The dev_tracker is added to ax25_cb in ax25_bind(). When the ax25 device is detaching, the dev_tracker of ax25_cb should be deallocated in ax25_kill_by_device() instead of the dev_tracker of ax25_dev. The log reported by ref_tracker is shown below: [ 80.884935] ref_tracker: reference already released. [ 80.885150] ref_tracker: allocated in: [ 80.885349] ax25_dev_device_up+0x105/0x540 [ 80.885730] ax25_device_event+0xa4/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] __dev_notify_flags+0x138/0x280 [ 80.885730] dev_change_flags+0xd7/0x180 [ 80.885730] dev_ifsioc+0x6a9/0xa30 [ 80.885730] dev_ioctl+0x4d8/0xd90 [ 80.885730] sock_do_ioctl+0x1c2/0x2d0 [ 80.885730] sock_ioctl+0x38b/0x4f0 [ 80.885730] __se_sys_ioctl+0xad/0xf0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.885730] ref_tracker: freed in: [ 80.885730] ax25_device_event+0x272/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] dev_close_many+0x272/0x370 [ 80.885730] unregister_netdevice_many_notify+0x3b5/0x1180 [ 80.885730] unregister_netdev+0xcf/0x120 [ 80.885730] sixpack_close+0x11f/0x1b0 [ 80.885730] tty_ldisc_kill+0xcb/0x190 [ 80.885730] tty_ldisc_hangup+0x338/0x3d0 [ 80.885730] __tty_hangup+0x504/0x740 [ 80.885730] tty_release+0x46e/0xd80 [ 80.885730] __fput+0x37f/0x770 [ 80.885730] __x64_sys_close+0x7b/0xb0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.893739] ------------[ cut here ]------------ [ 80.894030] WARNING: CPU: 2 PID: 140 at lib/ref_tracker.c:255 ref_tracker_free+0x47b/0x6b0 [ 80.894297] Modules linked in: [ 80.894929] CPU: 2 PID: 140 Comm: ax25_conn_rel_6 Not tainted 6.9.0-rc4-g8cd26fd90c1a #11 [ 80.895190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4 [ 80.895514] RIP: 0010:ref_tracker_free+0x47b/0x6b0 [ 80.895808] Code: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9 [ 80.896171] RSP: 0018:ffff888009edf8c0 EFLAGS: 00000286 [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000 [ 80.896502] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88800a0d6518 [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a [ 80.897212] R10: dffffc0000000000 R11: ffffed100da6511b R12: ffff88800a4a31d4 [ 80.897859] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518 [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000 [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 80.900181] CR2: 00007fd88c001d48 CR3: 000000000993e000 CR4: 00000000000006f0 ... [ 80.935774] ref_tracker: sp%d@000000000bb9df3d has 1/1 users at [ 80.935774] ax25_bind+0x424/0x4e0 [ 80.935774] __sys_bind+0x1d9/0x270 [ 80.935774] __x64_sys_bind+0x75/0x80 [ 80.935774] do_syscall_64+0xc4/0x1b0 [ 80.935774] entry_SYSCALL_64_after_hwframe+0x67/0x6f Change ax25_dev->dev_tracker to the dev_tracker of ax25_cb in order to mitigate the bug.
- https://git.kernel.org/stable/c/0d14f104027e30720582448706c7d6b43065c851
- https://git.kernel.org/stable/c/467324bcfe1a31ec65d0cf4aa59421d6b7a7d52b
- https://git.kernel.org/stable/c/4fee8fa86a15d7790268eea458b1aec69c695530
- https://git.kernel.org/stable/c/c42b073d9af4a5329b25b17390c63ab3847f30e8
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/0d14f104027e30720582448706c7d6b43065c851
- https://git.kernel.org/stable/c/467324bcfe1a31ec65d0cf4aa59421d6b7a7d52b
- https://git.kernel.org/stable/c/4fee8fa86a15d7790268eea458b1aec69c695530
- https://git.kernel.org/stable/c/c42b073d9af4a5329b25b17390c63ab3847f30e8
Modified: 2025-05-07
CVE-2024-36011
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HCI: Fix potential null-ptr-deref Fix potential null-ptr-deref in hci_le_big_sync_established_evt().
- https://git.kernel.org/stable/c/1f7ebb69c1d65732bcac2fda9d15421f76f01e81
- https://git.kernel.org/stable/c/9f3be61f55d4eedc20eedc56c0f04a5ce2b4a55a
- https://git.kernel.org/stable/c/d2706004a1b8b526592e823d7e52551b518a7941
- https://git.kernel.org/stable/c/1f7ebb69c1d65732bcac2fda9d15421f76f01e81
- https://git.kernel.org/stable/c/9f3be61f55d4eedc20eedc56c0f04a5ce2b4a55a
- https://git.kernel.org/stable/c/d2706004a1b8b526592e823d7e52551b518a7941
Modified: 2025-01-06
CVE-2024-36012
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: msft: fix slab-use-after-free in msft_do_close() Tying the msft->data lifetime to hdev by freeing it in hci_release_dev() to fix the following case: [use] msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- passed. return; mutex_lock(&msft->filter_lock); ...(4) <- used after freed. [free] msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed. ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30 kernel/locking/mutex.c:752 Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309
- https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac
- https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56
- https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940
- https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76
- https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac
- https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56
- https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940
- https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76
Modified: 2025-04-01
CVE-2024-36013
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect() Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix. Call stack summary: [use] l2cap_bredr_sig_cmd l2cap_connect ┌ mutex_lock(&conn->chan_lock); │ chan = pchan->ops->new_connection(pchan); <- alloc chan │ __l2cap_chan_add(conn, chan); │ l2cap_chan_hold(chan); │ list_add(&chan->list, &conn->chan_l); ... (1) └ mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free [free] l2cap_conn_del ┌ mutex_lock(&conn->chan_lock); │ foreach chan in conn->chan_l: ... (2) │ l2cap_chan_put(chan); │ l2cap_chan_destroy │ kfree(chan) ... (3) <- chan freed └ mutex_unlock(&conn->chan_lock); ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0 net/bluetooth/l2cap_core.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
- https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658
- https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6
- https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658
- https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6
- https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5
Modified: 2025-11-04
CVE-2024-36014
In the Linux kernel, the following vulnerability has been resolved: drm/arm/malidp: fix a possible null pointer dereference In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset.
- https://git.kernel.org/stable/c/335cc45ef2b81b68be63c698b4f867a530bdf7a5
- https://git.kernel.org/stable/c/3e54d4e95120641216dfe91a6c49f116a9f68490
- https://git.kernel.org/stable/c/565d9ad7e5a18eb69ed8b66a9e9bb3f45346520c
- https://git.kernel.org/stable/c/93f76ec1eddce60dbb5885cbc0d7df54adee4639
- https://git.kernel.org/stable/c/a1f95aede6285dba6dd036d907196f35ae3a11ea
- https://git.kernel.org/stable/c/a5fa5b40a278a3ca978fed64707bd27614adb1eb
- https://git.kernel.org/stable/c/b6cc5dd06336ed8bb3a7a1fc5aaf7d5e88bc0818
- https://git.kernel.org/stable/c/b77620730f614059db2470e8ebab3e725280fc6d
- https://git.kernel.org/stable/c/e4b52d49383306ef73fd1bd9102538beebb0fe07
- https://git.kernel.org/stable/c/335cc45ef2b81b68be63c698b4f867a530bdf7a5
- https://git.kernel.org/stable/c/3e54d4e95120641216dfe91a6c49f116a9f68490
- https://git.kernel.org/stable/c/565d9ad7e5a18eb69ed8b66a9e9bb3f45346520c
- https://git.kernel.org/stable/c/93f76ec1eddce60dbb5885cbc0d7df54adee4639
- https://git.kernel.org/stable/c/a1f95aede6285dba6dd036d907196f35ae3a11ea
- https://git.kernel.org/stable/c/a5fa5b40a278a3ca978fed64707bd27614adb1eb
- https://git.kernel.org/stable/c/b6cc5dd06336ed8bb3a7a1fc5aaf7d5e88bc0818
- https://git.kernel.org/stable/c/b77620730f614059db2470e8ebab3e725280fc6d
- https://git.kernel.org/stable/c/e4b52d49383306ef73fd1bd9102538beebb0fe07
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-36015
In the Linux kernel, the following vulnerability has been resolved: ppdev: Add an error check in register_device In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value. To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.
- https://git.kernel.org/stable/c/5d5b24edad1107a2ffa99058f20f6aeeafeb5d39
- https://git.kernel.org/stable/c/65cd017d43f4319a56747d38308b0a24cf57299e
- https://git.kernel.org/stable/c/b65d0410b879af0295d22438a4a32012786d152a
- https://git.kernel.org/stable/c/b8c6b83cc3adff3ddf403c8c7063fe6d08b2b9d9
- https://git.kernel.org/stable/c/d32caf51379a4d71db03d3d4d7c22d27cdf7f68b
- https://git.kernel.org/stable/c/df9329247dbbf00f6057e002139ab3fa529ad828
- https://git.kernel.org/stable/c/ec3468221efec6660ff656e9ebe51ced3520fc57
- https://git.kernel.org/stable/c/fbf740aeb86a4fe82ad158d26d711f2f3be79b3e
- https://git.kernel.org/stable/c/5d5b24edad1107a2ffa99058f20f6aeeafeb5d39
- https://git.kernel.org/stable/c/65cd017d43f4319a56747d38308b0a24cf57299e
- https://git.kernel.org/stable/c/b65d0410b879af0295d22438a4a32012786d152a
- https://git.kernel.org/stable/c/b8c6b83cc3adff3ddf403c8c7063fe6d08b2b9d9
- https://git.kernel.org/stable/c/d32caf51379a4d71db03d3d4d7c22d27cdf7f68b
- https://git.kernel.org/stable/c/df9329247dbbf00f6057e002139ab3fa529ad828
- https://git.kernel.org/stable/c/ec3468221efec6660ff656e9ebe51ced3520fc57
- https://git.kernel.org/stable/c/fbf740aeb86a4fe82ad158d26d711f2f3be79b3e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-36016
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.
- https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04
- https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc
- https://git.kernel.org/stable/c/47388e807f85948eefc403a8a5fdc5b406a65d5a
- https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54
- https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350
- https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5
- https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56
- https://git.kernel.org/stable/c/b890d45aaf02b564e6cae2d2a590f9649330857d
- https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b9318898ea3
- https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04
- https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc
- https://git.kernel.org/stable/c/47388e807f85948eefc403a8a5fdc5b406a65d5a
- https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54
- https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350
- https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5
- https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56
- https://git.kernel.org/stable/c/b890d45aaf02b564e6cae2d2a590f9649330857d
- https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b9318898ea3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-36017
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.
- https://git.kernel.org/stable/c/1aec77b2bb2ed1db0f5efc61c4c1ca3813307489
- https://git.kernel.org/stable/c/206003c748b88890a910ef7142d18f77be57550b
- https://git.kernel.org/stable/c/4a4b9757789a1551d2df130df23bfb3545bfa7e8
- https://git.kernel.org/stable/c/5e7ef2d88666a0212db8c38e6703864b9ce70169
- https://git.kernel.org/stable/c/6c8f44b02500c7d14b5e6618fe4ef9a0da47b3de
- https://git.kernel.org/stable/c/6e4c7193954f4faab92f6e8d88bc5565317b44e7
- https://git.kernel.org/stable/c/8ac69ff2d0d5be9734c4402de932aa3dc8549c1a
- https://git.kernel.org/stable/c/f3c1bf3054f96ddeab0621d920445bada769b40e
- https://git.kernel.org/stable/c/1aec77b2bb2ed1db0f5efc61c4c1ca3813307489
- https://git.kernel.org/stable/c/206003c748b88890a910ef7142d18f77be57550b
- https://git.kernel.org/stable/c/4a4b9757789a1551d2df130df23bfb3545bfa7e8
- https://git.kernel.org/stable/c/5e7ef2d88666a0212db8c38e6703864b9ce70169
- https://git.kernel.org/stable/c/6c8f44b02500c7d14b5e6618fe4ef9a0da47b3de
- https://git.kernel.org/stable/c/6e4c7193954f4faab92f6e8d88bc5565317b44e7
- https://git.kernel.org/stable/c/8ac69ff2d0d5be9734c4402de932aa3dc8549c1a
- https://git.kernel.org/stable/c/f3c1bf3054f96ddeab0621d920445bada769b40e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-30
CVE-2024-36018
In the Linux kernel, the following vulnerability has been resolved: nouveau/uvmm: fix addr/range calcs for remap operations dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 was causing a remap operation like the below. op_remap: prev: 0000003fffed0000 00000000000f0000 00000000a5abd18a 0000000000000000 op_remap: next: op_remap: unmap: 0000003fffed0000 0000000000100000 0 op_map: map: 0000003ffffc0000 0000000000010000 000000005b1ba33c 00000000000e0000 This was resulting in an unmap operation from 0x3fffed0000+0xf0000, 0x100000 which was corrupting the pagetables and oopsing the kernel. Fixes the prev + unmap range calcs to use start/end and map back to addr/range.
- https://git.kernel.org/stable/c/0c16020d2b69a602c8ae6a1dd2aac9a3023249d6
- https://git.kernel.org/stable/c/692a51bebf4552bdf0a79ccd68d291182a26a569
- https://git.kernel.org/stable/c/be141849ec00ef39935bf169c0f194ac70bf85ce
- https://git.kernel.org/stable/c/0c16020d2b69a602c8ae6a1dd2aac9a3023249d6
- https://git.kernel.org/stable/c/692a51bebf4552bdf0a79ccd68d291182a26a569
- https://git.kernel.org/stable/c/be141849ec00ef39935bf169c0f194ac70bf85ce
Modified: 2025-09-18
CVE-2024-36019
In the Linux kernel, the following vulnerability has been resolved: regmap: maple: Fix cache corruption in regcache_maple_drop() When keeping the upper end of a cache block entry, the entry[] array must be indexed by the offset from the base register of the block, i.e. max - mas.index. The code was indexing entry[] by only the register address, leading to an out-of-bounds access that copied some part of the kernel memory over the cache contents. This bug was not detected by the regmap KUnit test because it only tests with a block of registers starting at 0, so mas.index == 0.
- https://git.kernel.org/stable/c/00bb549d7d63a21532e76e4a334d7807a54d9f31
- https://git.kernel.org/stable/c/3af6c5ac72dc5b721058132a0a1d7779e443175e
- https://git.kernel.org/stable/c/51c4440b9d3fd7c8234e6de9170a487c03506e53
- https://git.kernel.org/stable/c/00bb549d7d63a21532e76e4a334d7807a54d9f31
- https://git.kernel.org/stable/c/3af6c5ac72dc5b721058132a0a1d7779e443175e
- https://git.kernel.org/stable/c/51c4440b9d3fd7c8234e6de9170a487c03506e53
Modified: 2025-12-23
CVE-2024-36020
In the Linux kernel, the following vulnerability has been resolved: i40e: fix vf may be used uninitialized in this function warning To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause. In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf. Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity.
- https://git.kernel.org/stable/c/06df7618f591b2dc43c59967e294d7b9fc8675b6
- https://git.kernel.org/stable/c/0dcf573f997732702917af1563aa2493dc772fc0
- https://git.kernel.org/stable/c/3e89846283f3cf7c7a8e28b342576fd7c561d2ba
- https://git.kernel.org/stable/c/951d2748a2a8242853abc3d0c153ce4bf8faad31
- https://git.kernel.org/stable/c/9dcf0fcb80f6aeb01469e3c957f8d4c97365450a
- https://git.kernel.org/stable/c/b8e82128b44fa40bf99a50b919488ef361e1683c
- https://git.kernel.org/stable/c/cc9cd02dd9e8b7764ea9effb24f4f1dd73d1b23d
- https://git.kernel.org/stable/c/f37c4eac99c258111d414d31b740437e1925b8e8
- https://git.kernel.org/stable/c/06df7618f591b2dc43c59967e294d7b9fc8675b6
- https://git.kernel.org/stable/c/0dcf573f997732702917af1563aa2493dc772fc0
- https://git.kernel.org/stable/c/3e89846283f3cf7c7a8e28b342576fd7c561d2ba
- https://git.kernel.org/stable/c/951d2748a2a8242853abc3d0c153ce4bf8faad31
- https://git.kernel.org/stable/c/9dcf0fcb80f6aeb01469e3c957f8d4c97365450a
- https://git.kernel.org/stable/c/b8e82128b44fa40bf99a50b919488ef361e1683c
- https://git.kernel.org/stable/c/cc9cd02dd9e8b7764ea9effb24f4f1dd73d1b23d
- https://git.kernel.org/stable/c/f37c4eac99c258111d414d31b740437e1925b8e8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-30
CVE-2024-36021
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during pf initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization.
- https://git.kernel.org/stable/c/1b550dae55901c2cc9075d6a7155a71b4f516e86
- https://git.kernel.org/stable/c/50b69054f455dcdb34bd6b22764c7579b270eef3
- https://git.kernel.org/stable/c/7ca0f73e5e2da3c129935b97f3a0877cce8ebdf5
- https://git.kernel.org/stable/c/93305b77ffcb042f1538ecc383505e87d95aa05a
- https://git.kernel.org/stable/c/1b550dae55901c2cc9075d6a7155a71b4f516e86
- https://git.kernel.org/stable/c/50b69054f455dcdb34bd6b22764c7579b270eef3
- https://git.kernel.org/stable/c/7ca0f73e5e2da3c129935b97f3a0877cce8ebdf5
- https://git.kernel.org/stable/c/93305b77ffcb042f1538ecc383505e87d95aa05a
Modified: 2024-11-21
CVE-2024-36023
In the Linux kernel, the following vulnerability has been resolved: Julia Lawall reported this null pointer dereference, this should fix it.
- https://git.kernel.org/stable/c/214a6c4a28c11d67044e6cf3a0ab415050d9f03a
- https://git.kernel.org/stable/c/2e2177f94c0e0bc41323d7b6975a5f4820ed347e
- https://git.kernel.org/stable/c/9bf93dcfc453fae192fe5d7874b89699e8f800ac
- https://git.kernel.org/stable/c/b972e8ac3f44f693127a2806031962d100dfc4d1
- https://git.kernel.org/stable/c/214a6c4a28c11d67044e6cf3a0ab415050d9f03a
- https://git.kernel.org/stable/c/2e2177f94c0e0bc41323d7b6975a5f4820ed347e
- https://git.kernel.org/stable/c/9bf93dcfc453fae192fe5d7874b89699e8f800ac
- https://git.kernel.org/stable/c/b972e8ac3f44f693127a2806031962d100dfc4d1
Modified: 2025-09-18
CVE-2024-36025
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() The app_reply->elem[] array is allocated earlier in this function and it has app_req.num_ports elements. Thus this > comparison needs to be >= to prevent memory corruption.
- https://git.kernel.org/stable/c/4406e4176f47177f5e51b4cc7e6a7a2ff3dbfbbd
- https://git.kernel.org/stable/c/60b87b5ecbe07d70897d35947b0bb3e76ccd1b3a
- https://git.kernel.org/stable/c/8c820f7c8e9b46238d277c575392fe9930207aab
- https://git.kernel.org/stable/c/9fc74e367be4247a5ac39bb8ec41eaa73fade510
- https://git.kernel.org/stable/c/ea8ac95c22c93acecb710209a7fd10b851afe817
- https://git.kernel.org/stable/c/4406e4176f47177f5e51b4cc7e6a7a2ff3dbfbbd
- https://git.kernel.org/stable/c/60b87b5ecbe07d70897d35947b0bb3e76ccd1b3a
- https://git.kernel.org/stable/c/8c820f7c8e9b46238d277c575392fe9930207aab
- https://git.kernel.org/stable/c/9fc74e367be4247a5ac39bb8ec41eaa73fade510
- https://git.kernel.org/stable/c/ea8ac95c22c93acecb710209a7fd10b851afe817
Modified: 2025-09-30
CVE-2024-36026
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11 While doing multiple S4 stress tests, GC/RLC/PMFW get into an invalid state resulting into hard hangs. Adding a GFX reset as workaround just before sending the MP1_UNLOAD message avoids this failure.
- https://git.kernel.org/stable/c/1e3b8874d55c0c28378beb9007494a7a9269a5f5
- https://git.kernel.org/stable/c/31729e8c21ecfd671458e02b6511eb68c2225113
- https://git.kernel.org/stable/c/7521329e54931ede9e042bbf5f4f812b5bc4a01d
- https://git.kernel.org/stable/c/bd9b94055c3deb2398ee4490c1dfdf03f53efb8f
- https://git.kernel.org/stable/c/1e3b8874d55c0c28378beb9007494a7a9269a5f5
- https://git.kernel.org/stable/c/31729e8c21ecfd671458e02b6511eb68c2225113
- https://git.kernel.org/stable/c/7521329e54931ede9e042bbf5f4f812b5bc4a01d
- https://git.kernel.org/stable/c/bd9b94055c3deb2398ee4490c1dfdf03f53efb8f
Modified: 2025-09-18
CVE-2024-36028
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()
When I did memory failure tests recently, below warning occurs:
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0
Modules linked in: mce_inject hwpoison_inject
CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:__lock_acquire+0xccb/0x1ca0
RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082
RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0
RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb
R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10
R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004
FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/2effe407f7563add41750fd7e03da4ea44b98099
- https://git.kernel.org/stable/c/52ccdde16b6540abe43b6f8d8e1e1ec90b0983af
- https://git.kernel.org/stable/c/7e0a322877416e8c648819a8e441cf8c790b2cce
- https://git.kernel.org/stable/c/9c9b32d46afab2d911897914181c488954012300
- https://git.kernel.org/stable/c/2effe407f7563add41750fd7e03da4ea44b98099
- https://git.kernel.org/stable/c/52ccdde16b6540abe43b6f8d8e1e1ec90b0983af
- https://git.kernel.org/stable/c/7e0a322877416e8c648819a8e441cf8c790b2cce
- https://git.kernel.org/stable/c/9c9b32d46afab2d911897914181c488954012300
Modified: 2025-09-30
CVE-2024-36029
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-msm: pervent access to suspended controller Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.
- https://git.kernel.org/stable/c/1200481cd6069d16ce20133bcd86f5825e26a045
- https://git.kernel.org/stable/c/56b99a52229d7f8cd1f53d899f57aa7eb4b199af
- https://git.kernel.org/stable/c/a957ea5aa3d3518067a1ba32c6127322ad348d20
- https://git.kernel.org/stable/c/f653b04a818c490b045c97834d559911479aa1c5
- https://git.kernel.org/stable/c/f8def10f73a516b771051a2f70f2f0446902cb4f
- https://git.kernel.org/stable/c/1200481cd6069d16ce20133bcd86f5825e26a045
- https://git.kernel.org/stable/c/56b99a52229d7f8cd1f53d899f57aa7eb4b199af
- https://git.kernel.org/stable/c/a957ea5aa3d3518067a1ba32c6127322ad348d20
- https://git.kernel.org/stable/c/f653b04a818c490b045c97834d559911479aa1c5
- https://git.kernel.org/stable/c/f8def10f73a516b771051a2f70f2f0446902cb4f
Modified: 2025-11-04
CVE-2024-36031
In the Linux kernel, the following vulnerability has been resolved: keys: Fix overwrite of key expiration on instantiation The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.
- https://git.kernel.org/stable/c/25777f3f4e1f371d16a594925f31e37ce07b6ec7
- https://git.kernel.org/stable/c/939a08bcd4334bad4b201e60bd0ae1f278d71d41
- https://git.kernel.org/stable/c/9da27fb65a14c18efd4473e2e82b76b53ba60252
- https://git.kernel.org/stable/c/ad2011ea787928b2accb5134f1e423b11fe80a8a
- https://git.kernel.org/stable/c/cc219cb8afbc40ec100c0de941047bb29373126a
- https://git.kernel.org/stable/c/e4519a016650e952ad9eb27937f8c447d5a4e06d
- https://git.kernel.org/stable/c/ed79b93f725cd0da39a265dc23d77add1527b9be
- https://git.kernel.org/stable/c/25777f3f4e1f371d16a594925f31e37ce07b6ec7
- https://git.kernel.org/stable/c/939a08bcd4334bad4b201e60bd0ae1f278d71d41
- https://git.kernel.org/stable/c/9da27fb65a14c18efd4473e2e82b76b53ba60252
- https://git.kernel.org/stable/c/ad2011ea787928b2accb5134f1e423b11fe80a8a
- https://git.kernel.org/stable/c/cc219cb8afbc40ec100c0de941047bb29373126a
- https://git.kernel.org/stable/c/e4519a016650e952ad9eb27937f8c447d5a4e06d
- https://git.kernel.org/stable/c/ed79b93f725cd0da39a265dc23d77add1527b9be
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-09-18
CVE-2024-36032
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix info leak when fetching fw build id Add the missing sanity checks and move the 255-byte build-id buffer off the stack to avoid leaking stack data through debugfs in case the build-info reply is malformed.
- https://git.kernel.org/stable/c/57062aa13e87b1a78a4a8f6cb5fab6ba24f5f488
- https://git.kernel.org/stable/c/62d5550ab62042dcceaf18844d0feadbb962cffe
- https://git.kernel.org/stable/c/6b63e0ef4d3ce0080395e5091fba2023f246c45a
- https://git.kernel.org/stable/c/a571044cc0a0c944e7c12237b6768aeedd7480e1
- https://git.kernel.org/stable/c/cda0d6a198e2a7ec6f176c36173a57bdd8af7af2
- https://git.kernel.org/stable/c/57062aa13e87b1a78a4a8f6cb5fab6ba24f5f488
- https://git.kernel.org/stable/c/62d5550ab62042dcceaf18844d0feadbb962cffe
- https://git.kernel.org/stable/c/6b63e0ef4d3ce0080395e5091fba2023f246c45a
- https://git.kernel.org/stable/c/a571044cc0a0c944e7c12237b6768aeedd7480e1
- https://git.kernel.org/stable/c/cda0d6a198e2a7ec6f176c36173a57bdd8af7af2
Modified: 2025-11-03
CVE-2024-36244
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: extend minimum interval restriction to entire cycle too It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals. We need one more restriction, which is that the cycle time itself must be larger than N * ETH_ZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)" branch. This way covers both conditions and scenarios. Add a selftest which illustrates the issue triggered by syzbot.
- https://git.kernel.org/stable/c/34d83c3e6e97867ae061d14eb52123404aab1cbc
- https://git.kernel.org/stable/c/91f249b01fe490fce11fbb4307952ca8cce78724
- https://git.kernel.org/stable/c/b939d1e04a90248b4cdf417b0969c270ceb992b2
- https://git.kernel.org/stable/c/fb66df20a7201e60f2b13d7f95d031b31a8831d3
- https://git.kernel.org/stable/c/91f249b01fe490fce11fbb4307952ca8cce78724
- https://git.kernel.org/stable/c/b939d1e04a90248b4cdf417b0969c270ceb992b2
- https://git.kernel.org/stable/c/fb66df20a7201e60f2b13d7f95d031b31a8831d3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-36270
In the Linux kernel, the following vulnerability has been resolved: netfilter: tproxy: bail out if IP has been disabled on the device syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this.
- https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c
- https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d
- https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6d47e8d3
- https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0
- https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03
- https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c
- https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80
- https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c
- https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d
- https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6d47e8d3
- https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0
- https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03
- https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c
- https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80
Modified: 2024-11-21
CVE-2024-36281
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules
rx_create no longer allocates a modify_hdr instance that needs to be
cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer
dereference. A leak in the rules also previously occurred since there are
now two rules populated related to status.
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 109907067 P4D 109907067 PUD 116890067 PMD 0
Oops: 0000 [#1] SMP
CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014
RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70
- https://git.kernel.org/stable/c/16d66a4fa81da07bc4ed19f4e53b87263c2f8d38
- https://git.kernel.org/stable/c/b0a15cde37a8388e57573686f650a17208ae1212
- https://git.kernel.org/stable/c/cc9ac559f2e21894c21ac5b0c85fb24a5cab266c
- https://git.kernel.org/stable/c/16d66a4fa81da07bc4ed19f4e53b87263c2f8d38
- https://git.kernel.org/stable/c/b0a15cde37a8388e57573686f650a17208ae1212
- https://git.kernel.org/stable/c/cc9ac559f2e21894c21ac5b0c85fb24a5cab266c
Modified: 2025-11-04
CVE-2024-36286
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
syzbot reported that nf_reinject() could be called without rcu_read_lock() :
WARNING: suspicious RCU usage
6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor.4/13427:
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
stack backtrace:
CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
- https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f8736f3e7a
- https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4
- https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256
- https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5
- https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9
- https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718
- https://git.kernel.org/stable/c/dc21c6cc3d6986d938efbf95de62473982c98dec
- https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab
- https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f8736f3e7a
- https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4
- https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256
- https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5
- https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9
- https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718
- https://git.kernel.org/stable/c/dc21c6cc3d6986d938efbf95de62473982c98dec
- https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-05-23
CVE-2024-36477
In the Linux kernel, the following vulnerability has been resolved: tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the maximum transfer length and the size of the transfer buffer. As such, it does not account for the 4 bytes of header that prepends the SPI data frame. This can result in out-of-bounds accesses and was confirmed with KASAN. Introduce SPI_HDRSIZE to account for the header and use to allocate the transfer buffer.
- https://git.kernel.org/stable/c/1547183852dcdfcc25878db7dd3620509217b0cd
- https://git.kernel.org/stable/c/195aba96b854dd664768f382cd1db375d8181f88
- https://git.kernel.org/stable/c/de13c56f99477b56980c7e00b09c776d16b7563d
- https://git.kernel.org/stable/c/1547183852dcdfcc25878db7dd3620509217b0cd
- https://git.kernel.org/stable/c/195aba96b854dd664768f382cd1db375d8181f88
- https://git.kernel.org/stable/c/de13c56f99477b56980c7e00b09c776d16b7563d
Modified: 2025-11-03
CVE-2024-36479
In the Linux kernel, the following vulnerability has been resolved: fpga: bridge: add owner module and take its refcount The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge. Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions.
- https://git.kernel.org/stable/c/18dc8366abb6cadcb77668b1a16434654e355d49
- https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529
- https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125
- https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b
- https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529
- https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125
- https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2024-11-21
CVE-2024-36481
In the Linux kernel, the following vulnerability has been resolved: tracing/probes: fix error check in parse_btf_field() btf_find_struct_member() might return NULL or an error via the ERR_PTR() macro. However, its caller in parse_btf_field() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack.
- https://git.kernel.org/stable/c/4ed468edfeb54c7202e559eba74c25fac6a0dad0
- https://git.kernel.org/stable/c/ad4b202da2c498fefb69e5d87f67b946e7fe1e6a
- https://git.kernel.org/stable/c/e569eb34970281438e2b48a3ef11c87459fcfbcb
- https://git.kernel.org/stable/c/4ed468edfeb54c7202e559eba74c25fac6a0dad0
- https://git.kernel.org/stable/c/ad4b202da2c498fefb69e5d87f67b946e7fe1e6a
- https://git.kernel.org/stable/c/e569eb34970281438e2b48a3ef11c87459fcfbcb
Modified: 2024-11-21
CVE-2024-36489
In the Linux kernel, the following vulnerability has been resolved: tls: fix missing memory barrier in tls_init In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot.
- https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b
- https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b
- https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302
- https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c
- https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071
- https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b
- https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b
- https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b
- https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302
- https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c
- https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071
- https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b
Modified: 2025-09-30
CVE-2024-36880
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: add missing firmware sanity checks Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.
- https://git.kernel.org/stable/c/02f05ed44b71152d5e11d29be28aed91c0489b4e
- https://git.kernel.org/stable/c/1caceadfb50432dbf6d808796cb6c34ebb6d662c
- https://git.kernel.org/stable/c/2e4edfa1e2bd821a317e7d006517dcf2f3fac68d
- https://git.kernel.org/stable/c/427281f9498ed614f9aabc80e46ec077c487da6d
- https://git.kernel.org/stable/c/ed53949cc92e28aaa3463d246942bda1fbb7f307
- https://git.kernel.org/stable/c/02f05ed44b71152d5e11d29be28aed91c0489b4e
- https://git.kernel.org/stable/c/1caceadfb50432dbf6d808796cb6c34ebb6d662c
- https://git.kernel.org/stable/c/2e4edfa1e2bd821a317e7d006517dcf2f3fac68d
- https://git.kernel.org/stable/c/427281f9498ed614f9aabc80e46ec077c487da6d
- https://git.kernel.org/stable/c/ed53949cc92e28aaa3463d246942bda1fbb7f307
Modified: 2025-04-01
CVE-2024-36881
In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: reset ptes when close() for wr-protected ones Userfaultfd unregister includes a step to remove wr-protect bits from all the relevant pgtable entries, but that only covered an explicit UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover that too. This fixes a WARN trace. The only user visible side effect is the user can observe leftover wr-protect bits even if the user close()ed on an userfaultfd when releasing the last reference of it. However hopefully that should be harmless, and nothing bad should happen even if so. This change is now more important after the recent page-table-check patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check: support userfault wr-protect entries")), as we'll do sanity check on uffd-wp bits without vma context. So it's better if we can 100% guarantee no uffd-wp bit leftovers, to make sure each report will be valid.
- https://git.kernel.org/stable/c/377f3a9a3d032a52325a5b110379a25dd1ab1931
- https://git.kernel.org/stable/c/8d8b68a5b0c9fb23d37df06bb273ead38fd5a29d
- https://git.kernel.org/stable/c/c88033efe9a391e72ba6b5df4b01d6e628f4e734
- https://git.kernel.org/stable/c/377f3a9a3d032a52325a5b110379a25dd1ab1931
- https://git.kernel.org/stable/c/8d8b68a5b0c9fb23d37df06bb273ead38fd5a29d
- https://git.kernel.org/stable/c/c88033efe9a391e72ba6b5df4b01d6e628f4e734
Modified: 2025-01-10
CVE-2024-36882
In the Linux kernel, the following vulnerability has been resolved: mm: use memalloc_nofs_save() in page_cache_ra_order() See commit f2c817bed58d ("mm: use memalloc_nofs_save in readahead path"), ensure that page_cache_ra_order() do not attempt to reclaim file-backed pages too, or it leads to a deadlock, found issue when test ext4 large folio. INFO: task DataXceiver for:7494 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace: __switch_to+0x14c/0x240 __schedule+0x82c/0xdd0 schedule+0x58/0xf0 io_schedule+0x24/0xa0 __folio_lock+0x130/0x300 migrate_pages_batch+0x378/0x918 migrate_pages+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118 try_to_compact_pages+0xb0/0x280 __alloc_pages_direct_compact+0x98/0x248 __alloc_pages+0x510/0x1110 alloc_pages+0x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0 page_cache_ra_order+0x174/0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8 filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280 ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 splice_direct_to_actor+0xbc/0x288 do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468 __arm64_sys_sendfile64+0x8c/0x148 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x4c/0x1f8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190
- https://git.kernel.org/stable/c/30153e4466647a17eebfced13eede5cbe4290e69
- https://git.kernel.org/stable/c/468971c3f4b8187f25334503b68050a0e1370147
- https://git.kernel.org/stable/c/7629ef6dda1564098aadeef38e5fbd11ee8627c4
- https://git.kernel.org/stable/c/cf6a1d16c6df3c30b03f0c6a92a2ba7f86dffb45
- https://git.kernel.org/stable/c/30153e4466647a17eebfced13eede5cbe4290e69
- https://git.kernel.org/stable/c/468971c3f4b8187f25334503b68050a0e1370147
- https://git.kernel.org/stable/c/7629ef6dda1564098aadeef38e5fbd11ee8627c4
- https://git.kernel.org/stable/c/cf6a1d16c6df3c30b03f0c6a92a2ba7f86dffb45
Modified: 2026-01-22
CVE-2024-36883
In the Linux kernel, the following vulnerability has been resolved: net: fix out-of-bounds access in ops_init net_alloc_generic is called by net_alloc, which is called without any locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access. It is possible that the array is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then used to set s.len with a larger than allocated length for the variable array. Fix it by reading max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in net_assign_generic.
- https://git.kernel.org/stable/c/0c3248bc708a7797be573214065cf908ff1f54c7
- https://git.kernel.org/stable/c/2d60ff5874aefd006717ca5e22ac1e25eac29c42
- https://git.kernel.org/stable/c/3cdc34d76c4f777579e28ad373979d36c030cfd3
- https://git.kernel.org/stable/c/7b0e64583eab8c1d896b47e5dd0bf2e7d86ec41f
- https://git.kernel.org/stable/c/9518b79bfd2fbf99fa9b7e8e36bcb1825e7ba030
- https://git.kernel.org/stable/c/a26ff37e624d12e28077e5b24d2b264f62764ad6
- https://git.kernel.org/stable/c/b6dbfd5bcc267a95a0bf1bf96af46243f96ec6cd
- https://git.kernel.org/stable/c/f4f94587e1bf87cb40ec33955a9d90148dd026ab
- https://git.kernel.org/stable/c/0c3248bc708a7797be573214065cf908ff1f54c7
- https://git.kernel.org/stable/c/2d60ff5874aefd006717ca5e22ac1e25eac29c42
- https://git.kernel.org/stable/c/3cdc34d76c4f777579e28ad373979d36c030cfd3
- https://git.kernel.org/stable/c/7b0e64583eab8c1d896b47e5dd0bf2e7d86ec41f
- https://git.kernel.org/stable/c/9518b79bfd2fbf99fa9b7e8e36bcb1825e7ba030
- https://git.kernel.org/stable/c/a26ff37e624d12e28077e5b24d2b264f62764ad6
- https://git.kernel.org/stable/c/b6dbfd5bcc267a95a0bf1bf96af46243f96ec6cd
- https://git.kernel.org/stable/c/f4f94587e1bf87cb40ec33955a9d90148dd026ab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241018-0001/
Modified: 2026-01-22
CVE-2024-36886
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
linux/net/core/skbuff.c:1183
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.0-debian-1.16.0-5 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/080cbb890286cd794f1ee788bbc5463e2deb7c2b
- https://git.kernel.org/stable/c/21ea04aad8a0839b4ec27ef1691ca480620e8e14
- https://git.kernel.org/stable/c/367766ff9e407f8a68409b7ce4dc4d5a72afeab1
- https://git.kernel.org/stable/c/66116556076f0b96bc1aa9844008c743c8c67684
- https://git.kernel.org/stable/c/93bc2d6d16f2c3178736ba6b845b30475856dc40
- https://git.kernel.org/stable/c/a0fbb26f8247e326a320e2cb4395bfb234332c90
- https://git.kernel.org/stable/c/e19ec8ab0e25bc4803d7cc91c84e84532e2781bd
- https://git.kernel.org/stable/c/ffd4917c1edb3c3ff334fce3704fbe9c39f35682
- https://git.kernel.org/stable/c/080cbb890286cd794f1ee788bbc5463e2deb7c2b
- https://git.kernel.org/stable/c/21ea04aad8a0839b4ec27ef1691ca480620e8e14
- https://git.kernel.org/stable/c/367766ff9e407f8a68409b7ce4dc4d5a72afeab1
- https://git.kernel.org/stable/c/66116556076f0b96bc1aa9844008c743c8c67684
- https://git.kernel.org/stable/c/93bc2d6d16f2c3178736ba6b845b30475856dc40
- https://git.kernel.org/stable/c/a0fbb26f8247e326a320e2cb4395bfb234332c90
- https://git.kernel.org/stable/c/e19ec8ab0e25bc4803d7cc91c84e84532e2781bd
- https://git.kernel.org/stable/c/ffd4917c1edb3c3ff334fce3704fbe9c39f35682
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241018-0002/
Modified: 2025-04-01
CVE-2024-36888
In the Linux kernel, the following vulnerability has been resolved: workqueue: Fix selection of wake_cpu in kick_pool() With cpu_possible_mask=0-63 and cpu_online_mask=0-7 the following kernel oops was observed: smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 8 CPUs Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000803 [..] Call Trace: arch_vcpu_is_preempted+0x12/0x80 select_idle_sibling+0x42/0x560 select_task_rq_fair+0x29a/0x3b0 try_to_wake_up+0x38e/0x6e0 kick_pool+0xa4/0x198 __queue_work.part.0+0x2bc/0x3a8 call_timer_fn+0x36/0x160 __run_timers+0x1e2/0x328 __run_timer_base+0x5a/0x88 run_timer_softirq+0x40/0x78 __do_softirq+0x118/0x388 irq_exit_rcu+0xc0/0xd8 do_ext_irq+0xae/0x168 ext_int_handler+0xbe/0xf0 psw_idle_exit+0x0/0xc default_idle_call+0x3c/0x110 do_idle+0xd4/0x158 cpu_startup_entry+0x40/0x48 rest_init+0xc6/0xc8 start_kernel+0x3c4/0x5e0 startup_continue+0x3c/0x50 The crash is caused by calling arch_vcpu_is_preempted() for an offline CPU. To avoid this, select the cpu with cpumask_any_and_distribute() to mask __pod_cpumask with cpu_online_mask. In case no cpu is left in the pool, skip the assignment. tj: This doesn't fully fix the bug as CPUs can still go down between picking the target CPU and the wake call. Fixing that likely requires adding cpu_online() test to either the sched or s390 arch code. However, regardless of how that is fixed, workqueue shouldn't be picking a CPU which isn't online as that would result in unpredictable and worse behavior.
- https://git.kernel.org/stable/c/57a01eafdcf78f6da34fad9ff075ed5dfdd9f420
- https://git.kernel.org/stable/c/6d559e70b3eb6623935cbe7f94c1912c1099777b
- https://git.kernel.org/stable/c/c57824d4fe07c2131f8c48687cbd5ee2be60c767
- https://git.kernel.org/stable/c/57a01eafdcf78f6da34fad9ff075ed5dfdd9f420
- https://git.kernel.org/stable/c/6d559e70b3eb6623935cbe7f94c1912c1099777b
- https://git.kernel.org/stable/c/c57824d4fe07c2131f8c48687cbd5ee2be60c767
Modified: 2025-12-17
CVE-2024-36889
In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure snd_nxt is properly initialized on connect
Christoph reported a splat hinting at a corrupted snd_una:
WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
Modules linked in:
CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
Call Trace:
- https://git.kernel.org/stable/c/39ca83ed73db9edcc6d70c0dc7a73085a4725012
- https://git.kernel.org/stable/c/592f69b41766d366dbb8ff4ef5a67c4396527bbe
- https://git.kernel.org/stable/c/99951b62bf20cec9247f633a3bea898338b9e5b4
- https://git.kernel.org/stable/c/aa0c07c1f20e05b30019bff083ec43665536f06f
- https://git.kernel.org/stable/c/dc941fec0719d0471a5902424d6b2a17df233193
- https://git.kernel.org/stable/c/fb7a0d334894206ae35f023a82cad5a290fd7386
- https://git.kernel.org/stable/c/39ca83ed73db9edcc6d70c0dc7a73085a4725012
- https://git.kernel.org/stable/c/592f69b41766d366dbb8ff4ef5a67c4396527bbe
- https://git.kernel.org/stable/c/99951b62bf20cec9247f633a3bea898338b9e5b4
- https://git.kernel.org/stable/c/aa0c07c1f20e05b30019bff083ec43665536f06f
- https://git.kernel.org/stable/c/dc941fec0719d0471a5902424d6b2a17df233193
- https://git.kernel.org/stable/c/fb7a0d334894206ae35f023a82cad5a290fd7386
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-10-29
CVE-2024-36890
In the Linux kernel, the following vulnerability has been resolved: mm/slab: make __free(kfree) accept error pointers Currently, if an automatically freed allocation is an error pointer that will lead to a crash. An example of this is in wm831x_gpio_dbg_show(). 171 char *label __free(kfree) = gpiochip_dup_line_label(chip, i); 172 if (IS_ERR(label)) { 173 dev_err(wm831x->dev, "Failed to duplicate label\n"); 174 continue; 175 } The auto clean up function should check for error pointers as well, otherwise we're going to keep hitting issues like this.
- https://git.kernel.org/stable/c/79cbe0be6c0317b215ddd8bd3e32f0afdac48543
- https://git.kernel.org/stable/c/946771c2a2b1150f9b7286feadc3aa1e15a1eb16
- https://git.kernel.org/stable/c/9f6eb0ab4f95240589ee85fd9886a944cd3645b2
- https://git.kernel.org/stable/c/ac6cf3ce9b7d12acb7b528248df5f87caa25fcdc
- https://git.kernel.org/stable/c/cd7eb8f83fcf258f71e293f7fc52a70be8ed0128
- https://git.kernel.org/stable/c/edca32f87329d6e341d2143a3b58ec254e8f6b88
- https://git.kernel.org/stable/c/79cbe0be6c0317b215ddd8bd3e32f0afdac48543
- https://git.kernel.org/stable/c/9f6eb0ab4f95240589ee85fd9886a944cd3645b2
- https://git.kernel.org/stable/c/ac6cf3ce9b7d12acb7b528248df5f87caa25fcdc
- https://git.kernel.org/stable/c/cd7eb8f83fcf258f71e293f7fc52a70be8ed0128
Modified: 2024-11-21
CVE-2024-36891
In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix mas_empty_area_rev() null pointer dereference Currently the code calls mas_start() followed by mas_data_end() if the maple state is MA_START, but mas_start() may return with the maple state node == NULL. This will lead to a null pointer dereference when checking information in the NULL node, which is done in mas_data_end(). Avoid setting the offset if there is no node by waiting until after the maple state is checked for an empty or single entry state. A user could trigger the events to cause a kernel oops by unmapping all vmas to produce an empty maple tree, then mapping a vma that would cause the scenario described above.
- https://git.kernel.org/stable/c/6c9c7c1e63b198a8b979ad963eb21410f10ccb00
- https://git.kernel.org/stable/c/883e5d542bbdddbddeba60250cb482baf3ae2415
- https://git.kernel.org/stable/c/955a923d2809803980ff574270f81510112be9cf
- https://git.kernel.org/stable/c/f3956791cf526540addd3295e4c1e0f0442486cc
- https://git.kernel.org/stable/c/6c9c7c1e63b198a8b979ad963eb21410f10ccb00
- https://git.kernel.org/stable/c/883e5d542bbdddbddeba60250cb482baf3ae2415
- https://git.kernel.org/stable/c/955a923d2809803980ff574270f81510112be9cf
- https://git.kernel.org/stable/c/f3956791cf526540addd3295e4c1e0f0442486cc
Modified: 2024-11-21
CVE-2024-36893
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Check for port partner validity before consuming it typec_register_partner() does not guarantee partner registration to always succeed. In the event of failure, port->partner is set to the error value or NULL. Given that port->partner validity is not checked, this results in the following crash: Unable to handle kernel NULL pointer dereference at virtual address xx pc : run_state_machine+0x1bc8/0x1c08 lr : run_state_machine+0x1b90/0x1c08 .. Call trace: run_state_machine+0x1bc8/0x1c08 tcpm_state_machine_work+0x94/0xe4 kthread_worker_fn+0x118/0x328 kthread+0x1d0/0x23c ret_from_fork+0x10/0x20 To prevent the crash, check for port->partner validity before derefencing it in all the call sites.
- https://git.kernel.org/stable/c/2a07e6f0ad8a6e504a3912cfe8dc859b7d0740a5
- https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637
- https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd
- https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57
- https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77
- https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637
- https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd
- https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57
- https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77
Modified: 2025-11-03
CVE-2024-36894
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following: DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock. Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it. This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
- https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19
- https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a
- https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb
- https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867
- https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14
- https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4
- https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd
- https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311
- https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19
- https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a
- https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb
- https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867
- https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14
- https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4
- https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd
- https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-18
CVE-2024-36895
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: use correct buffer size when parsing configfs lists This commit fixes uvc gadget support on 32-bit platforms. Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for reuse") introduced a helper function __uvcg_iter_item_entries() to aid with parsing lists of items on configfs attributes stores. This function is a generalization of another very similar function, which used a stack-allocated temporary buffer of fixed size for each item in the list and used the sizeof() operator to check for potential buffer overruns. The new function was changed to allocate the now variably sized temp buffer on heap, but wasn't properly updated to also check for max buffer size using the computed size instead of sizeof() operator. As a result, the maximum item size was 7 (plus null terminator) on 64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just barely enough, 3 is definitely too small for some of UVC configfs attributes. For example, dwFrameInteval, specified in 100ns units, usually has 6-digit item values, e.g. 166666 for 60fps.
- https://git.kernel.org/stable/c/650ae71c80749fc7cb8858c8049f532eaec64410
- https://git.kernel.org/stable/c/7a54e5052bde582fd0e7677334fe7a5be92e242c
- https://git.kernel.org/stable/c/a422089ce42ced73713e5032aad29a9a7cbe9528
- https://git.kernel.org/stable/c/650ae71c80749fc7cb8858c8049f532eaec64410
- https://git.kernel.org/stable/c/7a54e5052bde582fd0e7677334fe7a5be92e242c
- https://git.kernel.org/stable/c/a422089ce42ced73713e5032aad29a9a7cbe9528
Modified: 2025-04-01
CVE-2024-36896
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix access violation during port device removal Testing with KASAN and syzkaller revealed a bug in port.c:disable_store(): usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value. It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems. The same bug exists in the disable_show() routine, and it can be fixed the same way.
- https://git.kernel.org/stable/c/5f1d68ef5ddac27c6b997adccd1c339cef1e6848
- https://git.kernel.org/stable/c/6119ef6517ce501fc548154691abdaf1f954a277
- https://git.kernel.org/stable/c/63533549ff53d24daf47c443dbd43c308afc3434
- https://git.kernel.org/stable/c/a4b46d450c49f32e9d4247b421e58083fde304ce
- https://git.kernel.org/stable/c/5f1d68ef5ddac27c6b997adccd1c339cef1e6848
- https://git.kernel.org/stable/c/6119ef6517ce501fc548154691abdaf1f954a277
- https://git.kernel.org/stable/c/63533549ff53d24daf47c443dbd43c308afc3434
- https://git.kernel.org/stable/c/a4b46d450c49f32e9d4247b421e58083fde304ce
Modified: 2024-11-21
CVE-2024-36897
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Atom Integrated System Info v2_2 for DCN35 New request from KMD/VBIOS in order to support new UMA carveout model. This fixes a null dereference from accessing Ctx->dc_bios->integrated_info while it was NULL. DAL parses through the BIOS and extracts the necessary integrated_info but was missing a case for the new BIOS version 2.3.
- https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c
- https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a
- https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b
- https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60
- https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0
- https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c
- https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a
- https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b
- https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60
- https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0
Modified: 2026-04-23
CVE-2024-36898
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.
- https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5
- https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2
- https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e
- https://git.kernel.org/stable/c/c87cc32bc48b187067e089b15ab7a6a7eed5767d
- https://git.kernel.org/stable/c/ee0166b637a5e376118e9659e5b4148080f1d27e
- https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5
- https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2
- https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e
- https://git.kernel.org/stable/c/ee0166b637a5e376118e9659e5b4148080f1d27e
Modified: 2025-11-03
CVE-2024-36899
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain.
- https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da
- https://git.kernel.org/stable/c/2d008d4961b039d2edce8976289773961b7e5fb5
- https://git.kernel.org/stable/c/2dfbb920a89bdc58087672ad5325dc6c588b6860
- https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a
- https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239
- https://git.kernel.org/stable/c/d38c49f7bdf14381270736299e2ff68ec248a017
- https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da
- https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a
- https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-09-30
CVE-2024-36900
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by registering the devlink after hardware initialization.
- https://git.kernel.org/stable/c/35d92abfbad88cf947c010baf34b075e40566095
- https://git.kernel.org/stable/c/5c623fe0534806b627054da09b6f51b7b2f7b9cd
- https://git.kernel.org/stable/c/72ede790f5a03c3957487400a1b72ebce293a2e7
- https://git.kernel.org/stable/c/c98bc78ce0909ccc92005e2cb6609ec6c7942f69
- https://git.kernel.org/stable/c/35d92abfbad88cf947c010baf34b075e40566095
- https://git.kernel.org/stable/c/5c623fe0534806b627054da09b6f51b7b2f7b9cd
- https://git.kernel.org/stable/c/72ede790f5a03c3957487400a1b72ebce293a2e7
- https://git.kernel.org/stable/c/c98bc78ce0909ccc92005e2cb6609ec6c7942f69
Modified: 2024-11-21
CVE-2024-36901
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev()
returns NULL in ip6_output(). Most places in IPv6 stack
deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237
Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff
RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000
RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48
RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad
R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0
R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000
FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579
- https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a
- https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488
- https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de
- https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0
- https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155
- https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579
- https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a
- https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488
- https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de
- https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0
- https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155
Modified: 2024-11-21
CVE-2024-36902
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
syzbot is able to trigger the following crash [1],
caused by unsafe ip6_dst_idev() use.
Indeed ip6_dst_idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09
- https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95
- https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa
- https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290
- https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0
- https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747
- https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa
- https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff
- https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09
- https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95
- https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa
- https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290
- https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0
- https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747
- https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa
- https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240926-0002/
Modified: 2026-01-19
CVE-2024-36903
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix potential uninit-value access in __ip6_make_skb() As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access.
- https://git.kernel.org/stable/c/2367bf254f3a27ecc6e229afd7a8b0a1395f7be3
- https://git.kernel.org/stable/c/40e5444a3ac315b60e94d82226b73cd82145d09e
- https://git.kernel.org/stable/c/4e13d3a9c25b7080f8a619f961e943fe08c2672c
- https://git.kernel.org/stable/c/59d74c843ebf46264c7903726cf6f2673a93b07a
- https://git.kernel.org/stable/c/68c8ba16ab712eb709c6bab80ff151079d11d97a
- https://git.kernel.org/stable/c/a05c1ede50e9656f0752e523c7b54f3a3489e9a8
- https://git.kernel.org/stable/c/2367bf254f3a27ecc6e229afd7a8b0a1395f7be3
- https://git.kernel.org/stable/c/4e13d3a9c25b7080f8a619f961e943fe08c2672c
- https://git.kernel.org/stable/c/68c8ba16ab712eb709c6bab80ff151079d11d97a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2026-01-22
CVE-2024-36904
In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()
with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for
timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's
sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to
reuse the port during connect() and call sock_hold() in tcp_twsk_unique()
for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten
and sock_put() will cause underflow, triggering a real use-after-free
somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in
tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023
RIP: 0010:refcount_warn_saturate+0xe5/0x110
Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8
RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027
RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0
RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0
R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84
R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0
FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/13ed7cdf079686ccd3618335205700c03f6fb446
- https://git.kernel.org/stable/c/1796ca9c6f5bd50554214053af5f47d112818ee3
- https://git.kernel.org/stable/c/1d9cf07810c30ef7948879567d10fd1f01121d34
- https://git.kernel.org/stable/c/27b0284d8be182a81feb65581ab6a724dfd596e8
- https://git.kernel.org/stable/c/517e32ea0a8c72202d0d8aa8df50a7cd3d6fdefc
- https://git.kernel.org/stable/c/6e48faad92be13166184d21506e4e54c79c13adc
- https://git.kernel.org/stable/c/84546cc1aeeb4df3e444b18a4293c9823f974be9
- https://git.kernel.org/stable/c/f2db7230f73a80dbb179deab78f88a7947f0ab7e
- https://git.kernel.org/stable/c/13ed7cdf079686ccd3618335205700c03f6fb446
- https://git.kernel.org/stable/c/1796ca9c6f5bd50554214053af5f47d112818ee3
- https://git.kernel.org/stable/c/1d9cf07810c30ef7948879567d10fd1f01121d34
- https://git.kernel.org/stable/c/27b0284d8be182a81feb65581ab6a724dfd596e8
- https://git.kernel.org/stable/c/517e32ea0a8c72202d0d8aa8df50a7cd3d6fdefc
- https://git.kernel.org/stable/c/6e48faad92be13166184d21506e4e54c79c13adc
- https://git.kernel.org/stable/c/84546cc1aeeb4df3e444b18a4293c9823f974be9
- https://git.kernel.org/stable/c/f2db7230f73a80dbb179deab78f88a7947f0ab7e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240905-0004/
Modified: 2026-01-22
CVE-2024-36905
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by
cross-syn connections, mostly used by fuzzers.
In the following crash [1], syzbot managed to trigger a divide
by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions,
without ever calling tcp_init_transfer(),
meaning tcp_init_buffer_space() is also not called.
TCP_CLOSE
connect()
TCP_SYN_SENT
TCP_SYN_RECV
shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)
TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not
perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,
which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,
and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH
context, and must use GFP_ATOMIC allocations.
[1]
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
Call Trace:
- https://git.kernel.org/stable/c/2552c9d9440f8e7a2ed0660911ff00f25b90a0a4
- https://git.kernel.org/stable/c/34e41a031fd7523bf1cd00a2adca2370aebea270
- https://git.kernel.org/stable/c/3fe4ef0568a48369b1891395d13ac593b1ba41b1
- https://git.kernel.org/stable/c/413c33b9f3bc36fdf719690a78824db9f88a9485
- https://git.kernel.org/stable/c/94062790aedb505bdda209b10bea47b294d6394f
- https://git.kernel.org/stable/c/cbf232ba11bc86a5281b4f00e1151349ef4d45cf
- https://git.kernel.org/stable/c/ed5e279b69e007ce6c0fe82a5a534c1b19783214
- https://git.kernel.org/stable/c/f47d0d32fa94e815fdd78b8b88684873e67939f4
- https://www.openwall.com/lists/oss-security/2024/10/29/1
- http://www.openwall.com/lists/oss-security/2024/10/29/1
- http://www.openwall.com/lists/oss-security/2024/10/30/1
- http://www.openwall.com/lists/oss-security/2024/11/12/4
- http://www.openwall.com/lists/oss-security/2024/11/12/5
- http://www.openwall.com/lists/oss-security/2024/11/12/6
- https://git.kernel.org/stable/c/2552c9d9440f8e7a2ed0660911ff00f25b90a0a4
- https://git.kernel.org/stable/c/34e41a031fd7523bf1cd00a2adca2370aebea270
- https://git.kernel.org/stable/c/3fe4ef0568a48369b1891395d13ac593b1ba41b1
- https://git.kernel.org/stable/c/413c33b9f3bc36fdf719690a78824db9f88a9485
- https://git.kernel.org/stable/c/94062790aedb505bdda209b10bea47b294d6394f
- https://git.kernel.org/stable/c/cbf232ba11bc86a5281b4f00e1151349ef4d45cf
- https://git.kernel.org/stable/c/ed5e279b69e007ce6c0fe82a5a534c1b19783214
- https://git.kernel.org/stable/c/f47d0d32fa94e815fdd78b8b88684873e67939f4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240905-0005/
- https://access.redhat.com/security/cve/cve-2024-36905
- https://alas.aws.amazon.com/cve/html/CVE-2024-36905.html
- https://github.com/cisagov/vulnrichment/issues/130
- https://www.openwall.com/lists/oss-security/2024/11/12/4
Modified: 2025-09-17
CVE-2024-36906
In the Linux kernel, the following vulnerability has been resolved: ARM: 9381/1: kasan: clear stale stack poison We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")
- https://git.kernel.org/stable/c/20ac71bee028ffbae4fc14ed679b23b4d3e95726
- https://git.kernel.org/stable/c/ad702338fe423cb1e79745787090317256a98dab
- https://git.kernel.org/stable/c/b26f353786d365e658cebc9a9ace88e04fc2325e
- https://git.kernel.org/stable/c/c4238686f9093b98bd6245a348bcf059cdce23af
- https://git.kernel.org/stable/c/ee0ce7573e5083031960faf602c9db693ab5b477
- https://git.kernel.org/stable/c/20ac71bee028ffbae4fc14ed679b23b4d3e95726
- https://git.kernel.org/stable/c/ad702338fe423cb1e79745787090317256a98dab
- https://git.kernel.org/stable/c/b26f353786d365e658cebc9a9ace88e04fc2325e
- https://git.kernel.org/stable/c/c4238686f9093b98bd6245a348bcf059cdce23af
- https://git.kernel.org/stable/c/ee0ce7573e5083031960faf602c9db693ab5b477
Modified: 2025-11-03
CVE-2024-36908
In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.
- https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6
- https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e
- https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67
- https://git.kernel.org/stable/c/56a9d07f427378eeb75b917bb49c6fbea8204126
- https://git.kernel.org/stable/c/7d215e013d097ed6fc4b0ad0272c9514214dc408
- https://git.kernel.org/stable/c/aed0aac18f039dd4af13c143063754efca358cb0
- https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6
- https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e
- https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-09-30
CVE-2024-36909
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus ring buffer code could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the struct vmbus_gpadl for the ring buffers to decide whether to free the memory.
- https://git.kernel.org/stable/c/2f622008bf784a9f5dd17baa19223cc2ac30a039
- https://git.kernel.org/stable/c/30d18df6567be09c1433e81993e35e3da573ac48
- https://git.kernel.org/stable/c/82f9e213b124a7d2bb5b16ea35d570260ef467e0
- https://git.kernel.org/stable/c/a9212a4e2963a7fbe3864ba33dc551d4ad8d0abb
- https://git.kernel.org/stable/c/2f622008bf784a9f5dd17baa19223cc2ac30a039
- https://git.kernel.org/stable/c/30d18df6567be09c1433e81993e35e3da573ac48
- https://git.kernel.org/stable/c/82f9e213b124a7d2bb5b16ea35d570260ef467e0
- https://git.kernel.org/stable/c/a9212a4e2963a7fbe3864ba33dc551d4ad8d0abb
Modified: 2025-04-01
CVE-2024-36910
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus device UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.
- https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7
- https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9
- https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54
- https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23
- https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7
- https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9
- https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54
- https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23
Modified: 2025-09-30
CVE-2024-36911
In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The netvsc driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.
- https://git.kernel.org/stable/c/4aaed9dbe8acd2b6114458f0498a617283d6275b
- https://git.kernel.org/stable/c/a56fe611326332bf6b7126e5559590c57dcebad4
- https://git.kernel.org/stable/c/bbf9ac34677b57506a13682b31a2a718934c0e31
- https://git.kernel.org/stable/c/4aaed9dbe8acd2b6114458f0498a617283d6275b
- https://git.kernel.org/stable/c/a56fe611326332bf6b7126e5559590c57dcebad4
- https://git.kernel.org/stable/c/bbf9ac34677b57506a13682b31a2a718934c0e31
Modified: 2025-11-18
CVE-2024-36912
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. In order to make sure callers of vmbus_establish_gpadl() and vmbus_teardown_gpadl() don't return decrypted/shared pages to allocators, add a field in struct vmbus_gpadl to keep track of the decryption status of the buffers. This will allow the callers to know if they should free or leak the pages.
- https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81
- https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca
- https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8
- https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99
- https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81
- https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca
- https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8
- https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99
Modified: 2025-11-14
CVE-2024-36913
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. VMBus code could free decrypted pages if set_memory_encrypted()/decrypted() fails. Leak the pages if this happens.
- https://git.kernel.org/stable/c/03f5a999adba062456c8c818a683beb1b498983a
- https://git.kernel.org/stable/c/6123a4e8e25bd40cf44db14694abac00e6b664e6
- https://git.kernel.org/stable/c/7f2afcbfe4f6b6047b5f68db5067b7321e5be125
- https://git.kernel.org/stable/c/e813a0fc2e597146e9cebea61ced9c796d4e308f
- https://git.kernel.org/stable/c/03f5a999adba062456c8c818a683beb1b498983a
- https://git.kernel.org/stable/c/6123a4e8e25bd40cf44db14694abac00e6b664e6
- https://git.kernel.org/stable/c/e813a0fc2e597146e9cebea61ced9c796d4e308f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-03
CVE-2024-36914
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip on writeback when it's not applicable [WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized. [HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.
- https://git.kernel.org/stable/c/87de0a741ef6d93fcb99983138a0d89a546a043c
- https://git.kernel.org/stable/c/951a498fa993c5501994ec2df97c9297b02488c7
- https://git.kernel.org/stable/c/e9baa7110e9f3756bd5a812af376c288d9be894d
- https://git.kernel.org/stable/c/ecedd99a9369fb5cde601ae9abd58bca2739f1ae
- https://git.kernel.org/stable/c/951a498fa993c5501994ec2df97c9297b02488c7
- https://git.kernel.org/stable/c/e9baa7110e9f3756bd5a812af376c288d9be894d
- https://git.kernel.org/stable/c/ecedd99a9369fb5cde601ae9abd58bca2739f1ae
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-36915
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies
syzbot reported unsafe calls to copy_from_sockptr() [1]
Use copy_safe_from_sockptr() instead.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078
CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
- https://git.kernel.org/stable/c/0f106133203021533cb753e80d75896f4ad222f8
- https://git.kernel.org/stable/c/298609e7069ce74542a2253a39ccc9717f1d877a
- https://git.kernel.org/stable/c/29dc0ea979d433dd3c26abc8fa971550bdc05107
- https://git.kernel.org/stable/c/7a87441c9651ba37842f4809224aca13a554a26f
- https://git.kernel.org/stable/c/29dc0ea979d433dd3c26abc8fa971550bdc05107
- https://git.kernel.org/stable/c/7a87441c9651ba37842f4809224aca13a554a26f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-01-22
CVE-2024-36916
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: avoid out of bounds shift
UBSAN catches undefined behavior in blk-iocost, where sometimes
iocg->delay is shifted right by a number that is too large,
resulting in undefined behavior on some architectures.
[ 186.556576] ------------[ cut here ]------------
UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23
shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')
CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1
Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020
Call Trace:
- https://git.kernel.org/stable/c/488dc6808cb8369685f18cee81e88e7052ac153b
- https://git.kernel.org/stable/c/62accf6c1d7b433752cb3591bba8967b7a801ad5
- https://git.kernel.org/stable/c/844fc023e9f14a4fb1de5ae1eaefafd6d69c5fa1
- https://git.kernel.org/stable/c/beaa51b36012fad5a4d3c18b88a617aea7a9b96d
- https://git.kernel.org/stable/c/ce0e99cae00e3131872936713b7f55eefd53ab86
- https://git.kernel.org/stable/c/f6add0a6f78dc6360b822ca4b6f9f2f14174c8ca
- https://git.kernel.org/stable/c/488dc6808cb8369685f18cee81e88e7052ac153b
- https://git.kernel.org/stable/c/62accf6c1d7b433752cb3591bba8967b7a801ad5
- https://git.kernel.org/stable/c/844fc023e9f14a4fb1de5ae1eaefafd6d69c5fa1
- https://git.kernel.org/stable/c/beaa51b36012fad5a4d3c18b88a617aea7a9b96d
- https://git.kernel.org/stable/c/ce0e99cae00e3131872936713b7f55eefd53ab86
- https://git.kernel.org/stable/c/f6add0a6f78dc6360b822ca4b6f9f2f14174c8ca
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://security.netapp.com/advisory/ntap-20240905-0006/
Modified: 2025-09-17
CVE-2024-36917
In the Linux kernel, the following vulnerability has been resolved: block: fix overflow in blk_ioctl_discard() There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.
- https://git.kernel.org/stable/c/22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
- https://git.kernel.org/stable/c/507d526a98c355e6f3fb2c47aacad44a69784bee
- https://git.kernel.org/stable/c/8a26198186e97ee5fc4b42fde82629cff8c75cd6
- https://git.kernel.org/stable/c/e1d38cde2b7b0fbd1c48082e7a98c37d750af59b
- https://git.kernel.org/stable/c/22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
- https://git.kernel.org/stable/c/507d526a98c355e6f3fb2c47aacad44a69784bee
- https://git.kernel.org/stable/c/8a26198186e97ee5fc4b42fde82629cff8c75cd6
- https://git.kernel.org/stable/c/e1d38cde2b7b0fbd1c48082e7a98c37d750af59b
Modified: 2025-09-17
CVE-2024-36918
In the Linux kernel, the following vulnerability has been resolved: bpf: Check bloom filter map value size This patch adds a missing check to bloom filter creating, rejecting values above KMALLOC_MAX_SIZE. This brings the bloom map in line with many other map types. The lack of this protection can cause kernel crashes for value sizes that overflow int's. Such a crash was caught by syzkaller. The next patch adds more guard-rails at a lower level.
- https://git.kernel.org/stable/c/608e13706c8b6c658a0646f09ebced74ec367f7c
- https://git.kernel.org/stable/c/a8d89feba7e54e691ca7c4efc2a6264fa83f3687
- https://git.kernel.org/stable/c/c418afb9bf23e2f2b76cb819601e4a5d9dbab42d
- https://git.kernel.org/stable/c/fa6995eeb62e74b5a1480c73fb7b420c270784d3
- https://git.kernel.org/stable/c/608e13706c8b6c658a0646f09ebced74ec367f7c
- https://git.kernel.org/stable/c/a8d89feba7e54e691ca7c4efc2a6264fa83f3687
- https://git.kernel.org/stable/c/c418afb9bf23e2f2b76cb819601e4a5d9dbab42d
- https://git.kernel.org/stable/c/fa6995eeb62e74b5a1480c73fb7b420c270784d3
Modified: 2026-01-22
CVE-2024-36919
In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required. This will suppress following BUG_ON(): [ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---
- https://git.kernel.org/stable/c/1150606d47d711d5bfdf329a1a96ed7027085936
- https://git.kernel.org/stable/c/468f3e3c15076338367b0945b041105b67cf31e3
- https://git.kernel.org/stable/c/93aa5ccc44781bdfef1bf0bc4c2c292d45251312
- https://git.kernel.org/stable/c/acd370c1fb86b7302c1cbb354a7c1cd9953768eb
- https://git.kernel.org/stable/c/ad498539dda0816aadef384ec117bfea304c75c3
- https://git.kernel.org/stable/c/c214ed2a4dda35b308b0b28eed804d7ae66401f9
- https://git.kernel.org/stable/c/c885ab23206b1f1ba0731ffe7c9455c6a91db256
- https://git.kernel.org/stable/c/ea50941cd8c9f0b12f38b73d3b1bfeca660dd342
- https://git.kernel.org/stable/c/1150606d47d711d5bfdf329a1a96ed7027085936
- https://git.kernel.org/stable/c/468f3e3c15076338367b0945b041105b67cf31e3
- https://git.kernel.org/stable/c/93aa5ccc44781bdfef1bf0bc4c2c292d45251312
- https://git.kernel.org/stable/c/acd370c1fb86b7302c1cbb354a7c1cd9953768eb
- https://git.kernel.org/stable/c/ad498539dda0816aadef384ec117bfea304c75c3
- https://git.kernel.org/stable/c/c214ed2a4dda35b308b0b28eed804d7ae66401f9
- https://git.kernel.org/stable/c/c885ab23206b1f1ba0731ffe7c9455c6a91db256
- https://git.kernel.org/stable/c/ea50941cd8c9f0b12f38b73d3b1bfeca660dd342
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240905-0009/
Modified: 2025-10-01
CVE-2024-36920
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Avoid memcpy field-spanning write WARNING When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver prints this WARNING message: memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf->reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1) WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr] The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8 replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended to be a flexible length array, so the WARN is a false positive. To suppress the WARN, remove the constant number '1' from the array declaration and clarify that it has flexible length. Also, adjust the memory allocation size to match the change.
- https://git.kernel.org/stable/c/429846b4b6ce9853e0d803a2357bb2e55083adf0
- https://git.kernel.org/stable/c/4d2772324f43cf5674ac3dbe3f74a7e656396716
- https://git.kernel.org/stable/c/5f0266044dc611563539705bff0b3e1545fbb6aa
- https://git.kernel.org/stable/c/f09318244c6cafd10aca741b9c01e0a2c362d43a
- https://git.kernel.org/stable/c/429846b4b6ce9853e0d803a2357bb2e55083adf0
- https://git.kernel.org/stable/c/4d2772324f43cf5674ac3dbe3f74a7e656396716
- https://git.kernel.org/stable/c/5f0266044dc611563539705bff0b3e1545fbb6aa
- https://git.kernel.org/stable/c/f09318244c6cafd10aca741b9c01e0a2c362d43a
Modified: 2025-03-01
CVE-2024-36921
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: guard against invalid STA ID on removal Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would result in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error handling.
- https://git.kernel.org/stable/c/17f64517bf5c26af56b6c3566273aad6646c3c4f
- https://git.kernel.org/stable/c/94f80a8ec15e238b78521f20f8afaed60521a294
- https://git.kernel.org/stable/c/fab21d220017daa5fd8a3d788ff25ccfecfaae2f
- https://git.kernel.org/stable/c/17f64517bf5c26af56b6c3566273aad6646c3c4f
- https://git.kernel.org/stable/c/94f80a8ec15e238b78521f20f8afaed60521a294
- https://git.kernel.org/stable/c/fab21d220017daa5fd8a3d788ff25ccfecfaae2f
Modified: 2025-10-01
CVE-2024-36922
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.
- https://git.kernel.org/stable/c/43d07103df670484cdd26f9588eabef80f69db89
- https://git.kernel.org/stable/c/b83db8e756dec68a950ed2f056248b1704b3deaa
- https://git.kernel.org/stable/c/c2ace6300600c634553657785dfe5ea0ed688ac2
- https://git.kernel.org/stable/c/43d07103df670484cdd26f9588eabef80f69db89
- https://git.kernel.org/stable/c/b83db8e756dec68a950ed2f056248b1704b3deaa
- https://git.kernel.org/stable/c/c2ace6300600c634553657785dfe5ea0ed688ac2
Modified: 2025-01-10
CVE-2024-36924
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up() lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.
- https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd
- https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3
- https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683
- https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f
- https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd
- https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3
- https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683
- https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f
Modified: 2024-11-21
CVE-2024-36925
In the Linux kernel, the following vulnerability has been resolved: swiotlb: initialise restricted pool list_head when SWIOTLB_DYNAMIC=y Using restricted DMA pools (CONFIG_DMA_RESTRICTED_POOL=y) in conjunction with dynamic SWIOTLB (CONFIG_SWIOTLB_DYNAMIC=y) leads to the following crash when initialising the restricted pools at boot-time: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 | Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP | pc : rmem_swiotlb_device_init+0xfc/0x1ec | lr : rmem_swiotlb_device_init+0xf0/0x1ec | Call trace: | rmem_swiotlb_device_init+0xfc/0x1ec | of_reserved_mem_device_init_by_idx+0x18c/0x238 | of_dma_configure_id+0x31c/0x33c | platform_dma_configure+0x34/0x80 faddr2line reveals that the crash is in the list validation code: include/linux/list.h:83 include/linux/rculist.h:79 include/linux/rculist.h:106 kernel/dma/swiotlb.c:306 kernel/dma/swiotlb.c:1695 because add_mem_pool() is trying to list_add_rcu() to a NULL 'mem->pools'. Fix the crash by initialising the 'mem->pools' list_head in rmem_swiotlb_device_init() before calling add_mem_pool().
- https://git.kernel.org/stable/c/75961ffb5cb3e5196f19cae7683f35cc88b50800
- https://git.kernel.org/stable/c/f2a6b3ed20f2dea4cb645abc6a73c4595662adca
- https://git.kernel.org/stable/c/f62e0fefcdfe2c05ccb1aa80521a69524eea9c84
- https://git.kernel.org/stable/c/75961ffb5cb3e5196f19cae7683f35cc88b50800
- https://git.kernel.org/stable/c/f2a6b3ed20f2dea4cb645abc6a73c4595662adca
- https://git.kernel.org/stable/c/f62e0fefcdfe2c05ccb1aa80521a69524eea9c84
Modified: 2024-11-21
CVE-2024-36926
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: LPAR panics during boot up with a frozen PE
At the time of LPAR boot up, partition firmware provides Open Firmware
property ibm,dma-window for the PE. This property is provided on the PCI
bus the PE is attached to.
There are execptions where the partition firmware might not provide this
property for the PE at the time of LPAR boot up. One of the scenario is
where the firmware has frozen the PE due to some error condition. This
PE is frozen for 24 hours or unless the whole system is reinitialized.
Within this time frame, if the LPAR is booted, the frozen PE will be
presented to the LPAR but ibm,dma-window property could be missing.
Today, under these circumstances, the LPAR oopses with NULL pointer
dereference, when configuring the PCI bus the PE is attached to.
BUG: Kernel NULL pointer dereference on read at 0x000000c8
Faulting instruction address: 0xc0000000001024c0
Oops: Kernel access of bad area, sig: 7 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
Supported: Yes
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1
Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries
NIP: c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450
REGS: c0000000037db5c0 TRAP: 0300 Not tainted (6.4.0-150600.9-default)
MSR: 8000000002009033
- https://git.kernel.org/stable/c/2bed905a72485a2b79a001bd7e66c750942d2155
- https://git.kernel.org/stable/c/49a940dbdc3107fecd5e6d3063dc07128177e058
- https://git.kernel.org/stable/c/7fb5793c53f8c024e3eae9f0d44eb659aed833c4
- https://git.kernel.org/stable/c/802b13b79ab1fef66c6852fc745cf197dca0cb15
- https://git.kernel.org/stable/c/2bed905a72485a2b79a001bd7e66c750942d2155
- https://git.kernel.org/stable/c/49a940dbdc3107fecd5e6d3063dc07128177e058
- https://git.kernel.org/stable/c/7fb5793c53f8c024e3eae9f0d44eb659aed833c4
- https://git.kernel.org/stable/c/802b13b79ab1fef66c6852fc745cf197dca0cb15
Modified: 2026-01-19
CVE-2024-36927
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix uninit-value access in __ip_make_skb() KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL while __ip_make_skb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN. Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL on the socket. Also, fl4->fl4_icmp_type and fl4->fl4_icmp_code are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4_init_output(), but we should not rely on specific union layout. Initialize these explicitly in raw_sendmsg(). [1] BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 ip_finish_skb include/net/ip.h:243 [inline] ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508 raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128 ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365 raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
- https://git.kernel.org/stable/c/20d3eb00ab81462d554ac6d09691b8d9aa5a5741
- https://git.kernel.org/stable/c/55bf541e018b76b3750cb6c6ea18c46e1ac5562e
- https://git.kernel.org/stable/c/5db08343ddb1b239320612036c398e4e1bb52818
- https://git.kernel.org/stable/c/88c66f1879f322f11de34d37b2d3d87497afdcb6
- https://git.kernel.org/stable/c/f5c603ad4e6fcf42f84053e882ebe20184bb309e
- https://git.kernel.org/stable/c/fc1092f51567277509563800a3c56732070b6aa4
- https://git.kernel.org/stable/c/5db08343ddb1b239320612036c398e4e1bb52818
- https://git.kernel.org/stable/c/f5c603ad4e6fcf42f84053e882ebe20184bb309e
- https://git.kernel.org/stable/c/fc1092f51567277509563800a3c56732070b6aa4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-04-01
CVE-2024-36928
In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Fix kernel panic after setting hsuid Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL. Example: --------------------------------------------------------------------------- [ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv] [ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv] [ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt ------------------------------------------------------------------------------------------- Analysis: There is one napi structure per out_q: card->qdio.out_qs[i].napi The napi.poll functions are set during qeth_open(). Since commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() no longer call dev_close()/ dev_open(). So if qeth_free_qdio_queues() cleared card->qdio.out_qs[i].napi.poll while the network interface was UP and the card was offline, they are not set again. Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated---
- https://git.kernel.org/stable/c/10cb803aff3b11fe0bd5f274fc1c231a43e88df6
- https://git.kernel.org/stable/c/8792b557eb50b986f2496156d486d0c7c85a1524
- https://git.kernel.org/stable/c/8a2e4d37afb8500b276e5ee903dee06f50ab0494
- https://git.kernel.org/stable/c/e28dd1e1bf3ebb52cdb877fb359e8978a51576e3
- https://git.kernel.org/stable/c/eae0aec245712c52a3ce9c05575b541a9eef5282
- https://git.kernel.org/stable/c/10cb803aff3b11fe0bd5f274fc1c231a43e88df6
- https://git.kernel.org/stable/c/8792b557eb50b986f2496156d486d0c7c85a1524
- https://git.kernel.org/stable/c/8a2e4d37afb8500b276e5ee903dee06f50ab0494
- https://git.kernel.org/stable/c/e28dd1e1bf3ebb52cdb877fb359e8978a51576e3
- https://git.kernel.org/stable/c/eae0aec245712c52a3ce9c05575b541a9eef5282
Modified: 2026-01-22
CVE-2024-36929
In the Linux kernel, the following vulnerability has been resolved: net: core: reject skb_copy(_expand) for fraglist GSO skbs SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment.
- https://git.kernel.org/stable/c/989bf6fd1e1d058e73a364dce1a0c53d33373f62
- https://git.kernel.org/stable/c/aea5e2669c2863fdd8679c40ee310b3bcaa85aec
- https://git.kernel.org/stable/c/c7af99cc21923a9650533c9d77265c8dd683a533
- https://git.kernel.org/stable/c/cfe34d86ef9765c388f145039006bb79b6c81ac6
- https://git.kernel.org/stable/c/d091e579b864fa790dd6a0cd537a22c383126681
- https://git.kernel.org/stable/c/faa83a7797f06cefed86731ba4baa3b4dfdc06c1
- https://git.kernel.org/stable/c/989bf6fd1e1d058e73a364dce1a0c53d33373f62
- https://git.kernel.org/stable/c/aea5e2669c2863fdd8679c40ee310b3bcaa85aec
- https://git.kernel.org/stable/c/c7af99cc21923a9650533c9d77265c8dd683a533
- https://git.kernel.org/stable/c/cfe34d86ef9765c388f145039006bb79b6c81ac6
- https://git.kernel.org/stable/c/d091e579b864fa790dd6a0cd537a22c383126681
- https://git.kernel.org/stable/c/faa83a7797f06cefed86731ba4baa3b4dfdc06c1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://security.netapp.com/advisory/ntap-20240905-0010/
Modified: 2024-11-21
CVE-2024-36930
In the Linux kernel, the following vulnerability has been resolved: spi: fix null pointer dereference within spi_sync If spi_sync() is called with the non-empty queue and the same spi_message is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spi_finalize_current_message(). With function inlining disabled, the call stack might look like this: _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474 spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue from __spi_sync+0x204/0x248 __spi_sync from spi_sync+0x24/0x3c spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd] mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154 _regmap_raw_read from _regmap_bus_read+0x44/0x70 _regmap_bus_read from _regmap_read+0x60/0xd8 _regmap_read from regmap_read+0x3c/0x5c regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x118/0x1f4 irq_thread from kthread+0xd8/0xf4 kthread from ret_from_fork+0x14/0x28 Fix this by also setting message->complete to NULL when the transfer is complete.
- https://git.kernel.org/stable/c/2070d008cc08bff50a58f0f4d30f12d3ebf94c00
- https://git.kernel.org/stable/c/4756fa529b2f12b7cb8f21fe229b0f6f47190829
- https://git.kernel.org/stable/c/a30659f1576d2c8e62e7426232bb18b885fd951a
- https://git.kernel.org/stable/c/e005d6754e3e440257006795b687c4ad8733b493
- https://git.kernel.org/stable/c/2070d008cc08bff50a58f0f4d30f12d3ebf94c00
- https://git.kernel.org/stable/c/4756fa529b2f12b7cb8f21fe229b0f6f47190829
- https://git.kernel.org/stable/c/a30659f1576d2c8e62e7426232bb18b885fd951a
- https://git.kernel.org/stable/c/e005d6754e3e440257006795b687c4ad8733b493
Modified: 2025-01-15
CVE-2024-36931
In the Linux kernel, the following vulnerability has been resolved: s390/cio: Ensure the copied buf is NUL terminated Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from userspace to that buffer. Later, we use scanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using scanf. Fix this issue by using memdup_user_nul instead.
- https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65
- https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c
- https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2
- https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5
- https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784
- https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65
- https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c
- https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2
- https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5
- https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784
Modified: 2026-01-22
CVE-2024-36933
In the Linux kernel, the following vulnerability has been resolved: nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers. nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol. and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_len There are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header. It seems nsh_gso_segment() has never worked with outer headers so far. At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header. To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly. [0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---
- https://git.kernel.org/stable/c/29a07f2ee4d273760c2acbfc756e29eccd82470a
- https://git.kernel.org/stable/c/37ed6f244ec5bda2e90b085084e322ea55d0aaa2
- https://git.kernel.org/stable/c/46134031c20fd313d03b90169d64b2e05ca6b65c
- https://git.kernel.org/stable/c/4b911a9690d72641879ea6d13cce1de31d346d79
- https://git.kernel.org/stable/c/5a4603fbc285752d19e4b415466db18ef3617e4a
- https://git.kernel.org/stable/c/696d18bb59727a2e0526c0802a812620be1c9340
- https://git.kernel.org/stable/c/a7c2c3c1caabcb4a3d6c47284c397507aaf54fe9
- https://git.kernel.org/stable/c/bbccf0caef2fa917d6d0692385a06ce3c262a216
- https://git.kernel.org/stable/c/29a07f2ee4d273760c2acbfc756e29eccd82470a
- https://git.kernel.org/stable/c/37ed6f244ec5bda2e90b085084e322ea55d0aaa2
- https://git.kernel.org/stable/c/46134031c20fd313d03b90169d64b2e05ca6b65c
- https://git.kernel.org/stable/c/4b911a9690d72641879ea6d13cce1de31d346d79
- https://git.kernel.org/stable/c/5a4603fbc285752d19e4b415466db18ef3617e4a
- https://git.kernel.org/stable/c/696d18bb59727a2e0526c0802a812620be1c9340
- https://git.kernel.org/stable/c/a7c2c3c1caabcb4a3d6c47284c397507aaf54fe9
- https://git.kernel.org/stable/c/bbccf0caef2fa917d6d0692385a06ce3c262a216
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240912-0006/
Modified: 2026-01-22
CVE-2024-36934
In the Linux kernel, the following vulnerability has been resolved: bna: ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.
- https://git.kernel.org/stable/c/06cb37e2ba6441888f24566a997481d4197b4e32
- https://git.kernel.org/stable/c/0f560240b4cc25d3de527deb257cdf072c0102a9
- https://git.kernel.org/stable/c/1518b2b498a0109eb6b15755169d3b6607356b35
- https://git.kernel.org/stable/c/6f0f19b79c085cc891c418b768f26f7004bd51a4
- https://git.kernel.org/stable/c/80578ec10335bc15ac35fd1703c22aab34e39fdd
- https://git.kernel.org/stable/c/8c34096c7fdf272fd4c0c37fe411cd2e3ed0ee9f
- https://git.kernel.org/stable/c/bd502ba81cd1d515deddad7dbc6b812b14b97147
- https://git.kernel.org/stable/c/e19478763154674c084defc62ae0d64d79657f91
- https://git.kernel.org/stable/c/06cb37e2ba6441888f24566a997481d4197b4e32
- https://git.kernel.org/stable/c/0f560240b4cc25d3de527deb257cdf072c0102a9
- https://git.kernel.org/stable/c/1518b2b498a0109eb6b15755169d3b6607356b35
- https://git.kernel.org/stable/c/6f0f19b79c085cc891c418b768f26f7004bd51a4
- https://git.kernel.org/stable/c/80578ec10335bc15ac35fd1703c22aab34e39fdd
- https://git.kernel.org/stable/c/8c34096c7fdf272fd4c0c37fe411cd2e3ed0ee9f
- https://git.kernel.org/stable/c/bd502ba81cd1d515deddad7dbc6b812b14b97147
- https://git.kernel.org/stable/c/e19478763154674c084defc62ae0d64d79657f91
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240912-0007/
Modified: 2025-09-17
CVE-2024-36937
In the Linux kernel, the following vulnerability has been resolved: xdp: use flags field to disambiguate broadcast redirect When redirecting a packet using XDP, the bpf_redirect_map() helper will set up the redirect destination information in struct bpf_redirect_info (using the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect() function will read this information after the XDP program returns and pass the frame on to the right redirect destination. When using the BPF_F_BROADCAST flag to do multicast redirect to a whole map, __bpf_xdp_redirect_map() sets the 'map' pointer in struct bpf_redirect_info to point to the destination map to be broadcast. And xdp_do_redirect() reacts to the value of this map pointer to decide whether it's dealing with a broadcast or a single-value redirect. However, if the destination map is being destroyed before xdp_do_redirect() is called, the map pointer will be cleared out (by bpf_clear_redirect_map()) without waiting for any XDP programs to stop running. This causes xdp_do_redirect() to think that the redirect was to a single target, but the target pointer is also NULL (since broadcast redirects don't have a single target), so this causes a crash when a NULL pointer is passed to dev_map_enqueue(). To fix this, change xdp_do_redirect() to react directly to the presence of the BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info to disambiguate between a single-target and a broadcast redirect. And only read the 'map' pointer if the broadcast flag is set, aborting if that has been cleared out in the meantime. This prevents the crash, while keeping the atomic (cmpxchg-based) clearing of the map pointer itself, and without adding any more checks in the non-broadcast fast path.
- https://git.kernel.org/stable/c/12481f30128fbebc2eeb55eb2d56390fdfa30c5e
- https://git.kernel.org/stable/c/272bfb019f3cc018f654b992115774e77b4f3ffc
- https://git.kernel.org/stable/c/5bcf0dcbf9066348058b88a510c57f70f384c92c
- https://git.kernel.org/stable/c/6fd81f9d333e7b3532036577b1beb74ba1323553
- https://git.kernel.org/stable/c/e22e25820fa04ea5eaac4ef7ee200e9923f466a4
- https://git.kernel.org/stable/c/12481f30128fbebc2eeb55eb2d56390fdfa30c5e
- https://git.kernel.org/stable/c/272bfb019f3cc018f654b992115774e77b4f3ffc
- https://git.kernel.org/stable/c/5bcf0dcbf9066348058b88a510c57f70f384c92c
- https://git.kernel.org/stable/c/6fd81f9d333e7b3532036577b1beb74ba1323553
- https://git.kernel.org/stable/c/e22e25820fa04ea5eaac4ef7ee200e9923f466a4
Modified: 2024-11-21
CVE-2024-36938
In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);". To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend.
- https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27
- https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d
- https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365
- https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80
- https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87
- https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973
- https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27
- https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d
- https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365
- https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80
- https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87
- https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973
Modified: 2025-12-17
CVE-2024-36939
In the Linux kernel, the following vulnerability has been resolved:
nfs: Handle error of rpc_proc_register() in nfs_net_init().
syzkaller reported a warning [0] triggered while destroying immature
netns.
rpc_proc_register() was called in init_nfs_fs(), but its error
has been ignored since at least the initial commit 1da177e4c3f4
("Linux-2.6.12-rc2").
Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs
in net namespaces") converted the procfs to per-netns and made
the problem more visible.
Even when rpc_proc_register() fails, nfs_net_init() could succeed,
and thus nfs_net_exit() will be called while destroying the netns.
Then, remove_proc_entry() will be called for non-existing proc
directory and trigger the warning below.
Let's handle the error of rpc_proc_register() properly in nfs_net_init().
[0]:
name 'nfs'
WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Modules linked in:
CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb
RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c
RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc
R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8
FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/24457f1be29f1e7042e50a7749f5c2dde8c433c8
- https://git.kernel.org/stable/c/8a1f89c98dcc542dd6d287e573523714702e0f9c
- https://git.kernel.org/stable/c/8ae63bd858691bee0e2a92571f2fbb36a4d86d65
- https://git.kernel.org/stable/c/9909dde2e53a19585212c32fe3eda482b5faaaa3
- https://git.kernel.org/stable/c/b33ca18c3a1190208dfd569c4fa8a2f93084709f
- https://git.kernel.org/stable/c/d4891d817350c67392d4731536945f3809a2a0ba
- https://git.kernel.org/stable/c/ea6ce93327bd2c8a0c6cf6f2f0e800f3b778f021
- https://git.kernel.org/stable/c/24457f1be29f1e7042e50a7749f5c2dde8c433c8
- https://git.kernel.org/stable/c/8a1f89c98dcc542dd6d287e573523714702e0f9c
- https://git.kernel.org/stable/c/8ae63bd858691bee0e2a92571f2fbb36a4d86d65
- https://git.kernel.org/stable/c/9909dde2e53a19585212c32fe3eda482b5faaaa3
- https://git.kernel.org/stable/c/b33ca18c3a1190208dfd569c4fa8a2f93084709f
- https://git.kernel.org/stable/c/d4891d817350c67392d4731536945f3809a2a0ba
- https://git.kernel.org/stable/c/ea6ce93327bd2c8a0c6cf6f2f0e800f3b778f021
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-01-10
CVE-2024-36940
In the Linux kernel, the following vulnerability has been resolved: pinctrl: core: delete incorrect free in pinctrl_enable() The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free. The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well.
- https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068
- https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca
- https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79
- https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c
- https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d
- https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e
- https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd
- https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba
- https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068
- https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca
- https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79
- https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c
- https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d
- https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e
- https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd
- https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-05-20
CVE-2024-36941
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: don't free NULL coalescing rule If the parsing fails, we can dereference a NULL pointer here.
- https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d
- https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a
- https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307
- https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7
- https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457
- https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4
- https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f
- https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383
- https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d
- https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a
- https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307
- https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7
- https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457
- https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4
- https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f
- https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-17
CVE-2024-36945
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix neighbour and rtable leak in smc_ib_find_route() In smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable resolved by ip_route_output_flow() are not released or put before return. It may cause the refcount leak, so fix it.
- https://git.kernel.org/stable/c/2ddc0dd7fec86ee53b8928a5cca5fbddd4fc7c06
- https://git.kernel.org/stable/c/5df93c029a907b0ff5a4eeadd77ba06ff0a277d2
- https://git.kernel.org/stable/c/d5a466ab6e78d6f2e0f64435f1e17246c8e941ff
- https://git.kernel.org/stable/c/da91e447d06dc649fcf46e59122e7bf8f0b2e0db
- https://git.kernel.org/stable/c/2ddc0dd7fec86ee53b8928a5cca5fbddd4fc7c06
- https://git.kernel.org/stable/c/5df93c029a907b0ff5a4eeadd77ba06ff0a277d2
- https://git.kernel.org/stable/c/d5a466ab6e78d6f2e0f64435f1e17246c8e941ff
- https://git.kernel.org/stable/c/da91e447d06dc649fcf46e59122e7bf8f0b2e0db
- https://security.netapp.com/advisory/ntap-20250404-0006/
Modified: 2026-01-22
CVE-2024-36946
In the Linux kernel, the following vulnerability has been resolved: phonet: fix rtm_phonet_notify() skb allocation fill_route() stores three components in the skb: - struct rtmsg - RTA_DST (u8) - RTA_OIF (u32) Therefore, rtm_phonet_notify() should use NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4)
- https://git.kernel.org/stable/c/4ff334cade9dae50e4be387f71e94fae634aa9b4
- https://git.kernel.org/stable/c/728a83160f98ee6b60df0d890141b9b7240182fe
- https://git.kernel.org/stable/c/9a77226440008cf04ba68faf641a2d50f4998137
- https://git.kernel.org/stable/c/d8cac8568618dcb8a51af3db1103e8d4cc4aeea7
- https://git.kernel.org/stable/c/dc6beac059f0331de97155a89d84058d4a9e49c7
- https://git.kernel.org/stable/c/ec1f71c05caeba0f814df77e0f511d8b4618623a
- https://git.kernel.org/stable/c/ee9e39a6cb3ca2a3d35b4ae25547ee3526a44d00
- https://git.kernel.org/stable/c/f085e02f0a32f6dfcfabc6535c9c4a1707cef86b
- https://git.kernel.org/stable/c/4ff334cade9dae50e4be387f71e94fae634aa9b4
- https://git.kernel.org/stable/c/728a83160f98ee6b60df0d890141b9b7240182fe
- https://git.kernel.org/stable/c/9a77226440008cf04ba68faf641a2d50f4998137
- https://git.kernel.org/stable/c/d8cac8568618dcb8a51af3db1103e8d4cc4aeea7
- https://git.kernel.org/stable/c/dc6beac059f0331de97155a89d84058d4a9e49c7
- https://git.kernel.org/stable/c/ec1f71c05caeba0f814df77e0f511d8b4618623a
- https://git.kernel.org/stable/c/ee9e39a6cb3ca2a3d35b4ae25547ee3526a44d00
- https://git.kernel.org/stable/c/f085e02f0a32f6dfcfabc6535c9c4a1707cef86b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241004-0002/
Modified: 2025-09-17
CVE-2024-36947
In the Linux kernel, the following vulnerability has been resolved:
qibfs: fix dentry leak
simple_recursive_removal() drops the pinning references to all positives
in subtree. For the cases when its argument has been kept alive by
the pinning alone that's exactly the right thing to do, but here
the argument comes from dcache lookup, that needs to be balanced by
explicit dput().
Fucked-up-by: Al Viro
- https://git.kernel.org/stable/c/02ee394a5d899d9bd2f0759382e9481cab6166f8
- https://git.kernel.org/stable/c/24dd9b08df718f20ccf2dd1519909fefd8c233ee
- https://git.kernel.org/stable/c/aa23317d0268b309bb3f0801ddd0d61813ff5afb
- https://git.kernel.org/stable/c/bd8f78c71defbcb7a9ed331e7f287507df972b00
- https://git.kernel.org/stable/c/db71ca93259dd1078bcfea3afafde2143cfc2da7
- https://git.kernel.org/stable/c/02ee394a5d899d9bd2f0759382e9481cab6166f8
- https://git.kernel.org/stable/c/24dd9b08df718f20ccf2dd1519909fefd8c233ee
- https://git.kernel.org/stable/c/aa23317d0268b309bb3f0801ddd0d61813ff5afb
- https://git.kernel.org/stable/c/bd8f78c71defbcb7a9ed331e7f287507df972b00
- https://git.kernel.org/stable/c/db71ca93259dd1078bcfea3afafde2143cfc2da7
Modified: 2025-10-01
CVE-2024-36949
In the Linux kernel, the following vulnerability has been resolved: amd/amdkfd: sync all devices to wait all processes being evicted If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.
- https://git.kernel.org/stable/c/b6f6626528fe724b512c34f3fb5946c36a135f58
- https://git.kernel.org/stable/c/d06af584be5a769d124b7302b32a033e9559761d
- https://git.kernel.org/stable/c/ed28ef3840bbf93a64376ea7814ce39f86352e14
- https://git.kernel.org/stable/c/b6f6626528fe724b512c34f3fb5946c36a135f58
- https://git.kernel.org/stable/c/d06af584be5a769d124b7302b32a033e9559761d
- https://git.kernel.org/stable/c/ed28ef3840bbf93a64376ea7814ce39f86352e14
Modified: 2025-12-17
CVE-2024-36950
In the Linux kernel, the following vulnerability has been resolved: firewire: ohci: mask bus reset interrupts between ISR and bottom half In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt. Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them. irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally. This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization. irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired. As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed.
- https://git.kernel.org/stable/c/31279bbca40d2f40cb3bbb6d538ec9620a645dec
- https://git.kernel.org/stable/c/4f9cc355c328fc4f41cbd9c4cd58b235184fa420
- https://git.kernel.org/stable/c/5982887de60c1b84f9c0ca07c835814d07fd1da0
- https://git.kernel.org/stable/c/6fafe3661712b143d9c69a7322294bd53f559d5d
- https://git.kernel.org/stable/c/752e3c53de0fa3b7d817a83050b6699b8e9c6ec9
- https://git.kernel.org/stable/c/8643332aac0576581cfdf01798ea3e4e0d624b61
- https://git.kernel.org/stable/c/b3948c69d60279fce5b2eeda92a07d66296c8130
- https://git.kernel.org/stable/c/fa273f312334246c909475c5868e6daab889cc8c
- https://git.kernel.org/stable/c/31279bbca40d2f40cb3bbb6d538ec9620a645dec
- https://git.kernel.org/stable/c/4f9cc355c328fc4f41cbd9c4cd58b235184fa420
- https://git.kernel.org/stable/c/5982887de60c1b84f9c0ca07c835814d07fd1da0
- https://git.kernel.org/stable/c/6fafe3661712b143d9c69a7322294bd53f559d5d
- https://git.kernel.org/stable/c/752e3c53de0fa3b7d817a83050b6699b8e9c6ec9
- https://git.kernel.org/stable/c/8643332aac0576581cfdf01798ea3e4e0d624b61
- https://git.kernel.org/stable/c/b3948c69d60279fce5b2eeda92a07d66296c8130
- https://git.kernel.org/stable/c/fa273f312334246c909475c5868e6daab889cc8c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-10-01
CVE-2024-36951
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: range check cp bad op exception interrupts Due to a CP interrupt bug, bad packet garbage exception codes are raised. Do a range check so that the debugger and runtime do not receive garbage codes. Update the user api to guard exception code type checking as well.
- https://git.kernel.org/stable/c/0cac183b98d8a8c692c98e8dba37df15a9e9210d
- https://git.kernel.org/stable/c/41dc6791596656dd41100b85647ed489e1d5c2f2
- https://git.kernel.org/stable/c/b6735bfe941486c5dfc9c3085d2d75d4923f9449
- https://git.kernel.org/stable/c/0cac183b98d8a8c692c98e8dba37df15a9e9210d
- https://git.kernel.org/stable/c/41dc6791596656dd41100b85647ed489e1d5c2f2
- https://git.kernel.org/stable/c/b6735bfe941486c5dfc9c3085d2d75d4923f9449
Modified: 2025-10-01
CVE-2024-36952
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.
- https://git.kernel.org/stable/c/0936809d968ecf81e0726fbd02ff2a5732d960c3
- https://git.kernel.org/stable/c/4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c
- https://git.kernel.org/stable/c/718602cd15f4c5710850090ea3066a89eeb46278
- https://git.kernel.org/stable/c/76337eb8daee32bcc67742efab3168ed4ca299d0
- https://git.kernel.org/stable/c/f2c7f029051edc4b394bb48edbe2297575abefe0
- https://git.kernel.org/stable/c/0936809d968ecf81e0726fbd02ff2a5732d960c3
- https://git.kernel.org/stable/c/4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c
- https://git.kernel.org/stable/c/718602cd15f4c5710850090ea3066a89eeb46278
- https://git.kernel.org/stable/c/76337eb8daee32bcc67742efab3168ed4ca299d0
- https://git.kernel.org/stable/c/f2c7f029051edc4b394bb48edbe2297575abefe0
Modified: 2025-12-23
CVE-2024-36953
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr() vgic_v2_parse_attr() is responsible for finding the vCPU that matches the user-provided CPUID, which (of course) may not be valid. If the ID is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled gracefully. Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id() actually returns something and fail the ioctl if not.
- https://git.kernel.org/stable/c/01981276d64e542c177b243f7c979fee855d5487
- https://git.kernel.org/stable/c/17db92da8be5dd3bf63c01f4109fe47db64fc66f
- https://git.kernel.org/stable/c/3a5b0378ac6776c7c31b18e0f3c1389bd6005e80
- https://git.kernel.org/stable/c/4404465a1bee3607ad90a4c5f9e16dfd75b85728
- https://git.kernel.org/stable/c/6ddb4f372fc63210034b903d96ebbeb3c7195adb
- https://git.kernel.org/stable/c/8d6a1c8e3de36cb0f5e866f1a582b00939e23104
- https://git.kernel.org/stable/c/01981276d64e542c177b243f7c979fee855d5487
- https://git.kernel.org/stable/c/17db92da8be5dd3bf63c01f4109fe47db64fc66f
- https://git.kernel.org/stable/c/3a5b0378ac6776c7c31b18e0f3c1389bd6005e80
- https://git.kernel.org/stable/c/4404465a1bee3607ad90a4c5f9e16dfd75b85728
- https://git.kernel.org/stable/c/6ddb4f372fc63210034b903d96ebbeb3c7195adb
- https://git.kernel.org/stable/c/8d6a1c8e3de36cb0f5e866f1a582b00939e23104
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-01-14
CVE-2024-36954
In the Linux kernel, the following vulnerability has been resolved: tipc: fix a possible memleak in tipc_buf_append __skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path.
- https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6
- https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae
- https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565
- https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c
- https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574
- https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d
- https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd
- https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e
- https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6
- https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae
- https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565
- https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c
- https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574
- https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d
- https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd
- https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-01
CVE-2024-36955
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node() The documentation for device_get_named_child_node() mentions this important point: " The caller is responsible for calling fwnode_handle_put() on the returned fwnode pointer. " Add fwnode_handle_put() to avoid a leaked reference.
- https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e
- https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf
- https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07
- https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377
- https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a
- https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e
- https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf
- https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07
- https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377
- https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a
Modified: 2025-12-23
CVE-2024-36957
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: avoid off-by-one read from userspace We try to access count + 1 byte from userspace with memdup_user(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdup_user_nul instead.
- https://git.kernel.org/stable/c/0a0285cee11c7dcc2657bcd456e469958a5009e7
- https://git.kernel.org/stable/c/8f11fe3ea3fc261640cfc8a5addd838000407c67
- https://git.kernel.org/stable/c/bcdac70adceb44373da204c3c297f2a98e13216e
- https://git.kernel.org/stable/c/ec697fbd38cbe2eef0948b58673b146caa95402f
- https://git.kernel.org/stable/c/f299ee709fb45036454ca11e90cb2810fe771878
- https://git.kernel.org/stable/c/fc3e0076c1f82fe981d321e3a7bad4cbee542c19
- https://git.kernel.org/stable/c/0a0285cee11c7dcc2657bcd456e469958a5009e7
- https://git.kernel.org/stable/c/8f11fe3ea3fc261640cfc8a5addd838000407c67
- https://git.kernel.org/stable/c/bcdac70adceb44373da204c3c297f2a98e13216e
- https://git.kernel.org/stable/c/ec697fbd38cbe2eef0948b58673b146caa95402f
- https://git.kernel.org/stable/c/f299ee709fb45036454ca11e90cb2810fe771878
- https://git.kernel.org/stable/c/fc3e0076c1f82fe981d321e3a7bad4cbee542c19
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
Modified: 2025-01-14
CVE-2024-36959
In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map() If we fail to allocate propname buffer, we need to drop the reference count we just took. Because the pinctrl_dt_free_maps() includes the droping operation, here we call it directly.
- https://git.kernel.org/stable/c/026e24cf31733dbd97f41cc9bc5273ace428eeec
- https://git.kernel.org/stable/c/06780473cb8a858d1d6cab2673e021b072a852d1
- https://git.kernel.org/stable/c/35ab679e8bb5a81a4f922d3efbd43e32bce69274
- https://git.kernel.org/stable/c/47d253c485491caaf70d8cd8c0248ae26e42581f
- https://git.kernel.org/stable/c/518d5ddafeb084d6d9b1773ed85164300037d0e6
- https://git.kernel.org/stable/c/76aa2440deb9a35507590f2c981a69a57ecd305d
- https://git.kernel.org/stable/c/a0cedbcc8852d6c77b00634b81e41f17f29d9404
- https://git.kernel.org/stable/c/c7e02ccc9fdc496fe51e440e3e66ac36509ca049
- https://git.kernel.org/stable/c/026e24cf31733dbd97f41cc9bc5273ace428eeec
- https://git.kernel.org/stable/c/06780473cb8a858d1d6cab2673e021b072a852d1
- https://git.kernel.org/stable/c/35ab679e8bb5a81a4f922d3efbd43e32bce69274
- https://git.kernel.org/stable/c/47d253c485491caaf70d8cd8c0248ae26e42581f
- https://git.kernel.org/stable/c/518d5ddafeb084d6d9b1773ed85164300037d0e6
- https://git.kernel.org/stable/c/76aa2440deb9a35507590f2c981a69a57ecd305d
- https://git.kernel.org/stable/c/a0cedbcc8852d6c77b00634b81e41f17f29d9404
- https://git.kernel.org/stable/c/c7e02ccc9fdc496fe51e440e3e66ac36509ca049
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-01
CVE-2024-36960
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix invalid reads in fence signaled events Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.
- https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b
- https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f
- https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36
- https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22
- https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c
- https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0
- https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9
- https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77
- https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b
- https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f
- https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36
- https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22
- https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c
- https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0
- https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9
- https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-17
CVE-2024-36963
In the Linux kernel, the following vulnerability has been resolved: tracefs: Reset permissions on remount if permissions are options There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs). But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated. This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some. For example: # cd /sys/kernel/tracing # chgrp 1002 current_tracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root root 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root root 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root root 0 May 1 21:25 dynamic_events -r--r----- 1 root root 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root root 0 May 1 21:25 enabled_functions Where current_tracer now has group "lkp". # mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root tracing 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root tracing 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamic_events -r--r----- 1 root tracing 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root tracing 0 May 1 21:25 enabled_functions Everything changed but the "current_tracer". Add a new link list that keeps track of all the tracefs_inodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories.
- https://git.kernel.org/stable/c/414fb08628143203d29ccd0264b5a83fb9523c03
- https://git.kernel.org/stable/c/5f91fc82794d4a6e41cdcd02d00baa377d94ca78
- https://git.kernel.org/stable/c/baa23a8d4360d981a49913841a726edede5cdd54
- https://git.kernel.org/stable/c/414fb08628143203d29ccd0264b5a83fb9523c03
- https://git.kernel.org/stable/c/5f91fc82794d4a6e41cdcd02d00baa377d94ca78
- https://git.kernel.org/stable/c/baa23a8d4360d981a49913841a726edede5cdd54
Modified: 2025-12-17
CVE-2024-36964
In the Linux kernel, the following vulnerability has been resolved: fs/9p: only translate RWX permissions for plain 9P2000 Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.
- https://git.kernel.org/stable/c/157d468e34fdd3cb1ddc07c2be32fb3b02826b02
- https://git.kernel.org/stable/c/5a605930e19f451294bd838754f7d66c976a8a2c
- https://git.kernel.org/stable/c/ad4f65328661392de74e3608bb736fedf3b67e32
- https://git.kernel.org/stable/c/ca9b5c81f0c918c63d73d962ed8a8e231f840bc8
- https://git.kernel.org/stable/c/cd25e15e57e68a6b18dc9323047fe9c68b99290b
- https://git.kernel.org/stable/c/df1962a199783ecd66734d563caf0fedecf08f96
- https://git.kernel.org/stable/c/e55c601af3b1223a84f9f27f9cdbd2af5e203bf3
- https://git.kernel.org/stable/c/e90bc596a74bb905e0a45bf346038c3f9d1e868d
- https://git.kernel.org/stable/c/157d468e34fdd3cb1ddc07c2be32fb3b02826b02
- https://git.kernel.org/stable/c/5a605930e19f451294bd838754f7d66c976a8a2c
- https://git.kernel.org/stable/c/ad4f65328661392de74e3608bb736fedf3b67e32
- https://git.kernel.org/stable/c/ca9b5c81f0c918c63d73d962ed8a8e231f840bc8
- https://git.kernel.org/stable/c/cd25e15e57e68a6b18dc9323047fe9c68b99290b
- https://git.kernel.org/stable/c/df1962a199783ecd66734d563caf0fedecf08f96
- https://git.kernel.org/stable/c/e55c601af3b1223a84f9f27f9cdbd2af5e203bf3
- https://git.kernel.org/stable/c/e90bc596a74bb905e0a45bf346038c3f9d1e868d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-36965
In the Linux kernel, the following vulnerability has been resolved: remoteproc: mediatek: Make sure IPI buffer fits in L2TCM The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core).
- https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf
- https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2
- https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e
- https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42
- https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9
- https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf
- https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf
- https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2
- https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e
- https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42
- https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9
- https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf
Modified: 2025-10-01
CVE-2024-36966
In the Linux kernel, the following vulnerability has been resolved:
erofs: reliably distinguish block based and fscache mode
When erofs_kill_sb() is called in block dev based mode, s_bdev may not
have been initialised yet, and if CONFIG_EROFS_FS_ONDEMAND is enabled,
it will be mistaken for fscache mode, and then attempt to free an anon_dev
that has never been allocated, triggering the following warning:
============================================
ida_free called for id=0 which is not allocated.
WARNING: CPU: 14 PID: 926 at lib/idr.c:525 ida_free+0x134/0x140
Modules linked in:
CPU: 14 PID: 926 Comm: mount Not tainted 6.9.0-rc3-dirty #630
RIP: 0010:ida_free+0x134/0x140
Call Trace:
- https://git.kernel.org/stable/c/7af2ae1b1531feab5d38ec9c8f472dc6cceb4606
- https://git.kernel.org/stable/c/dcdd49701e429c55b3644fd70fc58d85745f8cfe
- https://git.kernel.org/stable/c/f9b877a7ee312ec8ce17598a7ef85cb820d7c371
- https://git.kernel.org/stable/c/7af2ae1b1531feab5d38ec9c8f472dc6cceb4606
- https://git.kernel.org/stable/c/dcdd49701e429c55b3644fd70fc58d85745f8cfe
- https://git.kernel.org/stable/c/f9b877a7ee312ec8ce17598a7ef85cb820d7c371
Modified: 2024-11-21
CVE-2024-36967
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak in tpm2_key_encode() 'scratch' is never freed. Fix this by calling kfree() in the success, and in the error case.
- https://git.kernel.org/stable/c/189c768932d435045b1fae12bf63e53866f06a28
- https://git.kernel.org/stable/c/1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf
- https://git.kernel.org/stable/c/5d91238b590bd883c86ba7707c5c9096469c08b7
- https://git.kernel.org/stable/c/cf26a92f560eed5d6ddc3d441cc645950cbabc56
- https://git.kernel.org/stable/c/e62835264d0352be6086975f18fdfed2b5520b13
- https://git.kernel.org/stable/c/ffcaa2172cc1a85ddb8b783de96d38ca8855e248
- https://git.kernel.org/stable/c/189c768932d435045b1fae12bf63e53866f06a28
- https://git.kernel.org/stable/c/1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf
- https://git.kernel.org/stable/c/5d91238b590bd883c86ba7707c5c9096469c08b7
- https://git.kernel.org/stable/c/cf26a92f560eed5d6ddc3d441cc645950cbabc56
- https://git.kernel.org/stable/c/e62835264d0352be6086975f18fdfed2b5520b13
- https://git.kernel.org/stable/c/ffcaa2172cc1a85ddb8b783de96d38ca8855e248
Modified: 2024-11-21
CVE-2024-36968
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
overflow since hdev->le_mtu may not fall in the valid range.
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
process earlier if MTU is invalid.
Also, add a missing validation in read_buffer_size() and make it return
an error value if the validation fails.
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
kzalloc failure and invalid MTU value.
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci0 hci_rx_work
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/4d3dbaa252257d20611c3647290e6171f1bbd6c8
- https://git.kernel.org/stable/c/a5b862c6a221459d54e494e88965b48dcfa6cc44
- https://git.kernel.org/stable/c/ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674
- https://git.kernel.org/stable/c/d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30
- https://git.kernel.org/stable/c/dfece2b4e3759759b2bdfac2cd6d0ee9fbf055f3
- https://git.kernel.org/stable/c/4d3dbaa252257d20611c3647290e6171f1bbd6c8
- https://git.kernel.org/stable/c/a5b862c6a221459d54e494e88965b48dcfa6cc44
- https://git.kernel.org/stable/c/ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674
- https://git.kernel.org/stable/c/d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30
- https://git.kernel.org/stable/c/dfece2b4e3759759b2bdfac2cd6d0ee9fbf055f3
Modified: 2024-11-21
CVE-2024-36969
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix division by zero in setup_dsc_config When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113.
- https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba
- https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911
- https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639
- https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f
- https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445
- https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563
- https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba
- https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911
- https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639
- https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f
- https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445
- https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563
Modified: 2025-11-05
CVE-2024-36971
In the Linux kernel, the following vulnerability has been resolved: net: fix __dst_negative_advice() race __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst). Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the blamed commit, using UDP sockets.
- https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13
- https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6
- https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508
- https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4
- https://git.kernel.org/stable/c/92f1655aa2b2294d0b49925f3b875a634bd3b59e
- https://git.kernel.org/stable/c/b8af8e6118a6605f0e495a58d591ca94a85a50fc
- https://git.kernel.org/stable/c/db0082825037794c5dba9959c9de13ca34cc5e72
- https://git.kernel.org/stable/c/eacb8b195579c174a6d3e12a9690b206eb7f28cf
- https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13
- https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6
- https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508
- https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4
- https://git.kernel.org/stable/c/92f1655aa2b2294d0b49925f3b875a634bd3b59e
- https://git.kernel.org/stable/c/b8af8e6118a6605f0e495a58d591ca94a85a50fc
- https://git.kernel.org/stable/c/db0082825037794c5dba9959c9de13ca34cc5e72
- https://git.kernel.org/stable/c/eacb8b195579c174a6d3e12a9690b206eb7f28cf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-36971
Modified: 2025-04-01
CVE-2024-36972
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock.
Billy Jheng Bing-Jhong reported a race between __unix_gc() and
queue_oob().
__unix_gc() tries to garbage-collect close()d inflight sockets,
and then if the socket has MSG_OOB in unix_sk(sk)->oob_skb, GC
will drop the reference and set NULL to it locklessly.
However, the peer socket still can send MSG_OOB message and
queue_oob() can update unix_sk(sk)->oob_skb concurrently, leading
NULL pointer dereference. [0]
To fix the issue, let's update unix_sk(sk)->oob_skb under the
sk_receive_queue's lock and take it everywhere we touch oob_skb.
Note that we defer kfree_skb() in manage_oob() to silence lockdep
false-positive (See [1]).
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PF: supervisor write access in kernel mode
PF: error_code(0x0002) - not-present page
PGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0
Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Workqueue: events delayed_fput
RIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847)
Code: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc
RSP: 0018:ffffc900001bfd48 EFLAGS: 00000002
RAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9
RDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00
RBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001
R10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00
R13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80
FS: 0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/4708f49add84a57ce0ccc7bf9a6269845c631cc3
- https://git.kernel.org/stable/c/4bf6964451c3cb411fbaa1ae8b214b3d97a59bf1
- https://git.kernel.org/stable/c/518a994aa0b87d96f1bc6678a7035df5d1fcd7a1
- https://git.kernel.org/stable/c/9841991a446c87f90f66f4b9fee6fe934c1336a2
- https://git.kernel.org/stable/c/d59ae9314b97e01c76a4171472441e55721ba636
- https://git.kernel.org/stable/c/4708f49add84a57ce0ccc7bf9a6269845c631cc3
- https://git.kernel.org/stable/c/4bf6964451c3cb411fbaa1ae8b214b3d97a59bf1
- https://git.kernel.org/stable/c/518a994aa0b87d96f1bc6678a7035df5d1fcd7a1
- https://git.kernel.org/stable/c/9841991a446c87f90f66f4b9fee6fe934c1336a2
- https://git.kernel.org/stable/c/d59ae9314b97e01c76a4171472441e55721ba636
Modified: 2025-11-03
CVE-2024-36973
In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe() When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function gp_auxiliary_device_release() calls ida_free() and kfree(aux_device_wrapper) to free memory. We should't call them again in the error handling path. Fix this by skipping the redundant cleanup functions.
- https://git.kernel.org/stable/c/086c6cbcc563c81d55257f9b27e14faf1d0963d3
- https://git.kernel.org/stable/c/1efe551982297924d05a367aa2b6ec3d275d5742
- https://git.kernel.org/stable/c/34ae447b138680b5ed3660f7d935ff3faf88ba1a
- https://git.kernel.org/stable/c/86c9713602f786f441630c4ee02891987f8618b9
- https://git.kernel.org/stable/c/086c6cbcc563c81d55257f9b27e14faf1d0963d3
- https://git.kernel.org/stable/c/1efe551982297924d05a367aa2b6ec3d275d5742
- https://git.kernel.org/stable/c/34ae447b138680b5ed3660f7d935ff3faf88ba1a
- https://git.kernel.org/stable/c/86c9713602f786f441630c4ee02891987f8618b9
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-01
CVE-2024-36974
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided, taprio_parse_mqprio_opt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called. First call (with valid attributes) sets dev->num_tc to a non zero value. Second call (with arbitrary mqprio attributes) returns early from taprio_parse_mqprio_opt() and bad things can happen.
- https://git.kernel.org/stable/c/0bf6cc96612bd396048f57d63f1ad454a846e39c
- https://git.kernel.org/stable/c/6db4af09987cc5d5f0136bd46148b0e0460dae5b
- https://git.kernel.org/stable/c/724050ae4b76e4fae05a923cb54101d792cf4404
- https://git.kernel.org/stable/c/c37a27a35eadb59286c9092c49c241270c802ae2
- https://git.kernel.org/stable/c/c6041e7124464ce7e896ee3f912897ce88a0c4ec
- https://git.kernel.org/stable/c/d3dde4c217f0c31ab0621912e682b57e677dd923
- https://git.kernel.org/stable/c/f921a58ae20852d188f70842431ce6519c4fdc36
- https://git.kernel.org/stable/c/0bf6cc96612bd396048f57d63f1ad454a846e39c
- https://git.kernel.org/stable/c/6db4af09987cc5d5f0136bd46148b0e0460dae5b
- https://git.kernel.org/stable/c/724050ae4b76e4fae05a923cb54101d792cf4404
- https://git.kernel.org/stable/c/c37a27a35eadb59286c9092c49c241270c802ae2
- https://git.kernel.org/stable/c/c6041e7124464ce7e896ee3f912897ce88a0c4ec
- https://git.kernel.org/stable/c/d3dde4c217f0c31ab0621912e682b57e677dd923
- https://git.kernel.org/stable/c/f921a58ae20852d188f70842431ce6519c4fdc36
Modified: 2025-10-01
CVE-2024-36975
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Do not use WARN when encode fails When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information.
- https://git.kernel.org/stable/c/050bf3c793a07f96bd1e2fd62e1447f731ed733b
- https://git.kernel.org/stable/c/1c652e1e10676f942149052d9329b8bf2703529a
- https://git.kernel.org/stable/c/681935009fec3fc22af97ee312d4a24ccf3cf087
- https://git.kernel.org/stable/c/96f650995c70237b061b497c66755e32908f8972
- https://git.kernel.org/stable/c/d32c6e09f7c4bec3ebc4941323f0aa6366bc1487
- https://git.kernel.org/stable/c/ff91cc12faf798f573dab2abc976c1d5b1862fea
- https://git.kernel.org/stable/c/050bf3c793a07f96bd1e2fd62e1447f731ed733b
- https://git.kernel.org/stable/c/1c652e1e10676f942149052d9329b8bf2703529a
- https://git.kernel.org/stable/c/681935009fec3fc22af97ee312d4a24ccf3cf087
- https://git.kernel.org/stable/c/96f650995c70237b061b497c66755e32908f8972
- https://git.kernel.org/stable/c/d32c6e09f7c4bec3ebc4941323f0aa6366bc1487
- https://git.kernel.org/stable/c/ff91cc12faf798f573dab2abc976c1d5b1862fea
Modified: 2025-10-01
CVE-2024-36977
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Wait unconditionally after issuing EndXfer command Currently all controller IP/revisions except DWC3_usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed. Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests. Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally.
- https://git.kernel.org/stable/c/1ba145f05b5c8f0b1a947a0633b5edff5dd1f1c5
- https://git.kernel.org/stable/c/1d26ba0944d398f88aaf997bda3544646cf21945
- https://git.kernel.org/stable/c/341eb08dbca9eae05308c442fbfab1813a44c97a
- https://git.kernel.org/stable/c/4a387e032909c6dc2b479452c5bbe9a252057925
- https://git.kernel.org/stable/c/ec96bcf5f96a7a5c556b0e881ac3e5c3924d542c
- https://git.kernel.org/stable/c/1ba145f05b5c8f0b1a947a0633b5edff5dd1f1c5
- https://git.kernel.org/stable/c/1d26ba0944d398f88aaf997bda3544646cf21945
- https://git.kernel.org/stable/c/341eb08dbca9eae05308c442fbfab1813a44c97a
- https://git.kernel.org/stable/c/4a387e032909c6dc2b479452c5bbe9a252057925
- https://git.kernel.org/stable/c/ec96bcf5f96a7a5c556b0e881ac3e5c3924d542c
Modified: 2025-11-03
CVE-2024-36978
In the Linux kernel, the following vulnerability has been resolved: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur.
- https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882
- https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f
- https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e
- https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3
- https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b9fe043d
- https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d
- https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129
- https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882
- https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f
- https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e
- https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3
- https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b9fe043d
- https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d
- https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-36979
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mst: fix vlan use-after-free
syzbot reported a suspicious rcu usage[1] in bridge's mst code. While
fixing it I noticed that nothing prevents a vlan to be freed while
walking the list from the same path (br forward delay timer). Fix the rcu
usage and also make sure we are not accessing freed memory by making
br_mst_vlan_set_state use rcu read lock.
[1]
WARNING: suspicious RCU usage
6.9.0-rc6-syzkaller #0 Not tainted
-----------------------------
net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!
...
stack backtrace:
CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
- https://git.kernel.org/stable/c/3a7c1661ae1383364cd6092d851f5e5da64d476b
- https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59
- https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e
- https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac
- https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4
- https://git.kernel.org/stable/c/3a7c1661ae1383364cd6092d851f5e5da64d476b
- https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59
- https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e
- https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac
- https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4
Modified: 2025-11-03
CVE-2024-37021
In the Linux kernel, the following vulnerability has been resolved: fpga: manager: add owner module and take its refcount The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga manager. Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions.
- https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad
- https://git.kernel.org/stable/c/304f8032d601d4f9322ca841cd0b573bd1beb158
- https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9
- https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb
- https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad
- https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9
- https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2025-11-03
CVE-2024-37078
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
Destructive writes to a block device on which nilfs2 is mounted can cause
a kernel bug in the folio/page writeback start routine or writeback end
routine (__folio_start_writeback in the log below):
kernel BUG at mm/page-writeback.c:3070!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
...
RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
...
Call Trace:
- https://git.kernel.org/stable/c/0ecfe3a92869a59668d27228dabbd7965e83567f
- https://git.kernel.org/stable/c/1f3bff69f1214fe03a02bc650d5bbfaa6e65ae7d
- https://git.kernel.org/stable/c/271dcd977ccda8c7a26e360425ae7b4db7d2ecc0
- https://git.kernel.org/stable/c/33900d7eae616647e179eee1c66ebe654ee39627
- https://git.kernel.org/stable/c/614d397be0cf43412b3f94a0f6460eddced8ce92
- https://git.kernel.org/stable/c/95f6f81e50d858a7c9aa7c795ec14a0ac3819118
- https://git.kernel.org/stable/c/a4ca369ca221bb7e06c725792ac107f0e48e82e7
- https://git.kernel.org/stable/c/a75b8f493dfc48aa38c518430bd9e03b53bffebe
- https://git.kernel.org/stable/c/0ecfe3a92869a59668d27228dabbd7965e83567f
- https://git.kernel.org/stable/c/1f3bff69f1214fe03a02bc650d5bbfaa6e65ae7d
- https://git.kernel.org/stable/c/271dcd977ccda8c7a26e360425ae7b4db7d2ecc0
- https://git.kernel.org/stable/c/33900d7eae616647e179eee1c66ebe654ee39627
- https://git.kernel.org/stable/c/614d397be0cf43412b3f94a0f6460eddced8ce92
- https://git.kernel.org/stable/c/95f6f81e50d858a7c9aa7c795ec14a0ac3819118
- https://git.kernel.org/stable/c/a4ca369ca221bb7e06c725792ac107f0e48e82e7
- https://git.kernel.org/stable/c/a75b8f493dfc48aa38c518430bd9e03b53bffebe
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-12-06
CVE-2024-37354
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix crash on racing fsync and size-extending write into prealloc We have been seeing crashes on duplicate keys in btrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121) So we're logging a changed extent from fsync, which is splitting an extent in the log tree. But this split part already exists in the tree, triggering the BUG(). This is the state of the log tree at the time of the crash, dumped with drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ... So the real problem happened earlier: notice that items 4 (4k-12k) and 5 (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and item 5 starts at i_size. Here is the state of ---truncated---
- https://git.kernel.org/stable/c/1ff2bd566fbcefcb892be85c493bdb92b911c428
- https://git.kernel.org/stable/c/3d08c52ba1887a1ff9c179d4b6a18b427bcb2097
- https://git.kernel.org/stable/c/9d274c19a71b3a276949933859610721a453946b
- https://git.kernel.org/stable/c/c993fd02ba471e296ca1996f13626fc917120158
- https://git.kernel.org/stable/c/f4e5ed974876c14d3623e04dc43d3e3281bc6011
- https://git.kernel.org/stable/c/1ff2bd566fbcefcb892be85c493bdb92b911c428
- https://git.kernel.org/stable/c/3d08c52ba1887a1ff9c179d4b6a18b427bcb2097
- https://git.kernel.org/stable/c/9d274c19a71b3a276949933859610721a453946b
- https://git.kernel.org/stable/c/f4e5ed974876c14d3623e04dc43d3e3281bc6011
Modified: 2025-11-04
CVE-2024-37356
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
as follows:
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
...
delivered_ce <<= (10 - dctcp_shift_g);
It seems syzkaller started fuzzing module parameters and triggered
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
memcpy((void*)0x20000080,
"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
/*flags=*/2ul, /*mode=*/0ul);
memcpy((void*)0x20000000, "100\000", 4);
syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
With this patch:
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
# cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
10
# echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
-bash: echo: write error: Invalid argument
[0]:
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
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/02261d3f9dc7d1d7be7d778f839e3404ab99034c
- https://git.kernel.org/stable/c/06d0fe049b51b0a92a70df8333fd85c4ba3eb2c6
- https://git.kernel.org/stable/c/237340dee373b97833a491d2e99fcf1d4a9adafd
- https://git.kernel.org/stable/c/3ebc46ca8675de6378e3f8f40768e180bb8afa66
- https://git.kernel.org/stable/c/6aacaa80d962f4916ccf90e2080306cec6c90fcf
- https://git.kernel.org/stable/c/8602150286a2a860a1dc55cbd04f99316f19b40a
- https://git.kernel.org/stable/c/e65d13ec00a738fa7661925fd5929ab3c765d4be
- https://git.kernel.org/stable/c/e9b2f60636d18dfd0dd4965b3316f88dfd6a2b31
- https://git.kernel.org/stable/c/02261d3f9dc7d1d7be7d778f839e3404ab99034c
- https://git.kernel.org/stable/c/06d0fe049b51b0a92a70df8333fd85c4ba3eb2c6
- https://git.kernel.org/stable/c/237340dee373b97833a491d2e99fcf1d4a9adafd
- https://git.kernel.org/stable/c/3ebc46ca8675de6378e3f8f40768e180bb8afa66
- https://git.kernel.org/stable/c/6aacaa80d962f4916ccf90e2080306cec6c90fcf
- https://git.kernel.org/stable/c/8602150286a2a860a1dc55cbd04f99316f19b40a
- https://git.kernel.org/stable/c/e65d13ec00a738fa7661925fd5929ab3c765d4be
- https://git.kernel.org/stable/c/e9b2f60636d18dfd0dd4965b3316f88dfd6a2b31
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-24
CVE-2024-38384
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from reorder of WRITE ->lqueued __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed. If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted. Fix the issue by adding one barrier.
- https://git.kernel.org/stable/c/714e59b5456e4d6e4295a9968c564abe193f461c
- https://git.kernel.org/stable/c/785298ab6b802afa75089239266b6bbea590809c
- https://git.kernel.org/stable/c/d0aac2363549e12cc79b8e285f13d5a9f42fd08e
- https://git.kernel.org/stable/c/714e59b5456e4d6e4295a9968c564abe193f461c
- https://git.kernel.org/stable/c/785298ab6b802afa75089239266b6bbea590809c
- https://git.kernel.org/stable/c/d0aac2363549e12cc79b8e285f13d5a9f42fd08e
Modified: 2024-11-21
CVE-2024-38385
In the Linux kernel, the following vulnerability has been resolved: genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after() irq_find_at_or_after() dereferences the interrupt descriptor which is returned by mt_find() while neither holding sparse_irq_lock nor RCU read lock, which means the descriptor can be freed between mt_find() and the dereference: CPU0 CPU1 desc = mt_find() delayed_free_desc(desc) irq_desc_get_irq(desc) The use-after-free is reported by KASAN: Call trace: irq_get_next_irq+0x58/0x84 show_stat+0x638/0x824 seq_read_iter+0x158/0x4ec proc_reg_read_iter+0x94/0x12c vfs_read+0x1e0/0x2c8 Freed by task 4471: slab_free_freelist_hook+0x174/0x1e0 __kmem_cache_free+0xa4/0x1dc kfree+0x64/0x128 irq_kobj_release+0x28/0x3c kobject_put+0xcc/0x1e0 delayed_free_desc+0x14/0x2c rcu_do_batch+0x214/0x720 Guard the access with a RCU read lock section.
- https://git.kernel.org/stable/c/1c7891812d85500ae2ca4051fa5683fcf29930d8
- https://git.kernel.org/stable/c/b84a8aba806261d2f759ccedf4a2a6a80a5e55ba
- https://git.kernel.org/stable/c/d084aa022f84319f8079e30882cbcbc026af9f21
- https://git.kernel.org/stable/c/1c7891812d85500ae2ca4051fa5683fcf29930d8
- https://git.kernel.org/stable/c/b84a8aba806261d2f759ccedf4a2a6a80a5e55ba
- https://git.kernel.org/stable/c/d084aa022f84319f8079e30882cbcbc026af9f21
Modified: 2025-04-01
CVE-2024-38388
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers.
- https://git.kernel.org/stable/c/172811e3a557d8681a5e2d0f871dc04a2d17eb13
- https://git.kernel.org/stable/c/191dc1b2ff0fb35e7aff15a53224837637df8bff
- https://git.kernel.org/stable/c/3291486af5636540980ea55bae985f3eaa5b0740
- https://git.kernel.org/stable/c/6e359be4975006ff72818e79dad8fe48293f2eb2
- https://git.kernel.org/stable/c/172811e3a557d8681a5e2d0f871dc04a2d17eb13
- https://git.kernel.org/stable/c/191dc1b2ff0fb35e7aff15a53224837637df8bff
- https://git.kernel.org/stable/c/3291486af5636540980ea55bae985f3eaa5b0740
- https://git.kernel.org/stable/c/6e359be4975006ff72818e79dad8fe48293f2eb2
Modified: 2024-11-21
CVE-2024-38390
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Patchwork: https://patchwork.freedesktop.org/patch/588919/
- https://git.kernel.org/stable/c/247849eeb3fd88f8990ed73e33af70d5c10f9aec
- https://git.kernel.org/stable/c/46d4efcccc688cbacdd70a238bedca510acaa8e4
- https://git.kernel.org/stable/c/617e3d1680504a3f9d88e1582892c68be155498f
- https://git.kernel.org/stable/c/a1955a6df91355fef72a3a254700acd3cc1fec0d
- https://git.kernel.org/stable/c/247849eeb3fd88f8990ed73e33af70d5c10f9aec
- https://git.kernel.org/stable/c/46d4efcccc688cbacdd70a238bedca510acaa8e4
- https://git.kernel.org/stable/c/617e3d1680504a3f9d88e1582892c68be155498f
- https://git.kernel.org/stable/c/a1955a6df91355fef72a3a254700acd3cc1fec0d
Modified: 2025-11-03
CVE-2024-38538
In the Linux kernel, the following vulnerability has been resolved: net: bridge: xmit: make sure we have at least eth header len bytes syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
- https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5
- https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2
- https://git.kernel.org/stable/c/3e01fc3c66e65d9afe98f1489047a1b2dd8741ca
- https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a
- https://git.kernel.org/stable/c/82090f94c723dab724b1c32db406091d40448a17
- https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc
- https://git.kernel.org/stable/c/b2b7c43cd32080221bb233741bd6011983fe7c11
- https://git.kernel.org/stable/c/c964429ef53f42098a6545a5dabeb1441c1e821d
- https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2
- https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5
- https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2
- https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a
- https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc
- https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2024-11-21
CVE-2024-38539
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw
When running blktests nvme/rdma, the following kmemleak issue will appear.
kmemleak: Kernel memory leak detector initialized (mempool available:36041)
kmemleak: Automatic memory scanning thread started
kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
unreferenced object 0xffff88855da53400 (size 192):
comm "rdma", pid 10630, jiffies 4296575922
hex dump (first 32 bytes):
37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7...............
10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.]....
backtrace (crc 47f66721):
[
- https://git.kernel.org/stable/c/3eb127dc408bf7959a4920d04d16ce10e863686a
- https://git.kernel.org/stable/c/6564fc1818404254d1c9f7d75b403b4941516d26
- https://git.kernel.org/stable/c/9c0731832d3b7420cbadba6a7f334363bc8dfb15
- https://git.kernel.org/stable/c/b3a7fb93afd888793ef226e9665fbda98a95c48e
- https://git.kernel.org/stable/c/3eb127dc408bf7959a4920d04d16ce10e863686a
- https://git.kernel.org/stable/c/6564fc1818404254d1c9f7d75b403b4941516d26
- https://git.kernel.org/stable/c/9c0731832d3b7420cbadba6a7f334363bc8dfb15
- https://git.kernel.org/stable/c/b3a7fb93afd888793ef226e9665fbda98a95c48e
Modified: 2025-11-03
CVE-2024-38540
In the Linux kernel, the following vulnerability has been resolved:
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called
with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.
In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called.
roundup_pow_of_two is documented as undefined for 0.
Fix it in the one caller that had this combination.
The undefined behavior was detected by UBSAN:
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4
Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023
Call Trace:
- https://git.kernel.org/stable/c/627493443f3a8458cb55cdae1da254a7001123bc
- https://git.kernel.org/stable/c/66a9937187ac9b5c5ffff07b8b284483e56804d1
- https://git.kernel.org/stable/c/78cfd17142ef70599d6409cbd709d94b3da58659
- https://git.kernel.org/stable/c/84d2f29152184f0d72ed7c9648c4ee6927df4e59
- https://git.kernel.org/stable/c/8b799c00cea6fcfe5b501bbaeb228c8821acb753
- https://git.kernel.org/stable/c/a658f011d89dd20cf2c7cb4760ffd79201700b98
- https://git.kernel.org/stable/c/627493443f3a8458cb55cdae1da254a7001123bc
- https://git.kernel.org/stable/c/78cfd17142ef70599d6409cbd709d94b3da58659
- https://git.kernel.org/stable/c/8b799c00cea6fcfe5b501bbaeb228c8821acb753
- https://git.kernel.org/stable/c/a658f011d89dd20cf2c7cb4760ffd79201700b98
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-38541
In the Linux kernel, the following vulnerability has been resolved: of: module: add buffer overflow check in of_modalias() In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).
- https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6
- https://git.kernel.org/stable/c/46795440ef2b4ac919d09310a69a404c5bc90a88
- https://git.kernel.org/stable/c/5d59fd637a8af42b211a92b2edb2474325b4d488
- https://git.kernel.org/stable/c/733e62786bdf1b2b9dbb09ba2246313306503414
- https://git.kernel.org/stable/c/c7f24b7d94549ff4623e8f41ea4d9f5319bd8ac8
- https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252
- https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a
- https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e
- https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6
- https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252
- https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a
- https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2024-11-21
CVE-2024-38543
In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure The kcalloc() in dmirror_device_evict_chunk() will return null if the physical memory has run out. As a result, if src_pfns or dst_pfns is dereferenced, the null pointer dereference bug will happen. Moreover, the device is going away. If the kcalloc() fails, the pages mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, Switch kcalloc() to kvcalloc() in order to avoid failing allocations.
- https://git.kernel.org/stable/c/1a21fdeea502658e315bd939409b755974f4fb64
- https://git.kernel.org/stable/c/3b20d18f475bd17309db640dbe7d7c7ebb5bc2bc
- https://git.kernel.org/stable/c/65e528a69cb3ed4a286c45b4afba57461c8b5b33
- https://git.kernel.org/stable/c/c2af060d1c18beaec56351cf9c9bcbbc5af341a3
- https://git.kernel.org/stable/c/ce47e8ead9a72834cc68431d53f8092ce69bebb7
- https://git.kernel.org/stable/c/1a21fdeea502658e315bd939409b755974f4fb64
- https://git.kernel.org/stable/c/3b20d18f475bd17309db640dbe7d7c7ebb5bc2bc
- https://git.kernel.org/stable/c/65e528a69cb3ed4a286c45b4afba57461c8b5b33
- https://git.kernel.org/stable/c/c2af060d1c18beaec56351cf9c9bcbbc5af341a3
- https://git.kernel.org/stable/c/ce47e8ead9a72834cc68431d53f8092ce69bebb7
Modified: 2025-11-03
CVE-2024-38544
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale. This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.
- https://git.kernel.org/stable/c/21b4c6d4d89030fd4657a8e7c8110fd941049794
- https://git.kernel.org/stable/c/2b23b6097303ed0ba5f4bc036a1c07b6027af5c6
- https://git.kernel.org/stable/c/30df4bef8b8e183333e9b6e9d4509d552c7da6eb
- https://git.kernel.org/stable/c/bbad88f111a1829f366c189aa48e7e58e57553fc
- https://git.kernel.org/stable/c/c91fb72a2ca6480d8d77262eef52dc5b178463a3
- https://git.kernel.org/stable/c/de5a059e36657442b5637cc16df5163e435b9cb4
- https://git.kernel.org/stable/c/e0e14dd35d4242340c7346aac60c7ff8fbf87ffc
- https://git.kernel.org/stable/c/faa8d0ecf6c9c7c2ace3ca3e552180ada6f75e19
- https://git.kernel.org/stable/c/21b4c6d4d89030fd4657a8e7c8110fd941049794
- https://git.kernel.org/stable/c/2b23b6097303ed0ba5f4bc036a1c07b6027af5c6
- https://git.kernel.org/stable/c/30df4bef8b8e183333e9b6e9d4509d552c7da6eb
- https://git.kernel.org/stable/c/bbad88f111a1829f366c189aa48e7e58e57553fc
- https://git.kernel.org/stable/c/faa8d0ecf6c9c7c2ace3ca3e552180ada6f75e19
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-12-23
CVE-2024-38545
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix UAF for cq async event The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF. Use the xa_lock() to protect the CQ refcount.
- https://git.kernel.org/stable/c/330c825e66ef65278e4ebe57fd49c1d6f3f4e34e
- https://git.kernel.org/stable/c/37a7559dc1358a8d300437e99ed8ecdab0671507
- https://git.kernel.org/stable/c/39d26cf46306bdc7ae809ecfdbfeff5aa1098911
- https://git.kernel.org/stable/c/63da190eeb5c9d849b71f457b15b308c94cbaf08
- https://git.kernel.org/stable/c/763780ef0336a973e933e40e919339381732dcaf
- https://git.kernel.org/stable/c/a942ec2745ca864cd8512142100e4027dc306a42
- https://git.kernel.org/stable/c/37a7559dc1358a8d300437e99ed8ecdab0671507
- https://git.kernel.org/stable/c/39d26cf46306bdc7ae809ecfdbfeff5aa1098911
- https://git.kernel.org/stable/c/63da190eeb5c9d849b71f457b15b308c94cbaf08
- https://git.kernel.org/stable/c/763780ef0336a973e933e40e919339381732dcaf
- https://git.kernel.org/stable/c/a942ec2745ca864cd8512142100e4027dc306a42
Modified: 2024-11-21
CVE-2024-38546
In the Linux kernel, the following vulnerability has been resolved: drm: vc4: Fix possible null pointer dereference In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/2a345fe928c21de6f3c3c7230ff509d715153a31
- https://git.kernel.org/stable/c/2d9adecc88ab678785b581ab021f039372c324cb
- https://git.kernel.org/stable/c/42c22b63056cea259d5313bf138a834840af85a5
- https://git.kernel.org/stable/c/6cf1874aec42058a5ad621a23b5b2f248def0e96
- https://git.kernel.org/stable/c/80431ea3634efb47a3004305d76486db9dd8ed49
- https://git.kernel.org/stable/c/bd7827d46d403f8cdb43d16744cb1114e4726b21
- https://git.kernel.org/stable/c/c534b63bede6cb987c2946ed4d0b0013a52c5ba7
- https://git.kernel.org/stable/c/2a345fe928c21de6f3c3c7230ff509d715153a31
- https://git.kernel.org/stable/c/2d9adecc88ab678785b581ab021f039372c324cb
- https://git.kernel.org/stable/c/42c22b63056cea259d5313bf138a834840af85a5
- https://git.kernel.org/stable/c/6cf1874aec42058a5ad621a23b5b2f248def0e96
- https://git.kernel.org/stable/c/80431ea3634efb47a3004305d76486db9dd8ed49
- https://git.kernel.org/stable/c/bd7827d46d403f8cdb43d16744cb1114e4726b21
- https://git.kernel.org/stable/c/c534b63bede6cb987c2946ed4d0b0013a52c5ba7
Modified: 2025-09-29
CVE-2024-38547
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered.
- https://git.kernel.org/stable/c/3b621e9e9e148c0928ab109ac3d4b81487469acb
- https://git.kernel.org/stable/c/4b68b861b514a5c09220d622ac3784c0ebac6c80
- https://git.kernel.org/stable/c/51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
- https://git.kernel.org/stable/c/6482c433863b257b0b9b687c28ce80b89d5f89f0
- https://git.kernel.org/stable/c/69b27ff82f87379afeaaea4b2f339032fdd8486e
- https://git.kernel.org/stable/c/82c2c85aead3ea3cbceef4be077cf459c5df2272
- https://git.kernel.org/stable/c/a1ab99dcc8604afe7e3bccb01b10da03bdd7ea35
- https://git.kernel.org/stable/c/cc20c87b04db86c8e3e810bcdca686b406206069
- https://git.kernel.org/stable/c/3b621e9e9e148c0928ab109ac3d4b81487469acb
- https://git.kernel.org/stable/c/4b68b861b514a5c09220d622ac3784c0ebac6c80
- https://git.kernel.org/stable/c/6482c433863b257b0b9b687c28ce80b89d5f89f0
- https://git.kernel.org/stable/c/69b27ff82f87379afeaaea4b2f339032fdd8486e
- https://git.kernel.org/stable/c/82c2c85aead3ea3cbceef4be077cf459c5df2272
- https://git.kernel.org/stable/c/a1ab99dcc8604afe7e3bccb01b10da03bdd7ea35
- https://git.kernel.org/stable/c/cc20c87b04db86c8e3e810bcdca686b406206069
Modified: 2025-04-01
CVE-2024-38548
In the Linux kernel, the following vulnerability has been resolved: drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode.
- https://git.kernel.org/stable/c/32fb2ef124c3301656ac6c789a2ef35ef69a66da
- https://git.kernel.org/stable/c/47889711da20be9b43e1e136e5cb68df37cbcc79
- https://git.kernel.org/stable/c/85d1a27402f81f2e04b0e67d20f749c2a14edbb3
- https://git.kernel.org/stable/c/89788cd9824c28ffcdea40232c458233353d1896
- https://git.kernel.org/stable/c/935a92a1c400285545198ca2800a4c6c519c650a
- https://git.kernel.org/stable/c/ca53b7efd4ba6ae92fd2b3085cb099c745e96965
- https://git.kernel.org/stable/c/dcf53e6103b26e7458be71491d0641f49fbd5840
- https://git.kernel.org/stable/c/32fb2ef124c3301656ac6c789a2ef35ef69a66da
- https://git.kernel.org/stable/c/47889711da20be9b43e1e136e5cb68df37cbcc79
- https://git.kernel.org/stable/c/85d1a27402f81f2e04b0e67d20f749c2a14edbb3
- https://git.kernel.org/stable/c/89788cd9824c28ffcdea40232c458233353d1896
- https://git.kernel.org/stable/c/935a92a1c400285545198ca2800a4c6c519c650a
- https://git.kernel.org/stable/c/ca53b7efd4ba6ae92fd2b3085cb099c745e96965
- https://git.kernel.org/stable/c/dcf53e6103b26e7458be71491d0641f49fbd5840
Modified: 2025-11-04
CVE-2024-38549
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add 0 size check to mtk_drm_gem_obj Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.
- https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4
- https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05
- https://git.kernel.org/stable/c/1e4350095e8ab2577ee05f8c3b044e661b5af9a0
- https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364
- https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a3151ac7
- https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594
- https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67
- https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350
- https://git.kernel.org/stable/c/fb4aabdb1b48c25d9e1ee28f89440fd2ce556405
- https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4
- https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05
- https://git.kernel.org/stable/c/1e4350095e8ab2577ee05f8c3b044e661b5af9a0
- https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364
- https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a3151ac7
- https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594
- https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67
- https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350
- https://git.kernel.org/stable/c/fb4aabdb1b48c25d9e1ee28f89440fd2ce556405
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-01
CVE-2024-38550
In the Linux kernel, the following vulnerability has been resolved: ASoC: kirkwood: Fix potential NULL dereference In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if CONFIG_PLAT_ORION macro is not defined. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/1a7254525ca7a6f3e37d7882d7f7ad97f6235f7c
- https://git.kernel.org/stable/c/5bf5154739cd676b6d0958079070557c8d96afb6
- https://git.kernel.org/stable/c/802b49e39da669b54bd9b77dc3c649999a446bf6
- https://git.kernel.org/stable/c/d48d0c5fd733bd6d8d3ddb2ed553777ab4724169
- https://git.kernel.org/stable/c/de9987cec6fde1dd41dfcb971433e05945852489
- https://git.kernel.org/stable/c/ea60ab95723f5738e7737b56dda95e6feefa5b50
- https://git.kernel.org/stable/c/1a7254525ca7a6f3e37d7882d7f7ad97f6235f7c
- https://git.kernel.org/stable/c/5bf5154739cd676b6d0958079070557c8d96afb6
- https://git.kernel.org/stable/c/802b49e39da669b54bd9b77dc3c649999a446bf6
- https://git.kernel.org/stable/c/d48d0c5fd733bd6d8d3ddb2ed553777ab4724169
- https://git.kernel.org/stable/c/de9987cec6fde1dd41dfcb971433e05945852489
- https://git.kernel.org/stable/c/ea60ab95723f5738e7737b56dda95e6feefa5b50
Modified: 2024-11-21
CVE-2024-38551
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Assign dummy when codec not specified for a DAI link MediaTek sound card drivers are checking whether a DAI link is present and used on a board to assign the correct parameters and this is done by checking the codec DAI names at probe time. If no real codec is present, assign the dummy codec to the DAI link to avoid NULL pointer during string comparison.
- https://git.kernel.org/stable/c/0c052b1c11d8119f3048b1f7b3c39a90500cacf9
- https://git.kernel.org/stable/c/5f39231888c63f0a7708abc86b51b847476379d8
- https://git.kernel.org/stable/c/87b8dca6e06f9b1681bc52bf7bfa85c663a11158
- https://git.kernel.org/stable/c/cbbcabc7f0979f6542372cf88d7a9da7143a4226
- https://git.kernel.org/stable/c/0c052b1c11d8119f3048b1f7b3c39a90500cacf9
- https://git.kernel.org/stable/c/5f39231888c63f0a7708abc86b51b847476379d8
- https://git.kernel.org/stable/c/87b8dca6e06f9b1681bc52bf7bfa85c663a11158
- https://git.kernel.org/stable/c/cbbcabc7f0979f6542372cf88d7a9da7143a4226
Modified: 2025-11-04
CVE-2024-38552
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential index out of bounds in color transformation function Fixes index out of bounds issue in the color transformation function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, an error message is logged and the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
- https://git.kernel.org/stable/c/04bc4d1090c343025d69149ca669a27c5b9c34a7
- https://git.kernel.org/stable/c/123edbae64f4d21984359b99c6e79fcde31c6123
- https://git.kernel.org/stable/c/4e8c8b37ee84b3b19c448d2b8e4c916d2f5b9c86
- https://git.kernel.org/stable/c/604c506ca43fce52bb882cff9c1fdf2ec3b4029c
- https://git.kernel.org/stable/c/63ae548f1054a0b71678d0349c7dc9628ddd42ca
- https://git.kernel.org/stable/c/7226ddf3311c5e5a7726ad7d4e7b079bb3cfbb29
- https://git.kernel.org/stable/c/98b8a6bfd30d07a19cfacdf82b50f84bf3360869
- https://git.kernel.org/stable/c/ced9c4e2289a786b8fa684d8893b7045ea53ef7e
- https://git.kernel.org/stable/c/e280ab978c81443103d7c61bdd1d8d708cf6ed6d
- https://git.kernel.org/stable/c/04bc4d1090c343025d69149ca669a27c5b9c34a7
- https://git.kernel.org/stable/c/123edbae64f4d21984359b99c6e79fcde31c6123
- https://git.kernel.org/stable/c/4e8c8b37ee84b3b19c448d2b8e4c916d2f5b9c86
- https://git.kernel.org/stable/c/604c506ca43fce52bb882cff9c1fdf2ec3b4029c
- https://git.kernel.org/stable/c/63ae548f1054a0b71678d0349c7dc9628ddd42ca
- https://git.kernel.org/stable/c/7226ddf3311c5e5a7726ad7d4e7b079bb3cfbb29
- https://git.kernel.org/stable/c/98b8a6bfd30d07a19cfacdf82b50f84bf3360869
- https://git.kernel.org/stable/c/ced9c4e2289a786b8fa684d8893b7045ea53ef7e
- https://git.kernel.org/stable/c/e280ab978c81443103d7c61bdd1d8d708cf6ed6d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-38553
In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.
- https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f
- https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243
- https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5
- https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e
- https://git.kernel.org/stable/c/e2348d8c61d03feece1de4c05f72e6e99f74c650
- https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f
- https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243
- https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5
- https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-38554
In the Linux kernel, the following vulnerability has been resolved: ax25: Fix reference count leak issue of net_device There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak. In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null.
- https://git.kernel.org/stable/c/36e56b1b002bb26440403053f19f9e1a8bc075b2
- https://git.kernel.org/stable/c/3ec437f9bbae68e9b38115c4c91de995f73f6bad
- https://git.kernel.org/stable/c/8bad3a20a27be8d935f2aae08d3c6e743754944a
- https://git.kernel.org/stable/c/965d940fb7414b310a22666503d2af69459c981b
- https://git.kernel.org/stable/c/eef95df9b752699bddecefa851f64858247246e9
- https://git.kernel.org/stable/c/36e56b1b002bb26440403053f19f9e1a8bc075b2
- https://git.kernel.org/stable/c/3ec437f9bbae68e9b38115c4c91de995f73f6bad
- https://git.kernel.org/stable/c/8bad3a20a27be8d935f2aae08d3c6e743754944a
- https://git.kernel.org/stable/c/965d940fb7414b310a22666503d2af69459c981b
- https://git.kernel.org/stable/c/eef95df9b752699bddecefa851f64858247246e9
Modified: 2024-11-21
CVE-2024-38555
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Discard command completions in internal error
Fix use after free when FW completion arrives while device is in
internal error state. Avoid calling completion handler in this case,
since the device will flush the command interface and trigger all
completions manually.
Kernel log:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
...
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
...
Call Trace:
- https://git.kernel.org/stable/c/1337ec94bc5a9eed250e33f5f5c89a28a6bfabdb
- https://git.kernel.org/stable/c/1d5dce5e92a70274de67a59e1e674c3267f94cd7
- https://git.kernel.org/stable/c/3cb92b0ad73d3f1734e812054e698d655e9581b0
- https://git.kernel.org/stable/c/7ac4c69c34240c6de820492c0a28a0bd1494265a
- https://git.kernel.org/stable/c/bf8aaf0ae01c27ae3c06aa8610caf91e50393396
- https://git.kernel.org/stable/c/db9b31aa9bc56ff0d15b78f7e827d61c4a096e40
- https://git.kernel.org/stable/c/f6fbb8535e990f844371086ab2c1221f71f993d3
- https://git.kernel.org/stable/c/1337ec94bc5a9eed250e33f5f5c89a28a6bfabdb
- https://git.kernel.org/stable/c/1d5dce5e92a70274de67a59e1e674c3267f94cd7
- https://git.kernel.org/stable/c/3cb92b0ad73d3f1734e812054e698d655e9581b0
- https://git.kernel.org/stable/c/7ac4c69c34240c6de820492c0a28a0bd1494265a
- https://git.kernel.org/stable/c/bf8aaf0ae01c27ae3c06aa8610caf91e50393396
- https://git.kernel.org/stable/c/db9b31aa9bc56ff0d15b78f7e827d61c4a096e40
- https://git.kernel.org/stable/c/f6fbb8535e990f844371086ab2c1221f71f993d3
Modified: 2025-03-06
CVE-2024-38556
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Add a timeout to acquire the command queue semaphore Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion. Kernel log example: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion
- https://git.kernel.org/stable/c/2d0962d05c93de391ce85f6e764df895f47c8918
- https://git.kernel.org/stable/c/485d65e1357123a697c591a5aeb773994b247ad7
- https://git.kernel.org/stable/c/4baae687a20ef2b82fde12de3c04461e6f2521d6
- https://git.kernel.org/stable/c/94024332a129c6e4275569d85c0c1bfb2ae2d71b
- https://git.kernel.org/stable/c/f9caccdd42e999b74303c9b0643300073ed5d319
- https://git.kernel.org/stable/c/2d0962d05c93de391ce85f6e764df895f47c8918
- https://git.kernel.org/stable/c/485d65e1357123a697c591a5aeb773994b247ad7
- https://git.kernel.org/stable/c/4baae687a20ef2b82fde12de3c04461e6f2521d6
- https://git.kernel.org/stable/c/94024332a129c6e4275569d85c0c1bfb2ae2d71b
- https://git.kernel.org/stable/c/f9caccdd42e999b74303c9b0643300073ed5d319
Modified: 2024-11-21
CVE-2024-38557
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Reload only IB representors upon lag disable/enable On lag disable, the bond IB device along with all of its representors are destroyed, and then the slaves' representors get reloaded. In case the slave IB representor load fails, the eswitch error flow unloads all representors, including ethernet representors, where the netdevs get detached and removed from lag bond. Such flow is inaccurate as the lag driver is not responsible for loading/unloading ethernet representors. Furthermore, the flow described above begins by holding lag lock to prevent bond changes during disable flow. However, when reaching the ethernet representors detachment from lag, the lag lock is required again, triggering the following deadlock: Call trace: __switch_to+0xf4/0x148 __schedule+0x2c8/0x7d0 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x28 __mutex_lock.isra.13+0x2b8/0x570 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x4c/0x68 mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core] mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core] mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core] mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core] mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core] mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core] mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core] mlx5_disable_lag+0x130/0x138 [mlx5_core] mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core] devlink_nl_cmd_eswitch_set_doit+0xdc/0x180 genl_family_rcv_msg_doit.isra.17+0xe8/0x138 genl_rcv_msg+0xe4/0x220 netlink_rcv_skb+0x44/0x108 genl_rcv+0x40/0x58 netlink_unicast+0x198/0x268 netlink_sendmsg+0x1d4/0x418 sock_sendmsg+0x54/0x60 __sys_sendto+0xf4/0x120 __arm64_sys_sendto+0x30/0x40 el0_svc_common+0x8c/0x120 do_el0_svc+0x30/0xa0 el0_svc+0x20/0x30 el0_sync_handler+0x90/0xb8 el0_sync+0x160/0x180 Thus, upon lag enable/disable, load and unload only the IB representors of the slaves preventing the deadlock mentioned above. While at it, refactor the mlx5_esw_offloads_rep_load() function to have a static helper method for its internal logic, in symmetry with the representor unload design.
- https://git.kernel.org/stable/c/0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4
- https://git.kernel.org/stable/c/0f320f28f54b1b269a755be2e3fb3695e0b80b07
- https://git.kernel.org/stable/c/e93fc8d959e56092e2eca1e5511c2d2f0ad6807a
- https://git.kernel.org/stable/c/f03c714a0fdd1f93101a929d0e727c28a66383fc
- https://git.kernel.org/stable/c/0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4
- https://git.kernel.org/stable/c/0f320f28f54b1b269a755be2e3fb3695e0b80b07
- https://git.kernel.org/stable/c/e93fc8d959e56092e2eca1e5511c2d2f0ad6807a
- https://git.kernel.org/stable/c/f03c714a0fdd1f93101a929d0e727c28a66383fc
Modified: 2025-11-04
CVE-2024-38558
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix overwriting ct original tuple for ICMPv6 OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.
- https://git.kernel.org/stable/c/0b532f59437f688563e9c58bdc1436fefa46e3b5
- https://git.kernel.org/stable/c/431e9215576d7b728f3f53a704d237a520092120
- https://git.kernel.org/stable/c/483eb70f441e2df66ade78aa7217e6e4caadfef3
- https://git.kernel.org/stable/c/5ab6aecbede080b44b8e34720ab72050bf1e6982
- https://git.kernel.org/stable/c/6a51ac92bf35d34b4996d6eb67e2fe469f573b11
- https://git.kernel.org/stable/c/78741b4caae1e880368cb2f5110635f3ce45ecfd
- https://git.kernel.org/stable/c/7c988176b6c16c516474f6fceebe0f055af5eb56
- https://git.kernel.org/stable/c/9ec8b0ccadb908d92f7ee211a4eff05fd932f3f6
- https://git.kernel.org/stable/c/d73fb8bddf89503c9fae7c42e50d44c89909aad6
- https://git.kernel.org/stable/c/0b532f59437f688563e9c58bdc1436fefa46e3b5
- https://git.kernel.org/stable/c/431e9215576d7b728f3f53a704d237a520092120
- https://git.kernel.org/stable/c/483eb70f441e2df66ade78aa7217e6e4caadfef3
- https://git.kernel.org/stable/c/5ab6aecbede080b44b8e34720ab72050bf1e6982
- https://git.kernel.org/stable/c/6a51ac92bf35d34b4996d6eb67e2fe469f573b11
- https://git.kernel.org/stable/c/78741b4caae1e880368cb2f5110635f3ce45ecfd
- https://git.kernel.org/stable/c/7c988176b6c16c516474f6fceebe0f055af5eb56
- https://git.kernel.org/stable/c/9ec8b0ccadb908d92f7ee211a4eff05fd932f3f6
- https://git.kernel.org/stable/c/d73fb8bddf89503c9fae7c42e50d44c89909aad6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-38559
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Ensure the copied buf is NUL terminated Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user.
- https://git.kernel.org/stable/c/177f43c6892e6055de6541fe9391a8a3d1f95fc9
- https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95
- https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebbd3f20b8
- https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d
- https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c
- https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59
- https://git.kernel.org/stable/c/d0184a375ee797eb657d74861ba0935b6e405c62
- https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613
- https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255
- https://git.kernel.org/stable/c/177f43c6892e6055de6541fe9391a8a3d1f95fc9
- https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95
- https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebbd3f20b8
- https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d
- https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c
- https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59
- https://git.kernel.org/stable/c/d0184a375ee797eb657d74861ba0935b6e405c62
- https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613
- https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-38560
In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.
- https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a
- https://git.kernel.org/stable/c/13d0cecb4626fae67c00c84d3c7851f6b62f7df3
- https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf
- https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35
- https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462
- https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2
- https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec3334b4143
- https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c
- https://git.kernel.org/stable/c/ecb76200f5557a2886888aaa53702da1ab9e6cdf
- https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a
- https://git.kernel.org/stable/c/13d0cecb4626fae67c00c84d3c7851f6b62f7df3
- https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf
- https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35
- https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462
- https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2
- https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec3334b4143
- https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c
- https://git.kernel.org/stable/c/ecb76200f5557a2886888aaa53702da1ab9e6cdf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38561
In the Linux kernel, the following vulnerability has been resolved: kunit: Fix kthread reference There is a race condition when a kthread finishes after the deadline and before the call to kthread_stop(), which may lead to use after free.
- https://git.kernel.org/stable/c/1ec7ccb4cd4b6f72c2998b07880fa7aaf8dfe1d4
- https://git.kernel.org/stable/c/1f2ebd3758e1cef6a1f998a1f7ea73310dcb1699
- https://git.kernel.org/stable/c/8f5c841a559ccb700c8d27a3ca645b7a5f59b4f5
- https://git.kernel.org/stable/c/b0b755cb5a5e0d7168c3ab1b3814b0d3cad9f017
- https://git.kernel.org/stable/c/f8aa1b98ce40184521ed95ec26cc115a255183b2
- https://git.kernel.org/stable/c/1ec7ccb4cd4b6f72c2998b07880fa7aaf8dfe1d4
- https://git.kernel.org/stable/c/1f2ebd3758e1cef6a1f998a1f7ea73310dcb1699
- https://git.kernel.org/stable/c/8f5c841a559ccb700c8d27a3ca645b7a5f59b4f5
- https://git.kernel.org/stable/c/b0b755cb5a5e0d7168c3ab1b3814b0d3cad9f017
- https://git.kernel.org/stable/c/f8aa1b98ce40184521ed95ec26cc115a255183b2
Modified: 2024-11-21
CVE-2024-38562
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: Avoid address calculations via out of bounds array indexing Before request->channels[] can be used, request->n_channels must be set. Additionally, address calculations for memory after the "channels" array need to be calculated from the allocation base ("request") rather than via the first "out of bounds" index of "channels", otherwise run-time bounds checking will throw a warning.
- https://git.kernel.org/stable/c/4e2a5566462b53db7d4c4722da86eedf0b8f546c
- https://git.kernel.org/stable/c/838c7b8f1f278404d9d684c34a8cb26dc41aaaa1
- https://git.kernel.org/stable/c/8fa4d56564ee7cc2ee348258d88efe191d70dd7f
- https://git.kernel.org/stable/c/ed74398642fcb19f6ff385c35a7d512c6663e17b
- https://git.kernel.org/stable/c/4e2a5566462b53db7d4c4722da86eedf0b8f546c
- https://git.kernel.org/stable/c/838c7b8f1f278404d9d684c34a8cb26dc41aaaa1
- https://git.kernel.org/stable/c/8fa4d56564ee7cc2ee348258d88efe191d70dd7f
- https://git.kernel.org/stable/c/ed74398642fcb19f6ff385c35a7d512c6663e17b
Modified: 2025-10-20
CVE-2024-38564
In the Linux kernel, the following vulnerability has been resolved: bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks.
- https://git.kernel.org/stable/c/543576ec15b17c0c93301ac8297333c7b6e84ac7
- https://git.kernel.org/stable/c/6675c541f540a29487a802d3135280b69b9f568d
- https://git.kernel.org/stable/c/67929e973f5a347f05fef064fea4ae79e7cdb5fd
- https://git.kernel.org/stable/c/b34bbc76651065a5eafad8ddff1eb8d1f8473172
- https://git.kernel.org/stable/c/543576ec15b17c0c93301ac8297333c7b6e84ac7
- https://git.kernel.org/stable/c/6675c541f540a29487a802d3135280b69b9f568d
- https://git.kernel.org/stable/c/67929e973f5a347f05fef064fea4ae79e7cdb5fd
- https://git.kernel.org/stable/c/b34bbc76651065a5eafad8ddff1eb8d1f8473172
Modified: 2025-11-04
CVE-2024-38565
In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use
not having an expected type to it.
Fix the issue by checking for the existence of all proper
endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report:
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
- https://git.kernel.org/stable/c/34f7ebff1b9699e0b89fa58b693bc098c2f5ec72
- https://git.kernel.org/stable/c/68a5a00c5d38978a3f8460c6f182f7beec8688ff
- https://git.kernel.org/stable/c/79ddf5f2020fd593d50f1363bb5131283d74f78f
- https://git.kernel.org/stable/c/7bbf76c9bb2c58375e183074e44f9712483f0603
- https://git.kernel.org/stable/c/b33a81e4ecfb022b028cae37d1c1ce28ac1b359d
- https://git.kernel.org/stable/c/b4c24de37a6bb383394a6fef2b85a6db41d426f5
- https://git.kernel.org/stable/c/beeed260b92af158592f5e8d2dab65dae45c6f70
- https://git.kernel.org/stable/c/e120b6388d7d88635d67dcae6483f39c37111850
- https://git.kernel.org/stable/c/ee25389df80138907bc9dcdf4a2be2067cde9a81
- https://git.kernel.org/stable/c/34f7ebff1b9699e0b89fa58b693bc098c2f5ec72
- https://git.kernel.org/stable/c/68a5a00c5d38978a3f8460c6f182f7beec8688ff
- https://git.kernel.org/stable/c/79ddf5f2020fd593d50f1363bb5131283d74f78f
- https://git.kernel.org/stable/c/7bbf76c9bb2c58375e183074e44f9712483f0603
- https://git.kernel.org/stable/c/b33a81e4ecfb022b028cae37d1c1ce28ac1b359d
- https://git.kernel.org/stable/c/b4c24de37a6bb383394a6fef2b85a6db41d426f5
- https://git.kernel.org/stable/c/beeed260b92af158592f5e8d2dab65dae45c6f70
- https://git.kernel.org/stable/c/e120b6388d7d88635d67dcae6483f39c37111850
- https://git.kernel.org/stable/c/ee25389df80138907bc9dcdf4a2be2067cde9a81
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-17
CVE-2024-38566
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix verifier assumptions about socket->sk The verifier assumes that 'sk' field in 'struct socket' is valid and non-NULL when 'socket' pointer itself is trusted and non-NULL. That may not be the case when socket was just created and passed to LSM socket_accept hook. Fix this verifier assumption and adjust tests.
- https://git.kernel.org/stable/c/0db63c0b86e981a1e97d2596d64ceceba1a5470e
- https://git.kernel.org/stable/c/39f8a29330f433000e716eefc4b9abda05b71a82
- https://git.kernel.org/stable/c/6f5ae91172a93abac9720ba94edf3ec8f4d7f24f
- https://git.kernel.org/stable/c/c58ccdd2483a1d990748cdaf94206b5d5986a001
- https://git.kernel.org/stable/c/0db63c0b86e981a1e97d2596d64ceceba1a5470e
- https://git.kernel.org/stable/c/39f8a29330f433000e716eefc4b9abda05b71a82
- https://git.kernel.org/stable/c/6f5ae91172a93abac9720ba94edf3ec8f4d7f24f
- https://git.kernel.org/stable/c/c58ccdd2483a1d990748cdaf94206b5d5986a001
Modified: 2025-11-04
CVE-2024-38567
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: add a proper sanity check for endpoints
Syzkaller reports [1] hitting a warning which is caused by presence
of a wrong endpoint type at the URB sumbitting stage. While there
was a check for a specific 4th endpoint, since it can switch types
between bulk and interrupt, other endpoints are trusted implicitly.
Similar warning is triggered in a couple of other syzbot issues [2].
Fix the issue by doing a comprehensive check of all endpoints
taking into account difference between high- and full-speed
configuration.
[1] Syzkaller report:
...
WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
- https://git.kernel.org/stable/c/03ddc74bdfd71b84a55c9f2185d8787f258422cd
- https://git.kernel.org/stable/c/0fa08a55201ab9be72bacb8ea93cf752d338184f
- https://git.kernel.org/stable/c/265c3cda471c26e0f25d0c755da94e1eb15d7a0c
- https://git.kernel.org/stable/c/62eb07923f3693d55b0c2d9a5a4f1ad72cb6b8fd
- https://git.kernel.org/stable/c/6a9892bf24c906b4d6b587f8759ca38bff672582
- https://git.kernel.org/stable/c/8650725bb0a48b206d5a8ddad3a7488f9a5985b7
- https://git.kernel.org/stable/c/ac3ed46a8741d464bc70ebdf7433c1d786cf329d
- https://git.kernel.org/stable/c/b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0
- https://git.kernel.org/stable/c/eb0f2fc3ff5806cc572cd9055ce7c52a01e97645
- https://git.kernel.org/stable/c/03ddc74bdfd71b84a55c9f2185d8787f258422cd
- https://git.kernel.org/stable/c/0fa08a55201ab9be72bacb8ea93cf752d338184f
- https://git.kernel.org/stable/c/265c3cda471c26e0f25d0c755da94e1eb15d7a0c
- https://git.kernel.org/stable/c/62eb07923f3693d55b0c2d9a5a4f1ad72cb6b8fd
- https://git.kernel.org/stable/c/6a9892bf24c906b4d6b587f8759ca38bff672582
- https://git.kernel.org/stable/c/8650725bb0a48b206d5a8ddad3a7488f9a5985b7
- https://git.kernel.org/stable/c/ac3ed46a8741d464bc70ebdf7433c1d786cf329d
- https://git.kernel.org/stable/c/b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0
- https://git.kernel.org/stable/c/eb0f2fc3ff5806cc572cd9055ce7c52a01e97645
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38568
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the memory write overflow of event_group array occurs. Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds. There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}
- https://git.kernel.org/stable/c/3669baf308308385a2ab391324abdde5682af5aa
- https://git.kernel.org/stable/c/81bdd60a3d1d3b05e6cc6674845afb1694dd3a0e
- https://git.kernel.org/stable/c/aa2d3d678895c8eedd003f1473f87d3f06fe6ec7
- https://git.kernel.org/stable/c/b5120d322763c15c978bc47beb3b6dff45624304
- https://git.kernel.org/stable/c/be1fa711e59c874d049f592aef1d4685bdd22bdf
- https://git.kernel.org/stable/c/3669baf308308385a2ab391324abdde5682af5aa
- https://git.kernel.org/stable/c/81bdd60a3d1d3b05e6cc6674845afb1694dd3a0e
- https://git.kernel.org/stable/c/aa2d3d678895c8eedd003f1473f87d3f06fe6ec7
- https://git.kernel.org/stable/c/b5120d322763c15c978bc47beb3b6dff45624304
- https://git.kernel.org/stable/c/be1fa711e59c874d049f592aef1d4685bdd22bdf
Modified: 2024-11-21
CVE-2024-38569
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write overflow of event_group array occurs. Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds. There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'
- https://git.kernel.org/stable/c/3d1face00ebb7996842aee4214d7d0fb0c77b1e9
- https://git.kernel.org/stable/c/567d34626c22b36579ec0abfdf5eda2949044220
- https://git.kernel.org/stable/c/77fce82678ea5fd51442e62febec2004f79e041b
- https://git.kernel.org/stable/c/8e9aab2492178f25372f1820bfd9289fbd74efd0
- https://git.kernel.org/stable/c/ff48247144d13a3a0817127703724256008efa78
- https://git.kernel.org/stable/c/3d1face00ebb7996842aee4214d7d0fb0c77b1e9
- https://git.kernel.org/stable/c/567d34626c22b36579ec0abfdf5eda2949044220
- https://git.kernel.org/stable/c/77fce82678ea5fd51442e62febec2004f79e041b
- https://git.kernel.org/stable/c/8e9aab2492178f25372f1820bfd9289fbd74efd0
- https://git.kernel.org/stable/c/ff48247144d13a3a0817127703724256008efa78
Modified: 2024-11-21
CVE-2024-38570
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
- https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37
- https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca
- https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73
- https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0
- https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37
- https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca
- https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73
- https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0
Modified: 2024-11-21
CVE-2024-38571
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tsens: Fix null pointer dereference compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c) as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null pointer dereference (if DEBUG or DYNAMIC_DEBUG set). Fix this bug by adding null pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/06d17744b77bc6cb29a6c785f4fad8c4163ee653
- https://git.kernel.org/stable/c/11c731386ed82053c2759b6fea1a82ae946e5e0f
- https://git.kernel.org/stable/c/27600e0c5272a262b0903e35ae1df37d33c5c1ad
- https://git.kernel.org/stable/c/2d5ca6e4a2872e92a32fdfd87e04dd7d3ced7278
- https://git.kernel.org/stable/c/d998ddc86a27c92140b9f7984ff41e3d1d07a48f
- https://git.kernel.org/stable/c/fcf5f1b5f308f2eb422f6aca55d295b25890906b
- https://git.kernel.org/stable/c/06d17744b77bc6cb29a6c785f4fad8c4163ee653
- https://git.kernel.org/stable/c/11c731386ed82053c2759b6fea1a82ae946e5e0f
- https://git.kernel.org/stable/c/27600e0c5272a262b0903e35ae1df37d33c5c1ad
- https://git.kernel.org/stable/c/2d5ca6e4a2872e92a32fdfd87e04dd7d3ced7278
- https://git.kernel.org/stable/c/d998ddc86a27c92140b9f7984ff41e3d1d07a48f
- https://git.kernel.org/stable/c/fcf5f1b5f308f2eb422f6aca55d295b25890906b
Modified: 2025-09-17
CVE-2024-38572
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix out-of-bound access of qmi_invoke_handler() Currently, there is no terminator entry for ath12k_qmi_msg_handlers hence facing below KASAN warning, ================================================================== BUG: KASAN: global-out-of-bounds in qmi_invoke_handler+0xa4/0x148 Read of size 8 at addr ffffffd00a6428d8 by task kworker/u8:2/1273 CPU: 0 PID: 1273 Comm: kworker/u8:2 Not tainted 5.4.213 #0 Workqueue: qmi_msg_handler qmi_data_ready_work Call trace: dump_backtrace+0x0/0x20c show_stack+0x14/0x1c dump_stack+0xe0/0x138 print_address_description.isra.5+0x30/0x330 __kasan_report+0x16c/0x1bc kasan_report+0xc/0x14 __asan_load8+0xa8/0xb0 qmi_invoke_handler+0xa4/0x148 qmi_handle_message+0x18c/0x1bc qmi_data_ready_work+0x4ec/0x528 process_one_work+0x2c0/0x440 worker_thread+0x324/0x4b8 kthread+0x210/0x228 ret_from_fork+0x10/0x18 The address belongs to the variable: ath12k_mac_mon_status_filter_default+0x4bd8/0xfffffffffffe2300 [ath12k] [...] ================================================================== Add a dummy terminator entry at the end to assist the qmi_invoke_handler() in traversing up to the terminator entry without accessing an out-of-boundary index. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
- https://git.kernel.org/stable/c/95575de7dede7b1ed3b9718dab9dda97914ea775
- https://git.kernel.org/stable/c/a1abdb63628b04855a929850772de97435ed1555
- https://git.kernel.org/stable/c/b48d40f5840c505b7af700594aa8379eec28e925
- https://git.kernel.org/stable/c/e1bdff48a1bb4a4ac660c19c55a820968c48b3f2
- https://git.kernel.org/stable/c/95575de7dede7b1ed3b9718dab9dda97914ea775
- https://git.kernel.org/stable/c/a1abdb63628b04855a929850772de97435ed1555
- https://git.kernel.org/stable/c/b48d40f5840c505b7af700594aa8379eec28e925
- https://git.kernel.org/stable/c/e1bdff48a1bb4a4ac660c19c55a820968c48b3f2
Modified: 2025-04-01
CVE-2024-38573
In the Linux kernel, the following vulnerability has been resolved: cppc_cpufreq: Fix possible null pointer dereference cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/769c4f355b7962895205b86ad35617873feef9a5
- https://git.kernel.org/stable/c/9a185cc5a79ba408e1c73375706630662304f618
- https://git.kernel.org/stable/c/b18daa4ec727c0266de5bfc78e818d168cc4aedf
- https://git.kernel.org/stable/c/cf7de25878a1f4508c69dc9f6819c21ba177dbfe
- https://git.kernel.org/stable/c/dfec15222529d22b15e5b0d63572a9e39570cab4
- https://git.kernel.org/stable/c/f84b9b25d045e67a7eee5e73f21278c8ab06713c
- https://git.kernel.org/stable/c/769c4f355b7962895205b86ad35617873feef9a5
- https://git.kernel.org/stable/c/9a185cc5a79ba408e1c73375706630662304f618
- https://git.kernel.org/stable/c/b18daa4ec727c0266de5bfc78e818d168cc4aedf
- https://git.kernel.org/stable/c/cf7de25878a1f4508c69dc9f6819c21ba177dbfe
- https://git.kernel.org/stable/c/dfec15222529d22b15e5b0d63572a9e39570cab4
- https://git.kernel.org/stable/c/f84b9b25d045e67a7eee5e73f21278c8ab06713c
Modified: 2025-01-31
CVE-2024-38575
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: pcie: handle randbuf allocation failure The kzalloc() in brcmf_pcie_download_fw_nvram() will return null if the physical memory has run out. As a result, if we use get_random_bytes() to generate random bytes in the randbuf, the null pointer dereference bug will happen. In order to prevent allocation failure, this patch adds a separate function using buffer on kernel stack to generate random bytes in the randbuf, which could prevent the kernel stack from overflow.
- https://git.kernel.org/stable/c/0eb2c0528e232b3c32cde9d5e1c9f80ba2996e49
- https://git.kernel.org/stable/c/316f790ebcf94bdf59f794b7cdea4068dc676d4c
- https://git.kernel.org/stable/c/3729ca9e48d19a03ae049e2bde510e161c2f3720
- https://git.kernel.org/stable/c/7c15eb344b0d4d3468c9b2a7591ad2b859b29b88
- https://git.kernel.org/stable/c/c37466406f075476c2702ecc01917928af871f3b
- https://git.kernel.org/stable/c/0eb2c0528e232b3c32cde9d5e1c9f80ba2996e49
- https://git.kernel.org/stable/c/316f790ebcf94bdf59f794b7cdea4068dc676d4c
- https://git.kernel.org/stable/c/3729ca9e48d19a03ae049e2bde510e161c2f3720
- https://git.kernel.org/stable/c/7c15eb344b0d4d3468c9b2a7591ad2b859b29b88
- https://git.kernel.org/stable/c/c37466406f075476c2702ecc01917928af871f3b
Modified: 2025-04-01
CVE-2024-38576
In the Linux kernel, the following vulnerability has been resolved: rcu: Fix buffer overflow in print_cpu_stall_info() The rcuc-starvation output from print_cpu_stall_info() might overflow the buffer if there is a huge difference in jiffies difference. The situation might seem improbable, but computers sometimes get very confused about time, which can result in full-sized integers, and, in this case, buffer overflow. Also, the unsigned jiffies difference is printed using %ld, which is normally for signed integers. This is intentional for debugging purposes, but it is not obvious from the code. This commit therefore changes sprintf() to snprintf() and adds a clarifying comment about intention of %ld format. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/3758f7d9917bd7ef0482c4184c0ad673b4c4e069
- https://git.kernel.org/stable/c/4c3e2ef4d8ddd313c8ce3ac30505940bea8d6257
- https://git.kernel.org/stable/c/9351e1338539cb7f319ffc1210fa9b2aa27384b5
- https://git.kernel.org/stable/c/afb39909bfb5c08111f99e21bf5be7505f59ff1c
- https://git.kernel.org/stable/c/e2228ed3fe7aa838fba87c79a76fb1ad9ea47138
- https://git.kernel.org/stable/c/3758f7d9917bd7ef0482c4184c0ad673b4c4e069
- https://git.kernel.org/stable/c/4c3e2ef4d8ddd313c8ce3ac30505940bea8d6257
- https://git.kernel.org/stable/c/9351e1338539cb7f319ffc1210fa9b2aa27384b5
- https://git.kernel.org/stable/c/afb39909bfb5c08111f99e21bf5be7505f59ff1c
- https://git.kernel.org/stable/c/e2228ed3fe7aa838fba87c79a76fb1ad9ea47138
Modified: 2025-11-03
CVE-2024-38577
In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/08186d0c5fb64a1cc4b43e009314ee6b173ed222
- https://git.kernel.org/stable/c/17c43211d45f13d1badea3942b76bf16bcc49281
- https://git.kernel.org/stable/c/1a240e138071b25944ded0f5b3e357aa99fabcb7
- https://git.kernel.org/stable/c/32d988f48ed287e676a29a15ac30701c35849aec
- https://git.kernel.org/stable/c/6593d857ce5b5b802fb73d8091ac9c84b92c1697
- https://git.kernel.org/stable/c/af7b560c88fb420099e29890aa682b8a3efc8784
- https://git.kernel.org/stable/c/cc5645fddb0ce28492b15520306d092730dffa48
- https://git.kernel.org/stable/c/08186d0c5fb64a1cc4b43e009314ee6b173ed222
- https://git.kernel.org/stable/c/1a240e138071b25944ded0f5b3e357aa99fabcb7
- https://git.kernel.org/stable/c/32d988f48ed287e676a29a15ac30701c35849aec
- https://git.kernel.org/stable/c/6593d857ce5b5b802fb73d8091ac9c84b92c1697
- https://git.kernel.org/stable/c/cc5645fddb0ce28492b15520306d092730dffa48
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
Modified: 2025-11-04
CVE-2024-38578
In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: Fix buffer size for tag 66 packet
The 'TAG 66 Packet Format' description is missing the cipher code and
checksum fields that are packed into the message packet. As a result,
the buffer allocated for the packet is 3 bytes too small and
write_tag_66_packet() will write up to 3 bytes past the end of the
buffer.
Fix this by increasing the size of the allocation so the whole packet
will always fit in the buffer.
This fixes the below kasan slab-out-of-bounds bug:
BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
Write of size 1 at addr ffff88800afbb2a5 by task touch/181
CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/0d0f8ba042af16519f1ef7dd10463a33b21b677c
- https://git.kernel.org/stable/c/12db25a54ce6bb22b0af28010fff53ef9cb3fe93
- https://git.kernel.org/stable/c/1c125b9287e58f364d82174efb167414b92b11f1
- https://git.kernel.org/stable/c/235b85981051cd68fc215fd32a81c6f116bfc4df
- https://git.kernel.org/stable/c/2ed750b7ae1b5dc72896d7dd114c419afd3d1910
- https://git.kernel.org/stable/c/85a6a1aff08ec9f5b929d345d066e2830e8818e5
- https://git.kernel.org/stable/c/a20f09452e2f58f761d11ad7b96b5c894c91030e
- https://git.kernel.org/stable/c/edbfc42ab080e78c6907d40a42c9d10b69e445c1
- https://git.kernel.org/stable/c/f6008487f1eeb8693f8d2a36a89c87d9122ddf74
- https://git.kernel.org/stable/c/0d0f8ba042af16519f1ef7dd10463a33b21b677c
- https://git.kernel.org/stable/c/12db25a54ce6bb22b0af28010fff53ef9cb3fe93
- https://git.kernel.org/stable/c/1c125b9287e58f364d82174efb167414b92b11f1
- https://git.kernel.org/stable/c/235b85981051cd68fc215fd32a81c6f116bfc4df
- https://git.kernel.org/stable/c/2ed750b7ae1b5dc72896d7dd114c419afd3d1910
- https://git.kernel.org/stable/c/85a6a1aff08ec9f5b929d345d066e2830e8818e5
- https://git.kernel.org/stable/c/a20f09452e2f58f761d11ad7b96b5c894c91030e
- https://git.kernel.org/stable/c/edbfc42ab080e78c6907d40a42c9d10b69e445c1
- https://git.kernel.org/stable/c/f6008487f1eeb8693f8d2a36a89c87d9122ddf74
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-38579
In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - Fix pointer arithmetic In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9
- https://git.kernel.org/stable/c/3b7a40740f04e2f27114dfd6225c5e721dda9d57
- https://git.kernel.org/stable/c/49833a8da6407e7e9b532cc4054fdbcaf78f5fdd
- https://git.kernel.org/stable/c/c0082ee420639a97e40cae66778b02b341b005e5
- https://git.kernel.org/stable/c/c256b616067bfd6d274c679c06986b78d2402434
- https://git.kernel.org/stable/c/c69a1e4b419c2c466dd8c5602bdebadc353973dd
- https://git.kernel.org/stable/c/d0f14ae223c2421b334c1f1a9e48f1e809aee3a0
- https://git.kernel.org/stable/c/e719c8991c161977a67197775067ab456b518c7b
- https://git.kernel.org/stable/c/ebed0d666fa709bae9e8cafa8ec6e7ebd1d318c6
- https://git.kernel.org/stable/c/2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9
- https://git.kernel.org/stable/c/3b7a40740f04e2f27114dfd6225c5e721dda9d57
- https://git.kernel.org/stable/c/49833a8da6407e7e9b532cc4054fdbcaf78f5fdd
- https://git.kernel.org/stable/c/c0082ee420639a97e40cae66778b02b341b005e5
- https://git.kernel.org/stable/c/c256b616067bfd6d274c679c06986b78d2402434
- https://git.kernel.org/stable/c/c69a1e4b419c2c466dd8c5602bdebadc353973dd
- https://git.kernel.org/stable/c/d0f14ae223c2421b334c1f1a9e48f1e809aee3a0
- https://git.kernel.org/stable/c/e719c8991c161977a67197775067ab456b518c7b
- https://git.kernel.org/stable/c/ebed0d666fa709bae9e8cafa8ec6e7ebd1d318c6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-10-20
CVE-2024-38580
In the Linux kernel, the following vulnerability has been resolved: epoll: be better about file lifetimes epoll can call out to vfs_poll() with a file pointer that may race with the last 'fput()'. That would make f_count go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that f_count is already dead, and any use of it won't actually get a reference to the file any more: it's dead regardless. Make sure we have a valid ref on the file pointer before we call down to vfs_poll() from the epoll routines.
- https://git.kernel.org/stable/c/16e3182f6322575eb7c12e728ad3c7986a189d5d
- https://git.kernel.org/stable/c/4efaa5acf0a1d2b5947f98abb3acf8bfd966422b
- https://git.kernel.org/stable/c/4f65f4defe4e23659275ce5153541cd4f76ce2d2
- https://git.kernel.org/stable/c/559214eb4e5c3d05e69428af2fae2691ba1eb784
- https://git.kernel.org/stable/c/cbfd1088e24ec4c1199756a37cb8e4cd0a4b016e
- https://git.kernel.org/stable/c/16e3182f6322575eb7c12e728ad3c7986a189d5d
- https://git.kernel.org/stable/c/4efaa5acf0a1d2b5947f98abb3acf8bfd966422b
- https://git.kernel.org/stable/c/4f65f4defe4e23659275ce5153541cd4f76ce2d2
- https://git.kernel.org/stable/c/559214eb4e5c3d05e69428af2fae2691ba1eb784
- https://git.kernel.org/stable/c/cbfd1088e24ec4c1199756a37cb8e4cd0a4b016e
Modified: 2025-05-27
CVE-2024-38581
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/mes: fix use-after-free issue Delete fence fallback timer to fix the ramdom use-after-free issue. v2: move to amdgpu_mes.c
- https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c
- https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a
- https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de
- https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d
- https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c
- https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a
- https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de
- https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d
Modified: 2025-11-04
CVE-2024-38582
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential hang in nilfs_detach_log_writer() Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().
- https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd
- https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0
- https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b
- https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830
- https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a
- https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b
- https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728e9b427f
- https://git.kernel.org/stable/c/eb85dace897c5986bc2f36b3c783c6abb8a4292e
- https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb
- https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd
- https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0
- https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b
- https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830
- https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a
- https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b
- https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728e9b427f
- https://git.kernel.org/stable/c/eb85dace897c5986bc2f36b3c783c6abb8a4292e
- https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-38583
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free of timer for log writer thread Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.
- https://git.kernel.org/stable/c/2f12b2c03c5dae1a0de0a9e5853177e3d6eee3c6
- https://git.kernel.org/stable/c/67fa90d4a2ccd9ebb0e1e168c7d0b5d0cf3c7148
- https://git.kernel.org/stable/c/68e738be5c518fc3c4e9146b66f67c8fee0135fb
- https://git.kernel.org/stable/c/822ae5a8eac30478578a75f7e064f0584931bf2d
- https://git.kernel.org/stable/c/82933c84f188dcfe89eb26b0b48ab5d1ca99d164
- https://git.kernel.org/stable/c/86a30d6302deddb9fb97ba6fc4b04d0e870b582a
- https://git.kernel.org/stable/c/e65ccf3a4de4f0c763d94789615b83e11f204438
- https://git.kernel.org/stable/c/f5d4e04634c9cf68bdf23de08ada0bb92e8befe7
- https://git.kernel.org/stable/c/f9186bba4ea282b07293c1c892441df3a5441cb0
- https://git.kernel.org/stable/c/2f12b2c03c5dae1a0de0a9e5853177e3d6eee3c6
- https://git.kernel.org/stable/c/67fa90d4a2ccd9ebb0e1e168c7d0b5d0cf3c7148
- https://git.kernel.org/stable/c/68e738be5c518fc3c4e9146b66f67c8fee0135fb
- https://git.kernel.org/stable/c/822ae5a8eac30478578a75f7e064f0584931bf2d
- https://git.kernel.org/stable/c/82933c84f188dcfe89eb26b0b48ab5d1ca99d164
- https://git.kernel.org/stable/c/86a30d6302deddb9fb97ba6fc4b04d0e870b582a
- https://git.kernel.org/stable/c/e65ccf3a4de4f0c763d94789615b83e11f204438
- https://git.kernel.org/stable/c/f5d4e04634c9cf68bdf23de08ada0bb92e8befe7
- https://git.kernel.org/stable/c/f9186bba4ea282b07293c1c892441df3a5441cb0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38584
In the Linux kernel, the following vulnerability has been resolved: net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe() In the prueth_probe() function, if one of the calls to emac_phy_connect() fails due to of_phy_connect() returning NULL, then the subsequent call to phy_attached_info() will dereference a NULL pointer. Check the return code of emac_phy_connect and fail cleanly if there is an error.
- https://git.kernel.org/stable/c/1e1d5bd7f4682e6925dd960aba2a1aa1d93da53a
- https://git.kernel.org/stable/c/5cd17f0e74cb99d209945b9f1f06d411aa667eb1
- https://git.kernel.org/stable/c/b0a82ebabbdc4c307f781bb0e5cd617949a3900d
- https://git.kernel.org/stable/c/b31c7e78086127a7fcaa761e8d336ee855a920c6
- https://git.kernel.org/stable/c/1e1d5bd7f4682e6925dd960aba2a1aa1d93da53a
- https://git.kernel.org/stable/c/5cd17f0e74cb99d209945b9f1f06d411aa667eb1
- https://git.kernel.org/stable/c/b0a82ebabbdc4c307f781bb0e5cd617949a3900d
- https://git.kernel.org/stable/c/b31c7e78086127a7fcaa761e8d336ee855a920c6
Modified: 2025-09-17
CVE-2024-38585
In the Linux kernel, the following vulnerability has been resolved: tools/nolibc/stdlib: fix memory error in realloc() Pass user_p_len to memcpy() instead of heap->len to prevent realloc() from copying an extra sizeof(heap) bytes from beyond the allocated region.
- https://git.kernel.org/stable/c/4e6f225aefeb712cdb870176b6621f02cf235b8c
- https://git.kernel.org/stable/c/5996b2b2dac739f2a27da13de8eee5b85b2550b3
- https://git.kernel.org/stable/c/791f4641142e2aced85de082e5783b4fb0b977c2
- https://git.kernel.org/stable/c/8019d3dd921f39a237a9fab6d2ce716bfac0f983
- https://git.kernel.org/stable/c/f678c3c336559cf3255a32153e9a17c1be4e7c15
- https://git.kernel.org/stable/c/4e6f225aefeb712cdb870176b6621f02cf235b8c
- https://git.kernel.org/stable/c/5996b2b2dac739f2a27da13de8eee5b85b2550b3
- https://git.kernel.org/stable/c/791f4641142e2aced85de082e5783b4fb0b977c2
- https://git.kernel.org/stable/c/8019d3dd921f39a237a9fab6d2ce716bfac0f983
- https://git.kernel.org/stable/c/f678c3c336559cf3255a32153e9a17c1be4e7c15
Modified: 2025-09-17
CVE-2024-38586
In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
- https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6
- https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d
- https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479
- https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27
- https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1
- https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd
- https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417
- https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6
- https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d
- https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479
- https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27
- https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1
- https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd
- https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417
Modified: 2025-12-23
CVE-2024-38588
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr ffff888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
[...]
Call Trace:
- https://git.kernel.org/stable/c/1880a324af1c95940a7c954b6b937e86844a33bd
- https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757edabc0b
- https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6
- https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461
- https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831
- https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada
- https://git.kernel.org/stable/c/e60b613df8b6253def41215402f72986fee3fc8d
- https://git.kernel.org/stable/c/eea46baf145150910ba134f75a67106ba2222c1b
- https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757edabc0b
- https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6
- https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461
- https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831
- https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada
- https://git.kernel.org/stable/c/e60b613df8b6253def41215402f72986fee3fc8d
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-04
CVE-2024-38589
In the Linux kernel, the following vulnerability has been resolved: netrom: fix possible dead-lock in nr_rt_ioctl() syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1] Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node) [1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted ------------------------------------------------------ syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK *** 1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated---
- https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691
- https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7
- https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5
- https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3
- https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5
- https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de
- https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d
- https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6
- https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8
- https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691
- https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7
- https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5
- https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3
- https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5
- https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de
- https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d
- https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6
- https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38590
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Modify the print level of CQE error Too much print may lead to a panic in kernel. Change ibdev_err() to ibdev_err_ratelimited(), and change the printing level of cqe dump to debug level.
- https://git.kernel.org/stable/c/06cf121346bbd3d83a5eea05bb87666c6b279990
- https://git.kernel.org/stable/c/17f3741c65c4a042ae8ba094068b07a4b77e213c
- https://git.kernel.org/stable/c/349e859952285ab9689779fb46de163f13f18f43
- https://git.kernel.org/stable/c/45b31be4dd22827903df15c548b97b416790139b
- https://git.kernel.org/stable/c/6f541a89ced8305da459e3ab0006e7528cf7da7b
- https://git.kernel.org/stable/c/817a10a6df9354e67561922d2b7fce48dfbebc55
- https://git.kernel.org/stable/c/cc699b7eb2bc963c12ffcd37f80f45330d2924bd
- https://git.kernel.org/stable/c/06cf121346bbd3d83a5eea05bb87666c6b279990
- https://git.kernel.org/stable/c/17f3741c65c4a042ae8ba094068b07a4b77e213c
- https://git.kernel.org/stable/c/349e859952285ab9689779fb46de163f13f18f43
- https://git.kernel.org/stable/c/45b31be4dd22827903df15c548b97b416790139b
- https://git.kernel.org/stable/c/6f541a89ced8305da459e3ab0006e7528cf7da7b
- https://git.kernel.org/stable/c/817a10a6df9354e67561922d2b7fce48dfbebc55
- https://git.kernel.org/stable/c/cc699b7eb2bc963c12ffcd37f80f45330d2924bd
Modified: 2025-11-03
CVE-2024-38591
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix deadlock on SRQ async events. xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock.
- https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868
- https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d
- https://git.kernel.org/stable/c/605889754ee68aacf7c381938fcd5eb654e71822
- https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9
- https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0
- https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37
- https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c
- https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868
- https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d
- https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9
- https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0
- https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37
- https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-10-20
CVE-2024-38593
In the Linux kernel, the following vulnerability has been resolved: net: micrel: Fix receiving the timestamp in the frame for lan8841 The blamed commit started to use the ptp workqueue to get the second part of the timestamp. And when the port was set down, then this workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING is not enabled, then the ptp_clock is not initialized so then it would crash when it would try to access the delayed work. So then basically by setting up and then down the port, it would crash. The fix consists in checking if the ptp_clock is initialized and only then cancel the delayed work.
- https://git.kernel.org/stable/c/3ddf170e4a604f5d4d9459a36993f5e92b53e8b0
- https://git.kernel.org/stable/c/3fd4282d5f25c3c97fef3ef0b89b82ef4e2bc975
- https://git.kernel.org/stable/c/64a47cf634ae44e92be24ebc982410841093bd7b
- https://git.kernel.org/stable/c/aea27a92a41dae14843f92c79e9e42d8f570105c
- https://git.kernel.org/stable/c/3ddf170e4a604f5d4d9459a36993f5e92b53e8b0
- https://git.kernel.org/stable/c/3fd4282d5f25c3c97fef3ef0b89b82ef4e2bc975
- https://git.kernel.org/stable/c/64a47cf634ae44e92be24ebc982410841093bd7b
- https://git.kernel.org/stable/c/aea27a92a41dae14843f92c79e9e42d8f570105c
Modified: 2025-11-04
CVE-2024-38596
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03 The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7"). Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.") addressed a comparable issue in the past regarding sk->sk_shutdown. However, it overlooked resolving this particular data path. This patch only offending unix_stream_sendmsg() function, since the other reads seem to be protected by unix_state_lock() as discussed in
- https://git.kernel.org/stable/c/0688d4e499bee3f2749bca27329bd128686230cb
- https://git.kernel.org/stable/c/4d51845d734a4c5d079e56e0916f936a55e15055
- https://git.kernel.org/stable/c/540bf24fba16b88c1b3b9353927204b4f1074e25
- https://git.kernel.org/stable/c/8299e4d778f664b31b67cf4cf3d5409de2ecb92c
- https://git.kernel.org/stable/c/9aa8773abfa0e954136875b4cbf2df4cf638e8a5
- https://git.kernel.org/stable/c/a4c88072abcaca593cefe70f90e9d3707526e8f9
- https://git.kernel.org/stable/c/a52fa2addfcccc2c5a0217fd45562605088c018b
- https://git.kernel.org/stable/c/de6641d213373fbde9bbdd7c4b552254bc9f82fe
- https://git.kernel.org/stable/c/fca6072e1a7b1e709ada5604b951513b89b4bd0a
- https://git.kernel.org/stable/c/0688d4e499bee3f2749bca27329bd128686230cb
- https://git.kernel.org/stable/c/4d51845d734a4c5d079e56e0916f936a55e15055
- https://git.kernel.org/stable/c/540bf24fba16b88c1b3b9353927204b4f1074e25
- https://git.kernel.org/stable/c/8299e4d778f664b31b67cf4cf3d5409de2ecb92c
- https://git.kernel.org/stable/c/9aa8773abfa0e954136875b4cbf2df4cf638e8a5
- https://git.kernel.org/stable/c/a4c88072abcaca593cefe70f90e9d3707526e8f9
- https://git.kernel.org/stable/c/a52fa2addfcccc2c5a0217fd45562605088c018b
- https://git.kernel.org/stable/c/de6641d213373fbde9bbdd7c4b552254bc9f82fe
- https://git.kernel.org/stable/c/fca6072e1a7b1e709ada5604b951513b89b4bd0a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38597
In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.
- https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6
- https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b
- https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937
- https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4
- https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f
- https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce
- https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289
- https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6
- https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b
- https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937
- https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4
- https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f
- https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce
- https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289
Modified: 2025-11-04
CVE-2024-38598
In the Linux kernel, the following vulnerability has been resolved:
md: fix resync softlockup when bitmap size is less than array size
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
- https://git.kernel.org/stable/c/3f5b73ef8fd6268cbc968b308d8eafe56fda97f3
- https://git.kernel.org/stable/c/43771597feba89a839c5f893716df88ae5c237ce
- https://git.kernel.org/stable/c/5817f43ae1a118855676f57ef7ab50e37eac7482
- https://git.kernel.org/stable/c/69296914bfd508c85935bf5f711cad9b0fe78492
- https://git.kernel.org/stable/c/71e8e4f288e74a896b6d9cd194f3bab12bd7a10f
- https://git.kernel.org/stable/c/8bbc71315e0ae4bb7e37f8d43b915e1cb01a481b
- https://git.kernel.org/stable/c/c9566b812c8f66160466cc1e29df6d3646add0b1
- https://git.kernel.org/stable/c/d4b9c764d48fa41caa24cfb4275f3aa9fb4bd798
- https://git.kernel.org/stable/c/f0e729af2eb6bee9eb58c4df1087f14ebaefe26b
- https://git.kernel.org/stable/c/3f5b73ef8fd6268cbc968b308d8eafe56fda97f3
- https://git.kernel.org/stable/c/43771597feba89a839c5f893716df88ae5c237ce
- https://git.kernel.org/stable/c/5817f43ae1a118855676f57ef7ab50e37eac7482
- https://git.kernel.org/stable/c/69296914bfd508c85935bf5f711cad9b0fe78492
- https://git.kernel.org/stable/c/71e8e4f288e74a896b6d9cd194f3bab12bd7a10f
- https://git.kernel.org/stable/c/8bbc71315e0ae4bb7e37f8d43b915e1cb01a481b
- https://git.kernel.org/stable/c/c9566b812c8f66160466cc1e29df6d3646add0b1
- https://git.kernel.org/stable/c/d4b9c764d48fa41caa24cfb4275f3aa9fb4bd798
- https://git.kernel.org/stable/c/f0e729af2eb6bee9eb58c4df1087f14ebaefe26b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-38599
In the Linux kernel, the following vulnerability has been resolved:
jffs2: prevent xattr node from overflowing the eraseblock
Add a check to make sure that the requested xattr node size is no larger
than the eraseblock minus the cleanmarker.
Unlike the usual inode nodes, the xattr nodes aren't split into parts
and spread across multiple eraseblocks, which means that a xattr node
must not occupy more than one eraseblock. If the requested xattr value is
too large, the xattr node can spill onto the next eraseblock, overwriting
the nodes and causing errors such as:
jffs2: argh. node added in wrong place at 0x0000b050(2)
jffs2: nextblock 0x0000a000, expected at 0000b00c
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
read=0xfc892c93, calc=0x000000
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
end of the erase block
jffs2: Perhaps the file system was created with the wrong erase size?
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
at 0x00000010: 0x1044 instead
This breaks the filesystem and can lead to KASAN crashes such as:
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
Read of size 4 at addr ffff88802c31e914 by task repro/830
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Arch Linux 1.16.3-1-1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/2904e1d9b64f72d291095e3cbb31634f08788b11
- https://git.kernel.org/stable/c/526235dffcac74c7823ed504dfac4f88d84ba5df
- https://git.kernel.org/stable/c/8d431391320c5c5398ff966fb3a95e68a7def275
- https://git.kernel.org/stable/c/978a12c91b38bf1a213e567f3c20e2beef215f07
- https://git.kernel.org/stable/c/a1d21bcd78cf4a4353e1e835789429c6b76aca8b
- https://git.kernel.org/stable/c/af82d8d2179b7277ad627c39e7e0778f1c86ccdb
- https://git.kernel.org/stable/c/c6854e5a267c28300ff045480b5a7ee7f6f1d913
- https://git.kernel.org/stable/c/f06969df2e40ab1dc8f4364a5de967830c74a098
- https://git.kernel.org/stable/c/f0eea095ce8c959b86e1e57fe36ca4fea5ae54f8
- https://git.kernel.org/stable/c/2904e1d9b64f72d291095e3cbb31634f08788b11
- https://git.kernel.org/stable/c/526235dffcac74c7823ed504dfac4f88d84ba5df
- https://git.kernel.org/stable/c/8d431391320c5c5398ff966fb3a95e68a7def275
- https://git.kernel.org/stable/c/978a12c91b38bf1a213e567f3c20e2beef215f07
- https://git.kernel.org/stable/c/a1d21bcd78cf4a4353e1e835789429c6b76aca8b
- https://git.kernel.org/stable/c/af82d8d2179b7277ad627c39e7e0778f1c86ccdb
- https://git.kernel.org/stable/c/c6854e5a267c28300ff045480b5a7ee7f6f1d913
- https://git.kernel.org/stable/c/f06969df2e40ab1dc8f4364a5de967830c74a098
- https://git.kernel.org/stable/c/f0eea095ce8c959b86e1e57fe36ca4fea5ae54f8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38600
In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now.
- https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68
- https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4
- https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c
- https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7
- https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a
- https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7
- https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68
- https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4
- https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c
- https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7
- https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a
- https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7
Modified: 2025-11-04
CVE-2024-38601
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix a race between readers and resize checks
The reader code in rb_get_reader_page() swaps a new reader page into the
ring buffer by doing cmpxchg on old->list.prev->next to point it to the
new page. Following that, if the operation is successful,
old->list.next->prev gets updated too. This means the underlying
doubly-linked list is temporarily inconsistent, page->prev->next or
page->next->prev might not be equal back to page for some page in the
ring buffer.
The resize operation in ring_buffer_resize() can be invoked in parallel.
It calls rb_check_pages() which can detect the described inconsistency
and stop further tracing:
[ 190.271762] ------------[ cut here ]------------
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
[ 190.271789] Modules linked in: [...]
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
[ 190.272023] Code: [...]
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 190.272077] Call Trace:
[ 190.272098]
- https://git.kernel.org/stable/c/1e160196042cac946798ac192a0bc3398f1aa66b
- https://git.kernel.org/stable/c/54c64967ba5f8658ae7da76005024ebd3d9d8f6e
- https://git.kernel.org/stable/c/595363182f28786d641666a09e674b852c83b4bb
- https://git.kernel.org/stable/c/5ef9e330406d3fb4f4b2c8bca2c6b8a93bae32d1
- https://git.kernel.org/stable/c/79b52013429a42b8efdb0cda8bb0041386abab87
- https://git.kernel.org/stable/c/af3274905b3143ea23142bbf77bd9b610c54e533
- https://git.kernel.org/stable/c/b50932ea673b5a089a4bb570a8a868d95c72854e
- https://git.kernel.org/stable/c/c2274b908db05529980ec056359fae916939fdaa
- https://git.kernel.org/stable/c/c68b7a442ee61d04ca58b2b5cb5ea7cb8230f84a
- https://git.kernel.org/stable/c/1e160196042cac946798ac192a0bc3398f1aa66b
- https://git.kernel.org/stable/c/54c64967ba5f8658ae7da76005024ebd3d9d8f6e
- https://git.kernel.org/stable/c/595363182f28786d641666a09e674b852c83b4bb
- https://git.kernel.org/stable/c/5ef9e330406d3fb4f4b2c8bca2c6b8a93bae32d1
- https://git.kernel.org/stable/c/79b52013429a42b8efdb0cda8bb0041386abab87
- https://git.kernel.org/stable/c/af3274905b3143ea23142bbf77bd9b610c54e533
- https://git.kernel.org/stable/c/b50932ea673b5a089a4bb570a8a868d95c72854e
- https://git.kernel.org/stable/c/c2274b908db05529980ec056359fae916939fdaa
- https://git.kernel.org/stable/c/c68b7a442ee61d04ca58b2b5cb5ea7cb8230f84a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38602
In the Linux kernel, the following vulnerability has been resolved: ax25: Fix reference count leak issues of ax25_dev The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the issue of ax25_dev_device_down(), increase the reference count of ax25_dev once in ax25_dev_device_up() and decrease the reference count of ax25_dev after it is removed from the ax25_dev_list.
- https://git.kernel.org/stable/c/1ea02699c7557eeb35ccff2bd822de1b3e09d868
- https://git.kernel.org/stable/c/38eb01edfdaa1562fa00429be2e33f45383b1b3a
- https://git.kernel.org/stable/c/81d8240b0a243b3ddd8fa8aa172f1acc2f7cc8f3
- https://git.kernel.org/stable/c/ae467750a3765dd1092eb29f58247950a2f9b60c
- https://git.kernel.org/stable/c/b505e0319852b08a3a716b64620168eab21f4ced
- https://git.kernel.org/stable/c/1ea02699c7557eeb35ccff2bd822de1b3e09d868
- https://git.kernel.org/stable/c/38eb01edfdaa1562fa00429be2e33f45383b1b3a
- https://git.kernel.org/stable/c/81d8240b0a243b3ddd8fa8aa172f1acc2f7cc8f3
- https://git.kernel.org/stable/c/ae467750a3765dd1092eb29f58247950a2f9b60c
- https://git.kernel.org/stable/c/b505e0319852b08a3a716b64620168eab21f4ced
Modified: 2024-11-21
CVE-2024-38603
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset() pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails.
- https://git.kernel.org/stable/c/1491a01ef5a98149048b12e208f6ed8e86ad10b9
- https://git.kernel.org/stable/c/2fcffaaf529d5fe3fdc6c0ee65a6f266b74de782
- https://git.kernel.org/stable/c/582c1aeee0a9e73010cf1c4cef338709860deeb0
- https://git.kernel.org/stable/c/a7678a16c25b6ece1667ac681e3e783ff3de7a6f
- https://git.kernel.org/stable/c/b1e86f1ef8fa796f8935be392457639f3a907d91
- https://git.kernel.org/stable/c/1491a01ef5a98149048b12e208f6ed8e86ad10b9
- https://git.kernel.org/stable/c/2fcffaaf529d5fe3fdc6c0ee65a6f266b74de782
- https://git.kernel.org/stable/c/582c1aeee0a9e73010cf1c4cef338709860deeb0
- https://git.kernel.org/stable/c/a7678a16c25b6ece1667ac681e3e783ff3de7a6f
- https://git.kernel.org/stable/c/b1e86f1ef8fa796f8935be392457639f3a907d91
Modified: 2025-10-03
CVE-2024-38604
In the Linux kernel, the following vulnerability has been resolved: block: refine the EOF check in blkdev_iomap_begin blkdev_iomap_begin rounds down the offset to the logical block size before stashing it in iomap->offset and checking that it still is inside the inode size. Check the i_size check to the raw pos value so that we don't try a zero size write if iter->pos is unaligned.
- https://git.kernel.org/stable/c/0c12028aec837f5a002009bbf68d179d506510e8
- https://git.kernel.org/stable/c/10b723bcba8986537a484aa94dbfc9093fd776a1
- https://git.kernel.org/stable/c/72c54e063c32aeb38d43a2bd897821e6e5a1757d
- https://git.kernel.org/stable/c/910717920c8c3f9386277a44c44d448058a18084
- https://git.kernel.org/stable/c/0c12028aec837f5a002009bbf68d179d506510e8
- https://git.kernel.org/stable/c/10b723bcba8986537a484aa94dbfc9093fd776a1
- https://git.kernel.org/stable/c/72c54e063c32aeb38d43a2bd897821e6e5a1757d
- https://git.kernel.org/stable/c/910717920c8c3f9386277a44c44d448058a18084
Modified: 2025-04-01
CVE-2024-38605
In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.
- https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e7351138a29c1
- https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12
- https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5
- https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434
- https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e
- https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92
- https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811
- https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e7351138a29c1
- https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12
- https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5
- https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434
- https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e
- https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92
- https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811
Modified: 2025-10-03
CVE-2024-38607
In the Linux kernel, the following vulnerability has been resolved: macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization.
- https://git.kernel.org/stable/c/010d4cb19bb13f423e3e746b824f314a9bf3e9a9
- https://git.kernel.org/stable/c/1e9c3f2caec548cfa7a65416ec4e6006e542f18e
- https://git.kernel.org/stable/c/280619bbdeac186fb320fab3d61122d2a085def8
- https://git.kernel.org/stable/c/2907d409ce5946390f513976f0454888d37d1058
- https://git.kernel.org/stable/c/5900a88e897e6deb1bdce09ee34167a81c2da89d
- https://git.kernel.org/stable/c/787fb79efc15b3b86442ecf079b8148f173376d7
- https://git.kernel.org/stable/c/d301a71c76ee4c384b4e03cdc320a55f5cf1df05
- https://git.kernel.org/stable/c/d43a8c7ec0841e0ff91a968770aeca83f0fd4c56
- https://git.kernel.org/stable/c/e4ff8bcfb2841fe4e17e5901578b632adb89036d
- https://git.kernel.org/stable/c/010d4cb19bb13f423e3e746b824f314a9bf3e9a9
- https://git.kernel.org/stable/c/1e9c3f2caec548cfa7a65416ec4e6006e542f18e
- https://git.kernel.org/stable/c/280619bbdeac186fb320fab3d61122d2a085def8
- https://git.kernel.org/stable/c/2907d409ce5946390f513976f0454888d37d1058
- https://git.kernel.org/stable/c/5900a88e897e6deb1bdce09ee34167a81c2da89d
- https://git.kernel.org/stable/c/787fb79efc15b3b86442ecf079b8148f173376d7
- https://git.kernel.org/stable/c/d301a71c76ee4c384b4e03cdc320a55f5cf1df05
- https://git.kernel.org/stable/c/d43a8c7ec0841e0ff91a968770aeca83f0fd4c56
- https://git.kernel.org/stable/c/e4ff8bcfb2841fe4e17e5901578b632adb89036d
Modified: 2025-09-17
CVE-2024-38610
In the Linux kernel, the following vulnerability has been resolved: drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them. (3) We are only looking at the first PTE of a bigger range. We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing.
- https://git.kernel.org/stable/c/2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb
- https://git.kernel.org/stable/c/3d6586008f7b638f91f3332602592caa8b00b559
- https://git.kernel.org/stable/c/4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4
- https://git.kernel.org/stable/c/5c6705aa47b5b78d7ad36fea832bb69caa5bf49a
- https://git.kernel.org/stable/c/afeb0e69627695f759fc73c39c1640dbf8649b32
- https://git.kernel.org/stable/c/e873f36ec890bece26ecce850e969917bceebbb6
- https://git.kernel.org/stable/c/2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb
- https://git.kernel.org/stable/c/3d6586008f7b638f91f3332602592caa8b00b559
- https://git.kernel.org/stable/c/4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4
- https://git.kernel.org/stable/c/5c6705aa47b5b78d7ad36fea832bb69caa5bf49a
- https://git.kernel.org/stable/c/afeb0e69627695f759fc73c39c1640dbf8649b32
- https://git.kernel.org/stable/c/e873f36ec890bece26ecce850e969917bceebbb6
Modified: 2025-11-03
CVE-2024-38611
In the Linux kernel, the following vulnerability has been resolved: media: i2c: et8ek8: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)
- https://git.kernel.org/stable/c/04d1086a62ac492ebb6bb0c94c1c8cb55f5d1f36
- https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9
- https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce
- https://git.kernel.org/stable/c/904db2ba44ae60641b6378c5013254d09acf5e80
- https://git.kernel.org/stable/c/963523600d9f1e36bc35ba774c2493d6baa4dd8f
- https://git.kernel.org/stable/c/c1a3803e5bb91c13e9ad582003e4288f67f06cd9
- https://git.kernel.org/stable/c/ece3fc1c10197052044048bea4f13cfdcf25b416
- https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9
- https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce
- https://git.kernel.org/stable/c/904db2ba44ae60641b6378c5013254d09acf5e80
- https://git.kernel.org/stable/c/c1a3803e5bb91c13e9ad582003e4288f67f06cd9
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-04
CVE-2024-38612
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path.
- https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c
- https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7
- https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45
- https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01
- https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66
- https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4
- https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c9d4d89a
- https://git.kernel.org/stable/c/c04d6a914e890ccea4a9d11233009a2ee7978bf4
- https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925
- https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c
- https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7
- https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45
- https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01
- https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66
- https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4
- https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c9d4d89a
- https://git.kernel.org/stable/c/c04d6a914e890ccea4a9d11233009a2ee7978bf4
- https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-17
CVE-2024-38613
In the Linux kernel, the following vulnerability has been resolved: m68k: Fix spinlock race in kernel thread creation Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch. This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register. The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()). A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck. As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit. Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume(). Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed. Tested on ARAnyM and qemu (Quadra 800 emulation).
- https://git.kernel.org/stable/c/0d9ae1253535f6e85a016e09c25ecbe6f7f59ef0
- https://git.kernel.org/stable/c/2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14
- https://git.kernel.org/stable/c/4eeffecc8e3cce25bb559502c2fd94a948bcde82
- https://git.kernel.org/stable/c/5213cc01d0464c011fdc09f318705603ed3a746b
- https://git.kernel.org/stable/c/77b2b67a0f8bce260c53907e5749d61466d90c87
- https://git.kernel.org/stable/c/95f00caf767b5968c2c51083957b38be4748a78a
- https://git.kernel.org/stable/c/da89ce46f02470ef08f0f580755d14d547da59ed
- https://git.kernel.org/stable/c/f1d4274a84c069be0f6098ab10c3443fc1f7134c
- https://git.kernel.org/stable/c/f3baf0f4f92af32943ebf27b960e0552c6c082fd
- https://git.kernel.org/stable/c/0d9ae1253535f6e85a016e09c25ecbe6f7f59ef0
- https://git.kernel.org/stable/c/2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14
- https://git.kernel.org/stable/c/4eeffecc8e3cce25bb559502c2fd94a948bcde82
- https://git.kernel.org/stable/c/5213cc01d0464c011fdc09f318705603ed3a746b
- https://git.kernel.org/stable/c/77b2b67a0f8bce260c53907e5749d61466d90c87
- https://git.kernel.org/stable/c/95f00caf767b5968c2c51083957b38be4748a78a
- https://git.kernel.org/stable/c/da89ce46f02470ef08f0f580755d14d547da59ed
- https://git.kernel.org/stable/c/f1d4274a84c069be0f6098ab10c3443fc1f7134c
- https://git.kernel.org/stable/c/f3baf0f4f92af32943ebf27b960e0552c6c082fd
Modified: 2025-10-03
CVE-2024-38614
In the Linux kernel, the following vulnerability has been resolved: openrisc: traps: Don't send signals to kernel mode threads OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error. This patch adds conditions to die if the kernel receives these exceptions in kernel mode code.
- https://git.kernel.org/stable/c/075c0405b0d7d9fc490609e988a3af0069596538
- https://git.kernel.org/stable/c/c0ed9a711e3392d73e857faa031d8d349c0d70db
- https://git.kernel.org/stable/c/c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f
- https://git.kernel.org/stable/c/cea9d0015c140af39477dd5eeb9b20233a45daa9
- https://git.kernel.org/stable/c/075c0405b0d7d9fc490609e988a3af0069596538
- https://git.kernel.org/stable/c/c0ed9a711e3392d73e857faa031d8d349c0d70db
- https://git.kernel.org/stable/c/c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f
- https://git.kernel.org/stable/c/cea9d0015c140af39477dd5eeb9b20233a45daa9
Modified: 2025-10-03
CVE-2024-38615
In the Linux kernel, the following vulnerability has been resolved: cpufreq: exit() callback is optional The exit() callback is optional and shouldn't be called without checking a valid pointer first. Also, we must clear freq_table pointer even if the exit() callback isn't present.
- https://git.kernel.org/stable/c/2d730b465e377396d2a09a53524b96b111f7ccb6
- https://git.kernel.org/stable/c/35db5e76d5e9f752476df5fa0b9018a2398b0378
- https://git.kernel.org/stable/c/3e99f060cfd2e36504d62c9132b453ade5027e1c
- https://git.kernel.org/stable/c/8bc9546805e572ad101681437a49939f28777273
- https://git.kernel.org/stable/c/a8204d1b6ff762d2171d365c2c8560285d0a233d
- https://git.kernel.org/stable/c/ae37ebca325097d773d7bb6ec069123b30772872
- https://git.kernel.org/stable/c/b8f85833c05730d631576008daaa34096bc7f3ce
- https://git.kernel.org/stable/c/dfc56ff5ec9904c008e9376d90a6d7e2d2bec4d3
- https://git.kernel.org/stable/c/2d730b465e377396d2a09a53524b96b111f7ccb6
- https://git.kernel.org/stable/c/35db5e76d5e9f752476df5fa0b9018a2398b0378
- https://git.kernel.org/stable/c/3e99f060cfd2e36504d62c9132b453ade5027e1c
- https://git.kernel.org/stable/c/8bc9546805e572ad101681437a49939f28777273
- https://git.kernel.org/stable/c/a8204d1b6ff762d2171d365c2c8560285d0a233d
- https://git.kernel.org/stable/c/ae37ebca325097d773d7bb6ec069123b30772872
- https://git.kernel.org/stable/c/b8f85833c05730d631576008daaa34096bc7f3ce
- https://git.kernel.org/stable/c/dfc56ff5ec9904c008e9376d90a6d7e2d2bec4d3
Modified: 2025-04-01
CVE-2024-38616
In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: re-fix fortified-memset warning The carl9170_tx_release() function sometimes triggers a fortified-memset warning in my randconfig builds: In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortify_memset_chk', inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'kref_put' at include/linux/kref.h:65:3, inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size); Kees previously tried to avoid this by using memset_after(), but it seems this does not fully address the problem. I noticed that the memset_after() here is done on a different part of the union (status) than the original cast was from (rate_driver_data), which may confuse the compiler. Unfortunately, the memset_after() trick does not work on driver_rates[] because that is part of an anonymous struct, and I could not get struct_group() to do this either. Using two separate memset() calls on the two members does address the warning though.
- https://git.kernel.org/stable/c/042a39bb8e0812466327a5102606e88a5a4f8c02
- https://git.kernel.org/stable/c/066afafc10c9476ee36c47c9062527a17e763901
- https://git.kernel.org/stable/c/0c38c9c460bb8ce8d6f6cf316e0d71a70983ec83
- https://git.kernel.org/stable/c/13857683126e8a6492af73c74d702835f7a2175b
- https://git.kernel.org/stable/c/87586467098281f04fa93e59fe3a516b954bddc4
- https://git.kernel.org/stable/c/042a39bb8e0812466327a5102606e88a5a4f8c02
- https://git.kernel.org/stable/c/066afafc10c9476ee36c47c9062527a17e763901
- https://git.kernel.org/stable/c/0c38c9c460bb8ce8d6f6cf316e0d71a70983ec83
- https://git.kernel.org/stable/c/13857683126e8a6492af73c74d702835f7a2175b
- https://git.kernel.org/stable/c/87586467098281f04fa93e59fe3a516b954bddc4
Modified: 2025-10-03
CVE-2024-38617
In the Linux kernel, the following vulnerability has been resolved: kunit/fortify: Fix mismatched kvalloc()/vfree() usage The kv*() family of tests were accidentally freeing with vfree() instead of kvfree(). Use kvfree() instead.
- https://git.kernel.org/stable/c/03758d5a0932016b6d5f5bfbca580177e6bc937a
- https://git.kernel.org/stable/c/42d21c9727028fe7ee392223ba127484b1b8677e
- https://git.kernel.org/stable/c/7880dbf4eafe22a6a41a42e774f1122c814ed02d
- https://git.kernel.org/stable/c/998b18072ceb0613629c256b409f4d299829c7ec
- https://git.kernel.org/stable/c/03758d5a0932016b6d5f5bfbca580177e6bc937a
- https://git.kernel.org/stable/c/42d21c9727028fe7ee392223ba127484b1b8677e
- https://git.kernel.org/stable/c/7880dbf4eafe22a6a41a42e774f1122c814ed02d
- https://git.kernel.org/stable/c/998b18072ceb0613629c256b409f4d299829c7ec
Modified: 2025-11-04
CVE-2024-38618
In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Set lower bound of start tick time Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.
- https://git.kernel.org/stable/c/2c95241ac5fc90c929d6c0c023e84bf0d30e84c3
- https://git.kernel.org/stable/c/4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e
- https://git.kernel.org/stable/c/68396c825c43664b20a3a1ba546844deb2b4e48f
- https://git.kernel.org/stable/c/74bfb8d90f2601718ae203faf45a196844c01fa1
- https://git.kernel.org/stable/c/83f0ba8592b9e258fd80ac6486510ab1dcd7ad6e
- https://git.kernel.org/stable/c/abb1ad69d98cf1ff25bb14fff0e7c3f66239e1cd
- https://git.kernel.org/stable/c/bdd0aa055b8ec7e24bbc19513f3231958741d0ab
- https://git.kernel.org/stable/c/ceab795a67dd28dd942d0d8bba648c6c0f7a044b
- https://git.kernel.org/stable/c/2c95241ac5fc90c929d6c0c023e84bf0d30e84c3
- https://git.kernel.org/stable/c/4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e
- https://git.kernel.org/stable/c/68396c825c43664b20a3a1ba546844deb2b4e48f
- https://git.kernel.org/stable/c/74bfb8d90f2601718ae203faf45a196844c01fa1
- https://git.kernel.org/stable/c/83f0ba8592b9e258fd80ac6486510ab1dcd7ad6e
- https://git.kernel.org/stable/c/abb1ad69d98cf1ff25bb14fff0e7c3f66239e1cd
- https://git.kernel.org/stable/c/bdd0aa055b8ec7e24bbc19513f3231958741d0ab
- https://git.kernel.org/stable/c/ceab795a67dd28dd942d0d8bba648c6c0f7a044b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-38619
In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Check whether the media is initialized The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media().
- https://git.kernel.org/stable/c/16637fea001ab3c8df528a8995b3211906165a30
- https://git.kernel.org/stable/c/24bff7f714bdff97c2a75a0ff6a368cdf8ad5af4
- https://git.kernel.org/stable/c/2cc32639ec347e3365075b130f9953ef16cb13f1
- https://git.kernel.org/stable/c/3eee13ab67f65606faa66e0c3c729e4f514838fd
- https://git.kernel.org/stable/c/51fe16c058acb22f847e69bc598066ed0bcd5c15
- https://git.kernel.org/stable/c/e0aab7b07a9375337847c9d74a5ec044071e01c8
- https://git.kernel.org/stable/c/e0e2eec76920a133dd49a4fbe4656d83596a1361
- https://git.kernel.org/stable/c/f68820f1256b21466ff094dd97f243b7e708f9c1
- https://git.kernel.org/stable/c/16637fea001ab3c8df528a8995b3211906165a30
- https://git.kernel.org/stable/c/24bff7f714bdff97c2a75a0ff6a368cdf8ad5af4
- https://git.kernel.org/stable/c/2cc32639ec347e3365075b130f9953ef16cb13f1
- https://git.kernel.org/stable/c/3eee13ab67f65606faa66e0c3c729e4f514838fd
- https://git.kernel.org/stable/c/51fe16c058acb22f847e69bc598066ed0bcd5c15
- https://git.kernel.org/stable/c/e0aab7b07a9375337847c9d74a5ec044071e01c8
- https://git.kernel.org/stable/c/e0e2eec76920a133dd49a4fbe4656d83596a1361
- https://git.kernel.org/stable/c/f68820f1256b21466ff094dd97f243b7e708f9c1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-03
CVE-2024-38620
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HCI: Remove HCI_AMP support Since BT_HS has been remove HCI_AMP controllers no longer has any use so remove it along with the capability of creating AMP controllers. Since we no longer need to differentiate between AMP and Primary controllers, as only HCI_PRIMARY is left, this also remove hdev->dev_type altogether.
- https://git.kernel.org/stable/c/5af2e235b0d5b797e9531a00c50058319130e156
- https://git.kernel.org/stable/c/84a4bb6548a29326564f0e659fb8064503ecc1c7
- https://git.kernel.org/stable/c/af1d425b6dc67cd67809f835dd7afb6be4d43e03
- https://git.kernel.org/stable/c/d3c7b012d912b31ad23b9349c0e499d6dddd48ec
- https://git.kernel.org/stable/c/5af2e235b0d5b797e9531a00c50058319130e156
- https://git.kernel.org/stable/c/84a4bb6548a29326564f0e659fb8064503ecc1c7
- https://git.kernel.org/stable/c/af1d425b6dc67cd67809f835dd7afb6be4d43e03
- https://git.kernel.org/stable/c/d3c7b012d912b31ad23b9349c0e499d6dddd48ec
Modified: 2025-11-04
CVE-2024-38621
In the Linux kernel, the following vulnerability has been resolved: media: stk1160: fix bounds checking in stk1160_copy_video() The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true. Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line. To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes.
- https://git.kernel.org/stable/c/7532bcec0797adfa08791301c3bcae14141db3bd
- https://git.kernel.org/stable/c/a08492832cc4cacc24e0612f483c86ca899b9261
- https://git.kernel.org/stable/c/a16775828aaed1c54ff4e6fe83e8e4d5c6a50cb7
- https://git.kernel.org/stable/c/b504518a397059e1d55c521ba0ea2b545a6c4b52
- https://git.kernel.org/stable/c/d410017a7181cb55e4a5c810b32b75e4416c6808
- https://git.kernel.org/stable/c/ecf4ddc3aee8ade504c4d36b7b4053ce6093e200
- https://git.kernel.org/stable/c/f6a392266276730bea893b55d12940e32a25f56a
- https://git.kernel.org/stable/c/faa4364bef2ec0060de381ff028d1d836600a381
- https://git.kernel.org/stable/c/7532bcec0797adfa08791301c3bcae14141db3bd
- https://git.kernel.org/stable/c/a08492832cc4cacc24e0612f483c86ca899b9261
- https://git.kernel.org/stable/c/a16775828aaed1c54ff4e6fe83e8e4d5c6a50cb7
- https://git.kernel.org/stable/c/b504518a397059e1d55c521ba0ea2b545a6c4b52
- https://git.kernel.org/stable/c/d410017a7181cb55e4a5c810b32b75e4416c6808
- https://git.kernel.org/stable/c/ecf4ddc3aee8ade504c4d36b7b4053ce6093e200
- https://git.kernel.org/stable/c/f6a392266276730bea893b55d12940e32a25f56a
- https://git.kernel.org/stable/c/faa4364bef2ec0060de381ff028d1d836600a381
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-17
CVE-2024-38622
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Add callback function pointer check before its call In dpu_core_irq_callback_handler() callback function pointer is compared to NULL, but then callback function is unconditionally called by this pointer. Fix this bug by adding conditional return. Found by Linux Verification Center (linuxtesting.org) with SVACE. Patchwork: https://patchwork.freedesktop.org/patch/588237/
- https://git.kernel.org/stable/c/530f272053a5e72243a9cb07bb1296af6c346002
- https://git.kernel.org/stable/c/873f67699114452c2a996c4e10faac8ff860c241
- https://git.kernel.org/stable/c/9078630ed7f8f25d65d11823e7f2b11a8e2f4f0f
- https://git.kernel.org/stable/c/530f272053a5e72243a9cb07bb1296af6c346002
- https://git.kernel.org/stable/c/873f67699114452c2a996c4e10faac8ff860c241
- https://git.kernel.org/stable/c/9078630ed7f8f25d65d11823e7f2b11a8e2f4f0f
Modified: 2025-03-24
CVE-2024-38623
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Use variable length array instead of fixed size Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)
- https://git.kernel.org/stable/c/1997cdc3e727526aa5d84b32f7cbb3f56459b7ef
- https://git.kernel.org/stable/c/1fe1c9dc21ee52920629d2d9b9bd84358931a8d1
- https://git.kernel.org/stable/c/3839a9b19a4b70eff6b6ad70446f639f7fd5a3d7
- https://git.kernel.org/stable/c/a2de301d90b782ac5d7a5fe32995caaee9ab3a0f
- https://git.kernel.org/stable/c/cceef44b34819c24bb6ed70dce5b524bd3e368d1
- https://git.kernel.org/stable/c/1997cdc3e727526aa5d84b32f7cbb3f56459b7ef
- https://git.kernel.org/stable/c/1fe1c9dc21ee52920629d2d9b9bd84358931a8d1
- https://git.kernel.org/stable/c/3839a9b19a4b70eff6b6ad70446f639f7fd5a3d7
- https://git.kernel.org/stable/c/a2de301d90b782ac5d7a5fe32995caaee9ab3a0f
- https://git.kernel.org/stable/c/cceef44b34819c24bb6ed70dce5b524bd3e368d1
Modified: 2025-10-03
CVE-2024-38624
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow For example, in the expression: vbo = 2 * vbo + skip
- https://git.kernel.org/stable/c/109d85a98345ee52d47c650405dc51bdd2bc7d40
- https://git.kernel.org/stable/c/2d1ad595d15f36a925480199bf1d9ad72614210b
- https://git.kernel.org/stable/c/847db4049f6189427ddaefcfc967d4d235b73c57
- https://git.kernel.org/stable/c/98db3155b54d3684ef0ab5bfa0b856d13f65843d
- https://git.kernel.org/stable/c/e931f6b630ffb22d66caab202a52aa8cbb10c649
- https://git.kernel.org/stable/c/109d85a98345ee52d47c650405dc51bdd2bc7d40
- https://git.kernel.org/stable/c/2d1ad595d15f36a925480199bf1d9ad72614210b
- https://git.kernel.org/stable/c/847db4049f6189427ddaefcfc967d4d235b73c57
- https://git.kernel.org/stable/c/98db3155b54d3684ef0ab5bfa0b856d13f65843d
- https://git.kernel.org/stable/c/e931f6b630ffb22d66caab202a52aa8cbb10c649
Modified: 2025-01-07
CVE-2024-38625
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check 'folio' pointer for NULL It can be NULL if bmap is called.
- https://git.kernel.org/stable/c/1cd6c96219c429ebcfa8e79a865277376c563803
- https://git.kernel.org/stable/c/6c8054d590668629bb2eb6fb4cbf22455d08ada8
- https://git.kernel.org/stable/c/ff1068929459347f9e47f8d14c409dcf938c2641
- https://git.kernel.org/stable/c/1cd6c96219c429ebcfa8e79a865277376c563803
- https://git.kernel.org/stable/c/6c8054d590668629bb2eb6fb4cbf22455d08ada8
- https://git.kernel.org/stable/c/ff1068929459347f9e47f8d14c409dcf938c2641
Modified: 2025-11-04
CVE-2024-38627
In the Linux kernel, the following vulnerability has been resolved: stm class: Fix a double free in stm_register_device() The put_device(&stm->dev) call will trigger stm_device_release() which frees "stm" so the vfree(stm) on the next line is a double free.
- https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21ec827b20
- https://git.kernel.org/stable/c/3df463865ba42b8f88a590326f4c9ea17a1ce459
- https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247
- https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931
- https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b
- https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36
- https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695
- https://git.kernel.org/stable/c/d782a2db8f7ac49c33b9ca3e835500a28667d1be
- https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21ec827b20
- https://git.kernel.org/stable/c/3df463865ba42b8f88a590326f4c9ea17a1ce459
- https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247
- https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931
- https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b
- https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36
- https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695
- https://git.kernel.org/stable/c/d782a2db8f7ac49c33b9ca3e835500a28667d1be
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-24
CVE-2024-38628
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind. Hang on to the control IDs instead of pointers since those are correctly handled with locks.
- https://git.kernel.org/stable/c/1b739388aa3f8dfb63a9fca777e6dfa6912d0464
- https://git.kernel.org/stable/c/453d3fa9266e53f85377b911c19b9a4563fa88c0
- https://git.kernel.org/stable/c/89e66809684485590ea0b32c3178e42cba36ac09
- https://git.kernel.org/stable/c/bea73b58ab67fe581037ad9cdb93c2557590c068
- https://git.kernel.org/stable/c/1b739388aa3f8dfb63a9fca777e6dfa6912d0464
- https://git.kernel.org/stable/c/453d3fa9266e53f85377b911c19b9a4563fa88c0
- https://git.kernel.org/stable/c/89e66809684485590ea0b32c3178e42cba36ac09
- https://git.kernel.org/stable/c/bea73b58ab67fe581037ad9cdb93c2557590c068
Modified: 2025-10-03
CVE-2024-38629
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Avoid unnecessary destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues.
- https://git.kernel.org/stable/c/15edb906211bf53e7b5574f7326ab734d6bff4f9
- https://git.kernel.org/stable/c/76e43fa6a456787bad31b8d0daeabda27351a480
- https://git.kernel.org/stable/c/9eb15f24a0b9b017b39cde8b8c07243676b63687
- https://git.kernel.org/stable/c/15edb906211bf53e7b5574f7326ab734d6bff4f9
- https://git.kernel.org/stable/c/76e43fa6a456787bad31b8d0daeabda27351a480
- https://git.kernel.org/stable/c/9eb15f24a0b9b017b39cde8b8c07243676b63687
Modified: 2024-11-21
CVE-2024-38630
In the Linux kernel, the following vulnerability has been resolved: watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released.
- https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4
- https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314
- https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a
- https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4
- https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314
- https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a
Modified: 2025-11-04
CVE-2024-38633
In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Update uart_driver_registered on driver removal The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call.
- https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b
- https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752
- https://git.kernel.org/stable/c/712a1fcb38dc7cac6da63ee79a88708fbf9c45ec
- https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003
- https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00
- https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762
- https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72
- https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a98ca6a0
- https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b
- https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752
- https://git.kernel.org/stable/c/712a1fcb38dc7cac6da63ee79a88708fbf9c45ec
- https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003
- https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00
- https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762
- https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72
- https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a98ca6a0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-38634
In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Lock port->lock when calling uart_handle_cts_change() uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]
- https://git.kernel.org/stable/c/44b38924135d2093e2ec1812969464845dd66dc9
- https://git.kernel.org/stable/c/77ab53371a2066fdf9b895246505f5ef5a4b5d47
- https://git.kernel.org/stable/c/78dbda51bb4241b88a52d71620f06231a341f9ba
- https://git.kernel.org/stable/c/8296bb9e5925b6634259c5d4daee88f0cc0884ec
- https://git.kernel.org/stable/c/865b30c8661924ee9145f442bf32cea549faa869
- https://git.kernel.org/stable/c/93df2fba6c7dfa9a2f08546ea9a5ca4728758458
- https://git.kernel.org/stable/c/cc121e3722a0a2c8f716ef991e5425b180a5fb94
- https://git.kernel.org/stable/c/ea9b35372b58ac2931bfc1d5bc25e839d1221e30
- https://git.kernel.org/stable/c/44b38924135d2093e2ec1812969464845dd66dc9
- https://git.kernel.org/stable/c/77ab53371a2066fdf9b895246505f5ef5a4b5d47
- https://git.kernel.org/stable/c/78dbda51bb4241b88a52d71620f06231a341f9ba
- https://git.kernel.org/stable/c/8296bb9e5925b6634259c5d4daee88f0cc0884ec
- https://git.kernel.org/stable/c/865b30c8661924ee9145f442bf32cea549faa869
- https://git.kernel.org/stable/c/93df2fba6c7dfa9a2f08546ea9a5ca4728758458
- https://git.kernel.org/stable/c/cc121e3722a0a2c8f716ef991e5425b180a5fb94
- https://git.kernel.org/stable/c/ea9b35372b58ac2931bfc1d5bc25e839d1221e30
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-17
CVE-2024-38635
In the Linux kernel, the following vulnerability has been resolved: soundwire: cadence: fix invalid PDI offset For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT. This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds. A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well. A follow-up patch completely removes this useless offset.
- https://git.kernel.org/stable/c/002364b2d594a9afc0385c09e00994c510b1d089
- https://git.kernel.org/stable/c/2ebcaa0e5db9b6044bb487ae1cf41bc601761567
- https://git.kernel.org/stable/c/4e99103f757cdf636c6ee860994a19a346a11785
- https://git.kernel.org/stable/c/7eeef1e935d23db5265233d92395bd5c648a4021
- https://git.kernel.org/stable/c/8ee1b439b1540ae543149b15a2a61b9dff937d91
- https://git.kernel.org/stable/c/902f6d656441a511ac25c6cffce74496db10a078
- https://git.kernel.org/stable/c/fd4bcb991ebaf0d1813d81d9983cfa99f9ef5328
- https://git.kernel.org/stable/c/002364b2d594a9afc0385c09e00994c510b1d089
- https://git.kernel.org/stable/c/2ebcaa0e5db9b6044bb487ae1cf41bc601761567
- https://git.kernel.org/stable/c/4e99103f757cdf636c6ee860994a19a346a11785
- https://git.kernel.org/stable/c/7eeef1e935d23db5265233d92395bd5c648a4021
- https://git.kernel.org/stable/c/8ee1b439b1540ae543149b15a2a61b9dff937d91
- https://git.kernel.org/stable/c/902f6d656441a511ac25c6cffce74496db10a078
- https://git.kernel.org/stable/c/fd4bcb991ebaf0d1813d81d9983cfa99f9ef5328
Modified: 2025-10-03
CVE-2024-38636
In the Linux kernel, the following vulnerability has been resolved:
f2fs: multidev: fix to recognize valid zero block address
As reported by Yi Zhang in mailing list [1], kernel warning was catched
during zbd/010 test as below:
./check zbd/010
zbd/010 (test gap zone support with F2FS) [failed]
runtime ... 3.752s
something found in dmesg:
[ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13
[ 4378.192349] null_blk: module loaded
[ 4378.209860] null_blk: disk nullb0 created
[ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim
poll_queues to 0. poll_q/nr_hw = (0/1)
[ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]
dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0
[ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux
scsi_debug 0191 PQ: 0 ANSI: 7
[ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred
[ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20
[ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device
...
(See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'
WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51
CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1
RIP: 0010:iomap_iter+0x32b/0x350
Call Trace:
- https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc
- https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065
- https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5
- https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a
- https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc
- https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065
- https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5
- https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a
Modified: 2025-11-04
CVE-2024-38637
In the Linux kernel, the following vulnerability has been resolved: greybus: lights: check return of get_channel_from_mode If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
- https://git.kernel.org/stable/c/330f6bcdcef03f70f81db5f2ed6747af656a09f2
- https://git.kernel.org/stable/c/518e2c46b5dbce40b1aa0100001d03c3ceaa7d38
- https://git.kernel.org/stable/c/895cdd9aa9546523df839f9cc1488a0ecc1e0731
- https://git.kernel.org/stable/c/8f4a76d477f0cc3c54d512f07f6f88c8e1c1e07b
- https://git.kernel.org/stable/c/9b41a9b9c8be8c552f10633453fdb509e83b66f8
- https://git.kernel.org/stable/c/a1ba19a1ae7cd1e324685ded4ab563e78fe68648
- https://git.kernel.org/stable/c/e2c64246e5dc8c0d35ec41770b85e2b4cafdff21
- https://git.kernel.org/stable/c/eac10cf3a97ffd4b4deb0a29f57c118225a42850
- https://git.kernel.org/stable/c/330f6bcdcef03f70f81db5f2ed6747af656a09f2
- https://git.kernel.org/stable/c/518e2c46b5dbce40b1aa0100001d03c3ceaa7d38
- https://git.kernel.org/stable/c/895cdd9aa9546523df839f9cc1488a0ecc1e0731
- https://git.kernel.org/stable/c/8f4a76d477f0cc3c54d512f07f6f88c8e1c1e07b
- https://git.kernel.org/stable/c/9b41a9b9c8be8c552f10633453fdb509e83b66f8
- https://git.kernel.org/stable/c/a1ba19a1ae7cd1e324685ded4ab563e78fe68648
- https://git.kernel.org/stable/c/e2c64246e5dc8c0d35ec41770b85e2b4cafdff21
- https://git.kernel.org/stable/c/eac10cf3a97ffd4b4deb0a29f57c118225a42850
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-38659
In the Linux kernel, the following vulnerability has been resolved: enic: Validate length of nl attributes in enic_set_vf_port enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port.
- https://git.kernel.org/stable/c/25571a12fbc8a1283bd8380d461267956fd426f7
- https://git.kernel.org/stable/c/2b649d7e0cb42a660f0260ef25fd55fdc9c6c600
- https://git.kernel.org/stable/c/3c0d36972edbe56fcf98899622d9b90ac9965227
- https://git.kernel.org/stable/c/7077c22f84f41974a711604a42fd0e0684232ee5
- https://git.kernel.org/stable/c/aee1955a1509a921c05c70dad5d6fc8563dfcb31
- https://git.kernel.org/stable/c/ca63fb7af9d3e531aa25f7ae187bfc6c7166ec2d
- https://git.kernel.org/stable/c/e8021b94b0412c37bcc79027c2e382086b6ce449
- https://git.kernel.org/stable/c/f6638e955ca00c489894789492776842e102af9c
- https://git.kernel.org/stable/c/25571a12fbc8a1283bd8380d461267956fd426f7
- https://git.kernel.org/stable/c/2b649d7e0cb42a660f0260ef25fd55fdc9c6c600
- https://git.kernel.org/stable/c/3c0d36972edbe56fcf98899622d9b90ac9965227
- https://git.kernel.org/stable/c/7077c22f84f41974a711604a42fd0e0684232ee5
- https://git.kernel.org/stable/c/aee1955a1509a921c05c70dad5d6fc8563dfcb31
- https://git.kernel.org/stable/c/ca63fb7af9d3e531aa25f7ae187bfc6c7166ec2d
- https://git.kernel.org/stable/c/e8021b94b0412c37bcc79027c2e382086b6ce449
- https://git.kernel.org/stable/c/f6638e955ca00c489894789492776842e102af9c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-38661
In the Linux kernel, the following vulnerability has been resolved: s390/ap: Fix crash in AP internal function modify_bitmap() A system crash like this Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oops occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX. The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.
- https://git.kernel.org/stable/c/2062e3f1f2374102f8014d7ca286b9aa527bd558
- https://git.kernel.org/stable/c/4c0bfb4e867c1ec6616a5049bd3618021e127056
- https://git.kernel.org/stable/c/67011123453b91ec03671d40712fa213e94a01b9
- https://git.kernel.org/stable/c/7360cef95aa1ea2b5efb7b5e2ed32e941664e1f0
- https://git.kernel.org/stable/c/7c72af16abf2ec7520407098360bbba312289e05
- https://git.kernel.org/stable/c/7dabe54a016defe11bb2a278cd9f1ff6db3feba6
- https://git.kernel.org/stable/c/8c5f5911c1b13170d3404eb992c6a0deaa8d81ad
- https://git.kernel.org/stable/c/d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9
- https://git.kernel.org/stable/c/2062e3f1f2374102f8014d7ca286b9aa527bd558
- https://git.kernel.org/stable/c/4c0bfb4e867c1ec6616a5049bd3618021e127056
- https://git.kernel.org/stable/c/67011123453b91ec03671d40712fa213e94a01b9
- https://git.kernel.org/stable/c/7360cef95aa1ea2b5efb7b5e2ed32e941664e1f0
- https://git.kernel.org/stable/c/7c72af16abf2ec7520407098360bbba312289e05
- https://git.kernel.org/stable/c/7dabe54a016defe11bb2a278cd9f1ff6db3feba6
- https://git.kernel.org/stable/c/8c5f5911c1b13170d3404eb992c6a0deaa8d81ad
- https://git.kernel.org/stable/c/d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9
Modified: 2024-11-21
CVE-2024-38662
In the Linux kernel, the following vulnerability has been resolved: bpf: Allow delete from sockmap/sockhash only if update is allowed We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash. We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map. From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types.
- https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1
- https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9
- https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d
- https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e
- https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d
- https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c
- https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1
- https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9
- https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d
- https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e
- https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d
- https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c
Modified: 2025-10-03
CVE-2024-38663
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part.
- https://git.kernel.org/stable/c/6da6680632792709cecf2b006f2fe3ca7857e791
- https://git.kernel.org/stable/c/89bb36c72e1951843f9e04dc84412e31fcc849a9
- https://git.kernel.org/stable/c/d4a60298ac34f027a09f8f893fdbd9e06279bb24
- https://git.kernel.org/stable/c/6da6680632792709cecf2b006f2fe3ca7857e791
- https://git.kernel.org/stable/c/89bb36c72e1951843f9e04dc84412e31fcc849a9
- https://git.kernel.org/stable/c/d4a60298ac34f027a09f8f893fdbd9e06279bb24
Modified: 2025-05-30
CVE-2024-38664
In the Linux kernel, the following vulnerability has been resolved:
drm: zynqmp_dpsub: Always register bridge
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func
calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be
initialized. We do this before zynqmp_dpsub_drm_init since that calls
drm_bridge_attach. This fixes the following lockdep warning:
[ 19.217084] ------------[ cut here ]------------
[ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550
[ 19.241696] Modules linked in:
[ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96
[ 19.252046] Hardware name: xlnx,zynqmp (DT)
[ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func
[ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 19.269104] pc : __mutex_lock+0x4bc/0x550
[ 19.273364] lr : __mutex_lock+0x4bc/0x550
[ 19.277592] sp : ffffffc085c5bbe0
[ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8
[ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000
[ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000
[ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000
[ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720
[ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001
[ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888
[ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000
[ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000
[ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880
[ 19.356581] Call trace:
[ 19.359160] __mutex_lock+0x4bc/0x550
[ 19.363032] mutex_lock_nested+0x24/0x30
[ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c
[ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54
[ 19.376364] process_one_work+0x3ac/0x988
[ 19.380660] worker_thread+0x398/0x694
[ 19.384736] kthread+0x1bc/0x1c0
[ 19.388241] ret_from_fork+0x10/0x20
[ 19.392031] irq event stamp: 183
[ 19.395450] hardirqs last enabled at (183): [
- https://git.kernel.org/stable/c/603661357056b5e5ba6d86f505fbc936eff396ba
- https://git.kernel.org/stable/c/6ead3eccf67bc8318b1ce95ed879b2cc05b4fce9
- https://git.kernel.org/stable/c/be3f3042391d061cfca2bd22630e0d101acea5fc
- https://git.kernel.org/stable/c/603661357056b5e5ba6d86f505fbc936eff396ba
- https://git.kernel.org/stable/c/6ead3eccf67bc8318b1ce95ed879b2cc05b4fce9
- https://git.kernel.org/stable/c/be3f3042391d061cfca2bd22630e0d101acea5fc
Modified: 2025-05-30
CVE-2024-38667
In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.
- https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80
- https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44
- https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af
- https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e
- https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80
- https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44
- https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af
- https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e
Modified: 2025-11-04
CVE-2024-38780
In the Linux kernel, the following vulnerability has been resolved: dma-buf/sw-sync: don't enable IRQ from sync_print_obj() Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq().
- https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed
- https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a
- https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a
- https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e
- https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878
- https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef
- https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8
- https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39
- https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed
- https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a
- https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a
- https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e
- https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878
- https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef
- https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8
- https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-24
CVE-2024-39276
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================
WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
Modules linked in:
CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
Call Trace:
- https://git.kernel.org/stable/c/0c0b4a49d3e7f49690a6827a41faeffad5df7e21
- https://git.kernel.org/stable/c/681ff9a09accd8a4379f8bd30b7a1641ee19bb3e
- https://git.kernel.org/stable/c/76dc776153a47372719d664e0fc50d6355791abb
- https://git.kernel.org/stable/c/896a7e7d0d555ad8b2b46af0c2fa7de7467f9483
- https://git.kernel.org/stable/c/9ad75e78747b5a50dc5a52f0f8e92e920a653f16
- https://git.kernel.org/stable/c/a95df6f04f2c37291adf26a74205cde0314d4577
- https://git.kernel.org/stable/c/b37c0edef4e66fb21a2fbc211471195a383e5ab8
- https://git.kernel.org/stable/c/e941b712e758f615d311946bf98216e79145ccd9
- https://git.kernel.org/stable/c/0c0b4a49d3e7f49690a6827a41faeffad5df7e21
- https://git.kernel.org/stable/c/681ff9a09accd8a4379f8bd30b7a1641ee19bb3e
- https://git.kernel.org/stable/c/76dc776153a47372719d664e0fc50d6355791abb
- https://git.kernel.org/stable/c/896a7e7d0d555ad8b2b46af0c2fa7de7467f9483
- https://git.kernel.org/stable/c/9ad75e78747b5a50dc5a52f0f8e92e920a653f16
- https://git.kernel.org/stable/c/a95df6f04f2c37291adf26a74205cde0314d4577
- https://git.kernel.org/stable/c/b37c0edef4e66fb21a2fbc211471195a383e5ab8
- https://git.kernel.org/stable/c/e941b712e758f615d311946bf98216e79145ccd9
Modified: 2025-05-30
CVE-2024-39277
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: handle NUMA_NO_NODE correctly
cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark()
resulting in the following sanitizer report:
UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28
index -1 is out of range for type 'cpumask [64][1]'
CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
- https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f
- https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41
- https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464
- https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13
- https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f
- https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f
- https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41
- https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464
- https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13
- https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f
Modified: 2025-05-30
CVE-2024-39291
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating about potential truncation of output when using the snprintf function. The issue was due to the size of the buffer 'ucode_prefix' being too small to accommodate the maximum possible length of the string being written into it. The string being written is "amdgpu/%s_mec.bin" or "amdgpu/%s_rlc.bin", where %s is replaced by the value of 'chip_name'. The length of this string without the %s is 16 characters. The warning message indicated that 'chip_name' could be up to 29 characters long, resulting in a total of 45 characters, which exceeds the buffer size of 30 characters. To resolve this issue, the size of the 'ucode_prefix' buffer has been reduced from 30 to 15. This ensures that the maximum possible length of the string being written into the buffer will not exceed its size, thus preventing potential buffer overflow and truncation issues. Fixes the below with gcc W=1: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: In function ‘gfx_v9_4_3_early_init’: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~ ...... 439 | r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~ ...... 443 | r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- https://git.kernel.org/stable/c/19bd9537b6bc1c882df25206c15917214d8e9460
- https://git.kernel.org/stable/c/acce6479e30f73ab0872e93a75aed1fb791d04ec
- https://git.kernel.org/stable/c/f1b6a016dfa45cedc080d36fa5d6f22237d80e8b
- https://git.kernel.org/stable/c/19bd9537b6bc1c882df25206c15917214d8e9460
- https://git.kernel.org/stable/c/acce6479e30f73ab0872e93a75aed1fb791d04ec
- https://git.kernel.org/stable/c/f1b6a016dfa45cedc080d36fa5d6f22237d80e8b
Modified: 2025-11-04
CVE-2024-39292
In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.
- https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4
- https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2
- https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14
- https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0
- https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33
- https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1
- https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101
- https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0
- https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4
- https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2
- https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14
- https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0
- https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33
- https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1
- https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101
- https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-17
CVE-2024-39296
In the Linux kernel, the following vulnerability has been resolved: bonding: fix oops during rmmod "rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding: remove redundant NULL check in debugfs function"). Here are the relevant functions being called: bonding_exit() bond_destroy_debugfs() debugfs_remove_recursive(bonding_debug_root); bonding_debug_root = NULL; <--------- SET TO NULL HERE bond_netlink_fini() rtnl_link_unregister() __rtnl_link_unregister() unregister_netdevice_many_notify() bond_uninit() bond_debug_unregister() (commit removed check for bonding_debug_root == NULL) debugfs_remove() simple_recursive_removal() down_write() -> OOPS However, reverting the bad commit does not solve the problem completely because the original code contains a race that could cause the same oops, although it was much less likely to be triggered unintentionally: CPU1 rmmod bonding bonding_exit() bond_destroy_debugfs() debugfs_remove_recursive(bonding_debug_root); CPU2 echo -bond0 > /sys/class/net/bonding_masters bond_uninit() bond_debug_unregister() if (!bonding_debug_root) CPU1 bonding_debug_root = NULL; So do NOT revert the bad commit (since the removed checks were racy anyway), and instead change the order of actions taken during module removal. The same oops can also happen if there is an error during module init, so apply the same fix there.
- https://git.kernel.org/stable/c/a45835a0bb6ef7d5ddbc0714dd760de979cb6ece
- https://git.kernel.org/stable/c/cf48aee81103ca06d09d73d33fb72f1191069aa6
- https://git.kernel.org/stable/c/f07224c16678a8af54ddc059b3d2d51885d7f35e
- https://git.kernel.org/stable/c/a45835a0bb6ef7d5ddbc0714dd760de979cb6ece
- https://git.kernel.org/stable/c/cf48aee81103ca06d09d73d33fb72f1191069aa6
- https://git.kernel.org/stable/c/f07224c16678a8af54ddc059b3d2d51885d7f35e
Modified: 2025-11-03
CVE-2024-39298
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix handling of dissolved but not taken off from buddy pages
When I did memory failure tests recently, below panic occurs:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00
flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)
raw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(!PageBuddy(page))
------------[ cut here ]------------
kernel BUG at include/linux/page-flags.h:1009!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:__del_page_from_free_list+0x151/0x180
RSP: 0018:ffffa49c90437998 EFLAGS: 00000046
RAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8
RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0
RBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69
R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80
R13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009
FS: 00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/00b0752c7f15dfdf129cacc6a27d61c54141182b
- https://git.kernel.org/stable/c/41cd2de3c95020b7f86a3cb5fab42fbf454a63bd
- https://git.kernel.org/stable/c/8cf360b9d6a840700e06864236a01a883b34bbad
- https://git.kernel.org/stable/c/bb9bb13ce64cc7cae47f5e2ab9ce93b7bfa0117e
- https://git.kernel.org/stable/c/00b0752c7f15dfdf129cacc6a27d61c54141182b
- https://git.kernel.org/stable/c/41cd2de3c95020b7f86a3cb5fab42fbf454a63bd
- https://git.kernel.org/stable/c/8cf360b9d6a840700e06864236a01a883b34bbad
- https://git.kernel.org/stable/c/bb9bb13ce64cc7cae47f5e2ab9ce93b7bfa0117e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-39301
In the Linux kernel, the following vulnerability has been resolved: net/9p: fix uninit-value in p9_client_rpc() Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage.
- https://git.kernel.org/stable/c/124947855564572713d705a13be7d0c9dae16a17
- https://git.kernel.org/stable/c/2101901dd58c6da4924bc5efb217a1d83436290b
- https://git.kernel.org/stable/c/25460d6f39024cc3b8241b14c7ccf0d6f11a736a
- https://git.kernel.org/stable/c/6c1791130b781c843572fb6391c4a4c5d857ab17
- https://git.kernel.org/stable/c/72c5d8e416ecc46af370a1340b3db5ff0b0cc867
- https://git.kernel.org/stable/c/89969ffbeb948ffc159d19252e7469490103011b
- https://git.kernel.org/stable/c/ca71f204711ad24113e8b344dc5bb8b0385f5672
- https://git.kernel.org/stable/c/fe5c604053c36c62af24eee8a76407d026ea5163
- https://git.kernel.org/stable/c/124947855564572713d705a13be7d0c9dae16a17
- https://git.kernel.org/stable/c/2101901dd58c6da4924bc5efb217a1d83436290b
- https://git.kernel.org/stable/c/25460d6f39024cc3b8241b14c7ccf0d6f11a736a
- https://git.kernel.org/stable/c/6c1791130b781c843572fb6391c4a4c5d857ab17
- https://git.kernel.org/stable/c/72c5d8e416ecc46af370a1340b3db5ff0b0cc867
- https://git.kernel.org/stable/c/89969ffbeb948ffc159d19252e7469490103011b
- https://git.kernel.org/stable/c/ca71f204711ad24113e8b344dc5bb8b0385f5672
- https://git.kernel.org/stable/c/fe5c604053c36c62af24eee8a76407d026ea5163
Modified: 2025-11-03
CVE-2024-39371
In the Linux kernel, the following vulnerability has been resolved:
io_uring: check for non-NULL file pointer in io_file_can_poll()
In earlier kernels, it was possible to trigger a NULL pointer
dereference off the forced async preparation path, if no file had
been assigned. The trace leading to that looks as follows:
BUG: kernel NULL pointer dereference, address: 00000000000000b0
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022
RIP: 0010:io_buffer_select+0xc3/0x210
Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b
RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246
RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040
RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700
RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020
R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8
R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000
FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0
Call Trace:
- https://git.kernel.org/stable/c/43cfac7b88adedfb26c27834386992650f1642f3
- https://git.kernel.org/stable/c/5fc16fa5f13b3c06fdb959ef262050bd810416a2
- https://git.kernel.org/stable/c/65561b4c1c9e01443cb76387eb36a9109e7048ee
- https://git.kernel.org/stable/c/c2844d5e58576c55d8e8d4a9f74902d3f7be8044
- https://git.kernel.org/stable/c/43cfac7b88adedfb26c27834386992650f1642f3
- https://git.kernel.org/stable/c/5fc16fa5f13b3c06fdb959ef262050bd810416a2
- https://git.kernel.org/stable/c/65561b4c1c9e01443cb76387eb36a9109e7048ee
- https://git.kernel.org/stable/c/c2844d5e58576c55d8e8d4a9f74902d3f7be8044
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-39461
In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in raspberrypi_discover_clocks() due to ->num being assigned after ->hws has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') Move the ->num initialization to before the first access of ->hws, which clears up the warning.
- https://git.kernel.org/stable/c/6dc445c1905096b2ed4db1a84570375b4e00cc0f
- https://git.kernel.org/stable/c/9562dbe5cdbb16ac887d27ef6f179980bb99193c
- https://git.kernel.org/stable/c/cdf9c7871d58d3df59d2775982e3533adb8ec920
- https://git.kernel.org/stable/c/6dc445c1905096b2ed4db1a84570375b4e00cc0f
- https://git.kernel.org/stable/c/9562dbe5cdbb16ac887d27ef6f179980bb99193c
- https://git.kernel.org/stable/c/cdf9c7871d58d3df59d2775982e3533adb8ec920
Modified: 2025-03-24
CVE-2024-39462
In the Linux kernel, the following vulnerability has been resolved: clk: bcm: dvp: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in clk_dvp_probe() due to ->num being assigned after ->hws has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') Move the ->num initialization to before the first access of ->hws, which clears up the warning.
- https://git.kernel.org/stable/c/0dc913217fb79096597005bba9ba738e2db5cd02
- https://git.kernel.org/stable/c/9368cdf90f52a68120d039887ccff74ff33b4444
- https://git.kernel.org/stable/c/a1dd92fca0d6b58b55ed0484f75d4205dbb77010
- https://git.kernel.org/stable/c/0dc913217fb79096597005bba9ba738e2db5cd02
- https://git.kernel.org/stable/c/9368cdf90f52a68120d039887ccff74ff33b4444
- https://git.kernel.org/stable/c/a1dd92fca0d6b58b55ed0484f75d4205dbb77010
Modified: 2026-01-06
CVE-2024-39463
In the Linux kernel, the following vulnerability has been resolved: 9p: add missing locking around taking dentry fid list Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible.
- https://git.kernel.org/stable/c/3bb6763a8319170c2d41c4232c8e7e4c37dcacfb
- https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409
- https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456
- https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5
- https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4
- https://www.zerodayinitiative.com/advisories/ZDI-24-1194/
- https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409
- https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456
- https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5
- https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4
Modified: 2024-11-21
CVE-2024-39464
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Fix notifier list entry init struct v4l2_async_notifier has several list_head members, but only waiting_list and done_list are initialized. notifier_entry was kept 'zeroed' leading to an uninitialized list_head. This results in a NULL-pointer dereference if csi2_async_register() fails, e.g. node for remote endpoint is disabled, and returns -ENOTCONN. The following calls to v4l2_async_nf_unregister() results in a NULL pointer dereference. Add the missing list head initializer.
- https://git.kernel.org/stable/c/44f6d619c30f0c65fcdd2b6eba70fdb4460d87ad
- https://git.kernel.org/stable/c/6d8acd02c4c6a8f917eefac1de2e035521ca119d
- https://git.kernel.org/stable/c/a80d1da923f671c1e6a14e8417cd2f117b27a442
- https://git.kernel.org/stable/c/44f6d619c30f0c65fcdd2b6eba70fdb4460d87ad
- https://git.kernel.org/stable/c/6d8acd02c4c6a8f917eefac1de2e035521ca119d
- https://git.kernel.org/stable/c/a80d1da923f671c1e6a14e8417cd2f117b27a442
Modified: 2024-11-21
CVE-2024-39466
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/qcom/lmh: Check for SCM availability at probe Up until now, the necessary scm availability check has not been performed, leading to possible null pointer dereferences (which did happen for me on RB1). Fix that.
- https://git.kernel.org/stable/c/0a47ba94ec3d8f782b33e3d970cfcb769b962464
- https://git.kernel.org/stable/c/2226b145afa5e13cb60dbe77fb20fb0666a1caf3
- https://git.kernel.org/stable/c/560d69c975072974c11434ca6953891e74c1a665
- https://git.kernel.org/stable/c/aa1a0807b4a76b44fb6b58a7e9087cd4b18ab41b
- https://git.kernel.org/stable/c/d9d3490c48df572edefc0b64655259eefdcbb9be
- https://git.kernel.org/stable/c/0a47ba94ec3d8f782b33e3d970cfcb769b962464
- https://git.kernel.org/stable/c/2226b145afa5e13cb60dbe77fb20fb0666a1caf3
- https://git.kernel.org/stable/c/560d69c975072974c11434ca6953891e74c1a665
- https://git.kernel.org/stable/c/aa1a0807b4a76b44fb6b58a7e9087cd4b18ab41b
- https://git.kernel.org/stable/c/d9d3490c48df572edefc0b64655259eefdcbb9be
Modified: 2025-09-17
CVE-2024-39467
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
syzbot reports a kernel bug as below:
F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
==================================================================
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076
CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
- https://git.kernel.org/stable/c/1640dcf383cdba52be8b28d2a1a2aa7ef7a30c98
- https://git.kernel.org/stable/c/20faaf30e55522bba2b56d9c46689233205d7717
- https://git.kernel.org/stable/c/68e3cd4ecb8603936cccdc338929130045df2e57
- https://git.kernel.org/stable/c/75c87e2ac6149abf44bdde0dd6d541763ddb0dff
- https://git.kernel.org/stable/c/8c8aa473fe6eb46a4bf99f3ea2dbe52bf0c1a1f0
- https://git.kernel.org/stable/c/be0155202e431f3007778568a72432c68f8946ba
- https://git.kernel.org/stable/c/c559a8d840562fbfce9f318448dda2f7d3e6d8e8
- https://git.kernel.org/stable/c/1640dcf383cdba52be8b28d2a1a2aa7ef7a30c98
- https://git.kernel.org/stable/c/20faaf30e55522bba2b56d9c46689233205d7717
- https://git.kernel.org/stable/c/68e3cd4ecb8603936cccdc338929130045df2e57
- https://git.kernel.org/stable/c/75c87e2ac6149abf44bdde0dd6d541763ddb0dff
- https://git.kernel.org/stable/c/8c8aa473fe6eb46a4bf99f3ea2dbe52bf0c1a1f0
- https://git.kernel.org/stable/c/be0155202e431f3007778568a72432c68f8946ba
- https://git.kernel.org/stable/c/c559a8d840562fbfce9f318448dda2f7d3e6d8e8
Modified: 2024-11-21
CVE-2024-39468
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix deadlock in smb2_find_smb_tcon() Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such deadlock.
- https://git.kernel.org/stable/c/02c418774f76a0a36a6195c9dbf8971eb4130a15
- https://git.kernel.org/stable/c/21f5dd36e655d25a7b45b61c1e537198b671f720
- https://git.kernel.org/stable/c/225de871ddf994f69a57f035709cad9c0ab8615a
- https://git.kernel.org/stable/c/8d0f5f1ccf675454a833a573c53830a49b7d1a47
- https://git.kernel.org/stable/c/b055752675cd1d1db4ac9c2750db3dc3e89ea261
- https://git.kernel.org/stable/c/b09b556e48968317887a11243a5331a7bc00ece5
- https://git.kernel.org/stable/c/02c418774f76a0a36a6195c9dbf8971eb4130a15
- https://git.kernel.org/stable/c/21f5dd36e655d25a7b45b61c1e537198b671f720
- https://git.kernel.org/stable/c/225de871ddf994f69a57f035709cad9c0ab8615a
- https://git.kernel.org/stable/c/8d0f5f1ccf675454a833a573c53830a49b7d1a47
- https://git.kernel.org/stable/c/b055752675cd1d1db4ac9c2750db3dc3e89ea261
- https://git.kernel.org/stable/c/b09b556e48968317887a11243a5331a7bc00ece5
Modified: 2025-11-03
CVE-2024-39469
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors The error handling in nilfs_empty_dir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfs_check_folio() fails, it will falsely determine the directory as empty and corrupt the file system. In addition, since nilfs_empty_dir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot. Fix these issues by making nilfs_empty_dir() immediately return a false value (0) if it fails to get a directory folio/page.
- https://git.kernel.org/stable/c/11a2edb70356a2202dcb7c9c189c8356ab4752cd
- https://git.kernel.org/stable/c/129dcd3e7d036218db3f59c82d82004b9539ed82
- https://git.kernel.org/stable/c/2ac8a2fe22bdde9eecce2a42cf5cab79333fb428
- https://git.kernel.org/stable/c/405b71f1251e5ae865f53bd27c45114e6c83bee3
- https://git.kernel.org/stable/c/59f14875a96ef93f05b82ad3c980605f2cb444b5
- https://git.kernel.org/stable/c/7373a51e7998b508af7136530f3a997b286ce81c
- https://git.kernel.org/stable/c/c77ad608df6c091fe64ecb91f41ef7cb465587f1
- https://git.kernel.org/stable/c/d18b05eda7fa77f02114f15b02c009f28ee42346
- https://git.kernel.org/stable/c/11a2edb70356a2202dcb7c9c189c8356ab4752cd
- https://git.kernel.org/stable/c/129dcd3e7d036218db3f59c82d82004b9539ed82
- https://git.kernel.org/stable/c/2ac8a2fe22bdde9eecce2a42cf5cab79333fb428
- https://git.kernel.org/stable/c/405b71f1251e5ae865f53bd27c45114e6c83bee3
- https://git.kernel.org/stable/c/59f14875a96ef93f05b82ad3c980605f2cb444b5
- https://git.kernel.org/stable/c/7373a51e7998b508af7136530f3a997b286ce81c
- https://git.kernel.org/stable/c/c77ad608df6c091fe64ecb91f41ef7cb465587f1
- https://git.kernel.org/stable/c/d18b05eda7fa77f02114f15b02c009f28ee42346
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-39470
In the Linux kernel, the following vulnerability has been resolved: eventfs: Fix a possible null pointer dereference in eventfs_find_events() In function eventfs_find_events,there is a potential null pointer that may be caused by calling update_events_attr which will perform some operations on the members of the ei struct when ei is NULL. Hence,When ei->is_freed is set,return NULL directly.
- https://git.kernel.org/stable/c/5ade5fbdbbb1f023bb70730ba4d74146c8bc7eb9
- https://git.kernel.org/stable/c/7a1b2d138189375ed1dcd7d0851118230221bd1d
- https://git.kernel.org/stable/c/d4e9a968738bf66d3bb852dd5588d4c7afd6d7f4
- https://git.kernel.org/stable/c/5ade5fbdbbb1f023bb70730ba4d74146c8bc7eb9
- https://git.kernel.org/stable/c/7a1b2d138189375ed1dcd7d0851118230221bd1d
- https://git.kernel.org/stable/c/d4e9a968738bf66d3bb852dd5588d4c7afd6d7f4
Modified: 2024-11-21
CVE-2024-39471
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add error handle to avoid out-of-bounds if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL.
- https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46
- https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3
- https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8
- https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691
- https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f
- https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520
- https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a
- https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46
- https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3
- https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8
- https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691
- https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f
- https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520
- https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a
Modified: 2024-11-21
CVE-2024-39473
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension If a process module does not have base config extension then the same format applies to all of it's inputs and the process->base_config_ext is NULL, causing NULL dereference when specifically crafted topology and sequences used.
- https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368
- https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6
- https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8
- https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368
- https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6
- https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8
Modified: 2025-11-03
CVE-2024-39474
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") includes support for __GFP_NOFAIL, but it presents a conflict with commit dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A possible scenario is as follows: process-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer send SIGKILL to process-a if (fatal_signal_pending(current)) break; --> return NULL; To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() if __GFP_NOFAIL set. This issue occurred during OPLUS KASAN TEST. Below is part of the log -> oom-killer sends signal to process [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Call trace: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] show_stack+0x18/0x24 [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] die_kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] el1_abort+0x3c/0x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); kernel panic by NULL pointer dereference. erofs assume kvmalloc with __GFP_NOFAIL never return NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] read_pages+0x170/0xadc [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c
- https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91
- https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4
- https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc
- https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da
- https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91
- https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4
- https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc
- https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-39475
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Handle err return when savagefb_check_var failed The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
- https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b
- https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089
- https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95
- https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339
- https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547
- https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8
- https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7
- https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3
- https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b
- https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089
- https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95
- https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339
- https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547
- https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8
- https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7
- https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3
Modified: 2024-11-21
CVE-2024-39476
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well.
- https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a
- https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa
- https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
- https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4
- https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787
- https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347
- https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447
- https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7
- https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a
- https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa
- https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
- https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4
- https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787
- https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347
- https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447
- https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7
Modified: 2025-05-30
CVE-2024-39479
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hwmon: Get rid of devm When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)
- https://git.kernel.org/stable/c/5bc9de065b8bb9b8dd8799ecb4592d0403b54281
- https://git.kernel.org/stable/c/ce5a22d22db691d14516c3b8fdbf69139eb2ea8f
- https://git.kernel.org/stable/c/cfa73607eb21a4ce1d6294a2c5733628897b48a2
- https://git.kernel.org/stable/c/5bc9de065b8bb9b8dd8799ecb4592d0403b54281
- https://git.kernel.org/stable/c/ce5a22d22db691d14516c3b8fdbf69139eb2ea8f
- https://git.kernel.org/stable/c/cfa73607eb21a4ce1d6294a2c5733628897b48a2
Modified: 2024-11-21
CVE-2024-39480
In the Linux kernel, the following vulnerability has been resolved: kdb: Fix buffer overflow during tab-complete Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.
- https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5
- https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7
- https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96
- https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a
- https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454
- https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33
- https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7
- https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992
- https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5
- https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7
- https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96
- https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a
- https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454
- https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33
- https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7
- https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992
Modified: 2024-11-21
CVE-2024-39481
In the Linux kernel, the following vulnerability has been resolved: media: mc: Fix graph walk in media_pipeline_start The graph walk tries to follow all links, even if they are not between pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link. Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK links.
- https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376
- https://git.kernel.org/stable/c/8a9d420149c477e7c97fbd6453704e4612bdd3fa
- https://git.kernel.org/stable/c/bee9440bc0b6b3b7432f7bfde28656262a3484a2
- https://git.kernel.org/stable/c/e80d9db99b7b6c697d8d952dfd25c3425cf61499
- https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376
- https://git.kernel.org/stable/c/8a9d420149c477e7c97fbd6453704e4612bdd3fa
- https://git.kernel.org/stable/c/bee9440bc0b6b3b7432f7bfde28656262a3484a2
- https://git.kernel.org/stable/c/e80d9db99b7b6c697d8d952dfd25c3425cf61499
Modified: 2024-11-21
CVE-2024-39482
In the Linux kernel, the following vulnerability has been resolved: bcache: fix variable length array abuse in btree_iter btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array.
- https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671
- https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b
- https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31
- https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023
- https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148
- https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02
- https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671
- https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b
- https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31
- https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023
- https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148
- https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02
Modified: 2024-11-21
CVE-2024-39483
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support.
- https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1
- https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6
- https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356
- https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1
- https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6
- https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356
Modified: 2025-11-03
CVE-2024-39484
In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)
- https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584
- https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3
- https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e
- https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4
- https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb
- https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1
- https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584
- https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3
- https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e
- https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4
- https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb
- https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-39485
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Properly re-initialise notifier entry in unregister The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list.
- https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66
- https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb
- https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a
- https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66
- https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb
- https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a
Modified: 2024-11-21
CVE-2024-39486
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_file: Fix pid refcounting race
- https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844
- https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa
- https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9
- https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844
- https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa
- https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9
Modified: 2025-11-03
CVE-2024-39487
In the Linux kernel, the following vulnerability has been resolved:
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
In function bond_option_arp_ip_targets_set(), if newval->string is an
empty string, newval->string+1 will point to the byte after the
string, causing an out-of-bound read.
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e
- https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1
- https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b
- https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7abde78da
- https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8
- https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9
- https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f
- https://git.kernel.org/stable/c/e271ff53807e8f2c628758290f0e499dbe51cb3d
- https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e
- https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1
- https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b
- https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7abde78da
- https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8
- https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9
- https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f
- https://git.kernel.org/stable/c/e271ff53807e8f2c628758290f0e499dbe51cb3d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-17
CVE-2024-39488
In the Linux kernel, the following vulnerability has been resolved: arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc ---truncated---
- https://git.kernel.org/stable/c/22469a0335a1a1a690349b58bcb55822457df81e
- https://git.kernel.org/stable/c/3fd487ffaa697ddb05af78a75aaaddabe71c52b0
- https://git.kernel.org/stable/c/461a760d578b2b2c2faac3040b6b7c77baf128f8
- https://git.kernel.org/stable/c/9f2ad88f9b349554f64e4037ec185c84d7dd9c7d
- https://git.kernel.org/stable/c/c1929c041a262a4a27265db8dce3619c92aa678c
- https://git.kernel.org/stable/c/c27a2f7668e215c1ebbccd96fab27a220a93f1f7
- https://git.kernel.org/stable/c/f221bd58db0f6ca087ac0392284f6bce21f4f8ea
- https://git.kernel.org/stable/c/ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f
- https://git.kernel.org/stable/c/22469a0335a1a1a690349b58bcb55822457df81e
- https://git.kernel.org/stable/c/3fd487ffaa697ddb05af78a75aaaddabe71c52b0
- https://git.kernel.org/stable/c/461a760d578b2b2c2faac3040b6b7c77baf128f8
- https://git.kernel.org/stable/c/9f2ad88f9b349554f64e4037ec185c84d7dd9c7d
- https://git.kernel.org/stable/c/c1929c041a262a4a27265db8dce3619c92aa678c
- https://git.kernel.org/stable/c/c27a2f7668e215c1ebbccd96fab27a220a93f1f7
- https://git.kernel.org/stable/c/f221bd58db0f6ca087ac0392284f6bce21f4f8ea
- https://git.kernel.org/stable/c/ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f
Modified: 2024-11-21
CVE-2024-39489
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix memleak in seg6_hmac_init_algo seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly.
- https://git.kernel.org/stable/c/0e44d6cbe8de983470c3d2f978649783384fdcb6
- https://git.kernel.org/stable/c/4a3fcf53725b70010d1cf869a2ba549fed6b8fb3
- https://git.kernel.org/stable/c/599a5654215092ac22bfc453f4fd3959c55ea821
- https://git.kernel.org/stable/c/61d31ac85b4572d11f8071855c0ccb4f32d76c0c
- https://git.kernel.org/stable/c/afd5730969aec960a2fee4e5ee839a6014643976
- https://git.kernel.org/stable/c/daf341e0a2318b813427d5a78788c86f4a7f02be
- https://git.kernel.org/stable/c/efb9f4f19f8e37fde43dfecebc80292d179f56c6
- https://git.kernel.org/stable/c/f6a99ef4e056c20a138a95cc51332b2b96c8f383
- https://git.kernel.org/stable/c/0e44d6cbe8de983470c3d2f978649783384fdcb6
- https://git.kernel.org/stable/c/4a3fcf53725b70010d1cf869a2ba549fed6b8fb3
- https://git.kernel.org/stable/c/599a5654215092ac22bfc453f4fd3959c55ea821
- https://git.kernel.org/stable/c/61d31ac85b4572d11f8071855c0ccb4f32d76c0c
- https://git.kernel.org/stable/c/afd5730969aec960a2fee4e5ee839a6014643976
- https://git.kernel.org/stable/c/daf341e0a2318b813427d5a78788c86f4a7f02be
- https://git.kernel.org/stable/c/efb9f4f19f8e37fde43dfecebc80292d179f56c6
- https://git.kernel.org/stable/c/f6a99ef4e056c20a138a95cc51332b2b96c8f383
Modified: 2025-03-24
CVE-2024-39490
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix missing sk_buff release in seg6_input_core The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak. This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks. The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails.
- https://git.kernel.org/stable/c/5447f9708d9e4c17a647b16a9cb29e9e02820bd9
- https://git.kernel.org/stable/c/8f1fc3b86eaea70be6abcae2e9aa7e7b99453864
- https://git.kernel.org/stable/c/e8688218e38111ace457509d8f0cad75f79c1a7a
- https://git.kernel.org/stable/c/f4df8c7670a73752201cbde215254598efdf6ce8
- https://git.kernel.org/stable/c/f5fec1588642e415a3d72e02140160661b303940
- https://git.kernel.org/stable/c/5447f9708d9e4c17a647b16a9cb29e9e02820bd9
- https://git.kernel.org/stable/c/8f1fc3b86eaea70be6abcae2e9aa7e7b99453864
- https://git.kernel.org/stable/c/e8688218e38111ace457509d8f0cad75f79c1a7a
- https://git.kernel.org/stable/c/f4df8c7670a73752201cbde215254598efdf6ce8
- https://git.kernel.org/stable/c/f5fec1588642e415a3d72e02140160661b303940
Modified: 2025-09-17
CVE-2024-39491
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance The cs_dsp instance is initialized in the driver probe() so it should be freed in the driver remove(). Also fix a missing call to cs_dsp_remove() in the error path of cs35l56_hda_common_probe(). The call to cs_dsp_remove() was being done in the component unbind callback cs35l56_hda_unbind(). This meant that if the driver was unbound and then re-bound it would be using an uninitialized cs_dsp instance. It is best to initialize the cs_dsp instance in probe() so that it can return an error if it fails. The component binding API doesn't have any error handling so there's no way to handle a failure if cs_dsp was initialized in the bind.
- https://git.kernel.org/stable/c/60d5e087e5f334475b032ad7e6ad849fb998f303
- https://git.kernel.org/stable/c/9054c474f9c219e58a441e401c0e6e38fe713ff1
- https://git.kernel.org/stable/c/d344873c4cbde249b7152d36a273bcc45864001e
- https://git.kernel.org/stable/c/60d5e087e5f334475b032ad7e6ad849fb998f303
- https://git.kernel.org/stable/c/9054c474f9c219e58a441e401c0e6e38fe713ff1
- https://git.kernel.org/stable/c/d344873c4cbde249b7152d36a273bcc45864001e
Modified: 2026-01-06
CVE-2024-39494
In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.
- https://git.kernel.org/stable/c/0b31e28fbd773aefb6164687e0767319b8199829
- https://git.kernel.org/stable/c/480afcbeb7aaaa22677d3dd48ec590b441eaac1a
- https://git.kernel.org/stable/c/7fb374981e31c193b1152ed8d3b0a95b671330d4
- https://git.kernel.org/stable/c/a78a6f0da57d058e2009e9958fdcef66f165208c
- https://git.kernel.org/stable/c/be84f32bb2c981ca670922e047cdde1488b233de
- https://git.kernel.org/stable/c/dd431c3ac1fc34a9268580dd59ad3e3c76b32a8c
- https://git.kernel.org/stable/c/edf287bc610b18d7a9c0c0c1cb2e97b9348c71bb
- https://git.kernel.org/stable/c/7fb374981e31c193b1152ed8d3b0a95b671330d4
- https://git.kernel.org/stable/c/a78a6f0da57d058e2009e9958fdcef66f165208c
- https://git.kernel.org/stable/c/be84f32bb2c981ca670922e047cdde1488b233de
- https://git.kernel.org/stable/c/dd431c3ac1fc34a9268580dd59ad3e3c76b32a8c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-11-03
CVE-2024-39495
In the Linux kernel, the following vulnerability has been resolved: greybus: Fix use-after-free bug in gb_interface_release due to race condition. In gb_interface_create, &intf->mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object "intf". However, if gb_interface_mode_switch_work is scheduled to run after kfree, it may cause use-after-free error as gb_interface_mode_switch_work will use the object "intf". The possible execution flow that may lead to the issue is as follows: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (free) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (use) Fix it by canceling the work before kfree.
- https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445
- https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea
- https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83
- https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce
- https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201
- https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc
- https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9
- https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445
- https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea
- https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83
- https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce
- https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201
- https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc
- https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-01-06
CVE-2024-39496
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.
- https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9
- https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6
- https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43
- https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752
- https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9
- https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6
- https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43
- https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-39497
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE) Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Return -EINVAL early if COW mapping is detected. This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;
- https://git.kernel.org/stable/c/03c71c42809ef4b17f5d874cdb2d3bf40e847b86
- https://git.kernel.org/stable/c/1b4a8b89bf6787090b56424d269bf84ba00c3263
- https://git.kernel.org/stable/c/2219e5f97244b79c276751a1167615b9714db1b0
- https://git.kernel.org/stable/c/39bc27bd688066a63e56f7f64ad34fae03fbe3b8
- https://git.kernel.org/stable/c/3ae63a8c1685e16958560ec08d30defdc5b9cca0
- https://git.kernel.org/stable/c/a508a102edf8735adc9bb73d37dd13c38d1a1b10
- https://git.kernel.org/stable/c/03c71c42809ef4b17f5d874cdb2d3bf40e847b86
- https://git.kernel.org/stable/c/1b4a8b89bf6787090b56424d269bf84ba00c3263
- https://git.kernel.org/stable/c/39bc27bd688066a63e56f7f64ad34fae03fbe3b8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-39499
In the Linux kernel, the following vulnerability has been resolved: vmci: prevent speculation leaks by sanitizing event in event_deliver() Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW.
- https://git.kernel.org/stable/c/58730dfbd4ae01c1b022b0d234a8bf8c02cdfb81
- https://git.kernel.org/stable/c/681967c4ff210e06380acf9b9a1b33ae06e77cbd
- https://git.kernel.org/stable/c/757804e1c599af5d2a7f864c8e8b2842406ff4bb
- https://git.kernel.org/stable/c/8003f00d895310d409b2bf9ef907c56b42a4e0f4
- https://git.kernel.org/stable/c/95ac3e773a1f8da83c4710a720fbfe80055aafae
- https://git.kernel.org/stable/c/95bac1c8bedb362374ea1937b1d3e833e01174ee
- https://git.kernel.org/stable/c/e293c6b38ac9029d76ff0d2a6b2d74131709a9a8
- https://git.kernel.org/stable/c/f70ff737346744633e7b655c1fb23e1578491ff3
- https://git.kernel.org/stable/c/58730dfbd4ae01c1b022b0d234a8bf8c02cdfb81
- https://git.kernel.org/stable/c/681967c4ff210e06380acf9b9a1b33ae06e77cbd
- https://git.kernel.org/stable/c/757804e1c599af5d2a7f864c8e8b2842406ff4bb
- https://git.kernel.org/stable/c/8003f00d895310d409b2bf9ef907c56b42a4e0f4
- https://git.kernel.org/stable/c/95ac3e773a1f8da83c4710a720fbfe80055aafae
- https://git.kernel.org/stable/c/95bac1c8bedb362374ea1937b1d3e833e01174ee
- https://git.kernel.org/stable/c/e293c6b38ac9029d76ff0d2a6b2d74131709a9a8
- https://git.kernel.org/stable/c/f70ff737346744633e7b655c1fb23e1578491ff3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-39500
In the Linux kernel, the following vulnerability has been resolved:
sock_map: avoid race between sock_map_close and sk_psock_put
sk_psock_get will return NULL if the refcount of psock has gone to 0, which
will happen when the last call of sk_psock_put is done. However,
sk_psock_drop may not have finished yet, so the close callback will still
point to sock_map_close despite psock being NULL.
This can be reproduced with a thread deleting an element from the sock map,
while the second one creates a socket, adds it to the map and closes it.
That will trigger the WARN_ON_ONCE:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
Modules linked in:
CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02
RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293
RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000
RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0
RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3
R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840
R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870
FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0
Call Trace:
- https://git.kernel.org/stable/c/3627605de498639a3c586c8684d12c89cba11073
- https://git.kernel.org/stable/c/4959ffc65a0e94f8acaac20deac49f89e6ded52d
- https://git.kernel.org/stable/c/4b4647add7d3c8530493f7247d11e257ee425bf0
- https://git.kernel.org/stable/c/5eabdf17fed2ad41b836bb4055ec36d95e512c50
- https://git.kernel.org/stable/c/e946428439a0d2079959f5603256ac51b6047017
- https://git.kernel.org/stable/c/3627605de498639a3c586c8684d12c89cba11073
- https://git.kernel.org/stable/c/4959ffc65a0e94f8acaac20deac49f89e6ded52d
- https://git.kernel.org/stable/c/4b4647add7d3c8530493f7247d11e257ee425bf0
- https://git.kernel.org/stable/c/5eabdf17fed2ad41b836bb4055ec36d95e512c50
- https://git.kernel.org/stable/c/e946428439a0d2079959f5603256ac51b6047017
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-39502
In the Linux kernel, the following vulnerability has been resolved:
ionic: fix use after netif_napi_del()
When queues are started, netif_napi_add() and napi_enable() are called.
If there are 4 queues and only 3 queues are used for the current
configuration, only 3 queues' napi should be registered and enabled.
The ionic_qcq_enable() checks whether the .poll pointer is not NULL for
enabling only the using queue' napi. Unused queues' napi will not be
registered by netif_napi_add(), so the .poll pointer indicates NULL.
But it couldn't distinguish whether the napi was unregistered or not
because netif_napi_del() doesn't reset the .poll pointer to NULL.
So, ionic_qcq_enable() calls napi_enable() for the queue, which was
unregistered by netif_napi_del().
Reproducer:
ethtool -L
- https://git.kernel.org/stable/c/0d19267cb150e8f76ade210e16ee820a77f684e7
- https://git.kernel.org/stable/c/183ebc167a8a19e916b885d4bb61a3491991bfa5
- https://git.kernel.org/stable/c/60cd714871cd5a683353a355cbb17a685245cf84
- https://git.kernel.org/stable/c/79f18a41dd056115d685f3b0a419c7cd40055e13
- https://git.kernel.org/stable/c/8edd18dab443863e9e48f084e7f123fca3065e4e
- https://git.kernel.org/stable/c/a87d72b37b9ec2c1e18fe36b09241d8b30334a2e
- https://git.kernel.org/stable/c/ff9c2a9426ecf5b9631e9fd74993b357262387d6
- https://git.kernel.org/stable/c/0d19267cb150e8f76ade210e16ee820a77f684e7
- https://git.kernel.org/stable/c/183ebc167a8a19e916b885d4bb61a3491991bfa5
- https://git.kernel.org/stable/c/60cd714871cd5a683353a355cbb17a685245cf84
- https://git.kernel.org/stable/c/79f18a41dd056115d685f3b0a419c7cd40055e13
- https://git.kernel.org/stable/c/8edd18dab443863e9e48f084e7f123fca3065e4e
- https://git.kernel.org/stable/c/a87d72b37b9ec2c1e18fe36b09241d8b30334a2e
- https://git.kernel.org/stable/c/ff9c2a9426ecf5b9631e9fd74993b357262387d6
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-39503
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type Lion Ackermann reported that there is a race condition between namespace cleanup in ipset and the garbage collection of the list:set type. The namespace cleanup can destroy the list:set type of sets while the gc of the set type is waiting to run in rcu cleanup. The latter uses data from the destroyed set which thus leads use after free. The patch contains the following parts: - When destroying all sets, first remove the garbage collectors, then wait if needed and then destroy the sets. - Fix the badly ordered "wait then remove gc" for the destroy a single set case. - Fix the missing rcu locking in the list:set type in the userspace test case. - Use proper RCU list handlings in the list:set type. The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).
- https://git.kernel.org/stable/c/0f1bb77c6d837c9513943bc7c08f04c5cc5c6568
- https://git.kernel.org/stable/c/2ba35b37f780c6410bb4bba9c3072596d8576702
- https://git.kernel.org/stable/c/390b353d1a1da3e9c6c0fd14fe650d69063c95d6
- https://git.kernel.org/stable/c/4e7aaa6b82d63e8ddcbfb56b4fd3d014ca586f10
- https://git.kernel.org/stable/c/90ae20d47de602198eb69e6cd7a3db3420abfc08
- https://git.kernel.org/stable/c/93b53c202b51a69e42ca57f5a183f7e008e19f83
- https://git.kernel.org/stable/c/c0761d1f1ce1d5b85b5e82bbb714df12de1aa8c3
- https://git.kernel.org/stable/c/0f1bb77c6d837c9513943bc7c08f04c5cc5c6568
- https://git.kernel.org/stable/c/2ba35b37f780c6410bb4bba9c3072596d8576702
- https://git.kernel.org/stable/c/390b353d1a1da3e9c6c0fd14fe650d69063c95d6
- https://git.kernel.org/stable/c/4e7aaa6b82d63e8ddcbfb56b4fd3d014ca586f10
- https://git.kernel.org/stable/c/90ae20d47de602198eb69e6cd7a3db3420abfc08
- https://git.kernel.org/stable/c/93b53c202b51a69e42ca57f5a183f7e008e19f83
- https://git.kernel.org/stable/c/c0761d1f1ce1d5b85b5e82bbb714df12de1aa8c3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-39504
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_inner: validate mandatory meta and payload Check for mandatory netlink attributes in payload and meta expression when used embedded from the inner expression, otherwise NULL pointer dereference is possible from userspace.
- https://git.kernel.org/stable/c/39323f54cad29602917848346c71b087da92a19d
- https://git.kernel.org/stable/c/b30669fdea0ca03aa22995e6c99f7e7d9dee89ff
- https://git.kernel.org/stable/c/c4ab9da85b9df3692f861512fe6c9812f38b7471
- https://git.kernel.org/stable/c/39323f54cad29602917848346c71b087da92a19d
- https://git.kernel.org/stable/c/b30669fdea0ca03aa22995e6c99f7e7d9dee89ff
- https://git.kernel.org/stable/c/c4ab9da85b9df3692f861512fe6c9812f38b7471
Modified: 2025-11-03
CVE-2024-39505
In the Linux kernel, the following vulnerability has been resolved: drm/komeda: check for error-valued pointer komeda_pipeline_get_state() may return an error-valued pointer, thus check the pointer for negative or null value before dereferencing.
- https://git.kernel.org/stable/c/0674ed1e58e2fdcc155e7d944f8aad007a94ac69
- https://git.kernel.org/stable/c/3b1cf943b029c147bfacfd53dc28ffa632c0a622
- https://git.kernel.org/stable/c/86042e3d16b7e0686db835c9e7af0f9044dd3a56
- https://git.kernel.org/stable/c/9460961d82134ceda7377b77a3e3e3531b625dfe
- https://git.kernel.org/stable/c/99392c98b9be0523fe76944b2264b1847512ad23
- https://git.kernel.org/stable/c/b880018edd3a577e50366338194dee9b899947e0
- https://git.kernel.org/stable/c/bda7cdaeebf57e46c1a488ae7a15f6f264691f59
- https://git.kernel.org/stable/c/0674ed1e58e2fdcc155e7d944f8aad007a94ac69
- https://git.kernel.org/stable/c/3b1cf943b029c147bfacfd53dc28ffa632c0a622
- https://git.kernel.org/stable/c/86042e3d16b7e0686db835c9e7af0f9044dd3a56
- https://git.kernel.org/stable/c/9460961d82134ceda7377b77a3e3e3531b625dfe
- https://git.kernel.org/stable/c/99392c98b9be0523fe76944b2264b1847512ad23
- https://git.kernel.org/stable/c/b880018edd3a577e50366338194dee9b899947e0
- https://git.kernel.org/stable/c/bda7cdaeebf57e46c1a488ae7a15f6f264691f59
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-39506
In the Linux kernel, the following vulnerability has been resolved: liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2
- https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989b42bbfa
- https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c
- https://git.kernel.org/stable/c/c44711b78608c98a3e6b49ce91678cd0917d5349
- https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347
- https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79
- https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee
- https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea
- https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2
- https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989b42bbfa
- https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c
- https://git.kernel.org/stable/c/c44711b78608c98a3e6b49ce91678cd0917d5349
- https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347
- https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79
- https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee
- https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-39507
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash problem in concurrent scenario When link status change, the nic driver need to notify the roce driver to handle this event, but at this time, the roce driver may uninit, then cause kernel crash. To fix the problem, when link status change, need to check whether the roce registered, and when uninit, need to wait link update finish.
- https://git.kernel.org/stable/c/12cda920212a49fa22d9e8b9492ac4ea013310a4
- https://git.kernel.org/stable/c/62b5dfb67bfa8bd0301bf3442004563495f9ee48
- https://git.kernel.org/stable/c/689de7c3bfc7d47e0eacc641c4ce4a0f579aeefa
- https://git.kernel.org/stable/c/6d0007f7b69d684879a0f598a042e40244d3cf63
- https://git.kernel.org/stable/c/b2c5024b771cd1dd8175d5f6949accfadbab7edd
- https://git.kernel.org/stable/c/12cda920212a49fa22d9e8b9492ac4ea013310a4
- https://git.kernel.org/stable/c/62b5dfb67bfa8bd0301bf3442004563495f9ee48
- https://git.kernel.org/stable/c/689de7c3bfc7d47e0eacc641c4ce4a0f579aeefa
- https://git.kernel.org/stable/c/6d0007f7b69d684879a0f598a042e40244d3cf63
- https://git.kernel.org/stable/c/b2c5024b771cd1dd8175d5f6949accfadbab7edd
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-03
CVE-2024-39508
In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq
to address potential data races.
The structure io_worker->flags may be accessed through various data
paths, leading to concurrency issues. When KCSAN is enabled, it reveals
data races occurring in io_worker_handle_work and
io_wq_activate_free_worker functions.
BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
io_wq_worker (io_uring/io-wq.c:?)
- https://git.kernel.org/stable/c/1cbb0affb15470a9621267fe0a8568007553a4bf
- https://git.kernel.org/stable/c/8a565304927fbd28c9f028c492b5c1714002cbab
- https://git.kernel.org/stable/c/ab702c3483db9046bab9f40306f1a28b22dbbdc0
- https://git.kernel.org/stable/c/1cbb0affb15470a9621267fe0a8568007553a4bf
- https://git.kernel.org/stable/c/8a565304927fbd28c9f028c492b5c1714002cbab
- https://git.kernel.org/stable/c/ab702c3483db9046bab9f40306f1a28b22dbbdc0
Modified: 2025-11-03
CVE-2024-39509
In the Linux kernel, the following vulnerability has been resolved:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying
to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
...
value &= m;
...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.
[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
- https://git.kernel.org/stable/c/30f76bc468b9b2cbbd5d3eb482661e3e4798893f
- https://git.kernel.org/stable/c/33f6832798dd3297317901cc1db556ac3ae80c24
- https://git.kernel.org/stable/c/4aa2dcfbad538adf7becd0034a3754e1bd01b2b5
- https://git.kernel.org/stable/c/655c6de2f215b61d0708db6b06305eee9bbfeba2
- https://git.kernel.org/stable/c/8bac61934cd563b073cd30b8cf6d5c758ab5ab26
- https://git.kernel.org/stable/c/955b3764671f3f157215194972d9c01a3a4bd316
- https://git.kernel.org/stable/c/bfd546fc7fd76076f81bf41b85b51ceda30949fd
- https://git.kernel.org/stable/c/f9db5fbeffb951cac3f0fb1c2eeffb79785399ca
- https://git.kernel.org/stable/c/30f76bc468b9b2cbbd5d3eb482661e3e4798893f
- https://git.kernel.org/stable/c/33f6832798dd3297317901cc1db556ac3ae80c24
- https://git.kernel.org/stable/c/4aa2dcfbad538adf7becd0034a3754e1bd01b2b5
- https://git.kernel.org/stable/c/655c6de2f215b61d0708db6b06305eee9bbfeba2
- https://git.kernel.org/stable/c/8bac61934cd563b073cd30b8cf6d5c758ab5ab26
- https://git.kernel.org/stable/c/955b3764671f3f157215194972d9c01a3a4bd316
- https://git.kernel.org/stable/c/bfd546fc7fd76076f81bf41b85b51ceda30949fd
- https://git.kernel.org/stable/c/f9db5fbeffb951cac3f0fb1c2eeffb79785399ca
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40900
In the Linux kernel, the following vulnerability has been resolved: cachefiles: remove requests from xarray during flushing requests Even with CACHEFILES_DEAD set, we can still read the requests, so in the following concurrency the request may be used after it has been freed: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------------------ cachefiles_ondemand_init_object cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read // close dev fd cachefiles_flush_reqs complete(&REQ_A->done) kfree(REQ_A) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // req use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Hence remove requests from cache->reqs when flushing them to avoid accessing freed requests.
- https://git.kernel.org/stable/c/0fc75c5940fa634d84e64c93bfc388e1274ed013
- https://git.kernel.org/stable/c/37e19cf86a520d65de1de9cb330415c332a40d19
- https://git.kernel.org/stable/c/50d0e55356ba5b84ffb51c42704126124257e598
- https://git.kernel.org/stable/c/9f13aacdd4ee9a7644b2a3c96d67113cd083c9c7
- https://git.kernel.org/stable/c/0fc75c5940fa634d84e64c93bfc388e1274ed013
- https://git.kernel.org/stable/c/37e19cf86a520d65de1de9cb330415c332a40d19
- https://git.kernel.org/stable/c/50d0e55356ba5b84ffb51c42704126124257e598
- https://git.kernel.org/stable/c/9f13aacdd4ee9a7644b2a3c96d67113cd083c9c7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40901
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump: BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965 For full log, please look at [1]. Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory. [1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
- https://git.kernel.org/stable/c/0081d2b3ae0a17a86b8cc0fa3c8bdc54e233ba16
- https://git.kernel.org/stable/c/18abb5db0aa9b2d48f7037a88b41af2eef821674
- https://git.kernel.org/stable/c/19649e49a6df07cd2e03e0a11396fd3a99485ec2
- https://git.kernel.org/stable/c/4254dfeda82f20844299dca6c38cbffcfd499f41
- https://git.kernel.org/stable/c/46bab2bcd771e725ff5ca3a68ba68cfeac45676c
- https://git.kernel.org/stable/c/521f333e644c4246ca04a4fc4772edc53dd2a801
- https://git.kernel.org/stable/c/9079338c5a0d1f1fee34fb1c9e99b754efe414c5
- https://git.kernel.org/stable/c/e9bce7c751f6d6c7be88c0bc081a66aaf61a23ee
- https://git.kernel.org/stable/c/0081d2b3ae0a17a86b8cc0fa3c8bdc54e233ba16
- https://git.kernel.org/stable/c/18abb5db0aa9b2d48f7037a88b41af2eef821674
- https://git.kernel.org/stable/c/19649e49a6df07cd2e03e0a11396fd3a99485ec2
- https://git.kernel.org/stable/c/4254dfeda82f20844299dca6c38cbffcfd499f41
- https://git.kernel.org/stable/c/46bab2bcd771e725ff5ca3a68ba68cfeac45676c
- https://git.kernel.org/stable/c/521f333e644c4246ca04a4fc4772edc53dd2a801
- https://git.kernel.org/stable/c/9079338c5a0d1f1fee34fb1c9e99b754efe414c5
- https://git.kernel.org/stable/c/e9bce7c751f6d6c7be88c0bc081a66aaf61a23ee
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40902
In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log.
- https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a
- https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123
- https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69
- https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7
- https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f
- https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f
- https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f
- https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0
- https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a
- https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123
- https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69
- https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7
- https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f
- https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f
- https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f
- https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40904
In the Linux kernel, the following vulnerability has been resolved:
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
The syzbot fuzzer found that the interrupt-URB completion callback in
the cdc-wdm driver was taking too long, and the driver's immediate
resubmission of interrupt URBs with -EPROTO status combined with the
dummy-hcd emulation to cause a CPU lockup:
cdc_wdm 1-1:1.0: nonzero urb status received: -71
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
CPU#0 Utilization every 4s during lockup:
#1: 98% system, 0% softirq, 3% hardirq, 0% idle
#2: 98% system, 0% softirq, 3% hardirq, 0% idle
#3: 98% system, 0% softirq, 3% hardirq, 0% idle
#4: 98% system, 0% softirq, 3% hardirq, 0% idle
#5: 98% system, 1% softirq, 3% hardirq, 0% idle
Modules linked in:
irq event stamp: 73096
hardirqs last enabled at (73095): [
- https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94
- https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28
- https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56
- https://git.kernel.org/stable/c/22f00812862564b314784167a89f27b444f82a46
- https://git.kernel.org/stable/c/53250b54c92fe087fd4b0c48f85529efe1ebd879
- https://git.kernel.org/stable/c/72a3fe36cf9f0d030865e571f45a40f9c1e07e8a
- https://git.kernel.org/stable/c/82075aff7ffccb1e72b0ac8aa349e473624d857c
- https://git.kernel.org/stable/c/c0747d76eb05542b5d49f67069b64ef5ff732c6c
- https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94
- https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28
- https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56
- https://git.kernel.org/stable/c/22f00812862564b314784167a89f27b444f82a46
- https://git.kernel.org/stable/c/53250b54c92fe087fd4b0c48f85529efe1ebd879
- https://git.kernel.org/stable/c/72a3fe36cf9f0d030865e571f45a40f9c1e07e8a
- https://git.kernel.org/stable/c/82075aff7ffccb1e72b0ac8aa349e473624d857c
- https://git.kernel.org/stable/c/c0747d76eb05542b5d49f67069b64ef5ff732c6c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40905
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible race in __fib6_drop_pcpu_from()
syzbot found a race in __fib6_drop_pcpu_from() [1]
If compiler reads more than once (*ppcpu_rt),
second read could read NULL, if another cpu clears
the value in rt6_get_pcpu_route().
Add a READ_ONCE() to prevent this race.
Also add rcu_read_lock()/rcu_read_unlock() because
we rely on RCU protection while dereferencing pcpu_rt.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: netns cleanup_net
RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/09e5a5a80e205922151136069e440477d6816914
- https://git.kernel.org/stable/c/2498960dac9b6fc49b6d1574f7cd1a4872744adf
- https://git.kernel.org/stable/c/7e796c3fefa8b17b30e7252886ae8cffacd2b9ef
- https://git.kernel.org/stable/c/a0bc020592b54a8f3fa2b7f244b6e39e526c2e12
- https://git.kernel.org/stable/c/b01e1c030770ff3b4fe37fc7cc6bca03f594133f
- https://git.kernel.org/stable/c/c693698787660c97950bc1f93a8dd19d8307153d
- https://git.kernel.org/stable/c/c90af1cced2f669a7b2304584be4ada495eaa0e5
- https://git.kernel.org/stable/c/09e5a5a80e205922151136069e440477d6816914
- https://git.kernel.org/stable/c/2498960dac9b6fc49b6d1574f7cd1a4872744adf
- https://git.kernel.org/stable/c/7e796c3fefa8b17b30e7252886ae8cffacd2b9ef
- https://git.kernel.org/stable/c/a0bc020592b54a8f3fa2b7f244b6e39e526c2e12
- https://git.kernel.org/stable/c/b01e1c030770ff3b4fe37fc7cc6bca03f594133f
- https://git.kernel.org/stable/c/c693698787660c97950bc1f93a8dd19d8307153d
- https://git.kernel.org/stable/c/c90af1cced2f669a7b2304584be4ada495eaa0e5
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40906
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Always stop health timer during driver removal
Currently, if teardown_hca fails to execute during driver removal, mlx5
does not stop the health timer. Afterwards, mlx5 continue with driver
teardown. This may lead to a UAF bug, which results in page fault
Oops[1], since the health timer invokes after resources were freed.
Hence, stop the health monitor even if teardown_hca fails.
[1]
mlx5_core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
mlx5_core 0000:18:00.0: E-Switch: cleanup
mlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) timeout. Will cause a leak of a command resource
mlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): tear_down_hca failed, skip cleanup
BUG: unable to handle page fault for address: ffffa26487064230
PGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------- --- 6.7.0-68.fc38.x86_64 #1
Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020
RIP: 0010:ioread32be+0x34/0x60
RSP: 0018:ffffa26480003e58 EFLAGS: 00010292
RAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0
RDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230
RBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8
R10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0
R13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0
FS: 0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/6ccada6ffb42e0ac75e3db06d41baf5a7f483f8a
- https://git.kernel.org/stable/c/c8b3f38d2dae0397944814d691a419c451f9906f
- https://git.kernel.org/stable/c/e6777ae0bf6fd5bc626bb051c8c93e3c8198a3f8
- https://git.kernel.org/stable/c/e7d4485d47839f4d1284592ae242c4e65b2810a9
- https://git.kernel.org/stable/c/6ccada6ffb42e0ac75e3db06d41baf5a7f483f8a
- https://git.kernel.org/stable/c/c8b3f38d2dae0397944814d691a419c451f9906f
- https://git.kernel.org/stable/c/e6777ae0bf6fd5bc626bb051c8c93e3c8198a3f8
- https://git.kernel.org/stable/c/e7d4485d47839f4d1284592ae242c4e65b2810a9
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40908
In the Linux kernel, the following vulnerability has been resolved: bpf: Set run context for rawtp test_run callback syzbot reported crash when rawtp program executed through the test_run interface calls bpf_get_attach_cookie helper or any other helper that touches task->bpf_ctx pointer. Setting the run context (task->bpf_ctx pointer) for test_run callback.
- https://git.kernel.org/stable/c/3708b6c2546c9eb34aead8a34a17e8ae69004e4d
- https://git.kernel.org/stable/c/789bd77c9342aa6125003871ae5c6034d0f6f9d2
- https://git.kernel.org/stable/c/ae0ba0ab7475a129ef7d449966edf677367efeb4
- https://git.kernel.org/stable/c/d0d1df8ba18abc57f28fb3bc053b2bf319367f2c
- https://git.kernel.org/stable/c/d387805d4b4a46ee01e3dae133c81b6d80195e5b
- https://git.kernel.org/stable/c/3708b6c2546c9eb34aead8a34a17e8ae69004e4d
- https://git.kernel.org/stable/c/789bd77c9342aa6125003871ae5c6034d0f6f9d2
- https://git.kernel.org/stable/c/ae0ba0ab7475a129ef7d449966edf677367efeb4
- https://git.kernel.org/stable/c/d0d1df8ba18abc57f28fb3bc053b2bf319367f2c
- https://git.kernel.org/stable/c/d387805d4b4a46ee01e3dae133c81b6d80195e5b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40910
In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix refcount imbalance on inbound connections
When releasing a socket in ax25_release(), we call netdev_put() to
decrease the refcount on the associated ax.25 device. However, the
execution path for accepting an incoming connection never calls
netdev_hold(). This imbalance leads to refcount errors, and ultimately
to kernel crashes.
A typical call trace for the above situation will start with one of the
following errors:
refcount_t: decrement hit 0; leaking memory.
refcount_t: underflow; use-after-free.
And will then have a trace like:
Call Trace:
- https://git.kernel.org/stable/c/3c34fb0bd4a4237592c5ecb5b2e2531900c55774
- https://git.kernel.org/stable/c/52100fd74ad07b53a4666feafff1cd11436362d3
- https://git.kernel.org/stable/c/a723a6c8d4831cc8e2c7b0c9f3f0c010d4671964
- https://git.kernel.org/stable/c/f4df9d6c8d4e4c818252b0419c2165d66eabd4eb
- https://git.kernel.org/stable/c/3c34fb0bd4a4237592c5ecb5b2e2531900c55774
- https://git.kernel.org/stable/c/52100fd74ad07b53a4666feafff1cd11436362d3
- https://git.kernel.org/stable/c/a723a6c8d4831cc8e2c7b0c9f3f0c010d4671964
- https://git.kernel.org/stable/c/f4df9d6c8d4e4c818252b0419c2165d66eabd4eb
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40911
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Lock wiphy in cfg80211_get_station Wiphy should be locked before calling rdev_get_station() (see lockdep assert in ieee80211_get_station()). This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814) This happens because STA has time to disconnect and reconnect before batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In this situation, ath10k_sta_state() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that.
- https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a
- https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba
- https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae
- https://git.kernel.org/stable/c/6d540b0317901535275020bd4ac44fac6439ca76
- https://git.kernel.org/stable/c/dfd84ce41663be9ca3f69bd657c45f49b69344d9
- https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a
- https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba
- https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae
- https://git.kernel.org/stable/c/6d540b0317901535275020bd4ac44fac6439ca76
- https://git.kernel.org/stable/c/dfd84ce41663be9ca3f69bd657c45f49b69344d9
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40912
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup() The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from softirq context. However using only spin_lock() to get sta->ps_lock in ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150 Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise on the same CPU that is holding the lock.
- https://git.kernel.org/stable/c/28ba44d680a30c51cf485a2f5a3b680e66ed3932
- https://git.kernel.org/stable/c/44c06bbde6443de206b30f513100b5670b23fc5e
- https://git.kernel.org/stable/c/456bbb8a31e425177dc0e8d4f98728a560c20e81
- https://git.kernel.org/stable/c/47d176755d5c0baf284eff039560f8c1ba0ea485
- https://git.kernel.org/stable/c/9c49b58b9a2bed707e7638576e54c4bccd97b9eb
- https://git.kernel.org/stable/c/d90bdff79f8e40adf889b5408bfcf521528b169f
- https://git.kernel.org/stable/c/e51637e0c66a6f72d134d9f95daa47ea62b43c7e
- https://git.kernel.org/stable/c/e7e916d693dcb5a297f40312600a82475f2e63bc
- https://git.kernel.org/stable/c/28ba44d680a30c51cf485a2f5a3b680e66ed3932
- https://git.kernel.org/stable/c/44c06bbde6443de206b30f513100b5670b23fc5e
- https://git.kernel.org/stable/c/456bbb8a31e425177dc0e8d4f98728a560c20e81
- https://git.kernel.org/stable/c/47d176755d5c0baf284eff039560f8c1ba0ea485
- https://git.kernel.org/stable/c/9c49b58b9a2bed707e7638576e54c4bccd97b9eb
- https://git.kernel.org/stable/c/d90bdff79f8e40adf889b5408bfcf521528b169f
- https://git.kernel.org/stable/c/e51637e0c66a6f72d134d9f95daa47ea62b43c7e
- https://git.kernel.org/stable/c/e7e916d693dcb5a297f40312600a82475f2e63bc
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40913
In the Linux kernel, the following vulnerability has been resolved: cachefiles: defer exposing anon_fd until after copy_to_user() succeeds After installing the anonymous fd, we can now see it in userland and close it. However, at this point we may not have gotten the reference count of the cache, but we will put it during colse fd, so this may cause a cache UAF. So grab the cache reference count before fd_install(). In addition, by kernel convention, fd is taken over by the user land after fd_install(), and the kernel should not call close_fd() after that, i.e., it should call fd_install() after everything is ready, thus fd_install() is called after copy_to_user() succeeds.
- https://git.kernel.org/stable/c/4b4391e77a6bf24cba2ef1590e113d9b73b11039
- https://git.kernel.org/stable/c/b9f58cdae6a364a3270fd6b6a46e0fd4f7f8ce32
- https://git.kernel.org/stable/c/d2d3eb377a5d081bf2bed177d354a4f59b74da88
- https://git.kernel.org/stable/c/eac51d9daacd61dcc93333ff6a890cf3efc8c1c0
- https://git.kernel.org/stable/c/4b4391e77a6bf24cba2ef1590e113d9b73b11039
- https://git.kernel.org/stable/c/b9f58cdae6a364a3270fd6b6a46e0fd4f7f8ce32
- https://git.kernel.org/stable/c/d2d3eb377a5d081bf2bed177d354a4f59b74da88
- https://git.kernel.org/stable/c/eac51d9daacd61dcc93333ff6a890cf3efc8c1c0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40914
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: don't unpoison huge_zero_folio
When I did memory failure tests recently, below panic occurs:
kernel BUG at include/linux/mm.h:1135!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14
RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0
RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246
RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8
RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0
RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492
R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00
FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/0d73477af964dbd7396163a13817baf13940bca9
- https://git.kernel.org/stable/c/688bb46ad339497b5b7f527b6636d2afe04b46af
- https://git.kernel.org/stable/c/b2494506f30675245a3e6787281f79601af087bf
- https://git.kernel.org/stable/c/d72b7711919de49d92a67dfc844a6cf4c23dd794
- https://git.kernel.org/stable/c/fe6f86f4b40855a130a19aa589f9ba7f650423f4
- https://git.kernel.org/stable/c/0d73477af964dbd7396163a13817baf13940bca9
- https://git.kernel.org/stable/c/688bb46ad339497b5b7f527b6636d2afe04b46af
- https://git.kernel.org/stable/c/b2494506f30675245a3e6787281f79601af087bf
- https://git.kernel.org/stable/c/d72b7711919de49d92a67dfc844a6cf4c23dd794
- https://git.kernel.org/stable/c/fe6f86f4b40855a130a19aa589f9ba7f650423f4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40915
In the Linux kernel, the following vulnerability has been resolved:
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
__kernel_map_pages() is a debug function which clears the valid bit in page
table entry for deallocated pages to detect illegal memory accesses to
freed pages.
This function set/clear the valid bit using __set_memory(). __set_memory()
acquires init_mm's semaphore, and this operation may sleep. This is
problematic, because __kernel_map_pages() can be called in atomic context,
and thus is illegal to sleep. An example warning that this causes:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
preempt_count: 2, expected: 0
CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[
- https://git.kernel.org/stable/c/8661a7af04991201640863ad1a0983173f84b5eb
- https://git.kernel.org/stable/c/919f8626099d9909b9a9620b05e8c8ab06581876
- https://git.kernel.org/stable/c/d5257ceb19d92069195254866421f425aea42915
- https://git.kernel.org/stable/c/fb1cf0878328fe75d47f0aed0a65b30126fcefc4
- https://git.kernel.org/stable/c/8661a7af04991201640863ad1a0983173f84b5eb
- https://git.kernel.org/stable/c/919f8626099d9909b9a9620b05e8c8ab06581876
- https://git.kernel.org/stable/c/d5257ceb19d92069195254866421f425aea42915
- https://git.kernel.org/stable/c/fb1cf0878328fe75d47f0aed0a65b30126fcefc4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-17
CVE-2024-40918
In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. Another issue is that the present bit in PTEs is racy. 1) PA-RISC caches have a mind of their own and they can speculatively load data and instructions for a page as long as there is a entry in the TLB for the page which allows move-in. TLBs are local to each CPU. Thus, the TLB entry for a page must be purged before flushing the page. This is particularly important on SMP systems. In some of the flush routines, the flush routine would be called and then the TLB entry would be purged. This was because the flush routine needed the TLB entry to do the flush. 2) My initial approach to trying the fix the random faults was to try and use flush_cache_page_if_present for all flush operations. This actually made things worse and led to a couple of hardware lockups. It finally dawned on me that some lines weren't being flushed because the pte check code was racy. This resulted in random inequivalent mappings to physical pages. The __flush_cache_page tmpalias flush sets up its own TLB entry and it doesn't need the existing TLB entry. As long as we can find the pte pointer for the vm page, we can get the pfn and physical address of the page. We can also purge the TLB entry for the page before doing the flush. Further, __flush_cache_page uses a special TLB entry that inhibits cache move-in. When switching page mappings, we need to ensure that lines are removed from the cache. It is not sufficient to just flush the lines to memory as they may come back. This made it clear that we needed to implement all the required flush operations using tmpalias routines. This includes flushes for user and kernel pages. After modifying the code to use tmpalias flushes, it became clear that the random segmentation faults were not fully resolved. The frequency of faults was worse on systems with a 64 MB L2 (PA8900) and systems with more CPUs (rp4440). The warning that I added to flush_cache_page_if_present to detect pages that couldn't be flushed triggered frequently on some systems. Helge and I looked at the pages that couldn't be flushed and found that the PTE was either cleared or for a swap page. Ignoring pages that were swapped out seemed okay but pages with cleared PTEs seemed problematic. I looked at routines related to pte_clear and noticed ptep_clear_flush. The default implementation just flushes the TLB entry. However, it was obvious that on parisc we need to flush the cache page as well. If we don't flush the cache page, stale lines will be left in the cache and cause random corruption. Once a PTE is cleared, there is no way to find the physical address associated with the PTE and flush the associated page at a later time. I implemented an updated change with a parisc specific version of ptep_clear_flush. It fixed the random data corruption on Helge's rp4440 and rp3440, as well as on my c8000. At this point, I realized that I could restore the code where we only flush in flush_cache_page_if_present if the page has been accessed. However, for this, we also need to flush the cache when the accessed bit is cleared in ---truncated---
- https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0
- https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49
- https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20
- https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0
- https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49
- https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20
Modified: 2025-11-03
CVE-2024-40919
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send() In case of token is released due to token->state == BNXT_HWRM_DEFERRED, released token (set to NULL) is used in log messages. This issue is expected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But this error code is returned by recent firmware. So some firmware may not return it. This may lead to NULL pointer dereference. Adjust this issue by adding token pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/8b65eaeae88d4e9f999e806e196dd887b90bfed9
- https://git.kernel.org/stable/c/a9b9741854a9fe9df948af49ca5514e0ed0429df
- https://git.kernel.org/stable/c/ca6660c956242623b4cfe9be2a1abc67907c44bf
- https://git.kernel.org/stable/c/cde177fa235cd36f981012504a6376315bac03c9
- https://git.kernel.org/stable/c/8b65eaeae88d4e9f999e806e196dd887b90bfed9
- https://git.kernel.org/stable/c/a9b9741854a9fe9df948af49ca5514e0ed0429df
- https://git.kernel.org/stable/c/ca6660c956242623b4cfe9be2a1abc67907c44bf
- https://git.kernel.org/stable/c/cde177fa235cd36f981012504a6376315bac03c9
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-03
CVE-2024-40922
In the Linux kernel, the following vulnerability has been resolved:
io_uring/rsrc: don't lock while !TASK_RUNNING
There is a report of io_rsrc_ref_quiesce() locking a mutex while not
TASK_RUNNING, which is due to forgetting restoring the state back after
io_run_task_work_sig() and attempts to break out of the waiting loop.
do not call blocking ops when !TASK_RUNNING; state=1 set at
[
- https://git.kernel.org/stable/c/0c9df3df0c888d9ec8d11a68474a4aa04d371cff
- https://git.kernel.org/stable/c/4429c6c77e176a4c5aa7a3bbd1632f9fc0582518
- https://git.kernel.org/stable/c/54559642b96116b45e4b5ca7fd9f7835b8561272
- https://git.kernel.org/stable/c/0c9df3df0c888d9ec8d11a68474a4aa04d371cff
- https://git.kernel.org/stable/c/4429c6c77e176a4c5aa7a3bbd1632f9fc0582518
- https://git.kernel.org/stable/c/54559642b96116b45e4b5ca7fd9f7835b8561272
Modified: 2025-10-03
CVE-2024-40923
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: disable rx data ring on dma allocation failure
When vmxnet3_rq_create() fails to allocate memory for rq->data_ring.base,
the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset
rq->data_ring.desc_size for the data ring that failed, which presumably
causes the hypervisor to reference it on packet reception.
To fix this bug, rq->data_ring.desc_size needs to be set to 0 to tell
the hypervisor to disable this feature.
[ 95.436876] kernel BUG at net/core/skbuff.c:207!
[ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1
[ 95.441558] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
[ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f
[ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50
ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9
ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24
[ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246
[ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f
[ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f
[ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60
[ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000
[ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0
[ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000
[ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0
[ 95.459791] Call Trace:
[ 95.460515]
- https://git.kernel.org/stable/c/9ee14af24e67ef170108db547f7d1f701b3f2bc5
- https://git.kernel.org/stable/c/aa116ae9d169e28b692292460aed27fc44f4a017
- https://git.kernel.org/stable/c/ffbe335b8d471f79b259e950cb20999700670456
- https://git.kernel.org/stable/c/9ee14af24e67ef170108db547f7d1f701b3f2bc5
- https://git.kernel.org/stable/c/aa116ae9d169e28b692292460aed27fc44f4a017
- https://git.kernel.org/stable/c/ffbe335b8d471f79b259e950cb20999700670456
Modified: 2025-11-03
CVE-2024-40924
In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Make DPT object unshrinkable In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->bound_list. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic. [vsyrjala: Add TODO comment] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)
- https://git.kernel.org/stable/c/327280149066f0e5f2e50356b5823f76dabfe86e
- https://git.kernel.org/stable/c/43e2b37e2ab660c3565d4cff27922bc70e79c3f1
- https://git.kernel.org/stable/c/7a9883be3b98673333eec65c4a21cc18e60292eb
- https://git.kernel.org/stable/c/a2552020fb714ff357182c3c179abfac2289f84d
- https://git.kernel.org/stable/c/327280149066f0e5f2e50356b5823f76dabfe86e
- https://git.kernel.org/stable/c/43e2b37e2ab660c3565d4cff27922bc70e79c3f1
- https://git.kernel.org/stable/c/7a9883be3b98673333eec65c4a21cc18e60292eb
- https://git.kernel.org/stable/c/a2552020fb714ff357182c3c179abfac2289f84d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-17
CVE-2024-40925
In the Linux kernel, the following vulnerability has been resolved: block: fix request.queuelist usage in flush Friedrich Weber reported a kernel crash problem and bisected to commit 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine"). The root cause is that we use "list_move_tail(&rq->queuelist, pending)" in the PREFLUSH/POSTFLUSH sequences. But rq->queuelist.next == xxx since it's popped out from plug->cached_rq in __blk_mq_alloc_requests_batch(). We don't initialize its queuelist just for this first request, although the queuelist of all later popped requests will be initialized. Fix it by changing to use "list_add_tail(&rq->queuelist, pending)" so rq->queuelist doesn't need to be initialized. It should be ok since rq can't be on any list when PREFLUSH or POSTFLUSH, has no move actually. Please note the commit 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine") also has another requirement that no drivers would touch rq->queuelist after blk_mq_end_request() since we will reuse it to add rq to the post-flush pending list in POSTFLUSH. If this is not true, we will have to revert that commit IMHO. This updated version adds "list_del_init(&rq->queuelist)" in flush rq callback since the dm layer may submit request of a weird invalid format (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add if without this "list_del_init(&rq->queuelist)". The weird invalid format problem should be fixed in dm layer.
- https://git.kernel.org/stable/c/87907bd69721a8506618a954d41a1de3040e88aa
- https://git.kernel.org/stable/c/d0321c812d89c5910d8da8e4b10c891c6b96ff70
- https://git.kernel.org/stable/c/fe1e395563ccb051e9dbd8fa99859f5caaad2e71
- https://git.kernel.org/stable/c/87907bd69721a8506618a954d41a1de3040e88aa
- https://git.kernel.org/stable/c/d0321c812d89c5910d8da8e4b10c891c6b96ff70
- https://git.kernel.org/stable/c/fe1e395563ccb051e9dbd8fa99859f5caaad2e71
Modified: 2025-11-03
CVE-2024-40927
In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhci_dbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn't really hint at there being a problem at all). It took me *months* of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn't have been left in at all). > Another fix to solve clearing the caches of all stream rings with > cancelled TDs is needed, but not as urgent. 3 years after that statement and 14 years after the original bug was introduced, I think it's finally time to fix it. And maybe next time let's not leave bugs unfixed (that are actually worse than the original bug), and let's actually get people to review kernel commits please. Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use `hdparm` to mark an early sector (e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn't get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the `cat` in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro'd and tested on an Apple M1 Mac Mini (dwc3 host). On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---
- https://git.kernel.org/stable/c/26460c1afa311524f588e288a4941432f0de6228
- https://git.kernel.org/stable/c/5ceac4402f5d975e5a01c806438eb4e554771577
- https://git.kernel.org/stable/c/61593dc413c3655e4328a351555235bc3089486a
- https://git.kernel.org/stable/c/633f72cb6124ecda97b641fbc119340bd88d51a9
- https://git.kernel.org/stable/c/949be4ec5835e0ccb3e2a8ab0e46179cb5512518
- https://git.kernel.org/stable/c/26460c1afa311524f588e288a4941432f0de6228
- https://git.kernel.org/stable/c/5ceac4402f5d975e5a01c806438eb4e554771577
- https://git.kernel.org/stable/c/61593dc413c3655e4328a351555235bc3089486a
- https://git.kernel.org/stable/c/633f72cb6124ecda97b641fbc119340bd88d51a9
- https://git.kernel.org/stable/c/949be4ec5835e0ccb3e2a8ab0e46179cb5512518
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-01-19
CVE-2024-40928
In the Linux kernel, the following vulnerability has been resolved: net: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool() Clang static checker (scan-build) warning: net/ethtool/ioctl.c:line 2233, column 2 Called function pointer is null (null dereference). Return '-EOPNOTSUPP' when 'ops->get_ethtool_phy_stats' is NULL to fix this typo error.
- https://git.kernel.org/stable/c/0dcc53abf58d572d34c5313de85f607cd33fc691
- https://git.kernel.org/stable/c/25504f7fe60058b2a9553a9e424fb7dd9683843e
- https://git.kernel.org/stable/c/6548d543a27449a1a3d8079925de93f5764d6f22
- https://git.kernel.org/stable/c/92196be82a4eb61813833dc62876fd198ae51ab1
- https://git.kernel.org/stable/c/c3ba0557ab2ef15a3663e2fb9b1a3d628a8c3daa
- https://git.kernel.org/stable/c/f9e57e7ca77393b5b7072800370370b02eaad0f8
- https://git.kernel.org/stable/c/0dcc53abf58d572d34c5313de85f607cd33fc691
- https://git.kernel.org/stable/c/6548d543a27449a1a3d8079925de93f5764d6f22
- https://git.kernel.org/stable/c/92196be82a4eb61813833dc62876fd198ae51ab1
Modified: 2025-11-03
CVE-2024-40929
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: check n_ssids before accessing the ssids In some versions of cfg80211, the ssids poinet might be a valid one even though n_ssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking n_ssids first.
- https://git.kernel.org/stable/c/29a18d56bd64b95bd10bda4afda512558471382a
- https://git.kernel.org/stable/c/3c4771091ea8016c8601399078916f722dd8833b
- https://git.kernel.org/stable/c/60d62757df30b74bf397a2847a6db7385c6ee281
- https://git.kernel.org/stable/c/62e007bdeb91c6879a4652c3426aef1cd9d2937b
- https://git.kernel.org/stable/c/9e719ae3abad60e245ce248ba3f08148f375a614
- https://git.kernel.org/stable/c/f777792952d03bbaf8329fdfa99393a5a33e2640
- https://git.kernel.org/stable/c/29a18d56bd64b95bd10bda4afda512558471382a
- https://git.kernel.org/stable/c/3c4771091ea8016c8601399078916f722dd8833b
- https://git.kernel.org/stable/c/60d62757df30b74bf397a2847a6db7385c6ee281
- https://git.kernel.org/stable/c/62e007bdeb91c6879a4652c3426aef1cd9d2937b
- https://git.kernel.org/stable/c/9e719ae3abad60e245ce248ba3f08148f375a614
- https://git.kernel.org/stable/c/f777792952d03bbaf8329fdfa99393a5a33e2640
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40931
In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_una is properly initialized on connect This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq.
- https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde
- https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726
- https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3
- https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce
- https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813
- https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f
- https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde
- https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726
- https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3
- https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce
- https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813
- https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40932
In the Linux kernel, the following vulnerability has been resolved: drm/exynos/vidi: fix memory leak in .get_modes() The duplicated EDID is never freed. Fix it.
- https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003
- https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d737eb054e
- https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819
- https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226
- https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224
- https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d
- https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1
- https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8
- https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003
- https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d737eb054e
- https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819
- https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226
- https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224
- https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d
- https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1
- https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40934
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() Fix a memory leak on logi_dj_recv_send_report() error path.
- https://git.kernel.org/stable/c/15122dc140d82c51c216535c57b044c4587aae45
- https://git.kernel.org/stable/c/1df2ead5dfad5f8f92467bd94889392d53100b98
- https://git.kernel.org/stable/c/789c99a1d7d2c8f6096d75fc2930505840ec9ea0
- https://git.kernel.org/stable/c/a0503757947f2e46e59c1962326b53b3208c8213
- https://git.kernel.org/stable/c/caa9c9acb93db7ad7b74b157cf101579bac9596d
- https://git.kernel.org/stable/c/ce3af2ee95170b7d9e15fff6e500d67deab1e7b3
- https://git.kernel.org/stable/c/f677ca8cfefee2a729ca315f660cd4868abdf8de
- https://git.kernel.org/stable/c/15122dc140d82c51c216535c57b044c4587aae45
- https://git.kernel.org/stable/c/1df2ead5dfad5f8f92467bd94889392d53100b98
- https://git.kernel.org/stable/c/789c99a1d7d2c8f6096d75fc2930505840ec9ea0
- https://git.kernel.org/stable/c/a0503757947f2e46e59c1962326b53b3208c8213
- https://git.kernel.org/stable/c/caa9c9acb93db7ad7b74b157cf101579bac9596d
- https://git.kernel.org/stable/c/ce3af2ee95170b7d9e15fff6e500d67deab1e7b3
- https://git.kernel.org/stable/c/f677ca8cfefee2a729ca315f660cd4868abdf8de
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40935
In the Linux kernel, the following vulnerability has been resolved: cachefiles: flush all requests after setting CACHEFILES_DEAD In ondemand mode, when the daemon is processing an open request, if the kernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write() will always return -EIO, so the daemon can't pass the copen to the kernel. Then the kernel process that is waiting for the copen triggers a hung_task. Since the DEAD state is irreversible, it can only be exited by closing /dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark the cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to avoid the above hungtask. We may still be able to read some of the cached data before closing the fd of /dev/cachefiles. Note that this relies on the patch that adds reference counting to the req, otherwise it may UAF.
- https://git.kernel.org/stable/c/320ba9cbca78be79c912143bbba1d1b35ca55cf0
- https://git.kernel.org/stable/c/3bf0b8030296e9ee60d3d4c15849ad9ac0b47081
- https://git.kernel.org/stable/c/85e833cd7243bda7285492b0653c3abb1e2e757b
- https://git.kernel.org/stable/c/e73fac95084839c5178d97e81c6a2051251bdc00
- https://git.kernel.org/stable/c/320ba9cbca78be79c912143bbba1d1b35ca55cf0
- https://git.kernel.org/stable/c/3bf0b8030296e9ee60d3d4c15849ad9ac0b47081
- https://git.kernel.org/stable/c/85e833cd7243bda7285492b0653c3abb1e2e757b
- https://git.kernel.org/stable/c/e73fac95084839c5178d97e81c6a2051251bdc00
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-02-03
CVE-2024-40936
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix memregion leaks in devm_cxl_add_region() Move the mode verification to __create_region() before allocating the memregion to avoid the memregion leaks.
- https://git.kernel.org/stable/c/49ba7b515c4c0719b866d16f068e62d16a8a3dd1
- https://git.kernel.org/stable/c/bbb5d8746381c82f7e0fb6171094d375b492f266
- https://git.kernel.org/stable/c/d8316838aa0686da63a8be4194b7a17b0103ae4a
- https://git.kernel.org/stable/c/49ba7b515c4c0719b866d16f068e62d16a8a3dd1
- https://git.kernel.org/stable/c/bbb5d8746381c82f7e0fb6171094d375b492f266
- https://git.kernel.org/stable/c/d8316838aa0686da63a8be4194b7a17b0103ae4a
Modified: 2025-11-03
CVE-2024-40937
In the Linux kernel, the following vulnerability has been resolved: gve: Clear napi->skb before dev_kfree_skb_any() gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it is freed with dev_kfree_skb_any(). This can result in a subsequent call to napi_get_frags returning a dangling pointer. Fix this by clearing napi->skb before the skb is freed.
- https://git.kernel.org/stable/c/2ce5341c36993b776012601921d7688693f8c037
- https://git.kernel.org/stable/c/6f4d93b78ade0a4c2cafd587f7b429ce95abb02e
- https://git.kernel.org/stable/c/75afd8724739ee5ed8165acde5f6ac3988b485cc
- https://git.kernel.org/stable/c/a68184d5b420ea4fc7e6b7ceb52bbc66f90d3c50
- https://git.kernel.org/stable/c/d221284991118c0ab16480b53baecd857c0bc442
- https://git.kernel.org/stable/c/2ce5341c36993b776012601921d7688693f8c037
- https://git.kernel.org/stable/c/6f4d93b78ade0a4c2cafd587f7b429ce95abb02e
- https://git.kernel.org/stable/c/75afd8724739ee5ed8165acde5f6ac3988b485cc
- https://git.kernel.org/stable/c/a68184d5b420ea4fc7e6b7ceb52bbc66f90d3c50
- https://git.kernel.org/stable/c/d221284991118c0ab16480b53baecd857c0bc442
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40938
In the Linux kernel, the following vulnerability has been resolved: landlock: Fix d_parent walk The WARN_ON_ONCE() in collect_domain_accesses() can be triggered when trying to link a root mount point. This cannot work in practice because this directory is mounted, but the VFS check is done after the call to security_path_link(). Do not use source directory's d_parent when the source directory is the mount point. [mic: Fix commit message]
- https://git.kernel.org/stable/c/88da52ccd66e65f2e63a6c35c9dff55d448ef4dc
- https://git.kernel.org/stable/c/b6e5e696435832b33e40775f060ef5c95f4fda1f
- https://git.kernel.org/stable/c/c7618c7b0b8c45bcef34410cc1d1e953eb17f8f6
- https://git.kernel.org/stable/c/cc30d05b34f9a087a6928d09b131f7b491e9ab11
- https://git.kernel.org/stable/c/88da52ccd66e65f2e63a6c35c9dff55d448ef4dc
- https://git.kernel.org/stable/c/b6e5e696435832b33e40775f060ef5c95f4fda1f
- https://git.kernel.org/stable/c/c7618c7b0b8c45bcef34410cc1d1e953eb17f8f6
- https://git.kernel.org/stable/c/cc30d05b34f9a087a6928d09b131f7b491e9ab11
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40939
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: Fix tainted pointer delete is case of region creation fail In case of region creation fail in ipc_devlink_create_region(), previously created regions delete process starts from tainted pointer which actually holds error code value. Fix this bug by decreasing region index before delete. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/040d9384870386eb5dc55472ac573ac7756b2050
- https://git.kernel.org/stable/c/37a438704d19bdbe246d51d3749b6b3a8fe65afd
- https://git.kernel.org/stable/c/b0c9a26435413b81799047a7be53255640432547
- https://git.kernel.org/stable/c/fe394d59cdae81389dbf995e87c83c1acd120597
- https://git.kernel.org/stable/c/040d9384870386eb5dc55472ac573ac7756b2050
- https://git.kernel.org/stable/c/37a438704d19bdbe246d51d3749b6b3a8fe65afd
- https://git.kernel.org/stable/c/b0c9a26435413b81799047a7be53255640432547
- https://git.kernel.org/stable/c/fe394d59cdae81389dbf995e87c83c1acd120597
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40940
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix tainted pointer delete is case of flow rules creation fail In case of flow rule creation fail in mlx5_lag_create_port_sel_table(), instead of previously created rules, the tainted pointer is deleted deveral times. Fix this bug by using correct flow rules pointers. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/229bedbf62b13af5aba6525ad10b62ad38d9ccb5
- https://git.kernel.org/stable/c/531eab2da27dd42d68dfb841d82e987f4a6738b8
- https://git.kernel.org/stable/c/a03a3fa12769e25f4385bee587afe1445aee7f7a
- https://git.kernel.org/stable/c/d857df86837ac1c30592e8a068204d16feac9930
- https://git.kernel.org/stable/c/229bedbf62b13af5aba6525ad10b62ad38d9ccb5
- https://git.kernel.org/stable/c/531eab2da27dd42d68dfb841d82e987f4a6738b8
- https://git.kernel.org/stable/c/a03a3fa12769e25f4385bee587afe1445aee7f7a
- https://git.kernel.org/stable/c/d857df86837ac1c30592e8a068204d16feac9930
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40941
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't read past the mfuart notifcation In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing. This was reported by KFENCE.
- https://git.kernel.org/stable/c/15b37c6fab9d5e40ac399fa1c725118588ed649c
- https://git.kernel.org/stable/c/46c59a25337049a2a230ce7f7c3b9f21d0aaaad7
- https://git.kernel.org/stable/c/4bb95f4535489ed830cf9b34b0a891e384d1aee4
- https://git.kernel.org/stable/c/6532f18e66b384b8d4b7e5c9caca042faaa9e8de
- https://git.kernel.org/stable/c/65686118845d427df27ee83a6ddd4885596b0805
- https://git.kernel.org/stable/c/a05018739a5e6b9dc112c95bd4c59904062c8940
- https://git.kernel.org/stable/c/a8bc8276af9aeacabb773f0c267cfcdb847c6f2d
- https://git.kernel.org/stable/c/acdfa33c3cf5e1cd185cc1e0486bd0ea9f09c154
- https://git.kernel.org/stable/c/15b37c6fab9d5e40ac399fa1c725118588ed649c
- https://git.kernel.org/stable/c/46c59a25337049a2a230ce7f7c3b9f21d0aaaad7
- https://git.kernel.org/stable/c/4bb95f4535489ed830cf9b34b0a891e384d1aee4
- https://git.kernel.org/stable/c/6532f18e66b384b8d4b7e5c9caca042faaa9e8de
- https://git.kernel.org/stable/c/65686118845d427df27ee83a6ddd4885596b0805
- https://git.kernel.org/stable/c/a05018739a5e6b9dc112c95bd4c59904062c8940
- https://git.kernel.org/stable/c/a8bc8276af9aeacabb773f0c267cfcdb847c6f2d
- https://git.kernel.org/stable/c/acdfa33c3cf5e1cd185cc1e0486bd0ea9f09c154
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40942
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending(). This should take care of KASAN reports like this: unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20
- https://git.kernel.org/stable/c/377dbb220edc8421b7960691876c5b3bef62f89b
- https://git.kernel.org/stable/c/617dadbfb2d3e152c5753e28356d189c9d6f33c0
- https://git.kernel.org/stable/c/63d5f89bb5664d60edbf8cf0df911aaae8ed96a4
- https://git.kernel.org/stable/c/7518e20a189f8659b8b83969db4d33a4068fcfc3
- https://git.kernel.org/stable/c/b7d7f11a291830fdf69d3301075dd0fb347ced84
- https://git.kernel.org/stable/c/c4c865f971fd4a255208f57ef04d814c2ae9e0dc
- https://git.kernel.org/stable/c/d81e244af521de63ad2883e17571b789c39b6549
- https://git.kernel.org/stable/c/ec79670eae430b3ffb7e0a6417ad7657728b8f95
- https://git.kernel.org/stable/c/377dbb220edc8421b7960691876c5b3bef62f89b
- https://git.kernel.org/stable/c/617dadbfb2d3e152c5753e28356d189c9d6f33c0
- https://git.kernel.org/stable/c/63d5f89bb5664d60edbf8cf0df911aaae8ed96a4
- https://git.kernel.org/stable/c/7518e20a189f8659b8b83969db4d33a4068fcfc3
- https://git.kernel.org/stable/c/b7d7f11a291830fdf69d3301075dd0fb347ced84
- https://git.kernel.org/stable/c/c4c865f971fd4a255208f57ef04d814c2ae9e0dc
- https://git.kernel.org/stable/c/d81e244af521de63ad2883e17571b789c39b6549
- https://git.kernel.org/stable/c/ec79670eae430b3ffb7e0a6417ad7657728b8f95
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40943
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix races between hole punching and AIO+DIO After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed: ======================================================================== [ 473.293420 ] run fstests generic/300 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 ========================================================================= In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos. T1 T2 T3 inode lock ... insert extents ... inode unlock ocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_sem In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4.
- https://git.kernel.org/stable/c/050ce8af6838c71e872e982b50d3f1bec21da40e
- https://git.kernel.org/stable/c/117b9c009b72a6c2ebfd23484354dfee2d9570d2
- https://git.kernel.org/stable/c/38825ff9da91d2854dcf6d9ac320a7e641e10f25
- https://git.kernel.org/stable/c/3c26b5d21b1239e9c7fd31ba7d9b2d7bdbaa68d9
- https://git.kernel.org/stable/c/3c361f313d696df72f9bccf058510e9ec737b9b1
- https://git.kernel.org/stable/c/952b023f06a24b2ad6ba67304c4c84d45bea2f18
- https://git.kernel.org/stable/c/e8e2db1adac47970a6a9225f3858e9aa0e86287f
- https://git.kernel.org/stable/c/ea042dc2bea19d72e37c298bf65a9c341ef3fff3
- https://git.kernel.org/stable/c/050ce8af6838c71e872e982b50d3f1bec21da40e
- https://git.kernel.org/stable/c/117b9c009b72a6c2ebfd23484354dfee2d9570d2
- https://git.kernel.org/stable/c/38825ff9da91d2854dcf6d9ac320a7e641e10f25
- https://git.kernel.org/stable/c/3c26b5d21b1239e9c7fd31ba7d9b2d7bdbaa68d9
- https://git.kernel.org/stable/c/3c361f313d696df72f9bccf058510e9ec737b9b1
- https://git.kernel.org/stable/c/952b023f06a24b2ad6ba67304c4c84d45bea2f18
- https://git.kernel.org/stable/c/e8e2db1adac47970a6a9225f3858e9aa0e86287f
- https://git.kernel.org/stable/c/ea042dc2bea19d72e37c298bf65a9c341ef3fff3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-06
CVE-2024-40944
In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Fix bug with call depth tracking The call to cc_platform_has() triggers a fault and system crash if call depth tracking is active because the GS segment has been reset by load_segments() and GS_BASE is now 0 but call depth tracking uses per-CPU variables to operate. Call cc_platform_has() earlier in the function when GS is still valid. [ bp: Massage. ]
- https://git.kernel.org/stable/c/2cfb464669b645a9b98478b74f2bcea9860dcff1
- https://git.kernel.org/stable/c/93c1800b3799f17375989b0daf76497dd3e80922
- https://git.kernel.org/stable/c/d91ddd05082691e69b30744825d18ae799293258
- https://git.kernel.org/stable/c/2cfb464669b645a9b98478b74f2bcea9860dcff1
- https://git.kernel.org/stable/c/93c1800b3799f17375989b0daf76497dd3e80922
- https://git.kernel.org/stable/c/d91ddd05082691e69b30744825d18ae799293258
Modified: 2025-11-03
CVE-2024-40945
In the Linux kernel, the following vulnerability has been resolved: iommu: Return right value in iommu_sva_bind_device() iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all.
- https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b5547406998
- https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e
- https://git.kernel.org/stable/c/6325eab6c108fed27f60ff51852e3eac0ba23f3f
- https://git.kernel.org/stable/c/700f564758882db7c039dfba9443fe762561a3f8
- https://git.kernel.org/stable/c/7388ae6f26c0ba95f70cc96bf9c5d5cb06c908b6
- https://git.kernel.org/stable/c/89e8a2366e3bce584b6c01549d5019c5cda1205e
- https://git.kernel.org/stable/c/cf34f8f66982a36e5cba0d05781b21ec9606b91e
- https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b5547406998
- https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e
- https://git.kernel.org/stable/c/700f564758882db7c039dfba9443fe762561a3f8
- https://git.kernel.org/stable/c/7388ae6f26c0ba95f70cc96bf9c5d5cb06c908b6
- https://git.kernel.org/stable/c/89e8a2366e3bce584b6c01549d5019c5cda1205e
- https://git.kernel.org/stable/c/cf34f8f66982a36e5cba0d05781b21ec9606b91e
- https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html
Modified: 2025-11-03
CVE-2024-40947
In the Linux kernel, the following vulnerability has been resolved: ima: Avoid blocking in RCU read-side critical section A panic happens in ima_match_policy: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 42f873067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ima_match_policy+0x84/0x450 Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ima_get_action+0x22/0x30 process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170 ? alloc_set_pte+0x269/0x4c0 ? prep_new_page+0x81/0x140 ? simple_xattr_get+0x75/0xa0 ? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0 ? files_cgroup_alloc_fd+0x38/0x60 ? __alloc_fd+0xd4/0x250 ? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 entry_SYSCALL_64_after_hwframe+0x65/0xca Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a RCU read-side critical section which contains kmalloc with GFP_KERNEL. This implies a possible sleep and violates limitations of RCU read-side critical sections on non-PREEMPT systems. Sleeping within RCU read-side critical section might cause synchronize_rcu() returning early and break RCU protection, allowing a UAF to happen. The root cause of this issue could be described as follows: | Thread A | Thread B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | synchronize_rcu | | | | kmalloc(GFP_KERNEL)| | | sleep | ==> synchronize_rcu returns early | kfree(entry) | | | | entry = entry->next| ==> UAF happens and entry now becomes NULL (or could be anything). | | entry->action | ==> Accessing entry might cause panic. To fix this issue, we are converting all kmalloc that is called within RCU read-side critical section to use GFP_ATOMIC. [PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]
- https://git.kernel.org/stable/c/28d0ecc52f6c927d0e9ba70a4f2c1ea15453ee88
- https://git.kernel.org/stable/c/58275455893066149e9f4df2223ab2fdbdc59f9c
- https://git.kernel.org/stable/c/9a95c5bfbf02a0a7f5983280fe284a0ff0836c34
- https://git.kernel.org/stable/c/9c3906c3738562b1fedc6f1cfc81756a7cfefff0
- https://git.kernel.org/stable/c/a38e02265c681b51997a264aaf743095e2ee400a
- https://git.kernel.org/stable/c/a6176a802c4bfb83bf7524591aa75f44a639a853
- https://git.kernel.org/stable/c/28d0ecc52f6c927d0e9ba70a4f2c1ea15453ee88
- https://git.kernel.org/stable/c/58275455893066149e9f4df2223ab2fdbdc59f9c
- https://git.kernel.org/stable/c/9a95c5bfbf02a0a7f5983280fe284a0ff0836c34
- https://git.kernel.org/stable/c/9c3906c3738562b1fedc6f1cfc81756a7cfefff0
- https://git.kernel.org/stable/c/a38e02265c681b51997a264aaf743095e2ee400a
- https://git.kernel.org/stable/c/a6176a802c4bfb83bf7524591aa75f44a639a853
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40948
In the Linux kernel, the following vulnerability has been resolved: mm/page_table_check: fix crash on ZONE_DEVICE Not all pages may apply to pgtable check. One example is ZONE_DEVICE pages: they map PFNs directly, and they don't allocate page_ext at all even if there's struct page around. One may reference devm_memremap_pages(). When both ZONE_DEVICE and page-table-check enabled, then try to map some dax memories, one can trigger kernel bug constantly now when the kernel was trying to inject some pfn maps on the dax device: kernel BUG at mm/page_table_check.c:55! While it's pretty legal to use set_pxx_at() for ZONE_DEVICE pages for page fault resolutions, skip all the checks if page_ext doesn't even exist in pgtable checker, which applies to ZONE_DEVICE but maybe more.
- https://git.kernel.org/stable/c/51897f99351fff7b57f4f141940fa93b4e90fd2b
- https://git.kernel.org/stable/c/84d3549d54f5ff9fa3281257be3019386f51d1a0
- https://git.kernel.org/stable/c/8bb592c2eca8fd2bc06db7d80b38da18da4a2f43
- https://git.kernel.org/stable/c/dec2382247860d2134c8d41e103e26460c099629
- https://git.kernel.org/stable/c/51897f99351fff7b57f4f141940fa93b4e90fd2b
- https://git.kernel.org/stable/c/84d3549d54f5ff9fa3281257be3019386f51d1a0
- https://git.kernel.org/stable/c/8bb592c2eca8fd2bc06db7d80b38da18da4a2f43
- https://git.kernel.org/stable/c/dec2382247860d2134c8d41e103e26460c099629
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-04-16
CVE-2024-40951
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger() bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. Since ocfs2 hasn't set bh->b_assoc_map, it will trigger NULL pointer dereference when calling into ocfs2_abort_trigger(). Actually this was pointed out in history, see commit 74e364ad1b13. But I've made a mistake when reviewing commit 8887b94d9322 and then re-introduce this regression. Since we cannot revive bdev in buffer head, so fix this issue by initializing all types of ocfs2 triggers when fill super, and then get the specific ocfs2 trigger from ocfs2_caching_info when access journal. [joseph.qi@linux.alibaba.com: v2]
- https://git.kernel.org/stable/c/67bcecd780609f471260a8c83fb0ae15f27734ce
- https://git.kernel.org/stable/c/685d03c3795378fca6a1b3d43581f7f1a3fc095f
- https://git.kernel.org/stable/c/eb63357ef229fae061ce7ce2839d558681c42f1a
- https://git.kernel.org/stable/c/67bcecd780609f471260a8c83fb0ae15f27734ce
- https://git.kernel.org/stable/c/685d03c3795378fca6a1b3d43581f7f1a3fc095f
- https://git.kernel.org/stable/c/eb63357ef229fae061ce7ce2839d558681c42f1a
Modified: 2024-11-21
CVE-2024-40952
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()
bdev->bd_super has been removed and commit 8887b94d9322 change the usage
from bdev->bd_super to b_assoc_map->host->i_sb. This introduces the
following NULL pointer dereference in ocfs2_journal_dirty() since
b_assoc_map is still not initialized. This can be easily reproduced by
running xfstests generic/186, which simulate no more credits.
[ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000
...
[ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2]
...
[ 134.365071] Call Trace:
[ 134.365312]
- https://git.kernel.org/stable/c/0550ad87711f815b3d73e487ec58ca7d8f56edbc
- https://git.kernel.org/stable/c/58f7e1e2c9e72c7974054c64c3abeac81c11f822
- https://git.kernel.org/stable/c/72663d3e09091f431a0774227ca207c0358362dd
- https://git.kernel.org/stable/c/0550ad87711f815b3d73e487ec58ca7d8f56edbc
- https://git.kernel.org/stable/c/58f7e1e2c9e72c7974054c64c3abeac81c11f822
- https://git.kernel.org/stable/c/72663d3e09091f431a0774227ca207c0358362dd
Modified: 2025-11-03
CVE-2024-40953
In the Linux kernel, the following vulnerability has been resolved: KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000
- https://git.kernel.org/stable/c/11a772d5376aa6d3e2e69b5b5c585f79b60c0e17
- https://git.kernel.org/stable/c/49f683b41f28918df3e51ddc0d928cb2e934ccdb
- https://git.kernel.org/stable/c/4c141136a28421b78f34969b25a4fa32e06e2180
- https://git.kernel.org/stable/c/71fbc3af3dacb26c3aa2f30bb3ab05c44d082c84
- https://git.kernel.org/stable/c/82bd728a06e55f5b5f93d10ce67f4fe7e689853a
- https://git.kernel.org/stable/c/92c77807d938145c7c3350c944ef9f39d7f6017c
- https://git.kernel.org/stable/c/95c8dd79f3a14df96b3820b35b8399bd91b2be60
- https://git.kernel.org/stable/c/a937ef951bba72f48d2402451419d725d70dba20
- https://git.kernel.org/stable/c/49f683b41f28918df3e51ddc0d928cb2e934ccdb
- https://git.kernel.org/stable/c/92c77807d938145c7c3350c944ef9f39d7f6017c
- https://git.kernel.org/stable/c/95c8dd79f3a14df96b3820b35b8399bd91b2be60
- https://git.kernel.org/stable/c/a937ef951bba72f48d2402451419d725d70dba20
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-40954
In the Linux kernel, the following vulnerability has been resolved:
net: do not leave a dangling sk pointer, when socket creation fails
It is possible to trigger a use-after-free by:
* attaching an fentry probe to __sock_release() and the probe calling the
bpf_get_socket_cookie() helper
* running traceroute -I 1.1.1.1 on a freshly booted VM
A KASAN enabled kernel will log something like below (decoded and stripped):
==================================================================
BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
Read of size 8 at addr ffff888007110dd8 by task traceroute/299
CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5
- https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9
- https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2
- https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069
- https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e
- https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5
- https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9
- https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2
- https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069
- https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-40955
In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists() We can trigger a slab-out-of-bounds with the following commands: mkfs.ext4 -F /dev/$disk 10G mount /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ================================================================== BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 Call Trace: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] ext4_mb_new_blocks+0x88a/0x1370 [ext4] ext4_ext_map_blocks+0x14f7/0x2390 [ext4] ext4_map_blocks+0x569/0xea0 [ext4] ext4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ================================================================== The flow of issue triggering is as follows: // Set s_mb_group_prealloc to 2147483647 via sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose_next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order order = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi->s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // Trigger SOOB! At 4k block size, the length of the s_mb_avg_fragment_size list is 14, but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds to be triggered by an attempt to access an element at index 29. Add a new attr_id attr_clusters_in_group with values in the range [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as that type to fix the issue. In addition avoid returning an order from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) and reduce some useless loops.
- https://git.kernel.org/stable/c/13df4d44a3aaabe61cd01d277b6ee23ead2a5206
- https://git.kernel.org/stable/c/677ff4589f1501578fa903a25bb14831d0607992
- https://git.kernel.org/stable/c/b829687ae1229224262bcabf49accfa2dbf8db06
- https://git.kernel.org/stable/c/13df4d44a3aaabe61cd01d277b6ee23ead2a5206
- https://git.kernel.org/stable/c/677ff4589f1501578fa903a25bb14831d0607992
- https://git.kernel.org/stable/c/b829687ae1229224262bcabf49accfa2dbf8db06
Modified: 2025-11-03
CVE-2024-40956
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list Use list_for_each_entry_safe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxd_desc_complete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list.
- https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33
- https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5
- https://git.kernel.org/stable/c/a14968921486793f2a956086895c3793761309dd
- https://git.kernel.org/stable/c/e3215deca4520773cd2b155bed164c12365149a7
- https://git.kernel.org/stable/c/faa35db78b058a2ab6e074ee283f69fa398c36a8
- https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33
- https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5
- https://git.kernel.org/stable/c/a14968921486793f2a956086895c3793761309dd
- https://git.kernel.org/stable/c/e3215deca4520773cd2b155bed164c12365149a7
- https://git.kernel.org/stable/c/faa35db78b058a2ab6e074ee283f69fa398c36a8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40957
In the Linux kernel, the following vulnerability has been resolved:
seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors
input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for
PREROUTING hook, in PREROUTING hook, we should passing a valid indev,
and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer
dereference, as below:
[74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090
[74830.655633] #PF: supervisor read access in kernel mode
[74830.657888] #PF: error_code(0x0000) - not-present page
[74830.659500] PGD 0 P4D 0
[74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI
...
[74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]
...
[74830.689725] Call Trace:
[74830.690402]
- https://git.kernel.org/stable/c/561475d53aa7e4511ee7cdba8728ded81cf1db1c
- https://git.kernel.org/stable/c/9a3bc8d16e0aacd65c31aaf23a2bced3288a7779
- https://git.kernel.org/stable/c/af90e3d73dc45778767b2fb6e7edd57ebe34380d
- https://git.kernel.org/stable/c/d62df86c172033679d744f07d89e93e367dd11f6
- https://git.kernel.org/stable/c/ec4d970b597ee5e17b0d8d73b7875197ce9a04d4
- https://git.kernel.org/stable/c/561475d53aa7e4511ee7cdba8728ded81cf1db1c
- https://git.kernel.org/stable/c/9a3bc8d16e0aacd65c31aaf23a2bced3288a7779
- https://git.kernel.org/stable/c/af90e3d73dc45778767b2fb6e7edd57ebe34380d
- https://git.kernel.org/stable/c/d62df86c172033679d744f07d89e93e367dd11f6
- https://git.kernel.org/stable/c/ec4d970b597ee5e17b0d8d73b7875197ce9a04d4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40958
In the Linux kernel, the following vulnerability has been resolved:
netns: Make get_net_ns() handle zero refcount net
Syzkaller hit a warning:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0
Modules linked in:
CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0xdf/0x1d0
Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1
RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac
RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001
RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139
R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4
R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040
FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1b631bffcb2c09551888f3c723f4365c91fe05ef
- https://git.kernel.org/stable/c/2b82028a1f5ee3a8e04090776b10c534144ae77b
- https://git.kernel.org/stable/c/3a6cd326ead7c8bb1f64486789a01974a9f1ad55
- https://git.kernel.org/stable/c/3af28df0d883e8c89a29ac31bc65f9023485743b
- https://git.kernel.org/stable/c/cb7f811f638a14590ff98f53c6dd1fb54627d940
- https://git.kernel.org/stable/c/ef0394ca25953ea0eddcc82feae1f750451f1876
- https://git.kernel.org/stable/c/ff960f9d3edbe08a736b5a224d91a305ccc946b0
- https://git.kernel.org/stable/c/1b631bffcb2c09551888f3c723f4365c91fe05ef
- https://git.kernel.org/stable/c/2b82028a1f5ee3a8e04090776b10c534144ae77b
- https://git.kernel.org/stable/c/3a6cd326ead7c8bb1f64486789a01974a9f1ad55
- https://git.kernel.org/stable/c/3af28df0d883e8c89a29ac31bc65f9023485743b
- https://git.kernel.org/stable/c/cb7f811f638a14590ff98f53c6dd1fb54627d940
- https://git.kernel.org/stable/c/ef0394ca25953ea0eddcc82feae1f750451f1876
- https://git.kernel.org/stable/c/ff960f9d3edbe08a736b5a224d91a305ccc946b0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40959
In the Linux kernel, the following vulnerability has been resolved:
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
syzbot reported:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
RSP: 0018:ffffc90000117378 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1
- https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333adeaacf
- https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a
- https://git.kernel.org/stable/c/9f30f1f1a51d91e19f5a09236bb0b59e6a07ad08
- https://git.kernel.org/stable/c/c71761292d4d002a8eccb57b86792c4e3b3eb3c7
- https://git.kernel.org/stable/c/caf0bec84c62fb1cf6f7c9f0e8c857c87f8adbc3
- https://git.kernel.org/stable/c/d46401052c2d5614da8efea5788532f0401cb164
- https://git.kernel.org/stable/c/f897d7171652fcfc76d042bfec798b010ee89e41
- https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1
- https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333adeaacf
- https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a
- https://git.kernel.org/stable/c/9f30f1f1a51d91e19f5a09236bb0b59e6a07ad08
- https://git.kernel.org/stable/c/c71761292d4d002a8eccb57b86792c4e3b3eb3c7
- https://git.kernel.org/stable/c/caf0bec84c62fb1cf6f7c9f0e8c857c87f8adbc3
- https://git.kernel.org/stable/c/d46401052c2d5614da8efea5788532f0401cb164
- https://git.kernel.org/stable/c/f897d7171652fcfc76d042bfec798b010ee89e41
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40960
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible NULL dereference in rt6_probe()
syzbot caught a NULL dereference in rt6_probe() [1]
Bail out if __in6_dev_get() returns NULL.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1ed9849fdf9a1a617129346b11d2094ca26828dc
- https://git.kernel.org/stable/c/51ee2f7c30790799d0ec30c0ce0c743e58f046f2
- https://git.kernel.org/stable/c/569c9d9ea6648d099187527b93982f406ddcebc0
- https://git.kernel.org/stable/c/6eed6d3cd19ff3cfa83aeceed86da14abaf7417b
- https://git.kernel.org/stable/c/73e7c8ca6ad76f29b2c99c20845a6f3b203ff0c6
- https://git.kernel.org/stable/c/b86762dbe19a62e785c189f313cda5b989931f37
- https://git.kernel.org/stable/c/d66fc4826127c82f99c4033380f8e93833d331c7
- https://git.kernel.org/stable/c/f0cda984e4e634b221dbf9642b8ecc5b4806b41e
- https://git.kernel.org/stable/c/1ed9849fdf9a1a617129346b11d2094ca26828dc
- https://git.kernel.org/stable/c/51ee2f7c30790799d0ec30c0ce0c743e58f046f2
- https://git.kernel.org/stable/c/569c9d9ea6648d099187527b93982f406ddcebc0
- https://git.kernel.org/stable/c/6eed6d3cd19ff3cfa83aeceed86da14abaf7417b
- https://git.kernel.org/stable/c/73e7c8ca6ad76f29b2c99c20845a6f3b203ff0c6
- https://git.kernel.org/stable/c/b86762dbe19a62e785c189f313cda5b989931f37
- https://git.kernel.org/stable/c/d66fc4826127c82f99c4033380f8e93833d331c7
- https://git.kernel.org/stable/c/f0cda984e4e634b221dbf9642b8ecc5b4806b41e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40961
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible NULL deref in fib6_nh_init()
syzbot reminds us that in6_dev_get() can return NULL.
fib6_nh_init()
ip6_validate_gw( &idev )
ip6_route_check_nh( idev )
*idev = in6_dev_get(dev); // can be NULL
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606
Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b
RSP: 0018:ffffc900032775a0 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000
RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8
RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000
R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8
R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000
FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e59a03a6
- https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade
- https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668
- https://git.kernel.org/stable/c/88b9a55e2e35ea846d41f4efdc29d23345bd1aa4
- https://git.kernel.org/stable/c/ae8d3d39efe366c2198f530e01e4bf07830bf403
- https://git.kernel.org/stable/c/b6947723c9eabcab58cfb33cdb0a565a6aee6727
- https://git.kernel.org/stable/c/de5ad4d45cd0128a2a37555f48ab69aa19d78adc
- https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e59a03a6
- https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade
- https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668
- https://git.kernel.org/stable/c/88b9a55e2e35ea846d41f4efdc29d23345bd1aa4
- https://git.kernel.org/stable/c/ae8d3d39efe366c2198f530e01e4bf07830bf403
- https://git.kernel.org/stable/c/b6947723c9eabcab58cfb33cdb0a565a6aee6727
- https://git.kernel.org/stable/c/de5ad4d45cd0128a2a37555f48ab69aa19d78adc
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-01-07
CVE-2024-40962
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: allocate dummy checksums for zoned NODATASUM writes
Shin'ichiro reported that when he's running fstests' test-case
btrfs/167 on emulated zoned devices, he's seeing the following NULL
pointer dereference in 'btrfs_zone_finish_endio()':
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]
CPU: 4 PID: 2332440 Comm: kworker/u80:15 Tainted: G W 6.10.0-rc2-kts+ #4
Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020
Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]
RSP: 0018:ffff88867f107a90 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff893e5534
RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088
RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed1081696028
R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000
R13: 0000000000020000 R14: 0000000000000000 R15: ffff888530ad5210
FS: 0000000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f87223fff38 CR3: 00000007a7c6a002 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/082b3d4e788953a3ff42ecdb70c4210149076285
- https://git.kernel.org/stable/c/25cfe59f4470a051d1b80f51fa0ca3a5048e4a19
- https://git.kernel.org/stable/c/cebae292e0c32a228e8f2219c270a7237be24a6a
- https://git.kernel.org/stable/c/082b3d4e788953a3ff42ecdb70c4210149076285
- https://git.kernel.org/stable/c/25cfe59f4470a051d1b80f51fa0ca3a5048e4a19
- https://git.kernel.org/stable/c/cebae292e0c32a228e8f2219c270a7237be24a6a
Modified: 2025-11-03
CVE-2024-40963
In the Linux kernel, the following vulnerability has been resolved: mips: bmips: BCM6358: make sure CBR is correctly set It was discovered that some device have CBR address set to 0 causing kernel panic when arch_sync_dma_for_cpu_all is called. This was notice in situation where the system is booted from TP1 and BMIPS_GET_CBR() returns 0 instead of a valid address and !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing. The current check whether RAC flush should be disabled or not are not enough hence lets check if CBR is a valid address or not.
- https://git.kernel.org/stable/c/10afe5f7d30f6fe50c2b1177549d0e04921fc373
- https://git.kernel.org/stable/c/2cd4854ef14a487bcfb76c7980675980cad27b52
- https://git.kernel.org/stable/c/36d771ce6028b886e18a4a8956a5d23688e4e13d
- https://git.kernel.org/stable/c/6c0f6ccd939166f56a904c792d7fcadae43b9085
- https://git.kernel.org/stable/c/89167072fd249e5f23ae2f8093f87da5925cef27
- https://git.kernel.org/stable/c/ce5cdd3b05216b704a704f466fb4c2dff3778caf
- https://git.kernel.org/stable/c/da895fd6da438af8d9326b8f02d715a9c76c3b5b
- https://git.kernel.org/stable/c/10afe5f7d30f6fe50c2b1177549d0e04921fc373
- https://git.kernel.org/stable/c/2cd4854ef14a487bcfb76c7980675980cad27b52
- https://git.kernel.org/stable/c/36d771ce6028b886e18a4a8956a5d23688e4e13d
- https://git.kernel.org/stable/c/6c0f6ccd939166f56a904c792d7fcadae43b9085
- https://git.kernel.org/stable/c/89167072fd249e5f23ae2f8093f87da5925cef27
- https://git.kernel.org/stable/c/ce5cdd3b05216b704a704f466fb4c2dff3778caf
- https://git.kernel.org/stable/c/da895fd6da438af8d9326b8f02d715a9c76c3b5b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-40964
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind() The cs35l41_hda_unbind() function clears the hda_component entry matching it's index and then dereferences the codec pointer held in the first element of the hda_component array, this is an issue when the device index was 0. Instead use the codec pointer stashed in the cs35l41_hda structure as it will still be valid.
- https://git.kernel.org/stable/c/19be722369c347f3af1c5848e303980ed040b819
- https://git.kernel.org/stable/c/6386682cdc8b41319c92fbbe421953e33a28840c
- https://git.kernel.org/stable/c/ff27bd8e17884f7cdefecb3f3817caadd6813dc0
- https://git.kernel.org/stable/c/19be722369c347f3af1c5848e303980ed040b819
- https://git.kernel.org/stable/c/6386682cdc8b41319c92fbbe421953e33a28840c
- https://git.kernel.org/stable/c/ff27bd8e17884f7cdefecb3f3817caadd6813dc0
Modified: 2025-11-03
CVE-2024-40966
In the Linux kernel, the following vulnerability has been resolved: tty: add the option to have a tty reject a new ldisc ... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on. This avoids the BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659 when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.
- https://git.kernel.org/stable/c/287b569a5b914903ba7c438a3c0dbc3410ebb409
- https://git.kernel.org/stable/c/3c6332f3bb1578b5b10ac2561247b1d6272ae937
- https://git.kernel.org/stable/c/5920ac19964f9e20181f63b410d9200ddbf8dc86
- https://git.kernel.org/stable/c/6bd23e0c2bb6c65d4f5754d1456bc9a4427fc59b
- https://git.kernel.org/stable/c/287b569a5b914903ba7c438a3c0dbc3410ebb409
- https://git.kernel.org/stable/c/3c6332f3bb1578b5b10ac2561247b1d6272ae937
- https://git.kernel.org/stable/c/5920ac19964f9e20181f63b410d9200ddbf8dc86
- https://git.kernel.org/stable/c/6bd23e0c2bb6c65d4f5754d1456bc9a4427fc59b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40967
In the Linux kernel, the following vulnerability has been resolved: serial: imx: Introduce timeout when waiting on transmitter empty By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue.
- https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701
- https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7
- https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916
- https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44
- https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2
- https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701
- https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7
- https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916
- https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44
- https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40968
In the Linux kernel, the following vulnerability has been resolved: MIPS: Octeon: Add PCIe link status check The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic.
- https://git.kernel.org/stable/c/1c33fd17383f48f679186c54df78542106deeaa0
- https://git.kernel.org/stable/c/25998f5613159fe35920dbd484fcac7ea3ad0799
- https://git.kernel.org/stable/c/29b83a64df3b42c88c0338696feb6fdcd7f1f3b7
- https://git.kernel.org/stable/c/38d647d509543e9434b3cc470b914348be271fe9
- https://git.kernel.org/stable/c/64845ac64819683ad5e51b668b2ed56ee3386aee
- https://git.kernel.org/stable/c/6bff05aaa32c2f7e1f6e68e890876642159db419
- https://git.kernel.org/stable/c/6c1b9fe148a4e03bbfa234267ebb89f35285814a
- https://git.kernel.org/stable/c/d996deb80398a90dd3c03590e68dad543da87d62
- https://git.kernel.org/stable/c/1c33fd17383f48f679186c54df78542106deeaa0
- https://git.kernel.org/stable/c/25998f5613159fe35920dbd484fcac7ea3ad0799
- https://git.kernel.org/stable/c/29b83a64df3b42c88c0338696feb6fdcd7f1f3b7
- https://git.kernel.org/stable/c/38d647d509543e9434b3cc470b914348be271fe9
- https://git.kernel.org/stable/c/64845ac64819683ad5e51b668b2ed56ee3386aee
- https://git.kernel.org/stable/c/6bff05aaa32c2f7e1f6e68e890876642159db419
- https://git.kernel.org/stable/c/6c1b9fe148a4e03bbfa234267ebb89f35285814a
- https://git.kernel.org/stable/c/d996deb80398a90dd3c03590e68dad543da87d62
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-40969
In the Linux kernel, the following vulnerability has been resolved: f2fs: don't set RO when shutting down f2fs Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread);
- https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a
- https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7
- https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563
- https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a
- https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7
- https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563
Modified: 2025-11-03
CVE-2024-40970
In the Linux kernel, the following vulnerability has been resolved: Avoid hw_desc array overrun in dw-axi-dmac I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3 segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put() handles the hw_desc considering the descs_allocated, this scenario would result in a kernel panic (hw_desc array will be overrun). To fix this, the proposal is to add a new member to the axi_dma_desc structure, where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in axi_desc_put() to handle the hw_desc array correctly. Additionally I propose to remove the axi_chan_start_first_queued() call after completing the transfer, since it was identified that unbalance can occur (started descriptors can be interrupted and transfer ignored due to DMA channel not being enabled).
- https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697
- https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5
- https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe
- https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e
- https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66
- https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697
- https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5
- https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe
- https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e
- https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40971
In the Linux kernel, the following vulnerability has been resolved: f2fs: remove clear SB_INLINECRYPT flag in default_options In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again
- https://git.kernel.org/stable/c/38a82c8d00638bb642bef787eb1d5e0e4d3b7d71
- https://git.kernel.org/stable/c/724429db09e21ee153fef35e34342279d33df6ae
- https://git.kernel.org/stable/c/a9cea0489c562c97cd56bb345e78939f9909e7f4
- https://git.kernel.org/stable/c/ac5eecf481c29942eb9a862e758c0c8b68090c33
- https://git.kernel.org/stable/c/ae39c8ec4250d2a35ddaab1c40faacfec306ff66
- https://git.kernel.org/stable/c/eddeb8d941d5be11a9da5637dbe81ac37e8449a2
- https://git.kernel.org/stable/c/38a82c8d00638bb642bef787eb1d5e0e4d3b7d71
- https://git.kernel.org/stable/c/724429db09e21ee153fef35e34342279d33df6ae
- https://git.kernel.org/stable/c/a9cea0489c562c97cd56bb345e78939f9909e7f4
- https://git.kernel.org/stable/c/ac5eecf481c29942eb9a862e758c0c8b68090c33
- https://git.kernel.org/stable/c/ae39c8ec4250d2a35ddaab1c40faacfec306ff66
- https://git.kernel.org/stable/c/eddeb8d941d5be11a9da5637dbe81ac37e8449a2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40972
In the Linux kernel, the following vulnerability has been resolved: ext4: do not create EA inode under buffer lock ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers.
- https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd
- https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b
- https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752
- https://git.kernel.org/stable/c/737fb7853acd5bc8984f6f42e4bfba3334be8ae1
- https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b
- https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40973
In the Linux kernel, the following vulnerability has been resolved: media: mtk-vcodec: potential null pointer deference in SCP The return value of devm_kzalloc() needs to be checked to avoid NULL pointer deference. This is similar to CVE-2022-3113.
- https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b
- https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b
- https://git.kernel.org/stable/c/eeb62bb4ca22db17f7dfe8fb8472e0442df3d92f
- https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354
- https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b
- https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b
- https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2024-40974
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes.
- https://git.kernel.org/stable/c/19c166ee42cf16d8b156a6cb4544122d9a65d3ca
- https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d
- https://git.kernel.org/stable/c/3ad0034910a57aa88ed9976b1431b7b8c84e0048
- https://git.kernel.org/stable/c/8aa11aa001576bf3b00dcb8559564ad7a3113588
- https://git.kernel.org/stable/c/a8c988d752b3d98d5cc1e3929c519a55ef55426c
- https://git.kernel.org/stable/c/aa6107dcc4ce9a3451f2d729204713783b657257
- https://git.kernel.org/stable/c/acf2b80c31c37acab040baa3cf5f19fbd5140b18
- https://git.kernel.org/stable/c/ff2e185cf73df480ec69675936c4ee75a445c3e4
- https://git.kernel.org/stable/c/19c166ee42cf16d8b156a6cb4544122d9a65d3ca
- https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d
- https://git.kernel.org/stable/c/3ad0034910a57aa88ed9976b1431b7b8c84e0048
- https://git.kernel.org/stable/c/8aa11aa001576bf3b00dcb8559564ad7a3113588
- https://git.kernel.org/stable/c/a8c988d752b3d98d5cc1e3929c519a55ef55426c
- https://git.kernel.org/stable/c/aa6107dcc4ce9a3451f2d729204713783b657257
- https://git.kernel.org/stable/c/acf2b80c31c37acab040baa3cf5f19fbd5140b18
- https://git.kernel.org/stable/c/ff2e185cf73df480ec69675936c4ee75a445c3e4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40976
In the Linux kernel, the following vulnerability has been resolved: drm/lima: mask irqs in timeout path before hard reset There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler.
- https://git.kernel.org/stable/c/03e7b2f7ae4c0ae5fb8e4e2454ba4008877f196a
- https://git.kernel.org/stable/c/58bfd311c93d66d8282bf21ebbf35cc3bb8ad9db
- https://git.kernel.org/stable/c/70aa1f2dec46b6fdb5f6b9f37b6bfa4a4dee0d3a
- https://git.kernel.org/stable/c/9fd8ddd23793a50dbcd11c6ba51f437f1ea7d344
- https://git.kernel.org/stable/c/a421cc7a6a001b70415aa4f66024fa6178885a14
- https://git.kernel.org/stable/c/bdbc4ca77f5eaac15de7230814253cddfed273b1
- https://git.kernel.org/stable/c/03e7b2f7ae4c0ae5fb8e4e2454ba4008877f196a
- https://git.kernel.org/stable/c/58bfd311c93d66d8282bf21ebbf35cc3bb8ad9db
- https://git.kernel.org/stable/c/70aa1f2dec46b6fdb5f6b9f37b6bfa4a4dee0d3a
- https://git.kernel.org/stable/c/9fd8ddd23793a50dbcd11c6ba51f437f1ea7d344
- https://git.kernel.org/stable/c/a421cc7a6a001b70415aa4f66024fa6178885a14
- https://git.kernel.org/stable/c/bdbc4ca77f5eaac15de7230814253cddfed273b1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40977
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921s: fix potential hung tasks during chip recovery During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device. This patch prevents the execution of stat_worker during the chip recovery.
- https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08
- https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02
- https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9
- https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366
- https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08
- https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02
- https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9
- https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40978
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedi: Fix crash while reading debugfs attribute
The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
on a __user pointer, which results into the crash.
To fix this issue, use a small local stack buffer for sprintf() and then
call simple_read_from_buffer(), which in turns make the copy_to_user()
call.
BUG: unable to handle page fault for address: 00007f4801111000
PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
Oops: 0002 [#1] PREEMPT SMP PTI
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
RIP: 0010:memcpy_orig+0xcd/0x130
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/144d76a676b630e321556965011b00e2de0b40a7
- https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901
- https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad61e735b5
- https://git.kernel.org/stable/c/397a8990c377ee4b61d6df768e61dff9e316d46b
- https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0
- https://git.kernel.org/stable/c/e2f433ea7d0ff77998766a088a287337fb43ad75
- https://git.kernel.org/stable/c/eaddb86637669f6bad89245ee63f8fb2bfb50241
- https://git.kernel.org/stable/c/fa85b016a56b9775a3fe41e5d26e666945963b46
- https://git.kernel.org/stable/c/144d76a676b630e321556965011b00e2de0b40a7
- https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901
- https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad61e735b5
- https://git.kernel.org/stable/c/397a8990c377ee4b61d6df768e61dff9e316d46b
- https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0
- https://git.kernel.org/stable/c/e2f433ea7d0ff77998766a088a287337fb43ad75
- https://git.kernel.org/stable/c/eaddb86637669f6bad89245ee63f8fb2bfb50241
- https://git.kernel.org/stable/c/fa85b016a56b9775a3fe41e5d26e666945963b46
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40980
In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: replace spin_lock by raw_spin_lock
trace_drop_common() is called with preemption disabled, and it acquires
a spin_lock. This is problematic for RT kernels because spin_locks are
sleeping locks in this configuration, which causes the following splat:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
preempt_count: 1, expected: 0
RCU nest depth: 2, expected: 2
5 locks held by rcuc/47/449:
#0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
#1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
#2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
#3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
#4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
irq event stamp: 139909
hardirqs last enabled at (139908): [
- https://git.kernel.org/stable/c/07ea878684dfb78a9d4f564c39d07e855a9e242e
- https://git.kernel.org/stable/c/594e47957f3fe034645e6885393ce96c12286334
- https://git.kernel.org/stable/c/76ce2f9125244e1708d29c1d3f9d1d50b347bda0
- https://git.kernel.org/stable/c/96941f29ebcc1e9cbf570dc903f30374909562f5
- https://git.kernel.org/stable/c/b3722fb69468693555f531cddda5c30444726dac
- https://git.kernel.org/stable/c/f1e197a665c2148ebc25fe09c53689e60afea195
- https://git.kernel.org/stable/c/f251ccef1d864790e5253386e95544420b7cd8f3
- https://git.kernel.org/stable/c/07ea878684dfb78a9d4f564c39d07e855a9e242e
- https://git.kernel.org/stable/c/594e47957f3fe034645e6885393ce96c12286334
- https://git.kernel.org/stable/c/76ce2f9125244e1708d29c1d3f9d1d50b347bda0
- https://git.kernel.org/stable/c/96941f29ebcc1e9cbf570dc903f30374909562f5
- https://git.kernel.org/stable/c/b3722fb69468693555f531cddda5c30444726dac
- https://git.kernel.org/stable/c/f1e197a665c2148ebc25fe09c53689e60afea195
- https://git.kernel.org/stable/c/f251ccef1d864790e5253386e95544420b7cd8f3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40981
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
Many syzbot reports are pointing to soft lockups in
batadv_purge_orig_ref() [1]
Root cause is unknown, but we can avoid spending too much
time there and perhaps get more interesting reports.
[1]
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
Modules linked in:
irq event stamp: 6182794
hardirqs last enabled at (6182793): [
- https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2
- https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8
- https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0
- https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11
- https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030
- https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07
- https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a
- https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16
- https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2
- https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8
- https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0
- https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11
- https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030
- https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07
- https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a
- https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40983
In the Linux kernel, the following vulnerability has been resolved: tipc: force a dst refcount before doing decryption As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"): "Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers." On TIPC decryption path it has the same problem, and skb_dst_force() should be called before doing decryption to avoid a possible crash. Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0
- https://git.kernel.org/stable/c/2ebe8f840c7450ecbfca9d18ac92e9ce9155e269
- https://git.kernel.org/stable/c/3eb1b39627892c4e26cb0162b75725aa5fcc60c8
- https://git.kernel.org/stable/c/623c90d86a61e3780f682b32928af469c66ec4c2
- https://git.kernel.org/stable/c/6808b41371670c51feea14f63ade211e78100930
- https://git.kernel.org/stable/c/692803b39a36e63ac73208e0a3769ae6a2f9bc76
- https://git.kernel.org/stable/c/b57a4a2dc8746cea58a922ebe31b6aa629d69d93
- https://git.kernel.org/stable/c/2ebe8f840c7450ecbfca9d18ac92e9ce9155e269
- https://git.kernel.org/stable/c/3eb1b39627892c4e26cb0162b75725aa5fcc60c8
- https://git.kernel.org/stable/c/623c90d86a61e3780f682b32928af469c66ec4c2
- https://git.kernel.org/stable/c/6808b41371670c51feea14f63ade211e78100930
- https://git.kernel.org/stable/c/692803b39a36e63ac73208e0a3769ae6a2f9bc76
- https://git.kernel.org/stable/c/b57a4a2dc8746cea58a922ebe31b6aa629d69d93
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40984
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine." Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions.
- https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3
- https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98
- https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d
- https://git.kernel.org/stable/c/a83e1385b780d41307433ddbc86e3c528db031f0
- https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c
- https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f
- https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239
- https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b41d43c04
- https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3
- https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98
- https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d
- https://git.kernel.org/stable/c/a83e1385b780d41307433ddbc86e3c528db031f0
- https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c
- https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f
- https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239
- https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b41d43c04
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40987
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix UBSAN warning in kv_dpm.c Adds bounds check for sumo_vid_mapping_entry.
- https://git.kernel.org/stable/c/1c44f7759a5650acf8f13d3e0a184d09e03be9e4
- https://git.kernel.org/stable/c/4ad7d49059358ceadd352b4e2511425bdb68f400
- https://git.kernel.org/stable/c/4d020c1dbd2b2304f44d003e6de956ae570049dc
- https://git.kernel.org/stable/c/b065d79ed06a0bb4377bc6dcc2ff0cb1f55a798f
- https://git.kernel.org/stable/c/b0d612619ed70cab476c77b19e00d13aa414e14f
- https://git.kernel.org/stable/c/d8a04a6bfa75251ba7bcc3651ed211e82f13f388
- https://git.kernel.org/stable/c/f0d576f840153392d04b2d52cf3adab8f62e8cb6
- https://git.kernel.org/stable/c/fc5cb952e6723c5c55e47b8cf94a891bd4af1a86
- https://git.kernel.org/stable/c/1c44f7759a5650acf8f13d3e0a184d09e03be9e4
- https://git.kernel.org/stable/c/4ad7d49059358ceadd352b4e2511425bdb68f400
- https://git.kernel.org/stable/c/4d020c1dbd2b2304f44d003e6de956ae570049dc
- https://git.kernel.org/stable/c/b065d79ed06a0bb4377bc6dcc2ff0cb1f55a798f
- https://git.kernel.org/stable/c/b0d612619ed70cab476c77b19e00d13aa414e14f
- https://git.kernel.org/stable/c/d8a04a6bfa75251ba7bcc3651ed211e82f13f388
- https://git.kernel.org/stable/c/f0d576f840153392d04b2d52cf3adab8f62e8cb6
- https://git.kernel.org/stable/c/fc5cb952e6723c5c55e47b8cf94a891bd4af1a86
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40988
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix UBSAN warning in kv_dpm.c Adds bounds check for sumo_vid_mapping_entry.
- https://git.kernel.org/stable/c/07e8f15fa16695cf4c90e89854e59af4a760055b
- https://git.kernel.org/stable/c/468a50fd46a09bba7ba18a11054ae64b6479ecdc
- https://git.kernel.org/stable/c/9e57611182a817824a17b1c3dd300ee74a174b42
- https://git.kernel.org/stable/c/a498df5421fd737d11bfd152428ba6b1c8538321
- https://git.kernel.org/stable/c/a8c6df9fe5bc390645d1e96eff14ffe414951aad
- https://git.kernel.org/stable/c/cf1cc8fcfe517e108794fb711f7faabfca0dc855
- https://git.kernel.org/stable/c/f803532bc3825384100dfc58873e035d77248447
- https://git.kernel.org/stable/c/febe794b83693257f21a23d2e03ea695a62449c8
- https://git.kernel.org/stable/c/07e8f15fa16695cf4c90e89854e59af4a760055b
- https://git.kernel.org/stable/c/468a50fd46a09bba7ba18a11054ae64b6479ecdc
- https://git.kernel.org/stable/c/9e57611182a817824a17b1c3dd300ee74a174b42
- https://git.kernel.org/stable/c/a498df5421fd737d11bfd152428ba6b1c8538321
- https://git.kernel.org/stable/c/a8c6df9fe5bc390645d1e96eff14ffe414951aad
- https://git.kernel.org/stable/c/cf1cc8fcfe517e108794fb711f7faabfca0dc855
- https://git.kernel.org/stable/c/f803532bc3825384100dfc58873e035d77248447
- https://git.kernel.org/stable/c/febe794b83693257f21a23d2e03ea695a62449c8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40989
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Disassociate vcpus from redistributor region on teardown When tearing down a redistributor region, make sure we don't have any dangling pointer to that region stored in a vcpu.
- https://git.kernel.org/stable/c/0d92e4a7ffd5c42b9fa864692f82476c0bf8bcc8
- https://git.kernel.org/stable/c/152b4123f21e6aff31cea01158176ad96a999c76
- https://git.kernel.org/stable/c/48bb62859d47c5c4197a8c01128d0fa4f46ee58c
- https://git.kernel.org/stable/c/68df4fc449fcc24347209e500ce26d5816705a77
- https://git.kernel.org/stable/c/0d92e4a7ffd5c42b9fa864692f82476c0bf8bcc8
- https://git.kernel.org/stable/c/152b4123f21e6aff31cea01158176ad96a999c76
- https://git.kernel.org/stable/c/48bb62859d47c5c4197a8c01128d0fa4f46ee58c
- https://git.kernel.org/stable/c/68df4fc449fcc24347209e500ce26d5816705a77
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40990
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Add check for srq max_sge attribute max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it.
- https://git.kernel.org/stable/c/1e692244bf7dd827dd72edc6c4a3b36ae572f03c
- https://git.kernel.org/stable/c/36ab7ada64caf08f10ee5a114d39964d1f91e81d
- https://git.kernel.org/stable/c/4ab99e3613139f026d2d8ba954819e2876120ab3
- https://git.kernel.org/stable/c/7186b81c1f15e39069b1af172c6a951728ed3511
- https://git.kernel.org/stable/c/999586418600b4b3b93c2a0edd3a4ca71ee759bf
- https://git.kernel.org/stable/c/e0deb0e9c967b61420235f7f17a4450b4b4d6ce2
- https://git.kernel.org/stable/c/1e692244bf7dd827dd72edc6c4a3b36ae572f03c
- https://git.kernel.org/stable/c/36ab7ada64caf08f10ee5a114d39964d1f91e81d
- https://git.kernel.org/stable/c/4ab99e3613139f026d2d8ba954819e2876120ab3
- https://git.kernel.org/stable/c/7186b81c1f15e39069b1af172c6a951728ed3511
- https://git.kernel.org/stable/c/999586418600b4b3b93c2a0edd3a4ca71ee759bf
- https://git.kernel.org/stable/c/e0deb0e9c967b61420235f7f17a4450b4b4d6ce2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-07
CVE-2024-40992
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix responder length checking for UD request packets According to the IBA specification: If a UD request packet is detected with an invalid length, the request shall be an invalid request and it shall be silently dropped by the responder. The responder then waits for a new request packet. commit 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length checking") defers responder length check for UD QPs in function `copy_data`. But it introduces a regression issue for UD QPs. When the packet size is too large to fit in the receive buffer. `copy_data` will return error code -EINVAL. Then `send_data_in` will return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into ERROR state.
- https://git.kernel.org/stable/c/163868ec1f6c610d16da9e458fe1dd7d5de97341
- https://git.kernel.org/stable/c/943c94f41dfe36536dc9aaa12c9efdf548ceb996
- https://git.kernel.org/stable/c/f67ac0061c7614c1548963d3ef1ee1606efd8636
- https://git.kernel.org/stable/c/163868ec1f6c610d16da9e458fe1dd7d5de97341
- https://git.kernel.org/stable/c/943c94f41dfe36536dc9aaa12c9efdf548ceb996
- https://git.kernel.org/stable/c/f67ac0061c7614c1548963d3ef1ee1606efd8636
Modified: 2025-11-03
CVE-2024-40994
In the Linux kernel, the following vulnerability has been resolved: ptp: fix integer overflow in max_vclocks_store On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc() to do the allocation to prevent this.
- https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e
- https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f
- https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0
- https://git.kernel.org/stable/c/d50d62d5e6ee6aa03c00bddb91745d0b632d3b0f
- https://git.kernel.org/stable/c/e1fccfb4638ee6188377867f6015d0ce35764a8e
- https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e
- https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f
- https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0
- https://git.kernel.org/stable/c/d50d62d5e6ee6aa03c00bddb91745d0b632d3b0f
- https://git.kernel.org/stable/c/e1fccfb4638ee6188377867f6015d0ce35764a8e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-40995
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
syzbot found hanging tasks waiting on rtnl_lock [1]
A reproducer is available in the syzbot bug.
When a request to add multiple actions with the same index is sent, the
second request will block forever on the first request. This holds
rtnl_lock, and causes tasks to hang.
Return -EAGAIN to prevent infinite looping, while keeping documented
behavior.
[1]
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
Workqueue: events_power_efficient reg_check_chans_work
Call Trace:
- https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74
- https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da
- https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2
- https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4
- https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335
- https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90
- https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7008f5d6
- https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74
- https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da
- https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2
- https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4
- https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335
- https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90
- https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7008f5d6
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-40997
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: fix memory leak on CPU EPP exit The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that. [ rjw: Subject and changelog edits ]
- https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd
- https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582
- https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81
- https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd
- https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582
- https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81
Modified: 2025-09-25
CVE-2024-40998
In the Linux kernel, the following vulnerability has been resolved: ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super() In the following concurrency we will access the uninitialized rs->lock: ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, _RET_IP_) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock here and get the following dump_stack: ========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4] [...] ========================================================= Normally interval is 0 until s_msg_ratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.
- https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c
- https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798
- https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c
- https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c
- https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798
- https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c
Modified: 2026-01-14
CVE-2024-41000
In the Linux kernel, the following vulnerability has been resolved:
block/ioctl: prefer different overflow check
Running syzkaller with the newly reintroduced signed integer overflow
sanitizer shows this report:
[ 62.982337] ------------[ cut here ]------------
[ 62.985692] cgroup: Invalid name
[ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46
[ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1
[ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long'
[ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1
[ 62.999369] random: crng reseeded on system resumption
[ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)
[ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 63.000682] Call Trace:
[ 63.000686]
- https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66
- https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e
- https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24
- https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9
- https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9
- https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e
- https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66
- https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e
- https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24
- https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9
- https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9
- https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41001
In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: work around a potential audit memory leak kmemleak complains that there's a memory leak related to connect handling: unreferenced object 0xffff0001093bdf00 (size 128): comm "iou-sqp-455", pid 457, jiffies 4294894164 hex dump (first 32 bytes): 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 2e481b1a): [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38 [<000000009c30bb45>] kmalloc_trace+0x228/0x358 [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138 [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8 [<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4 [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48 [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4 [<00000000d999b491>] ret_from_fork+0x10/0x20 which can can happen if: 1) The command type does something on the prep side that triggers an audit call. 2) The thread hasn't done any operations before this that triggered an audit call inside ->issue(), where we have audit_uring_entry() and audit_uring_exit(). Work around this by issuing a blanket NOP operation before the SQPOLL does anything.
- https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227
- https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667
- https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3
- https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae
- https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227
- https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667
- https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3
- https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41002
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - Fix memory leak for sec resource release The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs. The aiv resource release is added to the sec resource release function.
- https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47
- https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6
- https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601
- https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2
- https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094
- https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47
- https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6
- https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601
- https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2
- https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41004
In the Linux kernel, the following vulnerability has been resolved:
tracing: Build event generation tests only as modules
The kprobes and synth event generation test modules add events and lock
(get a reference) those event file reference in module init function,
and unlock and delete it in module exit function. This is because those
are designed for playing as modules.
If we make those modules as built-in, those events are left locked in the
kernel, and never be removed. This causes kprobe event self-test failure
as below.
[ 97.349708] ------------[ cut here ]------------
[ 97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480
[ 97.357106] Modules linked in:
[ 97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14
[ 97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480
[ 97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 <0f> 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90
[ 97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286
[ 97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000
[ 97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68
[ 97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[ 97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000
[ 97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000
[ 97.381536] FS: 0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000
[ 97.383813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0
[ 97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 97.391196] Call Trace:
[ 97.391967]
- https://git.kernel.org/stable/c/32ef4dc2b1caf5825c0cf50646479608311cafc3
- https://git.kernel.org/stable/c/3572bd5689b0812b161b40279e39ca5b66d73e88
- https://git.kernel.org/stable/c/55d5d08174366efe57ca9e79964828b20c626c45
- https://git.kernel.org/stable/c/72a0199b361df2387018697b023fdcdd357449a9
- https://git.kernel.org/stable/c/98a7bfc48fffe170a60d87a5cbb7cdddf08184c3
- https://git.kernel.org/stable/c/a85bae262ccecc52a40c466ec067f6c915e0839d
- https://git.kernel.org/stable/c/32ef4dc2b1caf5825c0cf50646479608311cafc3
- https://git.kernel.org/stable/c/3572bd5689b0812b161b40279e39ca5b66d73e88
- https://git.kernel.org/stable/c/55d5d08174366efe57ca9e79964828b20c626c45
- https://git.kernel.org/stable/c/72a0199b361df2387018697b023fdcdd357449a9
- https://git.kernel.org/stable/c/98a7bfc48fffe170a60d87a5cbb7cdddf08184c3
- https://git.kernel.org/stable/c/a85bae262ccecc52a40c466ec067f6c915e0839d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41005
In the Linux kernel, the following vulnerability has been resolved:
netpoll: Fix race condition in netpoll_owner_active
KCSAN detected a race condition in netpoll:
BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
- https://git.kernel.org/stable/c/3f1a155950a1685ffd0fd7175b3f671da8771f3d
- https://git.kernel.org/stable/c/43c0ca793a18578a0f5b305dd77fcf7ed99f1265
- https://git.kernel.org/stable/c/96826b16ef9c6568d31a1f6ceaa266411a46e46c
- https://git.kernel.org/stable/c/a130e7da73ae93afdb4659842267eec734ffbd57
- https://git.kernel.org/stable/c/c2e6a872bde9912f1a7579639c5ca3adf1003916
- https://git.kernel.org/stable/c/efd29cd9c7b8369dfc7bcb34637e6bf1a188aa8e
- https://git.kernel.org/stable/c/3f1a155950a1685ffd0fd7175b3f671da8771f3d
- https://git.kernel.org/stable/c/43c0ca793a18578a0f5b305dd77fcf7ed99f1265
- https://git.kernel.org/stable/c/96826b16ef9c6568d31a1f6ceaa266411a46e46c
- https://git.kernel.org/stable/c/a130e7da73ae93afdb4659842267eec734ffbd57
- https://git.kernel.org/stable/c/c2e6a872bde9912f1a7579639c5ca3adf1003916
- https://git.kernel.org/stable/c/efd29cd9c7b8369dfc7bcb34637e6bf1a188aa8e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41006
In the Linux kernel, the following vulnerability has been resolved: netrom: Fix a memory leak in nr_heartbeat_expiry() syzbot reported a memory leak in nr_create() [0]. Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sock_hold() to the nr_heartbeat_expiry() function, where a) a socket has a SOCK_DESTROY flag or b) a listening socket has a SOCK_DEAD flag. But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor has already been closed and the nr_release() function has been called. So it makes no sense to hold the reference count because no one will call another nr_destroy_socket() and put it as in the case "b." nr_connect nr_establish_data_link nr_start_heartbeat nr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame switch (nr->state) case NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->state = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry switch (nr->state) case NR_STATE_0 if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket() To fix the memory leak, let's call sock_hold() only for a listening socket. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16
- https://git.kernel.org/stable/c/0b9130247f3b6a1122478471ff0e014ea96bb735
- https://git.kernel.org/stable/c/280cf1173726a7059b628c610c71050d5c0b6937
- https://git.kernel.org/stable/c/5391f9db2cab5ef1cb411be1ab7dbec728078fba
- https://git.kernel.org/stable/c/a02fd5d775cf9787ee7698c797e20f2fa13d2e2b
- https://git.kernel.org/stable/c/b6ebe4fed73eedeb73f4540f8edc4871945474c8
- https://git.kernel.org/stable/c/d377f5a28332954b19e373d36823e59830ab1712
- https://git.kernel.org/stable/c/d616876256b38ecf9a1a1c7d674192c5346bc69c
- https://git.kernel.org/stable/c/e07a9c2a850cdebf625e7a1b8171bd23a8554313
- https://git.kernel.org/stable/c/0b9130247f3b6a1122478471ff0e014ea96bb735
- https://git.kernel.org/stable/c/280cf1173726a7059b628c610c71050d5c0b6937
- https://git.kernel.org/stable/c/5391f9db2cab5ef1cb411be1ab7dbec728078fba
- https://git.kernel.org/stable/c/a02fd5d775cf9787ee7698c797e20f2fa13d2e2b
- https://git.kernel.org/stable/c/b6ebe4fed73eedeb73f4540f8edc4871945474c8
- https://git.kernel.org/stable/c/d377f5a28332954b19e373d36823e59830ab1712
- https://git.kernel.org/stable/c/d616876256b38ecf9a1a1c7d674192c5346bc69c
- https://git.kernel.org/stable/c/e07a9c2a850cdebf625e7a1b8171bd23a8554313
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41007
In the Linux kernel, the following vulnerability has been resolved: tcp: avoid too many retransmit packets If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has 'expired'. The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account. Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits. Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4.
- https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570
- https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982
- https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1
- https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4
- https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283
- https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969
- https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde
- https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466
- https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570
- https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982
- https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1
- https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4
- https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283
- https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969
- https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde
- https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41009
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.
- https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4
- https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225
- https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069
- https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f
- https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881
- https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686
- https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4
- https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225
- https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069
- https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f
- https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881
- https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-41010
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix too early release of tcx_entry Pedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported an issue that the tcx_entry can be released too early leading to a use after free (UAF) when an active old-style ingress or clsact qdisc with a shared tc block is later replaced by another ingress or clsact instance. Essentially, the sequence to trigger the UAF (one example) can be as follows: 1. A network namespace is created 2. An ingress qdisc is created. This allocates a tcx_entry, and &tcx_entry->miniq is stored in the qdisc's miniqp->p_miniq. At the same time, a tcf block with index 1 is created. 3. chain0 is attached to the tcf block. chain0 must be connected to the block linked to the ingress qdisc to later reach the function tcf_chain0_head_change_cb_del() which triggers the UAF. 4. Create and graft a clsact qdisc. This causes the ingress qdisc created in step 1 to be removed, thus freeing the previously linked tcx_entry: rtnetlink_rcv_msg() => tc_modify_qdisc() => qdisc_create() => clsact_init() [a] => qdisc_graft() => qdisc_destroy() => __qdisc_destroy() => ingress_destroy() [b] => tcx_entry_free() => kfree_rcu() // tcx_entry freed 5. Finally, the network namespace is closed. This registers the cleanup_net worker, and during the process of releasing the remaining clsact qdisc, it accesses the tcx_entry that was already freed in step 4, causing the UAF to occur: cleanup_net() => ops_exit_list() => default_device_exit_batch() => unregister_netdevice_many() => unregister_netdevice_many_notify() => dev_shutdown() => qdisc_put() => clsact_destroy() [c] => tcf_block_put_ext() => tcf_chain0_head_change_cb_del() => tcf_chain_head_change_item() => clsact_chain_head_change() => mini_qdisc_pair_swap() // UAF There are also other variants, the gist is to add an ingress (or clsact) qdisc with a specific shared block, then to replace that qdisc, waiting for the tcx_entry kfree_rcu() to be executed and subsequently accessing the current active qdisc's miniq one way or another. The correct fix is to turn the miniq_active boolean into a counter. What can be observed, at step 2 above, the counter transitions from 0->1, at step [a] from 1->2 (in order for the miniq object to remain active during the replacement), then in [b] from 2->1 and finally [c] 1->0 with the eventual release. The reference counter in general ranges from [0,2] and it does not need to be atomic since all access to the counter is protected by the rtnl mutex. With this in place, there is no longer a UAF happening and the tcx_entry is freed at the correct time.
- https://git.kernel.org/stable/c/1cb6f0bae50441f4b4b32a28315853b279c7404e
- https://git.kernel.org/stable/c/230bb13650b0f186f540500fd5f5f7096a822a2a
- https://git.kernel.org/stable/c/f61ecf1bd5b562ebfd7d430ccb31619857e80857
- https://git.kernel.org/stable/c/1cb6f0bae50441f4b4b32a28315853b279c7404e
- https://git.kernel.org/stable/c/230bb13650b0f186f540500fd5f5f7096a822a2a
- https://git.kernel.org/stable/c/f61ecf1bd5b562ebfd7d430ccb31619857e80857
Modified: 2025-11-03
CVE-2024-41012
In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().
- https://git.kernel.org/stable/c/3cad1bc010416c6dd780643476bc59ed742436b9
- https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22
- https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240
- https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763
- https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823731b224
- https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250
- https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235
- https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3
- https://git.kernel.org/stable/c/3cad1bc010416c6dd780643476bc59ed742436b9
- https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22
- https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240
- https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763
- https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823731b224
- https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250
- https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235
- https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41015
In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_check_dir_entry() This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.
- https://git.kernel.org/stable/c/13d38c00df97289e6fba2e54193959293fd910d2
- https://git.kernel.org/stable/c/255547c6bb8940a97eea94ef9d464ea5967763fb
- https://git.kernel.org/stable/c/53de17ad01cb5f6f8426f597e9d5c87d4cf53bb7
- https://git.kernel.org/stable/c/564d23cc5b216211e1694d53f7e45959396874d0
- https://git.kernel.org/stable/c/624b380074f0dc209fb8706db3295c735079f34c
- https://git.kernel.org/stable/c/77495e5da5cb110a8fed27b052c77853fe282176
- https://git.kernel.org/stable/c/e05a24289db90f76ff606086aadd62d068a88dcd
- https://git.kernel.org/stable/c/edb2e67dd4626b06fd7eb37252d5067912e78d59
- https://git.kernel.org/stable/c/fd65685594ee707cbf3ddf22ebb73697786ac114
- https://git.kernel.org/stable/c/13d38c00df97289e6fba2e54193959293fd910d2
- https://git.kernel.org/stable/c/255547c6bb8940a97eea94ef9d464ea5967763fb
- https://git.kernel.org/stable/c/53de17ad01cb5f6f8426f597e9d5c87d4cf53bb7
- https://git.kernel.org/stable/c/564d23cc5b216211e1694d53f7e45959396874d0
- https://git.kernel.org/stable/c/624b380074f0dc209fb8706db3295c735079f34c
- https://git.kernel.org/stable/c/77495e5da5cb110a8fed27b052c77853fe282176
- https://git.kernel.org/stable/c/e05a24289db90f76ff606086aadd62d068a88dcd
- https://git.kernel.org/stable/c/edb2e67dd4626b06fd7eb37252d5067912e78d59
- https://git.kernel.org/stable/c/fd65685594ee707cbf3ddf22ebb73697786ac114
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41017
In the Linux kernel, the following vulnerability has been resolved: jfs: don't walk off the end of ealist Add a check before visiting the members of ea to make sure each ea stays within the ealist.
- https://git.kernel.org/stable/c/17440dbc66ab98b410514b04987f61deedb86751
- https://git.kernel.org/stable/c/4e034f7e563ab723b93a59980e4a1bb33198ece8
- https://git.kernel.org/stable/c/6386f1b6a10e5d1ddd03db4ff6dfc55d488852ce
- https://git.kernel.org/stable/c/7e21574195a45fc193555fa40e99fed16565ff7e
- https://git.kernel.org/stable/c/7f91bd0f2941fa36449ce1a15faaa64f840d9746
- https://git.kernel.org/stable/c/d0fa70aca54c8643248e89061da23752506ec0d4
- https://git.kernel.org/stable/c/dbde7bc91093fa9c2410e418b236b70fde044b73
- https://git.kernel.org/stable/c/f4435f476b9bf059cd9e26a69f5b29c768d00375
- https://git.kernel.org/stable/c/fc16776a82e8df97b6c4f9a10ba95aa44cef7ba5
- https://git.kernel.org/stable/c/17440dbc66ab98b410514b04987f61deedb86751
- https://git.kernel.org/stable/c/4e034f7e563ab723b93a59980e4a1bb33198ece8
- https://git.kernel.org/stable/c/6386f1b6a10e5d1ddd03db4ff6dfc55d488852ce
- https://git.kernel.org/stable/c/7e21574195a45fc193555fa40e99fed16565ff7e
- https://git.kernel.org/stable/c/7f91bd0f2941fa36449ce1a15faaa64f840d9746
- https://git.kernel.org/stable/c/d0fa70aca54c8643248e89061da23752506ec0d4
- https://git.kernel.org/stable/c/dbde7bc91093fa9c2410e418b236b70fde044b73
- https://git.kernel.org/stable/c/f4435f476b9bf059cd9e26a69f5b29c768d00375
- https://git.kernel.org/stable/c/fc16776a82e8df97b6c4f9a10ba95aa44cef7ba5
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-07
CVE-2024-41018
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add a check for attr_names and oatbl Added out-of-bound checking for *ane (ATTR_NAME_ENTRY).
- https://git.kernel.org/stable/c/702d4930eb06dcfda85a2fa67e8a1a27bfa2a845
- https://git.kernel.org/stable/c/9b71f820f7168f1eab8378c80c7ea8a022a475bc
- https://git.kernel.org/stable/c/c114d2b88f8b226d4b2acf5a1ba0412cde6c31dd
- https://git.kernel.org/stable/c/f3124d51e4e7b56a732419d8dc270e807252334f
- https://git.kernel.org/stable/c/702d4930eb06dcfda85a2fa67e8a1a27bfa2a845
- https://git.kernel.org/stable/c/9b71f820f7168f1eab8378c80c7ea8a022a475bc
- https://git.kernel.org/stable/c/c114d2b88f8b226d4b2acf5a1ba0412cde6c31dd
- https://git.kernel.org/stable/c/f3124d51e4e7b56a732419d8dc270e807252334f
Modified: 2025-11-03
CVE-2024-41019
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate ff offset This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read.
- https://git.kernel.org/stable/c/35652dfa8cc9a8a900ec0f1e0395781f94ffc5f0
- https://git.kernel.org/stable/c/50c47879650b4c97836a0086632b3a2e300b0f06
- https://git.kernel.org/stable/c/617cf144c206f98978ec730b17159344fd147cb4
- https://git.kernel.org/stable/c/6ae7265a7b816879fd0203e83b5030d3720bbb7a
- https://git.kernel.org/stable/c/818a257428644b8873e79c44404d8fb6598d4440
- https://git.kernel.org/stable/c/82c94e6a7bd116724738aa67eba6f5fedf3a3319
- https://git.kernel.org/stable/c/35652dfa8cc9a8a900ec0f1e0395781f94ffc5f0
- https://git.kernel.org/stable/c/50c47879650b4c97836a0086632b3a2e300b0f06
- https://git.kernel.org/stable/c/617cf144c206f98978ec730b17159344fd147cb4
- https://git.kernel.org/stable/c/6ae7265a7b816879fd0203e83b5030d3720bbb7a
- https://git.kernel.org/stable/c/818a257428644b8873e79c44404d8fb6598d4440
- https://git.kernel.org/stable/c/82c94e6a7bd116724738aa67eba6f5fedf3a3319
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41020
In the Linux kernel, the following vulnerability has been resolved: filelock: Fix fcntl/close race recovery compat path When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels.
- https://git.kernel.org/stable/c/4c43ad4ab41602201d34c66ac62130fe339d686f
- https://git.kernel.org/stable/c/53e21cfa68a7d12de378b7116c75571f73e0dfa2
- https://git.kernel.org/stable/c/5b0af8e4c70e4b884bb94ff5f0cd49ecf1273c02
- https://git.kernel.org/stable/c/73ae349534ebc377328e7d21891e589626c6e82c
- https://git.kernel.org/stable/c/911cc83e56a2de5a40758766c6a70d6998248860
- https://git.kernel.org/stable/c/a561145f3ae973ebf3e0aee41624e92a6c5cb38d
- https://git.kernel.org/stable/c/ed898f9ca3fa32c56c858b463ceb9d9936cc69c4
- https://git.kernel.org/stable/c/f4d0775c6e2f1340ca0725f0337de149aaa989ca
- https://git.kernel.org/stable/c/f8138f2ad2f745b9a1c696a05b749eabe44337ea
- https://git.kernel.org/stable/c/4c43ad4ab41602201d34c66ac62130fe339d686f
- https://git.kernel.org/stable/c/53e21cfa68a7d12de378b7116c75571f73e0dfa2
- https://git.kernel.org/stable/c/5b0af8e4c70e4b884bb94ff5f0cd49ecf1273c02
- https://git.kernel.org/stable/c/73ae349534ebc377328e7d21891e589626c6e82c
- https://git.kernel.org/stable/c/911cc83e56a2de5a40758766c6a70d6998248860
- https://git.kernel.org/stable/c/a561145f3ae973ebf3e0aee41624e92a6c5cb38d
- https://git.kernel.org/stable/c/ed898f9ca3fa32c56c858b463ceb9d9936cc69c4
- https://git.kernel.org/stable/c/f4d0775c6e2f1340ca0725f0337de149aaa989ca
- https://git.kernel.org/stable/c/f8138f2ad2f745b9a1c696a05b749eabe44337ea
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-25
CVE-2024-41021
In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix VM_FAULT_HWPOISON handling in do_exception() There is no support for HWPOISON, MEMORY_FAILURE, or ARCH_HAS_COPY_MC on s390. Therefore we do not expect to see VM_FAULT_HWPOISON in do_exception(). However, since commit af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general"), it is possible to see VM_FAULT_HWPOISON in combination with PTE_MARKER_POISONED, even on architectures that do not support HWPOISON otherwise. In this case, we will end up on the BUG() in do_exception(). Fix this by treating VM_FAULT_HWPOISON the same as VM_FAULT_SIGBUS, similar to x86 when MEMORY_FAILURE is not configured. Also print unexpected fault flags, for easier debugging. Note that VM_FAULT_HWPOISON_LARGE is not expected, because s390 cannot support swap entries on other levels than PTE level.
- https://git.kernel.org/stable/c/73a9260b7366d2906ec011e100319359fe2277d0
- https://git.kernel.org/stable/c/9e13767ccefdc4f8aa92514b592b60f6b54882ff
- https://git.kernel.org/stable/c/a3aefb871222a9880602d1a44a558177b4143e3b
- https://git.kernel.org/stable/c/df39038cd89525d465c2c8827eb64116873f141a
- https://git.kernel.org/stable/c/9e13767ccefdc4f8aa92514b592b60f6b54882ff
- https://git.kernel.org/stable/c/a3aefb871222a9880602d1a44a558177b4143e3b
- https://git.kernel.org/stable/c/df39038cd89525d465c2c8827eb64116873f141a
Modified: 2025-02-03
CVE-2024-41025
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix memory leak in audio daemon attach operation Audio PD daemon send the name as part of the init IOCTL call. This name needs to be copied to kernel for which memory is allocated. This memory is never freed which might result in memory leak. Free the memory when it is not needed.
- https://git.kernel.org/stable/c/8b8b82dcf393ceaca8c88939338fd4c30b5b11b2
- https://git.kernel.org/stable/c/ad0bd973a033003ca578c42a760d1dc77aeea15e
- https://git.kernel.org/stable/c/dbf4c31c9b039fd9734da156036492a2a7f78f64
- https://git.kernel.org/stable/c/8b8b82dcf393ceaca8c88939338fd4c30b5b11b2
- https://git.kernel.org/stable/c/ad0bd973a033003ca578c42a760d1dc77aeea15e
- https://git.kernel.org/stable/c/dbf4c31c9b039fd9734da156036492a2a7f78f64
Modified: 2025-11-03
CVE-2024-41027
In the Linux kernel, the following vulnerability has been resolved: Fix userfaultfd_api to return EINVAL as expected Currently if we request a feature that is not set in the Kernel config we fail silently and return all the available features. However, the man page indicates we should return an EINVAL. We need to fix this issue since we can end up with a Kernel warning should a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with the config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660
- https://git.kernel.org/stable/c/14875fd5f9bcf60ac5518c63bfb676ade44aa7c6
- https://git.kernel.org/stable/c/1723f04caacb32cadc4e063725d836a0c4450694
- https://git.kernel.org/stable/c/519547760f16eae7803d2658d9524bc5ba7a20a7
- https://git.kernel.org/stable/c/8111f902b7c95d75fc80c7e577f5045886c6b384
- https://git.kernel.org/stable/c/cd94cac4069a763ab5206be2c64c9a8beae590ba
- https://git.kernel.org/stable/c/14875fd5f9bcf60ac5518c63bfb676ade44aa7c6
- https://git.kernel.org/stable/c/1723f04caacb32cadc4e063725d836a0c4450694
- https://git.kernel.org/stable/c/519547760f16eae7803d2658d9524bc5ba7a20a7
- https://git.kernel.org/stable/c/8111f902b7c95d75fc80c7e577f5045886c6b384
- https://git.kernel.org/stable/c/cd94cac4069a763ab5206be2c64c9a8beae590ba
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41028
In the Linux kernel, the following vulnerability has been resolved: platform/x86: toshiba_acpi: Fix array out-of-bounds access In order to use toshiba_dmi_quirks[] together with the standard DMI matching functions, it must be terminated by a empty entry. Since this entry is missing, an array out-of-bounds access occurs every time the quirk list is processed. Fix this by adding the terminating empty entry.
- https://git.kernel.org/stable/c/0d71da43d6b7916d36cf1953d793da80433c50bf
- https://git.kernel.org/stable/c/639868f1cb87b683cf830353bbee0c4078202313
- https://git.kernel.org/stable/c/b6e02c6b0377d4339986e07aeb696c632cd392aa
- https://git.kernel.org/stable/c/e030aa6c972641cb069086a8c7a0f747653e472a
- https://git.kernel.org/stable/c/0d71da43d6b7916d36cf1953d793da80433c50bf
- https://git.kernel.org/stable/c/639868f1cb87b683cf830353bbee0c4078202313
- https://git.kernel.org/stable/c/b6e02c6b0377d4339986e07aeb696c632cd392aa
- https://git.kernel.org/stable/c/e030aa6c972641cb069086a8c7a0f747653e472a
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41030
In the Linux kernel, the following vulnerability has been resolved: ksmbd: discard write access to the directory open may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let's discard the write access when opening a directory. list_add corruption. next is NULL. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:26! pc : __list_add_valid+0x88/0xbc lr : __list_add_valid+0x88/0xbc Call trace: __list_add_valid+0x88/0xbc fuse_finish_open+0x11c/0x170 fuse_open_common+0x284/0x5e8 fuse_dir_open+0x14/0x24 do_dentry_open+0x2a4/0x4e0 dentry_open+0x50/0x80 smb2_open+0xbe4/0x15a4 handle_ksmbd_work+0x478/0x5ec process_one_work+0x1b4/0x448 worker_thread+0x25c/0x430 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20
- https://git.kernel.org/stable/c/198498b2049c0f11f7670be6974570e02b0cc035
- https://git.kernel.org/stable/c/66cf853e1c7a2407f15d9f7aaa3e47d61745e361
- https://git.kernel.org/stable/c/9e84b1ba5c98fb5c9f869c85db1d870354613baa
- https://git.kernel.org/stable/c/e2e33caa5dc2eae7bddf88b22ce11ec3d760e5cd
- https://git.kernel.org/stable/c/198498b2049c0f11f7670be6974570e02b0cc035
- https://git.kernel.org/stable/c/66cf853e1c7a2407f15d9f7aaa3e47d61745e361
- https://git.kernel.org/stable/c/9e84b1ba5c98fb5c9f869c85db1d870354613baa
- https://git.kernel.org/stable/c/e2e33caa5dc2eae7bddf88b22ce11ec3d760e5cd
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-07
CVE-2024-41031
In the Linux kernel, the following vulnerability has been resolved: mm/filemap: skip to create PMD-sized page cache if needed On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB. The PMD-sized page cache can't be supported by xarray as the following error messages indicate. ------------[ cut here ]------------ WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm \ fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ sha1_ce virtio_net net_failover virtio_console virtio_blk failover \ dimlib virtio_mmio CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff800087a4f6c0 x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858 x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000 x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28 x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8 x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x720 truncate_inode_partial_folio+0xdc/0x160 truncate_inode_pages_range+0x1b4/0x4a8 truncate_pagecache_range+0x84/0xa0 xfs_flush_unmap_range+0x70/0x90 [xfs] xfs_file_fallocate+0xfc/0x4d8 [xfs] vfs_fallocate+0x124/0x2e8 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by skipping to allocate PMD-sized page cache when its size is larger than MAX_PAGECACHE_ORDER. For this specific case, we will fall to regular path where the readahead window is determined by BDI's sysfs file (read_ahead_kb).
- https://git.kernel.org/stable/c/06b5a69c27ec405a3c3f2da8520ff1ee70b94a21
- https://git.kernel.org/stable/c/1ef650d3b1b2a16473981b447f38705fe9b93972
- https://git.kernel.org/stable/c/3390916aca7af1893ed2ebcdfee1d6fdb65bb058
- https://git.kernel.org/stable/c/06b5a69c27ec405a3c3f2da8520ff1ee70b94a21
- https://git.kernel.org/stable/c/1ef650d3b1b2a16473981b447f38705fe9b93972
- https://git.kernel.org/stable/c/3390916aca7af1893ed2ebcdfee1d6fdb65bb058
Modified: 2025-10-07
CVE-2024-41032
In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: check if a hash-index is in cpu_possible_mask The problem is that there are systems where cpu_possible_mask has gaps between set CPUs, for example SPARC. In this scenario addr_to_vb_xa() hash function can return an index which accesses to not-possible and not setup CPU area using per_cpu() macro. This results in an oops on SPARC. A per-cpu vmap_block_queue is also used as hash table, incorrectly assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index to a next possible CPU.
- https://git.kernel.org/stable/c/28acd531c9a365dac01b32e6bc54aed8c1429bcb
- https://git.kernel.org/stable/c/47f9b6e49b422392fb0e348a65eb925103ba1882
- https://git.kernel.org/stable/c/a34acf30b19bc4ee3ba2f1082756ea2604c19138
- https://git.kernel.org/stable/c/28acd531c9a365dac01b32e6bc54aed8c1429bcb
- https://git.kernel.org/stable/c/47f9b6e49b422392fb0e348a65eb925103ba1882
- https://git.kernel.org/stable/c/a34acf30b19bc4ee3ba2f1082756ea2604c19138
Modified: 2025-11-03
CVE-2024-41034
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug on rename operation of broken directory Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size. This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories. Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().
- https://git.kernel.org/stable/c/1a8879c0771a68d70ee2e5e66eea34207e8c6231
- https://git.kernel.org/stable/c/24c1c8566a9b6be51f5347be2ea76e25fc82b11e
- https://git.kernel.org/stable/c/298cd810d7fb687c90a14d8f9fd1b8719a7cb8a5
- https://git.kernel.org/stable/c/60f61514374e4a0c3b65b08c6024dd7e26150bfd
- https://git.kernel.org/stable/c/7000b438dda9d0f41a956fc9bffed92d2eb6be0d
- https://git.kernel.org/stable/c/a9a466a69b85059b341239766a10efdd3ee68a4b
- https://git.kernel.org/stable/c/a9e1ddc09ca55746079cc479aa3eb6411f0d99d4
- https://git.kernel.org/stable/c/ff9767ba2cb949701e45e6e4287f8af82986b703
- https://git.kernel.org/stable/c/1a8879c0771a68d70ee2e5e66eea34207e8c6231
- https://git.kernel.org/stable/c/24c1c8566a9b6be51f5347be2ea76e25fc82b11e
- https://git.kernel.org/stable/c/298cd810d7fb687c90a14d8f9fd1b8719a7cb8a5
- https://git.kernel.org/stable/c/60f61514374e4a0c3b65b08c6024dd7e26150bfd
- https://git.kernel.org/stable/c/7000b438dda9d0f41a956fc9bffed92d2eb6be0d
- https://git.kernel.org/stable/c/a9a466a69b85059b341239766a10efdd3ee68a4b
- https://git.kernel.org/stable/c/a9e1ddc09ca55746079cc479aa3eb6411f0d99d4
- https://git.kernel.org/stable/c/ff9767ba2cb949701e45e6e4287f8af82986b703
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41035
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates.
- https://git.kernel.org/stable/c/2bd8534a1b83c65702aec3cab164170f8e584188
- https://git.kernel.org/stable/c/37514a5c1251a8c5c95c323f55050736e7069ac7
- https://git.kernel.org/stable/c/60abea505b726b38232a0ef410d2bd1994a77f78
- https://git.kernel.org/stable/c/647d61aef106dbed9c70447bcddbd4968e67ca64
- https://git.kernel.org/stable/c/9edcf317620d7c6a8354911b69b874cf89716646
- https://git.kernel.org/stable/c/a368ecde8a5055b627749b09c6218ef793043e47
- https://git.kernel.org/stable/c/d09dd21bb5215d583ca9a1cb1464dbc77a7e88cf
- https://git.kernel.org/stable/c/d8418fd083d1b90a6c007cf8dcf81aeae274727b
- https://git.kernel.org/stable/c/2bd8534a1b83c65702aec3cab164170f8e584188
- https://git.kernel.org/stable/c/37514a5c1251a8c5c95c323f55050736e7069ac7
- https://git.kernel.org/stable/c/60abea505b726b38232a0ef410d2bd1994a77f78
- https://git.kernel.org/stable/c/647d61aef106dbed9c70447bcddbd4968e67ca64
- https://git.kernel.org/stable/c/9edcf317620d7c6a8354911b69b874cf89716646
- https://git.kernel.org/stable/c/a368ecde8a5055b627749b09c6218ef793043e47
- https://git.kernel.org/stable/c/d09dd21bb5215d583ca9a1cb1464dbc77a7e88cf
- https://git.kernel.org/stable/c/d8418fd083d1b90a6c007cf8dcf81aeae274727b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41036
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Fix deadlock with the SPI chip variant When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup - CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock.
- https://git.kernel.org/stable/c/0913ec336a6c0c4a2b296bd9f74f8e41c4c83c8c
- https://git.kernel.org/stable/c/10fec0cd0e8f56ff06c46bb24254c7d8f8f2bbf0
- https://git.kernel.org/stable/c/80ece00137300d74642f2038c8fe5440deaf9f05
- https://git.kernel.org/stable/c/a0c69c492f4a8fad52f0a97565241c926160c9a4
- https://git.kernel.org/stable/c/0913ec336a6c0c4a2b296bd9f74f8e41c4c83c8c
- https://git.kernel.org/stable/c/10fec0cd0e8f56ff06c46bb24254c7d8f8f2bbf0
- https://git.kernel.org/stable/c/80ece00137300d74642f2038c8fe5440deaf9f05
- https://git.kernel.org/stable/c/a0c69c492f4a8fad52f0a97565241c926160c9a4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-41037
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: fix null deref on system suspend entry When system enters suspend with an active stream, SOF core calls hw_params_upon_resume(). On Intel platforms with HDA DMA used to manage the link DMA, this leads to call chain of hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() -> hda_ipc4_post_trigger() A bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first, which clears hext_stream->link_substream, and then hda_ipc4_post_trigger() is called with a NULL snd_pcm_substream pointer.
- https://git.kernel.org/stable/c/8246bbf818ed7b8d5afc92b951e6d562b45c2450
- https://git.kernel.org/stable/c/9065693dcc13f287b9e4991f43aee70cf5538fdd
- https://git.kernel.org/stable/c/993af0f2d9f24e3c18a445ae22b34190d1fcad61
- https://git.kernel.org/stable/c/8246bbf818ed7b8d5afc92b951e6d562b45c2450
- https://git.kernel.org/stable/c/9065693dcc13f287b9e4991f43aee70cf5538fdd
- https://git.kernel.org/stable/c/993af0f2d9f24e3c18a445ae22b34190d1fcad61
Modified: 2025-11-03
CVE-2024-41038
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers Check that all fields of a V2 algorithm header fit into the available firmware data buffer. The wmfw V2 format introduced variable-length strings in the algorithm block header. This means the overall header length is variable, and the position of most fields varies depending on the length of the string fields. Each field must be checked to ensure that it does not overflow the firmware data buffer. As this ia bugfix patch, the fixes avoid making any significant change to the existing code. This makes it easier to review and less likely to introduce new bugs.
- https://git.kernel.org/stable/c/014239b9971d79421a0ba652579e1ca1b7b57b6d
- https://git.kernel.org/stable/c/2163aff6bebbb752edf73f79700f5e2095f3559e
- https://git.kernel.org/stable/c/6619aa48a011364e9f29083cc76368e6acfe5b11
- https://git.kernel.org/stable/c/76ea8e13aaefdfda6e5601323d6ea5340359dcfa
- https://git.kernel.org/stable/c/014239b9971d79421a0ba652579e1ca1b7b57b6d
- https://git.kernel.org/stable/c/2163aff6bebbb752edf73f79700f5e2095f3559e
- https://git.kernel.org/stable/c/6619aa48a011364e9f29083cc76368e6acfe5b11
- https://git.kernel.org/stable/c/76ea8e13aaefdfda6e5601323d6ea5340359dcfa
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41039
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix overflow checking of wmfw header Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used.
- https://git.kernel.org/stable/c/3019b86bce16fbb5bc1964f3544d0ce7d0137278
- https://git.kernel.org/stable/c/49a79f344d0a17c6a5eef53716cc76fcdbfca9ba
- https://git.kernel.org/stable/c/9c9877a96e033bf6c6470b3b4f06106d91ace11e
- https://git.kernel.org/stable/c/fd035f0810b33c2a8792effdb82bf35920221565
- https://git.kernel.org/stable/c/3019b86bce16fbb5bc1964f3544d0ce7d0137278
- https://git.kernel.org/stable/c/49a79f344d0a17c6a5eef53716cc76fcdbfca9ba
- https://git.kernel.org/stable/c/9c9877a96e033bf6c6470b3b4f06106d91ace11e
- https://git.kernel.org/stable/c/fd035f0810b33c2a8792effdb82bf35920221565
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41040
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix UAF when resolving a clash
KASAN reports the following UAF:
BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
Read of size 1 at addr ffff888c07603600 by task handler130/6469
Call Trace:
- https://git.kernel.org/stable/c/26488172b0292bed837b95a006a3f3431d1898c3
- https://git.kernel.org/stable/c/2b4d68df3f57ea746c430941ba9c03d7d8b5a23f
- https://git.kernel.org/stable/c/4e71b10a100861fb27d9c5755dfd68f615629fae
- https://git.kernel.org/stable/c/799a34901b634008db4a7ece3900e2b971d4c932
- https://git.kernel.org/stable/c/b81a523d54ea689414f67c9fb81a5b917a41ed55
- https://git.kernel.org/stable/c/ef472cc6693b16b202a916482df72f35d94bd69e
- https://git.kernel.org/stable/c/26488172b0292bed837b95a006a3f3431d1898c3
- https://git.kernel.org/stable/c/2b4d68df3f57ea746c430941ba9c03d7d8b5a23f
- https://git.kernel.org/stable/c/4e71b10a100861fb27d9c5755dfd68f615629fae
- https://git.kernel.org/stable/c/799a34901b634008db4a7ece3900e2b971d4c932
- https://git.kernel.org/stable/c/b81a523d54ea689414f67c9fb81a5b917a41ed55
- https://git.kernel.org/stable/c/ef472cc6693b16b202a916482df72f35d94bd69e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41041
In the Linux kernel, the following vulnerability has been resolved:
udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
syzkaller triggered the warning [0] in udp_v4_early_demux().
In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount
of the looked-up sk and use sock_pfree() as skb->destructor, so we check
SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace
period.
Currently, SOCK_RCU_FREE is flagged for a bound socket after being put
into the hash table. Moreover, the SOCK_RCU_FREE check is done too early
in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race
window:
CPU1 CPU2
---- ----
udp_v4_early_demux() udp_lib_get_port()
| |- hlist_add_head_rcu()
|- sk = __udp4_lib_demux_lookup() |
|- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));
`- sock_set_flag(sk, SOCK_RCU_FREE)
We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
set SOCK_RCU_FREE before inserting socket into hashtable").
Let's apply the same fix for UDP.
[0]:
WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
Modules linked in:
CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52
RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c
RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001
RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680
R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e
FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/20ceae10623c3b29fdf7609690849475bcdebdb0
- https://git.kernel.org/stable/c/5c0b485a8c6116516f33925b9ce5b6104a6eadfd
- https://git.kernel.org/stable/c/7a67c4e47626e6daccda62888f8b096abb5d3940
- https://git.kernel.org/stable/c/9f965684c57c3117cfd2f754dd3270383c529fba
- https://git.kernel.org/stable/c/a6db0d3ea6536e7120871e5448b3032570152ec6
- https://git.kernel.org/stable/c/c5fd77ca13d657c6e99bf04f0917445e6a80231e
- https://git.kernel.org/stable/c/ddf516e50bf8a7bc9b3bd8a9831f9c7a8131a32a
- https://git.kernel.org/stable/c/20ceae10623c3b29fdf7609690849475bcdebdb0
- https://git.kernel.org/stable/c/5c0b485a8c6116516f33925b9ce5b6104a6eadfd
- https://git.kernel.org/stable/c/7a67c4e47626e6daccda62888f8b096abb5d3940
- https://git.kernel.org/stable/c/9f965684c57c3117cfd2f754dd3270383c529fba
- https://git.kernel.org/stable/c/a6db0d3ea6536e7120871e5448b3032570152ec6
- https://git.kernel.org/stable/c/c5fd77ca13d657c6e99bf04f0917445e6a80231e
- https://git.kernel.org/stable/c/ddf516e50bf8a7bc9b3bd8a9831f9c7a8131a32a
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41042
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prefer nft_chain_validate nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE). It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again. nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s. This also fixes a crash bug. Old loop detection code can result in unbounded recursion: BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..] with a suitable ruleset during validation of register stores. I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph. For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).
- https://git.kernel.org/stable/c/1947e4c3346faa8ac7e343652c0fd3b3e394202f
- https://git.kernel.org/stable/c/31c35f9f89ef585f1edb53e17ac73a0ca4a9712b
- https://git.kernel.org/stable/c/717c91c6ed73e248de6a15bc53adefb81446c9d0
- https://git.kernel.org/stable/c/8246b7466c8da49d0d9e85e26cbd69dd6d3e3d1e
- https://git.kernel.org/stable/c/9df785aeb7dcc8efd1d4110bb27d26005298ebae
- https://git.kernel.org/stable/c/b6b6e430470e1c3c5513311cb35a15a205595abe
- https://git.kernel.org/stable/c/cd4348e0a50286282c314ad6d2b0740e7c812c24
- https://git.kernel.org/stable/c/cff3bd012a9512ac5ed858d38e6ed65f6391008c
- https://git.kernel.org/stable/c/9df785aeb7dcc8efd1d4110bb27d26005298ebae
- https://git.kernel.org/stable/c/cff3bd012a9512ac5ed858d38e6ed65f6391008c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41044
In the Linux kernel, the following vulnerability has been resolved: ppp: reject claimed-as-LCP but actually malformed packets Since 'ppp_async_encode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise.
- https://git.kernel.org/stable/c/099502ca410922b56353ccef2749bc0de669da78
- https://git.kernel.org/stable/c/3134bdf7356ed952dcecb480861d2afcc1e40492
- https://git.kernel.org/stable/c/3ba12c2afd933fc1bf800f6d3f6c7ec8f602ce56
- https://git.kernel.org/stable/c/6e8f1c21174f9482033bbb59f13ce1a8cbe843c3
- https://git.kernel.org/stable/c/97d1efd8be26615ff680cdde86937d5943138f37
- https://git.kernel.org/stable/c/d683e7f3fc48f59576af34631b4fb07fd931343e
- https://git.kernel.org/stable/c/ebc5c630457783d17d0c438b0ad70b232a64a82f
- https://git.kernel.org/stable/c/f2aeb7306a898e1cbd03963d376f4b6656ca2b55
- https://git.kernel.org/stable/c/099502ca410922b56353ccef2749bc0de669da78
- https://git.kernel.org/stable/c/3134bdf7356ed952dcecb480861d2afcc1e40492
- https://git.kernel.org/stable/c/3ba12c2afd933fc1bf800f6d3f6c7ec8f602ce56
- https://git.kernel.org/stable/c/6e8f1c21174f9482033bbb59f13ce1a8cbe843c3
- https://git.kernel.org/stable/c/97d1efd8be26615ff680cdde86937d5943138f37
- https://git.kernel.org/stable/c/d683e7f3fc48f59576af34631b4fb07fd931343e
- https://git.kernel.org/stable/c/ebc5c630457783d17d0c438b0ad70b232a64a82f
- https://git.kernel.org/stable/c/f2aeb7306a898e1cbd03963d376f4b6656ca2b55
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41046
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times.
- https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec
- https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1
- https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156
- https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1fba964f
- https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1
- https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54
- https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3
- https://git.kernel.org/stable/c/e1533b6319ab9c3a97dad314dd88b3783bc41b69
- https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec
- https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1
- https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156
- https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1fba964f
- https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1
- https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54
- https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3
- https://git.kernel.org/stable/c/e1533b6319ab9c3a97dad314dd88b3783bc41b69
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41047
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix XDP program unloading while removing the driver
The commit 6533e558c650 ("i40e: Fix reset path while removing
the driver") introduced a new PF state "__I40E_IN_REMOVE" to block
modifying the XDP program while the driver is being removed.
Unfortunately, such a change is useful only if the ".ndo_bpf()"
callback was called out of the rmmod context because unloading the
existing XDP program is also a part of driver removing procedure.
In other words, from the rmmod context the driver is expected to
unload the XDP program without reporting any errors. Otherwise,
the kernel warning with callstack is printed out to dmesg.
Example failing scenario:
1. Load the i40e driver.
2. Load the XDP program.
3. Unload the i40e driver (using "rmmod" command).
The example kernel warning log:
[ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870
[...]
[ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870
[...]
[ +0.002726] Call Trace:
[ +0.002457]
- https://git.kernel.org/stable/c/0075b8c94d76830c7b6f018f6e4eeb0bf6465fdc
- https://git.kernel.org/stable/c/01fc5142ae6b06b61ed51a624f2732d6525d8ea3
- https://git.kernel.org/stable/c/4bc336b2345f1485438c0eb7246d9c8a8d09f8ff
- https://git.kernel.org/stable/c/5266302cb2c74d8ab0e9a69d5752fffaea70496e
- https://git.kernel.org/stable/c/b399a68054dfb36eed121846ef5fcddba40b7740
- https://git.kernel.org/stable/c/0075b8c94d76830c7b6f018f6e4eeb0bf6465fdc
- https://git.kernel.org/stable/c/01fc5142ae6b06b61ed51a624f2732d6525d8ea3
- https://git.kernel.org/stable/c/4bc336b2345f1485438c0eb7246d9c8a8d09f8ff
- https://git.kernel.org/stable/c/5266302cb2c74d8ab0e9a69d5752fffaea70496e
- https://git.kernel.org/stable/c/b399a68054dfb36eed121846ef5fcddba40b7740
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41048
In the Linux kernel, the following vulnerability has been resolved: skmsg: Skip zero length skb in sk_msg_recvmsg When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch platform, the following kernel panic occurs: [...] Oops[#1]: CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copy_page_to_iter+0x74/0x1c0 [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] inet_recvmsg+0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [<900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...] This crash happens every time when running sockmap_skb_verdict_shutdown subtest in sockmap_basic. This crash is because a NULL pointer is passed to page_address() in the sk_msg_recvmsg(). Due to the different implementations depending on the architecture, page_address(NULL) will trigger a panic on Loongarch platform but not on x86 platform. So this bug was hidden on x86 platform for a while, but now it is exposed on Loongarch platform. The root cause is that a zero length skb (skb->len == 0) was put on the queue. This zero length skb is a TCP FIN packet, which was sent by shutdown(), invoked in test_sockmap_skb_verdict_shutdown(): shutdown(p1, SHUT_WR); In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no page is put to this sge (see sg_set_page in sg_set_page), but this empty sge is queued into ingress_msg list. And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it to kmap_local_page() and to page_address(), then kernel panics. To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(), if copy is zero, that means it's a zero length skb, skip invoking copy_page_to_iter(). We are using the EFAULT return triggered by copy_page_to_iter to check for is_fin in tcp_bpf.c.
- https://git.kernel.org/stable/c/195b7bcdfc5adc5b2468f279dd9eb7eebd2e7632
- https://git.kernel.org/stable/c/b180739b45a38b4caa88fe16bb5273072e6613dc
- https://git.kernel.org/stable/c/f0c18025693707ec344a70b6887f7450bf4c826b
- https://git.kernel.org/stable/c/f8bd689f37f4198a4c61c4684f591ba639595b97
- https://git.kernel.org/stable/c/fb61d7b9fb6ef0032de469499a54dab4c7260d0d
- https://git.kernel.org/stable/c/195b7bcdfc5adc5b2468f279dd9eb7eebd2e7632
- https://git.kernel.org/stable/c/b180739b45a38b4caa88fe16bb5273072e6613dc
- https://git.kernel.org/stable/c/f0c18025693707ec344a70b6887f7450bf4c826b
- https://git.kernel.org/stable/c/f8bd689f37f4198a4c61c4684f591ba639595b97
- https://git.kernel.org/stable/c/fb61d7b9fb6ef0032de469499a54dab4c7260d0d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41049
In the Linux kernel, the following vulnerability has been resolved: filelock: fix potential use-after-free in posix_lock_inode Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen.
- https://git.kernel.org/stable/c/02a8964260756c70b20393ad4006948510ac9967
- https://git.kernel.org/stable/c/116599f6a26906cf33f67975c59f0692ecf7e9b2
- https://git.kernel.org/stable/c/1b3ec4f7c03d4b07bad70697d7e2f4088d2cfe92
- https://git.kernel.org/stable/c/1cbbb3d9475c403ebedc327490c7c2b991398197
- https://git.kernel.org/stable/c/432b06b69d1d354a171f7499141116536579eb6a
- https://git.kernel.org/stable/c/5cb36e35bc10ea334810937990c2b9023dacb1b0
- https://git.kernel.org/stable/c/7d4c14f4b511fd4c0dc788084ae59b4656ace58b
- https://git.kernel.org/stable/c/02a8964260756c70b20393ad4006948510ac9967
- https://git.kernel.org/stable/c/116599f6a26906cf33f67975c59f0692ecf7e9b2
- https://git.kernel.org/stable/c/1b3ec4f7c03d4b07bad70697d7e2f4088d2cfe92
- https://git.kernel.org/stable/c/1cbbb3d9475c403ebedc327490c7c2b991398197
- https://git.kernel.org/stable/c/432b06b69d1d354a171f7499141116536579eb6a
- https://git.kernel.org/stable/c/5cb36e35bc10ea334810937990c2b9023dacb1b0
- https://git.kernel.org/stable/c/7d4c14f4b511fd4c0dc788084ae59b4656ace58b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41050
In the Linux kernel, the following vulnerability has been resolved: cachefiles: cyclic allocation of msg_id to avoid reuse Reusing the msg_id after a maliciously completed reopen request may cause a read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3 ------------------------------------------------- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done) cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // will not set the object to close // because ondemand_id && fd is valid. // ondemand_object_worker() is done // but the object is still reopening. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reuse msg_id 6 process_open_req copen 6,A.size // The expected failed copen was executed successfully Expect copen to fail, and when it does, it closes fd, which sets the object to close, and then close triggers reopen again. However, due to msg_id reuse resulting in a successful copen, the anonymous fd is not closed until the daemon exits. Therefore read requests waiting for reopen to complete may trigger hung task. To avoid this issue, allocate the msg_id cyclically to avoid reusing the msg_id for a very short duration of time.
- https://git.kernel.org/stable/c/19f4f399091478c95947f6bd7ad61622300c30d9
- https://git.kernel.org/stable/c/35710c6c4a1c64478ec1b5e0e81d386c0844dec6
- https://git.kernel.org/stable/c/9d3bf4e9aa23f0d9e99ebe7a94f232ddba54ee17
- https://git.kernel.org/stable/c/de045a82e1a4e04be62718d3c2981a55150765a0
- https://git.kernel.org/stable/c/19f4f399091478c95947f6bd7ad61622300c30d9
- https://git.kernel.org/stable/c/35710c6c4a1c64478ec1b5e0e81d386c0844dec6
- https://git.kernel.org/stable/c/9d3bf4e9aa23f0d9e99ebe7a94f232ddba54ee17
- https://git.kernel.org/stable/c/de045a82e1a4e04be62718d3c2981a55150765a0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-41053
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix ufshcd_abort_one racing issue When ufshcd_abort_one is racing with the completion ISR, the completed tag of the request's mq_hctx pointer will be set to NULL by ISR. Return success when request is completed by ISR because ufshcd_abort_one does not need to do anything. The racing flow is: Thread A ufshcd_err_handler step 1 ... ufshcd_abort_one ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) step 3 ufshcd_mcq_req_to_hwq blk_mq_unique_tag rq->mq_hctx->queue_num step 5 Thread B ufs_mtk_mcq_intr(cq complete ISR) step 2 scsi_done ... __blk_mq_free_request rq->mq_hctx = NULL; step 4 Below is KE back trace. ufshcd_try_to_abort_task: cmd at tag 41 not pending in the device. ufshcd_try_to_abort_task: cmd at tag=41 is cleared. Aborting tag 41 / CDB 0x28 succeeded Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194 pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14 lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise] do_mem_abort+0x58/0x118 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x54/0x90 el1h_64_sync+0x68/0x6c blk_mq_unique_tag+0x8/0x14 ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise] process_one_work+0x208/0x4fc worker_thread+0x228/0x438 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20
- https://git.kernel.org/stable/c/74736103fb4123c71bf11fb7a6abe7c884c5269e
- https://git.kernel.org/stable/c/b5a6ac887256762758bfe7f2918cb0233aa544f4
- https://git.kernel.org/stable/c/c3111b3cf3889bfa7b73ebff83d7397db9b7e5e0
- https://git.kernel.org/stable/c/74736103fb4123c71bf11fb7a6abe7c884c5269e
- https://git.kernel.org/stable/c/b5a6ac887256762758bfe7f2918cb0233aa544f4
- https://git.kernel.org/stable/c/c3111b3cf3889bfa7b73ebff83d7397db9b7e5e0
Modified: 2024-11-21
CVE-2024-41054
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix ufshcd_clear_cmd racing issue When ufshcd_clear_cmd is racing with the completion ISR, the completed tag of the request's mq_hctx pointer will be set to NULL by the ISR. And ufshcd_clear_cmd's call to ufshcd_mcq_req_to_hwq will get NULL pointer KE. Return success when the request is completed by ISR because sq does not need cleanup. The racing flow is: Thread A ufshcd_err_handler step 1 ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) step 3 ufshcd_clear_cmd ... ufshcd_mcq_req_to_hwq blk_mq_unique_tag rq->mq_hctx->queue_num step 5 Thread B ufs_mtk_mcq_intr(cq complete ISR) step 2 scsi_done ... __blk_mq_free_request rq->mq_hctx = NULL; step 4 Below is KE back trace: ufshcd_try_to_abort_task: cmd pending in the device. tag = 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194 pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14 lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise] Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise] Call trace: dump_backtrace+0xf8/0x148 show_stack+0x18/0x24 dump_stack_lvl+0x60/0x7c dump_stack+0x18/0x3c mrdump_common_die+0x24c/0x398 [mrdump] ipanic_die+0x20/0x34 [mrdump] notify_die+0x80/0xd8 die+0x94/0x2b8 __do_kernel_fault+0x264/0x298 do_page_fault+0xa4/0x4b8 do_translation_fault+0x38/0x54 do_mem_abort+0x58/0x118 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x54/0x90 el1h_64_sync+0x68/0x6c blk_mq_unique_tag+0x8/0x14 ufshcd_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise] ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise] ufshcd_err_handler+0xa7c/0xfa8 [ufs_mediatek_mod_ise] process_one_work+0x208/0x4fc worker_thread+0x228/0x438 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20
- https://git.kernel.org/stable/c/11d81233f4ebe6907b12c79ad7d8787aa4db0633
- https://git.kernel.org/stable/c/9307a998cb9846a2557fdca286997430bee36a2a
- https://git.kernel.org/stable/c/bed0896008334eeee4b4bfd7150491ca098cbf72
- https://git.kernel.org/stable/c/11d81233f4ebe6907b12c79ad7d8787aa4db0633
- https://git.kernel.org/stable/c/9307a998cb9846a2557fdca286997430bee36a2a
- https://git.kernel.org/stable/c/bed0896008334eeee4b4bfd7150491ca098cbf72
Modified: 2025-11-03
CVE-2024-41055
In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") changed pfn_section_valid() to add a READ_ONCE() call around "ms->usage" to fix a race with section_deactivate() where ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.
- https://git.kernel.org/stable/c/0100aeb8a12d51950418e685f879cc80cb8e5982
- https://git.kernel.org/stable/c/797323d1cf92d09b7a017cfec576d9babf99cde7
- https://git.kernel.org/stable/c/82f0b6f041fad768c28b4ad05a683065412c226e
- https://git.kernel.org/stable/c/941e816185661bf2b44b488565d09444ae316509
- https://git.kernel.org/stable/c/adccdf702b4ea913ded5ff512239e382d7473b63
- https://git.kernel.org/stable/c/bc17f2377818dca643a74499c3f5333500c90503
- https://git.kernel.org/stable/c/0100aeb8a12d51950418e685f879cc80cb8e5982
- https://git.kernel.org/stable/c/797323d1cf92d09b7a017cfec576d9babf99cde7
- https://git.kernel.org/stable/c/82f0b6f041fad768c28b4ad05a683065412c226e
- https://git.kernel.org/stable/c/941e816185661bf2b44b488565d09444ae316509
- https://git.kernel.org/stable/c/adccdf702b4ea913ded5ff512239e382d7473b63
- https://git.kernel.org/stable/c/bc17f2377818dca643a74499c3f5333500c90503
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41056
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files. In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing.
- https://git.kernel.org/stable/c/16d76857d6b5426f41b587d0bb925de3f25bfb21
- https://git.kernel.org/stable/c/392cff2f86a25a4286ff3151c7739143c61c1781
- https://git.kernel.org/stable/c/53a9f8cdbf35a682e9894e1a606f4640e5359185
- https://git.kernel.org/stable/c/680e126ec0400f6daecf0510c5bb97a55779ff03
- https://git.kernel.org/stable/c/16d76857d6b5426f41b587d0bb925de3f25bfb21
- https://git.kernel.org/stable/c/392cff2f86a25a4286ff3151c7739143c61c1781
- https://git.kernel.org/stable/c/53a9f8cdbf35a682e9894e1a606f4640e5359185
- https://git.kernel.org/stable/c/680e126ec0400f6daecf0510c5bb97a55779ff03
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41057
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()
We got the following issue in our fault injection stress test:
==================================================================
BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600
Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109
CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566
Call Trace:
- https://git.kernel.org/stable/c/5d8f805789072ea7fd39504694b7bd17e5f751c4
- https://git.kernel.org/stable/c/8de253177112a47c9af157d23ae934779188b4e1
- https://git.kernel.org/stable/c/9e67589a4a7b7e5660b524d1d5fe61242bcbcc11
- https://git.kernel.org/stable/c/ef81340401e8a371d6b17f69e76d861920972cfe
- https://git.kernel.org/stable/c/5d8f805789072ea7fd39504694b7bd17e5f751c4
- https://git.kernel.org/stable/c/8de253177112a47c9af157d23ae934779188b4e1
- https://git.kernel.org/stable/c/9e67589a4a7b7e5660b524d1d5fe61242bcbcc11
- https://git.kernel.org/stable/c/ef81340401e8a371d6b17f69e76d861920972cfe
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41058
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in fscache_withdraw_volume() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370 Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798 CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565 Call Trace: kasan_check_range+0xf6/0x1b0 fscache_withdraw_volume+0x2e1/0x370 cachefiles_withdraw_volume+0x31/0x50 cachefiles_withdraw_cache+0x3ad/0x900 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 Allocated by task 5820: __kmalloc+0x1df/0x4b0 fscache_alloc_volume+0x70/0x600 __fscache_acquire_volume+0x1c/0x610 erofs_fscache_register_volume+0x96/0x1a0 erofs_fscache_register_fs+0x49a/0x690 erofs_fc_fill_super+0x6c0/0xcc0 vfs_get_super+0xa9/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] Freed by task 5820: kfree+0xf1/0x2c0 fscache_put_volume.part.0+0x5cb/0x9e0 erofs_fscache_unregister_fs+0x157/0x1b0 erofs_kill_sb+0xd9/0x1c0 deactivate_locked_super+0xa3/0x100 vfs_get_super+0x105/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] ================================================================== Following is the process that triggers the issue: mount failed | daemon exit ------------------------------------------------------------ deactivate_locked_super cachefiles_daemon_release erofs_kill_sb erofs_fscache_unregister_fs fscache_relinquish_volume __fscache_relinquish_volume fscache_put_volume(fscache_volume, fscache_volume_put_relinquish) zero = __refcount_dec_and_test(&fscache_volume->ref, &ref); cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache cachefiles_withdraw_volumes list_del_init(&volume->cache_link) fscache_free_volume(fscache_volume) cache->ops->free_volume cachefiles_free_volume list_del_init(&cachefiles_volume->cache_link); kfree(fscache_volume) cachefiles_withdraw_volume fscache_withdraw_volume fscache_volume->n_accesses // fscache_volume UAF !!! The fscache_volume in cache->volumes must not have been freed yet, but its reference count may be 0. So use the new fscache_try_get_volume() helper function try to get its reference count. If the reference count of fscache_volume is 0, fscache_put_volume() is freeing it, so wait for it to be removed from cache->volumes. If its reference count is not 0, call cachefiles_withdraw_volume() with reference count protection to avoid the above issue.
- https://git.kernel.org/stable/c/38b88d544216f806d93a273a62ff8ebe82254003
- https://git.kernel.org/stable/c/522018a0de6b6fcce60c04f86dfc5f0e4b6a1b36
- https://git.kernel.org/stable/c/90f17e47f1e209c6a3c92a1d038a0a80c95c460e
- https://git.kernel.org/stable/c/9dd7f5663899ea13a6a73216106d9c13c37453e3
- https://git.kernel.org/stable/c/38b88d544216f806d93a273a62ff8ebe82254003
- https://git.kernel.org/stable/c/522018a0de6b6fcce60c04f86dfc5f0e4b6a1b36
- https://git.kernel.org/stable/c/90f17e47f1e209c6a3c92a1d038a0a80c95c460e
- https://git.kernel.org/stable/c/9dd7f5663899ea13a6a73216106d9c13c37453e3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41059
In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value in copy_name [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.
- https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f76600baf57d
- https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c
- https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0
- https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335
- https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2
- https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4
- https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70
- https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a
- https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f76600baf57d
- https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c
- https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0
- https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335
- https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2
- https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4
- https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70
- https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41060
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check bo_va->bo is non-NULL before using it The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it.
- https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536
- https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af
- https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3
- https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342
- https://git.kernel.org/stable/c/e8d3c53c6f1cccea9c03113f06dd39521c228831
- https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe
- https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536
- https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af
- https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3
- https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342
- https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-41062
In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.
- https://git.kernel.org/stable/c/3b732449b78183d17178db40be3a4401cf3cd629
- https://git.kernel.org/stable/c/605572e64cd9cebb05ed609d96cff05b50d18cdf
- https://git.kernel.org/stable/c/89e856e124f9ae548572c56b1b70c2255705f8fe
- https://git.kernel.org/stable/c/b803f30ea23e0968b6c8285c42adf0d862ab2bf6
- https://git.kernel.org/stable/c/3b732449b78183d17178db40be3a4401cf3cd629
- https://git.kernel.org/stable/c/605572e64cd9cebb05ed609d96cff05b50d18cdf
- https://git.kernel.org/stable/c/89e856e124f9ae548572c56b1b70c2255705f8fe
- https://git.kernel.org/stable/c/b803f30ea23e0968b6c8285c42adf0d862ab2bf6
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41063
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: cancel all works upon hci_unregister_dev() syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush. We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,error_reset} which are queued into hdev->req_workqueue are no longer running by the moment destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); are called from hci_release_dev(). Call cancel_work_sync() on these work items from hci_unregister_dev() as soon as hdev->list is removed from hci_dev_list.
- https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5298d913
- https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678
- https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9
- https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa
- https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed
- https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f
- https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39
- https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92
- https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5298d913
- https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678
- https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9
- https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa
- https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed
- https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f
- https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39
- https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41064
In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: avoid possible crash when edev->pdev changes If a PCI device is removed during eeh_pe_report_edev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.
- https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1
- https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b
- https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff
- https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274
- https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3
- https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd
- https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5
- https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1
- https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b
- https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff
- https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274
- https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3
- https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd
- https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41065
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Whitelist dtl slub object for copying to userspace
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)
MSR: 8000000000029033
- https://git.kernel.org/stable/c/0f5892212c27be31792ef1daa89c8dac1b3047e4
- https://git.kernel.org/stable/c/1a14150e1656f7a332a943154fc486504db4d586
- https://git.kernel.org/stable/c/1ee68686d1e2a5da35d5650be0be1ce06fe2ceb2
- https://git.kernel.org/stable/c/6b16098148ea58a67430d90e20476be2377c3acd
- https://git.kernel.org/stable/c/a7b952941ce07e1e7a2cafd08c64a98e14f553e6
- https://git.kernel.org/stable/c/e512a59b472684d8585125101ab03b86c2c1348a
- https://git.kernel.org/stable/c/e59822f9d700349cd17968d22c979db23a2d347f
- https://git.kernel.org/stable/c/0f5892212c27be31792ef1daa89c8dac1b3047e4
- https://git.kernel.org/stable/c/1a14150e1656f7a332a943154fc486504db4d586
- https://git.kernel.org/stable/c/1ee68686d1e2a5da35d5650be0be1ce06fe2ceb2
- https://git.kernel.org/stable/c/6b16098148ea58a67430d90e20476be2377c3acd
- https://git.kernel.org/stable/c/a7b952941ce07e1e7a2cafd08c64a98e14f553e6
- https://git.kernel.org/stable/c/e512a59b472684d8585125101ab03b86c2c1348a
- https://git.kernel.org/stable/c/e59822f9d700349cd17968d22c979db23a2d347f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41066
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Add tx check to prevent skb leak
Below is a summary of how the driver stores a reference to an skb during
transmit:
tx_buff[free_map[consumer_index]]->skb = new_skb;
free_map[consumer_index] = IBMVNIC_INVALID_MAP;
consumer_index ++;
Where variable data looks like this:
free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]
consumer_index^
tx_buff == [skb=null, skb=
- https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561
- https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c
- https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06
- https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a
- https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561
- https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c
- https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06
- https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-01-05
CVE-2024-41068
In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix sclp_init() cleanup on failure If sclp_init() fails it only partially cleans up: if there are multiple failing calls to sclp_init() sclp_state_change_event will be added several times to sclp_reg_list, which results in the following warning: ------------[ cut here ]------------ list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8 ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30 Fix this by removing sclp_state_change_event from sclp_reg_list when sclp_init() fails.
- https://git.kernel.org/stable/c/0a31b3fdc7e735c4f8c65fe4339945c717ed6808
- https://git.kernel.org/stable/c/6434b33faaa063df500af355ee6c3942e0f8d982
- https://git.kernel.org/stable/c/79b4be70d5a160969b805f638ac5b4efd0aac7a3
- https://git.kernel.org/stable/c/be0259796d0b76bbc7461e12c186814a9e58244c
- https://git.kernel.org/stable/c/cf521049fcd07071ed42dc9758fce7d5ee120ec6
- https://git.kernel.org/stable/c/0a31b3fdc7e735c4f8c65fe4339945c717ed6808
- https://git.kernel.org/stable/c/2e51db7ab71b89dc5a17068f5e201c69f13a4c9a
- https://git.kernel.org/stable/c/455a6653d8700a81aa8ed2b6442a3be476007090
- https://git.kernel.org/stable/c/6434b33faaa063df500af355ee6c3942e0f8d982
- https://git.kernel.org/stable/c/79b4be70d5a160969b805f638ac5b4efd0aac7a3
- https://git.kernel.org/stable/c/a778987afc36d5dc02a1f82d352a81edcaf7eb83
- https://git.kernel.org/stable/c/be0259796d0b76bbc7461e12c186814a9e58244c
- https://git.kernel.org/stable/c/cf521049fcd07071ed42dc9758fce7d5ee120ec6
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41069
In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to freed memory Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed.
- https://git.kernel.org/stable/c/97ab304ecd95c0b1703ff8c8c3956dc6e2afe8e1
- https://git.kernel.org/stable/c/ab5a6208b4d6872b1c6ecea1867940fc668cc76d
- https://git.kernel.org/stable/c/b188d7f3dfab10e332e3c1066e18857964a520d2
- https://git.kernel.org/stable/c/ccae5c6a1fab9494c86b7856faf05e296c617702
- https://git.kernel.org/stable/c/97ab304ecd95c0b1703ff8c8c3956dc6e2afe8e1
- https://git.kernel.org/stable/c/ab5a6208b4d6872b1c6ecea1867940fc668cc76d
- https://git.kernel.org/stable/c/b188d7f3dfab10e332e3c1066e18857964a520d2
- https://git.kernel.org/stable/c/ccae5c6a1fab9494c86b7856faf05e296c617702
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41070
In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group() Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group(). It looks up `stt` from tablefd, but then continues to use it after doing fdput() on the returned fd. After the fdput() the tablefd is free to be closed by another thread. The close calls kvm_spapr_tce_release() and then release_spapr_tce_table() (via call_rcu()) which frees `stt`. Although there are calls to rcu_read_lock() in kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent the UAF, because `stt` is used outside the locked regions. With an artifcial delay after the fdput() and a userspace program which triggers the race, KASAN detects the UAF: BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14 Fix it by delaying the fdput() until `stt` is no longer in use, which is effectively the entire function. To keep the patch minimal add a call to fdput() at each of the existing return paths. Future work can convert the function to goto or __cleanup style cleanup. With the fix in place the test case no longer triggers the UAF.
- https://git.kernel.org/stable/c/4cdf6926f443c84f680213c7aafbe6f91a5fcbc0
- https://git.kernel.org/stable/c/5f856023971f97fff74cfaf21b48ec320147b50a
- https://git.kernel.org/stable/c/82c7a4cf14aa866f8f7f09e662b02eddc49ee0bf
- https://git.kernel.org/stable/c/9975f93c760a32453d7639cf6fcf3f73b4e71ffe
- https://git.kernel.org/stable/c/a986fa57fd81a1430e00b3c6cf8a325d6f894a63
- https://git.kernel.org/stable/c/b26c8c85463ef27a522d24fcd05651f0bb039e47
- https://git.kernel.org/stable/c/be847bb20c809de8ac124431b556f244400b0491
- https://git.kernel.org/stable/c/4cdf6926f443c84f680213c7aafbe6f91a5fcbc0
- https://git.kernel.org/stable/c/5f856023971f97fff74cfaf21b48ec320147b50a
- https://git.kernel.org/stable/c/82c7a4cf14aa866f8f7f09e662b02eddc49ee0bf
- https://git.kernel.org/stable/c/9975f93c760a32453d7639cf6fcf3f73b4e71ffe
- https://git.kernel.org/stable/c/a986fa57fd81a1430e00b3c6cf8a325d6f894a63
- https://git.kernel.org/stable/c/b26c8c85463ef27a522d24fcd05651f0bb039e47
- https://git.kernel.org/stable/c/be847bb20c809de8ac124431b556f244400b0491
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41072
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: wext: add extra SIOCSIWSCAN data check In 'cfg80211_wext_siwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.
- https://git.kernel.org/stable/c/001120ff0c9e3557dee9b5ee0d358e0fc189996f
- https://git.kernel.org/stable/c/35cee10ccaee5bd451a480521bbc25dc9f07fa5b
- https://git.kernel.org/stable/c/6295bad58f988eaafcf0e6f8b198a580398acb3b
- https://git.kernel.org/stable/c/6ef09cdc5ba0f93826c09d810c141a8d103a80fc
- https://git.kernel.org/stable/c/a43cc0558530b6c065976b6b9246f512f8d3593b
- https://git.kernel.org/stable/c/b02ba9a0b55b762bd04743a22f3d9f9645005e79
- https://git.kernel.org/stable/c/de5fcf757e33596eed32de170ce5a93fa44dd2ac
- https://git.kernel.org/stable/c/fe9644efd86704afe50e56b64b609de340ab7c95
- https://git.kernel.org/stable/c/001120ff0c9e3557dee9b5ee0d358e0fc189996f
- https://git.kernel.org/stable/c/35cee10ccaee5bd451a480521bbc25dc9f07fa5b
- https://git.kernel.org/stable/c/6295bad58f988eaafcf0e6f8b198a580398acb3b
- https://git.kernel.org/stable/c/6ef09cdc5ba0f93826c09d810c141a8d103a80fc
- https://git.kernel.org/stable/c/a43cc0558530b6c065976b6b9246f512f8d3593b
- https://git.kernel.org/stable/c/b02ba9a0b55b762bd04743a22f3d9f9645005e79
- https://git.kernel.org/stable/c/de5fcf757e33596eed32de170ce5a93fa44dd2ac
- https://git.kernel.org/stable/c/fe9644efd86704afe50e56b64b609de340ab7c95
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-01-14
CVE-2024-41073
In the Linux kernel, the following vulnerability has been resolved: nvme: avoid double free special payload If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQF_SPECIAL_LOAD when the request is cleaned.
- https://git.kernel.org/stable/c/1b9fd1265fac85916f90b4648de02adccdb7220b
- https://git.kernel.org/stable/c/882574942a9be8b9d70d13462ddacc80c4b385ba
- https://git.kernel.org/stable/c/ae84383c96d6662c24697ab6b44aae855ab670aa
- https://git.kernel.org/stable/c/c5942a14f795de957ae9d66027aac8ff4fe70057
- https://git.kernel.org/stable/c/e5d574ab37f5f2e7937405613d9b1a724811e5ad
- https://git.kernel.org/stable/c/f3ab45aacd25d957547fb6d115c1574c20964b3b
- https://git.kernel.org/stable/c/1b9fd1265fac85916f90b4648de02adccdb7220b
- https://git.kernel.org/stable/c/ae84383c96d6662c24697ab6b44aae855ab670aa
- https://git.kernel.org/stable/c/c5942a14f795de957ae9d66027aac8ff4fe70057
- https://git.kernel.org/stable/c/e5d574ab37f5f2e7937405613d9b1a724811e5ad
- https://git.kernel.org/stable/c/f3ab45aacd25d957547fb6d115c1574c20964b3b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-11-03
CVE-2024-41074
In the Linux kernel, the following vulnerability has been resolved: cachefiles: Set object to close if ondemand_id < 0 in copen If copen is maliciously called in the user mode, it may delete the request corresponding to the random id. And the request may have not been read yet. Note that when the object is set to reopen, the open request will be done with the still reopen state in above case. As a result, the request corresponding to this object is always skipped in select_req function, so the read request is never completed and blocks other process. Fix this issue by simply set object to close if its id < 0 in copen.
- https://git.kernel.org/stable/c/0845c553db11c84ff53fccd59da11b6d6ece4a60
- https://git.kernel.org/stable/c/4f8703fb3482f92edcfd31661857b16fec89c2c0
- https://git.kernel.org/stable/c/703bea37d13e4ccdafd17ae7c4cb583752ba7663
- https://git.kernel.org/stable/c/c32ee78fbc670e6f90989a45d340748e34cad333
- https://git.kernel.org/stable/c/0845c553db11c84ff53fccd59da11b6d6ece4a60
- https://git.kernel.org/stable/c/4f8703fb3482f92edcfd31661857b16fec89c2c0
- https://git.kernel.org/stable/c/703bea37d13e4ccdafd17ae7c4cb583752ba7663
- https://git.kernel.org/stable/c/c32ee78fbc670e6f90989a45d340748e34cad333
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41075
In the Linux kernel, the following vulnerability has been resolved: cachefiles: add consistency check for copen/cread This prevents malicious processes from completing random copen/cread requests and crashing the system. Added checks are listed below: * Generic, copen can only complete open requests, and cread can only complete read requests. * For copen, ondemand_id must not be 0, because this indicates that the request has not been read by the daemon. * For cread, the object corresponding to fd and req should be the same.
- https://git.kernel.org/stable/c/36d845ccd7bf527110a65fe953886a176c209539
- https://git.kernel.org/stable/c/3b744884c0431b5a62c92900e64bfd0ed61e8e2a
- https://git.kernel.org/stable/c/8aaa6c5dd2940ab934d6cd296175f43dbb32b34a
- https://git.kernel.org/stable/c/a26dc49df37e996876f50a0210039b2d211fdd6f
- https://git.kernel.org/stable/c/36d845ccd7bf527110a65fe953886a176c209539
- https://git.kernel.org/stable/c/3b744884c0431b5a62c92900e64bfd0ed61e8e2a
- https://git.kernel.org/stable/c/8aaa6c5dd2940ab934d6cd296175f43dbb32b34a
- https://git.kernel.org/stable/c/a26dc49df37e996876f50a0210039b2d211fdd6f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41076
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix memory leak in nfs4_set_security_label We leak nfs_fattr and nfs4_label every time we set a security xattr.
- https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c
- https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68
- https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e
- https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c
- https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c
- https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68
- https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e
- https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41077
In the Linux kernel, the following vulnerability has been resolved: null_blk: fix validation of block size Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check. Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1]. [axboe: remove unnecessary braces and != 0 check]
- https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7
- https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e
- https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1
- https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0
- https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053
- https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3
- https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7
- https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e
- https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1
- https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0
- https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053
- https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41078
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix quota root leak after quota disable failure If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps). Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted.
- https://git.kernel.org/stable/c/5ef3961682e5310f2221bae99bcf9f5d0f4b0d51
- https://git.kernel.org/stable/c/7dd6a5b96157a21245566b21fd58276a214357ff
- https://git.kernel.org/stable/c/8a69529f22590b67bb018de9acbcf94abc8603cf
- https://git.kernel.org/stable/c/94818bdb00ef34a996a06aa63d11f591074cb757
- https://git.kernel.org/stable/c/a7e4c6a3031c74078dba7fa36239d0f4fe476c53
- https://git.kernel.org/stable/c/f88aeff5a173e8ba3133314eb4b964236ef3589d
- https://git.kernel.org/stable/c/5ef3961682e5310f2221bae99bcf9f5d0f4b0d51
- https://git.kernel.org/stable/c/7dd6a5b96157a21245566b21fd58276a214357ff
- https://git.kernel.org/stable/c/8a69529f22590b67bb018de9acbcf94abc8603cf
- https://git.kernel.org/stable/c/94818bdb00ef34a996a06aa63d11f591074cb757
- https://git.kernel.org/stable/c/a7e4c6a3031c74078dba7fa36239d0f4fe476c53
- https://git.kernel.org/stable/c/f88aeff5a173e8ba3133314eb4b964236ef3589d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41079
In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.
- https://git.kernel.org/stable/c/0990e8a863645496b9e3f91cfcfd63cd95c80319
- https://git.kernel.org/stable/c/10967873b80742261527a071954be8b54f0f8e4d
- https://git.kernel.org/stable/c/30d35b24b7957922f81cfdaa66f2e1b1e9b9aed2
- https://git.kernel.org/stable/c/cd0c1b8e045a8d2785342b385cb2684d9b48e426
- https://git.kernel.org/stable/c/0990e8a863645496b9e3f91cfcfd63cd95c80319
- https://git.kernel.org/stable/c/10967873b80742261527a071954be8b54f0f8e4d
- https://git.kernel.org/stable/c/30d35b24b7957922f81cfdaa66f2e1b1e9b9aed2
- https://git.kernel.org/stable/c/cd0c1b8e045a8d2785342b385cb2684d9b48e426
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41081
In the Linux kernel, the following vulnerability has been resolved: ila: block BH in ila_output() As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled. ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock(). We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures. Fix the race by using local_bh_disable().
- https://git.kernel.org/stable/c/522c3336c2025818fa05e9daf0ac35711e55e316
- https://git.kernel.org/stable/c/7435bd2f84a25aba607030237261b3795ba782da
- https://git.kernel.org/stable/c/96103371091c6476eb07f4c66624bdd1b42f758a
- https://git.kernel.org/stable/c/9f9c79d8e527d867e0875868b14fb76e6011e70c
- https://git.kernel.org/stable/c/a0cafb7b0b94d18e4813ee4b712a056f280e7b5a
- https://git.kernel.org/stable/c/b4eb25a3d70df925a9fa4e82d17a958a0a228f5f
- https://git.kernel.org/stable/c/cf28ff8e4c02e1ffa850755288ac954b6ff0db8c
- https://git.kernel.org/stable/c/feac2391e26b086f73be30e9b1ab215eada8d830
- https://git.kernel.org/stable/c/522c3336c2025818fa05e9daf0ac35711e55e316
- https://git.kernel.org/stable/c/7435bd2f84a25aba607030237261b3795ba782da
- https://git.kernel.org/stable/c/96103371091c6476eb07f4c66624bdd1b42f758a
- https://git.kernel.org/stable/c/9f9c79d8e527d867e0875868b14fb76e6011e70c
- https://git.kernel.org/stable/c/a0cafb7b0b94d18e4813ee4b712a056f280e7b5a
- https://git.kernel.org/stable/c/b4eb25a3d70df925a9fa4e82d17a958a0a228f5f
- https://git.kernel.org/stable/c/cf28ff8e4c02e1ffa850755288ac954b6ff0db8c
- https://git.kernel.org/stable/c/feac2391e26b086f73be30e9b1ab215eada8d830
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-41084
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Avoid null pointer dereference in region lookup cxl_dpa_to_region() looks up a region based on a memdev and DPA. It wrongly assumes an endpoint found mapping the DPA is also of a fully assembled region. When not true it leads to a null pointer dereference looking up the region name. This appears during testing of region lookup after a failure to assemble a BIOS defined region or if the lookup raced with the assembly of the BIOS defined region. Failure to clean up BIOS defined regions that fail assembly is an issue in itself and a fix to that problem will alleviate some of the impact. It will not alleviate the race condition so let's harden this path. The behavior change is that the kernel oops due to a null pointer dereference is replaced with a dev_dbg() message noting that an endpoint was mapped. Additional comments are added so that future users of this function can more clearly understand what it provides.
- https://git.kernel.org/stable/c/285f2a08841432fc3e498b1cd00cce5216cdf189
- https://git.kernel.org/stable/c/a9e099e29e925f8b31cfe53e8a786b9796f8e453
- https://git.kernel.org/stable/c/b8a40a6dbfb0150c1081384caa9bbe28ce5d5060
- https://git.kernel.org/stable/c/285f2a08841432fc3e498b1cd00cce5216cdf189
- https://git.kernel.org/stable/c/a9e099e29e925f8b31cfe53e8a786b9796f8e453
- https://git.kernel.org/stable/c/b8a40a6dbfb0150c1081384caa9bbe28ce5d5060
Modified: 2025-11-03
CVE-2024-41087
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix double free on error
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:
kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/010de9acbea58fbcbda08e3793d6262086a493fe
- https://git.kernel.org/stable/c/062e256516d7db5e7dcdef117f52025cd5c456e3
- https://git.kernel.org/stable/c/290073b2b557e4dc21ee74a1e403d9ae79e393a2
- https://git.kernel.org/stable/c/56f1c7e290cd6c69c948fcd2e2a49e6a637ec38f
- https://git.kernel.org/stable/c/5dde5f8b790274723640d29a07c5a97d57d62047
- https://git.kernel.org/stable/c/702c1edbafb2e6f9d20f6d391273b5be09d366a5
- https://git.kernel.org/stable/c/8106da4d88bbaed809e023cc8014b766223d6e76
- https://git.kernel.org/stable/c/ab9e0c529eb7cafebdd31fe1644524e80a48b05d
- https://git.kernel.org/stable/c/010de9acbea58fbcbda08e3793d6262086a493fe
- https://git.kernel.org/stable/c/062e256516d7db5e7dcdef117f52025cd5c456e3
- https://git.kernel.org/stable/c/290073b2b557e4dc21ee74a1e403d9ae79e393a2
- https://git.kernel.org/stable/c/56f1c7e290cd6c69c948fcd2e2a49e6a637ec38f
- https://git.kernel.org/stable/c/5dde5f8b790274723640d29a07c5a97d57d62047
- https://git.kernel.org/stable/c/702c1edbafb2e6f9d20f6d391273b5be09d366a5
- https://git.kernel.org/stable/c/8106da4d88bbaed809e023cc8014b766223d6e76
- https://git.kernel.org/stable/c/ab9e0c529eb7cafebdd31fe1644524e80a48b05d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41088
In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: fix infinite loop when xmit fails When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. [mkl: use more imperative wording in patch description]
- https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b
- https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729
- https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510
- https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025
- https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b
- https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729
- https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510
- https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41089
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference.
- https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50
- https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad
- https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d
- https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0
- https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194ff5c843
- https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59
- https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637
- https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51
- https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50
- https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad
- https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d
- https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0
- https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194ff5c843
- https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59
- https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637
- https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41090
In the Linux kernel, the following vulnerability has been resolved: tap: add missing verification for short frame The cited commit missed to check against the validity of the frame length in the tap_get_user_xdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tap_get_user_xdp()-->skb_set_network_header() may assume the size is more than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. In the alternative path, tap_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted. This is to drop any frame shorter than the Ethernet header size just like how tap_get_user() does. CVE: CVE-2024-41090
- https://git.kernel.org/stable/c/73d462a38d5f782b7c872fe9ae8393d9ef5483da
- https://git.kernel.org/stable/c/7431144b406ae82807eb87d8c98e518475b0450f
- https://git.kernel.org/stable/c/8be915fc5ff9a5e296f6538be12ea75a1a93bdea
- https://git.kernel.org/stable/c/aa6a5704cab861c9b2ae9f475076e1881e87f5aa
- https://git.kernel.org/stable/c/e1a786b9bbb767fd1c922d424aaa8078cc542309
- https://git.kernel.org/stable/c/e5e5e63c506b93b89b01f522b6a7343585f784e6
- https://git.kernel.org/stable/c/ed7f2afdd0e043a397677e597ced0830b83ba0b3
- https://git.kernel.org/stable/c/ee93e6da30377cf2a75e16cd32bb9fcd86a61c46
- https://git.kernel.org/stable/c/73d462a38d5f782b7c872fe9ae8393d9ef5483da
- https://git.kernel.org/stable/c/7431144b406ae82807eb87d8c98e518475b0450f
- https://git.kernel.org/stable/c/8be915fc5ff9a5e296f6538be12ea75a1a93bdea
- https://git.kernel.org/stable/c/aa6a5704cab861c9b2ae9f475076e1881e87f5aa
- https://git.kernel.org/stable/c/e1a786b9bbb767fd1c922d424aaa8078cc542309
- https://git.kernel.org/stable/c/e5e5e63c506b93b89b01f522b6a7343585f784e6
- https://git.kernel.org/stable/c/ed7f2afdd0e043a397677e597ced0830b83ba0b3
- https://git.kernel.org/stable/c/ee93e6da30377cf2a75e16cd32bb9fcd86a61c46
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41091
In the Linux kernel, the following vulnerability has been resolved: tun: add missing verification for short frame The cited commit missed to check against the validity of the frame length in the tun_xdp_one() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tun_xdp_one-->eth_type_trans() may access the Ethernet header although it can be less than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. In the alternative path, tun_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted for IFF_TAP. This is to drop any frame shorter than the Ethernet header size just like how tun_get_user() does. CVE: CVE-2024-41091
- https://git.kernel.org/stable/c/049584807f1d797fc3078b68035450a9769eb5c3
- https://git.kernel.org/stable/c/32b0aaba5dbc85816898167d9b5d45a22eae82e9
- https://git.kernel.org/stable/c/589382f50b4a5d90d16d8bc9dcbc0e927a3e39b2
- https://git.kernel.org/stable/c/6100e0237204890269e3f934acfc50d35fd6f319
- https://git.kernel.org/stable/c/8418f55302fa1d2eeb73e16e345167e545c598a5
- https://git.kernel.org/stable/c/a9d1c27e2ee3b0ea5d40c105d6e728fc114470bb
- https://git.kernel.org/stable/c/ad6b3f622ccfb4bfedfa53b6ebd91c3d1d04f146
- https://git.kernel.org/stable/c/d5ad89b7d01ed4e66fd04734fc63d6e78536692a
- https://git.kernel.org/stable/c/049584807f1d797fc3078b68035450a9769eb5c3
- https://git.kernel.org/stable/c/32b0aaba5dbc85816898167d9b5d45a22eae82e9
- https://git.kernel.org/stable/c/589382f50b4a5d90d16d8bc9dcbc0e927a3e39b2
- https://git.kernel.org/stable/c/6100e0237204890269e3f934acfc50d35fd6f319
- https://git.kernel.org/stable/c/8418f55302fa1d2eeb73e16e345167e545c598a5
- https://git.kernel.org/stable/c/a9d1c27e2ee3b0ea5d40c105d6e728fc114470bb
- https://git.kernel.org/stable/c/ad6b3f622ccfb4bfedfa53b6ebd91c3d1d04f146
- https://git.kernel.org/stable/c/d5ad89b7d01ed4e66fd04734fc63d6e78536692a
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41092
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix potential UAF by revoke of fence registers
CI has been sporadically reporting the following issue triggered by
igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
...
<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
<3> [414.070354] Unable to pin Y-tiled fence; err:-4
<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
...
<4>[ 609.603992] ------------[ cut here ]------------
<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]
<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
...
<4>[ 609.604271] Call Trace:
<4>[ 609.604273]
- https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7
- https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d
- https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc
- https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50
- https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6
- https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535
- https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7
- https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d
- https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc
- https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50
- https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6
- https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41093
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer.
- https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800
- https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447
- https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc
- https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb
- https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46
- https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800
- https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447
- https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc
- https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb
- https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-41094
In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only set smem_start is enable per module option Only export struct fb_info.fix.smem_start if that is required by the user and the memory does not come from vmalloc(). Setting struct fb_info.fix.smem_start breaks systems where DMA memory is backed by vmalloc address space. An example error is shown below. [ 3.536043] ------------[ cut here ]------------ [ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000) [ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98 [ 3.565455] Modules linked in: [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250 [ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT) [ 3.582452] Workqueue: events_unbound deferred_probe_work_func [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.595233] pc : __virt_to_phys+0x68/0x98 [ 3.599246] lr : __virt_to_phys+0x68/0x98 [ 3.603276] sp : ffff800083603990 [ 3.677939] Call trace: [ 3.680393] __virt_to_phys+0x68/0x98 [ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238 [ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0 [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68 [ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0 [ 3.705161] drm_client_register+0x60/0xb0 [ 3.709269] drm_fbdev_dma_setup+0x94/0x148 Additionally, DMA memory is assumed to by contiguous in physical address space, which is not guaranteed by vmalloc(). Resolve this by checking the module flag drm_leak_fbdev_smem when DRM allocated the instance of struct fb_info. Fbdev-dma then only sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also guarantee that the framebuffer is not located in vmalloc address space.
- https://git.kernel.org/stable/c/00702cfa8432ac67a72f56de5e1d278ddea2ebde
- https://git.kernel.org/stable/c/d92a7580392ad4681b1d4f9275d00b95375ebe01
- https://git.kernel.org/stable/c/f29fcfbf6067c0d8c83f84a045da9276c08deac5
- https://git.kernel.org/stable/c/00702cfa8432ac67a72f56de5e1d278ddea2ebde
- https://git.kernel.org/stable/c/d92a7580392ad4681b1d4f9275d00b95375ebe01
- https://git.kernel.org/stable/c/f29fcfbf6067c0d8c83f84a045da9276c08deac5
Modified: 2025-11-03
CVE-2024-41095
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
- https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49
- https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389
- https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b0916b3726
- https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e
- https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714
- https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72
- https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb
- https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8
- https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49
- https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389
- https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b0916b3726
- https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e
- https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714
- https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72
- https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb
- https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-03-24
CVE-2024-41096
In the Linux kernel, the following vulnerability has been resolved: PCI/MSI: Fix UAF in msi_capability_init KFENCE reports the following UAF: BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488 Use-after-free read at 0x0000000024629571 (in kfence-#12): __pci_enable_msi_range+0x2c0/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128 allocated by task 81 on cpu 7 at 10.808142s: __kmem_cache_alloc_node+0x1f0/0x2bc kmalloc_trace+0x44/0x138 msi_alloc_desc+0x3c/0x9c msi_domain_insert_msi_desc+0x30/0x78 msi_setup_msi_desc+0x13c/0x184 __pci_enable_msi_range+0x258/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 freed by task 81 on cpu 7 at 10.811436s: msi_domain_free_descs+0xd4/0x10c msi_domain_free_locked.part.0+0xc0/0x1d8 msi_domain_alloc_irqs_all_locked+0xb4/0xbc pci_msi_setup_msi_irqs+0x30/0x4c __pci_enable_msi_range+0x2a8/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 Descriptor allocation done in: __pci_enable_msi_range msi_capability_init msi_setup_msi_desc msi_insert_msi_desc msi_domain_insert_msi_desc msi_alloc_desc ... Freed in case of failure in __msi_domain_alloc_locked() __pci_enable_msi_range msi_capability_init pci_msi_setup_msi_irqs msi_domain_alloc_irqs_all_locked msi_domain_alloc_locked __msi_domain_alloc_locked => fails msi_domain_free_locked ... That failure propagates back to pci_msi_setup_msi_irqs() in msi_capability_init() which accesses the descriptor for unmasking in the error exit path. Cure it by copying the descriptor and using the copy for the error exit path unmask operation. [ tglx: Massaged change log ]
- https://git.kernel.org/stable/c/0ae40b2d0a5de6b045504098e365d4fdff5bbeba
- https://git.kernel.org/stable/c/45fc8d20e0768ab0a0ad054081d0f68aa3c83976
- https://git.kernel.org/stable/c/9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1
- https://git.kernel.org/stable/c/ff1121d2214b794dc1772081f27bdd90721a84bc
- https://git.kernel.org/stable/c/45fc8d20e0768ab0a0ad054081d0f68aa3c83976
- https://git.kernel.org/stable/c/9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1
- https://git.kernel.org/stable/c/ff1121d2214b794dc1772081f27bdd90721a84bc
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41097
In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix endpoint checking in cxacru_bind() Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
- https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a
- https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47
- https://git.kernel.org/stable/c/2eabb655a968b862bc0c31629a09f0fbf3c80d51
- https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a
- https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727
- https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506
- https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b9109007bc781
- https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4
- https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a
- https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47
- https://git.kernel.org/stable/c/2eabb655a968b862bc0c31629a09f0fbf3c80d51
- https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a
- https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727
- https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506
- https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b9109007bc781
- https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41098
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix null pointer dereference on error
If the ata_port_alloc() call in ata_host_alloc() fails,
ata_host_release() will get called.
However, the code in ata_host_release() tries to free ata_port struct
members unconditionally, which can lead to the following:
BUG: unable to handle page fault for address: 0000000000003990
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/0f0d37c154bb108730c90a91aa31e3170e827962
- https://git.kernel.org/stable/c/119c97ace2a9ffcf4dc09a23bb057d6c281aff28
- https://git.kernel.org/stable/c/221e3b1297e74fdec32d0f572f4dcb2260a0a2af
- https://git.kernel.org/stable/c/56e62977eaaae3eb7122ee2cf9b720b6703114a9
- https://git.kernel.org/stable/c/5d92c7c566dc76d96e0e19e481d926bbe6631c1e
- https://git.kernel.org/stable/c/8a8ff7e3b736a70d7b7c8764cbcd2724d4079ec8
- https://git.kernel.org/stable/c/d9c4df80b1b009de1eb77c07e3bb4d45bd212aa5
- https://git.kernel.org/stable/c/e83405e75d90694ee6a5d898f7f0473ac2686054
- https://git.kernel.org/stable/c/119c97ace2a9ffcf4dc09a23bb057d6c281aff28
- https://git.kernel.org/stable/c/5d92c7c566dc76d96e0e19e481d926bbe6631c1e
- https://git.kernel.org/stable/c/8a8ff7e3b736a70d7b7c8764cbcd2724d4079ec8
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42063
In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode syzbot reported uninit memory usages during map_{lookup,delete}_elem. ========== BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline] bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237 ========== The reproducer should be in the interpreter mode. The C reproducer is trying to run the following bpf prog: 0: (18) r0 = 0x0 2: (18) r1 = map[id:49] 4: (b7) r8 = 16777216 5: (7b) *(u64 *)(r10 -8) = r8 6: (bf) r2 = r10 7: (07) r2 += -229 ^^^^^^^^^^ 8: (b7) r3 = 8 9: (b7) r4 = 0 10: (85) call dev_map_lookup_elem#1543472 11: (95) exit It is due to the "void *key" (r2) passed to the helper. bpf allows uninit stack memory access for bpf prog with the right privileges. This patch uses kmsan_unpoison_memory() to mark the stack as initialized. This should address different syzbot reports on the uninit "void *key" argument during map_{lookup,delete}_elem.
- https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12
- https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5
- https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf
- https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979
- https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12
- https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5
- https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf
- https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-01-24
CVE-2024-42067
In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out when bpf_jit_binary_lock_ro() returns an error.
- https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a
- https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5
- https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a
- https://git.kernel.org/stable/c/08f6c05feb1db21653e98ca84ea04ca032d014c7
- https://git.kernel.org/stable/c/9fef36cad60d4226f9d06953cd56d1d2f9119730
- https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5
Modified: 2025-11-03
CVE-2024-42068
In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() set_memory_ro() can fail, leaving memory unprotected. Check its return and take it into account as an error.
- https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a
- https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8
- https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03
- https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720
- https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a
- https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8
- https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03
- https://git.kernel.org/stable/c/e3540e5a7054d6daaf9a1415a48aacb092112a89
- https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720
- https://git.kernel.org/stable/c/fdd411af8178edc6b7bf260f8fa4fba1bedd0a6d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42069
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix possible double free in error handling path When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function adev_release calls kfree(madev). We shouldn't call kfree(madev) again in the error handling path. Set 'madev' to NULL.
- https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc
- https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a
- https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4
- https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc
- https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a
- https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4
- https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html
Modified: 2025-11-03
CVE-2024-42070
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.
- https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4
- https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f
- https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa1c2980f
- https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8
- https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf
- https://git.kernel.org/stable/c/7931d32955e09d0a11b1fe0b6aac1bfa061c005c
- https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564
- https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007
- https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4
- https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f
- https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa1c2980f
- https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8
- https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf
- https://git.kernel.org/stable/c/7931d32955e09d0a11b1fe0b6aac1bfa061c005c
- https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564
- https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42073
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems
The following two shared buffer operations make use of the Shared Buffer
Status Register (SBSR):
# devlink sb occupancy snapshot pci/0000:01:00.0
# devlink sb occupancy clearmax pci/0000:01:00.0
The register has two masks of 256 bits to denote on which ingress /
egress ports the register should operate on. Spectrum-4 has more than
256 ports, so the register was extended by cited commit with a new
'port_page' field.
However, when filling the register's payload, the driver specifies the
ports as absolute numbers and not relative to the first port of the port
page, resulting in memory corruptions [1].
Fix by specifying the ports relative to the first port of the port page.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0
Read of size 1 at addr ffff8881068cb00f by task devlink/1566
[...]
Call Trace:
- https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36
- https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a
- https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e
- https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13
- https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36
- https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a
- https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e
- https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-42074
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp: add a null check for chip_pdev structure When acp platform device creation is skipped, chip->chip_pdev value will remain NULL. Add NULL check for chip->chip_pdev structure in snd_acp_resume() function to avoid null pointer dereference.
- https://git.kernel.org/stable/c/98d919dfee1cc402ca29d45da642852d7c9a2301
- https://git.kernel.org/stable/c/b0c39ae1cc86afe74aa2f6273ccb514f8d180cf6
- https://git.kernel.org/stable/c/e158ed266fc1adfa456880fb6dabce2e5623843b
- https://git.kernel.org/stable/c/98d919dfee1cc402ca29d45da642852d7c9a2301
- https://git.kernel.org/stable/c/b0c39ae1cc86afe74aa2f6273ccb514f8d180cf6
- https://git.kernel.org/stable/c/e158ed266fc1adfa456880fb6dabce2e5623843b
Modified: 2025-11-03
CVE-2024-42076
In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: Initialize unused data in j1939_send_one() syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one() creates full frame including unused data, but it doesn't initialize it. This causes the kernel-infoleak issue. Fix this by initializing unused data. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] memcpy_to_msg include/linux/skbuff.h:4113 [inline] raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803 ___sys_recvmsg+0x223/0x840 net/socket.c:2845 do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1313 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 sock_alloc_send_skb include/net/sock.h:1842 [inline] j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at ffff888120969690 Data copied to user address 00000000200017c0 CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
- https://git.kernel.org/stable/c/4c5dc3927e17489c1cae6f48c0d5e4acb4cae01f
- https://git.kernel.org/stable/c/5e4ed38eb17eaca42de57d500cc0f9668d2b6abf
- https://git.kernel.org/stable/c/a2a0ebff7fdeb2f66e29335adf64b9e457300dd4
- https://git.kernel.org/stable/c/ab2a683938ba4416d389c2f5651cbbb2c41b779f
- https://git.kernel.org/stable/c/b7cdf1dd5d2a2d8200efd98d1893684db48fe134
- https://git.kernel.org/stable/c/ba7e5ae8208ac07d8e1eace0951a34c169a2d298
- https://git.kernel.org/stable/c/f97cbce633923588307049c4aef9feb2987e371b
- https://git.kernel.org/stable/c/4c5dc3927e17489c1cae6f48c0d5e4acb4cae01f
- https://git.kernel.org/stable/c/5e4ed38eb17eaca42de57d500cc0f9668d2b6abf
- https://git.kernel.org/stable/c/a2a0ebff7fdeb2f66e29335adf64b9e457300dd4
- https://git.kernel.org/stable/c/ab2a683938ba4416d389c2f5651cbbb2c41b779f
- https://git.kernel.org/stable/c/b7cdf1dd5d2a2d8200efd98d1893684db48fe134
- https://git.kernel.org/stable/c/ba7e5ae8208ac07d8e1eace0951a34c169a2d298
- https://git.kernel.org/stable/c/f97cbce633923588307049c4aef9feb2987e371b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42077
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix DIO failure due to insufficient transaction credits The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba
- https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a
- https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6
- https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4
- https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687
- https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36
- https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111
- https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a
- https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6
- https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4
- https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687
- https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36
- https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-03-17
CVE-2024-42079
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix NULL pointer dereference in gfs2_log_flush In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush lock to provide exclusion against gfs2_log_flush(). In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before dereferencing it. Otherwise, we could run into a NULL pointer dereference when outstanding glock work races with an unmount (glock_work_func -> run_queue -> do_xmote -> inode_go_sync -> gfs2_log_flush).
- https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce
- https://git.kernel.org/stable/c/35264909e9d1973ab9aaa2a1b07cda70f12bb828
- https://git.kernel.org/stable/c/5f6a84cfb33b34610623857bd93919dcb661e29b
- https://git.kernel.org/stable/c/c3c5cfa3170c0940bc66a142859caac07d19b9d6
- https://git.kernel.org/stable/c/f54f9d5368a4e92ede7dd078a62788dae3a7c6ef
- https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce
- https://git.kernel.org/stable/c/35264909e9d1973ab9aaa2a1b07cda70f12bb828
- https://git.kernel.org/stable/c/f54f9d5368a4e92ede7dd078a62788dae3a7c6ef
Modified: 2025-11-03
CVE-2024-42080
In the Linux kernel, the following vulnerability has been resolved: RDMA/restrack: Fix potential invalid address access struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry. These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them.
- https://git.kernel.org/stable/c/782bdaf9d01658281bc813f3f873e6258aa1fd8d
- https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5
- https://git.kernel.org/stable/c/8ac281d42337f36cf7061cf1ea094181b84bc1a9
- https://git.kernel.org/stable/c/ca537a34775c103f7b14d7bbd976403f1d1525d8
- https://git.kernel.org/stable/c/f45b43d17240e9ca67ebf3cc82bb046b07cc1c61
- https://git.kernel.org/stable/c/782bdaf9d01658281bc813f3f873e6258aa1fd8d
- https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5
- https://git.kernel.org/stable/c/8ac281d42337f36cf7061cf1ea094181b84bc1a9
- https://git.kernel.org/stable/c/ca537a34775c103f7b14d7bbd976403f1d1525d8
- https://git.kernel.org/stable/c/f45b43d17240e9ca67ebf3cc82bb046b07cc1c61
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42082
In the Linux kernel, the following vulnerability has been resolved: xdp: Remove WARN() from __xdp_reg_mem_model() syzkaller reports a warning in __xdp_reg_mem_model(). The warning occurs only if __mem_id_init_hash_table() returns an error. It returns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly. The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation. Thus, there is no sense in using WARN() to handle this error and it can be safely removed. WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Found by Linux Verification Center (linuxtesting.org) with syzkaller.
- https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0
- https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c
- https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54
- https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2
- https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4
- https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4
- https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0
- https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c
- https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54
- https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2
- https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4
- https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42084
In the Linux kernel, the following vulnerability has been resolved: ftruncate: pass a signed offset The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB. Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL. The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake.
- https://git.kernel.org/stable/c/4b8e88e563b5f666446d002ad0dc1e6e8e7102b0
- https://git.kernel.org/stable/c/5ae6af68410bdad6181ec82104bb9985a7a6a0fa
- https://git.kernel.org/stable/c/836359247b0403e0634bfbc83e5bb8063fad287a
- https://git.kernel.org/stable/c/84bf6b64a1a0dfc6de7e1b1c776d58d608e7865a
- https://git.kernel.org/stable/c/930a4c369f74da26816eaaa71b5888d29b759c27
- https://git.kernel.org/stable/c/c329760749b5419769e57cb2be80955d2805f9c9
- https://git.kernel.org/stable/c/dbb226d81cd02cee140139c2369791e6f61f2007
- https://git.kernel.org/stable/c/f531d4bc6c5588d713359e42ed65e46816d841d8
- https://git.kernel.org/stable/c/4b8e88e563b5f666446d002ad0dc1e6e8e7102b0
- https://git.kernel.org/stable/c/5ae6af68410bdad6181ec82104bb9985a7a6a0fa
- https://git.kernel.org/stable/c/836359247b0403e0634bfbc83e5bb8063fad287a
- https://git.kernel.org/stable/c/84bf6b64a1a0dfc6de7e1b1c776d58d608e7865a
- https://git.kernel.org/stable/c/930a4c369f74da26816eaaa71b5888d29b759c27
- https://git.kernel.org/stable/c/c329760749b5419769e57cb2be80955d2805f9c9
- https://git.kernel.org/stable/c/dbb226d81cd02cee140139c2369791e6f61f2007
- https://git.kernel.org/stable/c/f531d4bc6c5588d713359e42ed65e46816d841d8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42085
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume.
- https://git.kernel.org/stable/c/17e2956633ca560b95f1cbbb297cfc2adf650649
- https://git.kernel.org/stable/c/7026576e89094aa9a0062aa6d10cba18aa99944c
- https://git.kernel.org/stable/c/7838de15bb700c2898a7d741db9b1f3cbc86c136
- https://git.kernel.org/stable/c/8731a0b180f6b5d52397c7aeea6eda9511a467a7
- https://git.kernel.org/stable/c/d77e2b5104c51d3668b9717c825a4a06998efe63
- https://git.kernel.org/stable/c/f1274cfab183e69a7c7bafffcb4f50703c876276
- https://git.kernel.org/stable/c/17e2956633ca560b95f1cbbb297cfc2adf650649
- https://git.kernel.org/stable/c/7026576e89094aa9a0062aa6d10cba18aa99944c
- https://git.kernel.org/stable/c/7838de15bb700c2898a7d741db9b1f3cbc86c136
- https://git.kernel.org/stable/c/d77e2b5104c51d3668b9717c825a4a06998efe63
- https://git.kernel.org/stable/c/f1274cfab183e69a7c7bafffcb4f50703c876276
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42086
In the Linux kernel, the following vulnerability has been resolved: iio: chemical: bme680: Fix overflows in compensate() functions There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor"). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/
- https://git.kernel.org/stable/c/3add41bbda92938e9a528d74659dfc552796be4e
- https://git.kernel.org/stable/c/6fa31bbe2ea8665ee970258eb8320cbf231dbe9e
- https://git.kernel.org/stable/c/7a13d1357658d3a3c1cd7b3b9543c805a6e5e6e9
- https://git.kernel.org/stable/c/b0af334616ed425024bf220adda0f004806b5feb
- https://git.kernel.org/stable/c/b5967393d50e3c6e632efda3ea3fdde14c1bfd0e
- https://git.kernel.org/stable/c/ba1bb3e2a38a7fef1c1818dd4f2d9abbfdde553a
- https://git.kernel.org/stable/c/c326551e99f5416986074ce78bef94f6a404b517
- https://git.kernel.org/stable/c/fdd478c3ae98c3f13628e110dce9b6cfb0d9b3c8
- https://git.kernel.org/stable/c/3add41bbda92938e9a528d74659dfc552796be4e
- https://git.kernel.org/stable/c/6fa31bbe2ea8665ee970258eb8320cbf231dbe9e
- https://git.kernel.org/stable/c/7a13d1357658d3a3c1cd7b3b9543c805a6e5e6e9
- https://git.kernel.org/stable/c/b0af334616ed425024bf220adda0f004806b5feb
- https://git.kernel.org/stable/c/b5967393d50e3c6e632efda3ea3fdde14c1bfd0e
- https://git.kernel.org/stable/c/ba1bb3e2a38a7fef1c1818dd4f2d9abbfdde553a
- https://git.kernel.org/stable/c/c326551e99f5416986074ce78bef94f6a404b517
- https://git.kernel.org/stable/c/fdd478c3ae98c3f13628e110dce9b6cfb0d9b3c8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42087
In the Linux kernel, the following vulnerability has been resolved: drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue.
- https://git.kernel.org/stable/c/1618f7a875ffd916596392fd29880c0429b8af60
- https://git.kernel.org/stable/c/489f38de3375ab84b3d269d0a1d64d6ee95d7044
- https://git.kernel.org/stable/c/5f41401219fbe7663b3cf65ebd4ed95ebbb8ffb9
- https://git.kernel.org/stable/c/98686ec1824728ff41d7b358131f7d0227c2ba2a
- https://git.kernel.org/stable/c/b71348be1236398be2d04c5e145fd6eaae86a91b
- https://git.kernel.org/stable/c/cae52f61fda0f5d2949dc177f984c9e187d4c6a0
- https://git.kernel.org/stable/c/e646402bf82145349fcf5dcbe395afaf02a8ce47
- https://git.kernel.org/stable/c/ee7860cd8b5763017f8dc785c2851fecb7a0c565
- https://git.kernel.org/stable/c/1618f7a875ffd916596392fd29880c0429b8af60
- https://git.kernel.org/stable/c/489f38de3375ab84b3d269d0a1d64d6ee95d7044
- https://git.kernel.org/stable/c/5f41401219fbe7663b3cf65ebd4ed95ebbb8ffb9
- https://git.kernel.org/stable/c/98686ec1824728ff41d7b358131f7d0227c2ba2a
- https://git.kernel.org/stable/c/b71348be1236398be2d04c5e145fd6eaae86a91b
- https://git.kernel.org/stable/c/cae52f61fda0f5d2949dc177f984c9e187d4c6a0
- https://git.kernel.org/stable/c/e646402bf82145349fcf5dcbe395afaf02a8ce47
- https://git.kernel.org/stable/c/ee7860cd8b5763017f8dc785c2851fecb7a0c565
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42089
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations.
- https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed
- https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9
- https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a
- https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce165c4ea6
- https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a
- https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac
- https://git.kernel.org/stable/c/90f3feb24172185f1832636264943e8b5e289245
- https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a
- https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed
- https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9
- https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a
- https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce165c4ea6
- https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a
- https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac
- https://git.kernel.org/stable/c/90f3feb24172185f1832636264943e8b5e289245
- https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42090
In the Linux kernel, the following vulnerability has been resolved: pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.
- https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e
- https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc
- https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0
- https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e926179ddd
- https://git.kernel.org/stable/c/adec57ff8e66aee632f3dd1f93787c13d112b7a1
- https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6
- https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b
- https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04
- https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e
- https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc
- https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0
- https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e926179ddd
- https://git.kernel.org/stable/c/adec57ff8e66aee632f3dd1f93787c13d112b7a1
- https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6
- https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b
- https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42092
In the Linux kernel, the following vulnerability has been resolved: gpio: davinci: Validate the obtained number of IRQs Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/2d83492259ad746b655f196cd5d1be4b3d0a3782
- https://git.kernel.org/stable/c/70b48899f3f23f98a52c5b1060aefbdc7ba7957b
- https://git.kernel.org/stable/c/7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164
- https://git.kernel.org/stable/c/89d7008af4945808677662a630643b5ea89c6e8d
- https://git.kernel.org/stable/c/a8d78984fdc105bc1a38b73e98d32b1bc4222684
- https://git.kernel.org/stable/c/c542e51306d5f1eba3af84daa005826223382470
- https://git.kernel.org/stable/c/cd75721984337c38a12aeca33ba301d31ca4b3fd
- https://git.kernel.org/stable/c/e44a83bf15c4db053ac6dfe96a23af184c9136d9
- https://git.kernel.org/stable/c/2d83492259ad746b655f196cd5d1be4b3d0a3782
- https://git.kernel.org/stable/c/70b48899f3f23f98a52c5b1060aefbdc7ba7957b
- https://git.kernel.org/stable/c/7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164
- https://git.kernel.org/stable/c/89d7008af4945808677662a630643b5ea89c6e8d
- https://git.kernel.org/stable/c/a8d78984fdc105bc1a38b73e98d32b1bc4222684
- https://git.kernel.org/stable/c/c542e51306d5f1eba3af84daa005826223382470
- https://git.kernel.org/stable/c/cd75721984337c38a12aeca33ba301d31ca4b3fd
- https://git.kernel.org/stable/c/e44a83bf15c4db053ac6dfe96a23af184c9136d9
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42093
In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.
- https://git.kernel.org/stable/c/48147337d7efdea6ad6e49f5b8eb894b95868ef0
- https://git.kernel.org/stable/c/5e4f25091e6d06e99a23f724c839a58a8776a527
- https://git.kernel.org/stable/c/69f49527aea12c23b78fb3d0a421950bf44fb4e2
- https://git.kernel.org/stable/c/763896ab62a672d728f5eb10ac90d98c607a8509
- https://git.kernel.org/stable/c/a55afc0f5f20ba30970aaf7271929dc00eee5e7d
- https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1
- https://git.kernel.org/stable/c/d33fe1714a44ff540629b149d8fab4ac6967585c
- https://git.kernel.org/stable/c/48147337d7efdea6ad6e49f5b8eb894b95868ef0
- https://git.kernel.org/stable/c/5e4f25091e6d06e99a23f724c839a58a8776a527
- https://git.kernel.org/stable/c/69f49527aea12c23b78fb3d0a421950bf44fb4e2
- https://git.kernel.org/stable/c/763896ab62a672d728f5eb10ac90d98c607a8509
- https://git.kernel.org/stable/c/a55afc0f5f20ba30970aaf7271929dc00eee5e7d
- https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1
- https://git.kernel.org/stable/c/d33fe1714a44ff540629b149d8fab4ac6967585c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42094
In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.
- https://git.kernel.org/stable/c/0af718a690acc089aa1bbb95a93df833d864ef53
- https://git.kernel.org/stable/c/2b085521be5292016097b5e7ca81b26be3f7098d
- https://git.kernel.org/stable/c/2d090c7f7be3b26fcb80ac04d08a4a8062b1d959
- https://git.kernel.org/stable/c/724e7965af054079242b8d6f7e50ee226730a756
- https://git.kernel.org/stable/c/842afb47d84536fc976fece8fb6c54bea711ad1a
- https://git.kernel.org/stable/c/9dadab0db7d904413ea1cdaa13f127da05c31e71
- https://git.kernel.org/stable/c/be4e1304419c99a164b4c0e101c7c2a756b635b9
- https://git.kernel.org/stable/c/d85ca8179a54ff8cf1e1f8c3c9e3799831319bae
- https://git.kernel.org/stable/c/0af718a690acc089aa1bbb95a93df833d864ef53
- https://git.kernel.org/stable/c/2b085521be5292016097b5e7ca81b26be3f7098d
- https://git.kernel.org/stable/c/2d090c7f7be3b26fcb80ac04d08a4a8062b1d959
- https://git.kernel.org/stable/c/724e7965af054079242b8d6f7e50ee226730a756
- https://git.kernel.org/stable/c/842afb47d84536fc976fece8fb6c54bea711ad1a
- https://git.kernel.org/stable/c/9dadab0db7d904413ea1cdaa13f127da05c31e71
- https://git.kernel.org/stable/c/be4e1304419c99a164b4c0e101c7c2a756b635b9
- https://git.kernel.org/stable/c/d85ca8179a54ff8cf1e1f8c3c9e3799831319bae
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42095
In the Linux kernel, the following vulnerability has been resolved: serial: 8250_omap: Implementation of Errata i2310 As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution. [0] https://www.ti.com/lit/pdf/sprz536 page 23
- https://git.kernel.org/stable/c/6270051f656004ca5cde644c73cb1fa4d718792e
- https://git.kernel.org/stable/c/87257a28271c828a98f762bf2dd803c1793d2b5b
- https://git.kernel.org/stable/c/98840e410d53329f5331ecdce095e740791963d0
- https://git.kernel.org/stable/c/9d141c1e615795eeb93cd35501ad144ee997a826
- https://git.kernel.org/stable/c/cb879300669881970eabebe64bd509dbbe42b9de
- https://git.kernel.org/stable/c/e67d7f38008e56fb691b6a72cadf16c107c2f48b
- https://git.kernel.org/stable/c/6270051f656004ca5cde644c73cb1fa4d718792e
- https://git.kernel.org/stable/c/87257a28271c828a98f762bf2dd803c1793d2b5b
- https://git.kernel.org/stable/c/98840e410d53329f5331ecdce095e740791963d0
- https://git.kernel.org/stable/c/9d141c1e615795eeb93cd35501ad144ee997a826
- https://git.kernel.org/stable/c/cb879300669881970eabebe64bd509dbbe42b9de
- https://git.kernel.org/stable/c/e67d7f38008e56fb691b6a72cadf16c107c2f48b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42096
In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF. which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addresses but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame. It causes KASAN unhappiness reported for years by syzkaller [1] and others [2]. With no real practical reason for this any more, just remove the code. Just for historical interest, here's some background commits relating to this code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64") and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc") but the basics of this thing actually goes back to before the git tree.
- https://git.kernel.org/stable/c/093d9603b60093a9aaae942db56107f6432a5dca
- https://git.kernel.org/stable/c/161cef818545ecf980f0e2ebaf8ba7326ce53c2b
- https://git.kernel.org/stable/c/16222beb9f8e5ceb0beeb5cbe54bef16df501a92
- https://git.kernel.org/stable/c/27c3be840911b15a3f24ed623f86153c825b6b29
- https://git.kernel.org/stable/c/2d07fea561d64357fb7b3f3751e653bf20306d77
- https://git.kernel.org/stable/c/49c09ca35a5f521d7fa18caf62fdf378f15e8aa4
- https://git.kernel.org/stable/c/65ebdde16e7f5da99dbf8a548fb635837d78384e
- https://git.kernel.org/stable/c/a3b65c8cbc139bfce9541bc81c1bb766e5ba3f68
- https://git.kernel.org/stable/c/093d9603b60093a9aaae942db56107f6432a5dca
- https://git.kernel.org/stable/c/161cef818545ecf980f0e2ebaf8ba7326ce53c2b
- https://git.kernel.org/stable/c/16222beb9f8e5ceb0beeb5cbe54bef16df501a92
- https://git.kernel.org/stable/c/27c3be840911b15a3f24ed623f86153c825b6b29
- https://git.kernel.org/stable/c/2d07fea561d64357fb7b3f3751e653bf20306d77
- https://git.kernel.org/stable/c/49c09ca35a5f521d7fa18caf62fdf378f15e8aa4
- https://git.kernel.org/stable/c/65ebdde16e7f5da99dbf8a548fb635837d78384e
- https://git.kernel.org/stable/c/a3b65c8cbc139bfce9541bc81c1bb766e5ba3f68
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42097
In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did.
- https://git.kernel.org/stable/c/40d7def67841343c10f8642a41031fecbb248bab
- https://git.kernel.org/stable/c/79d9a000f0220cdaba1682d2a23c0d0c61d620a3
- https://git.kernel.org/stable/c/7a18293fd8d8519c2f7a03753bc1583b18e3db69
- https://git.kernel.org/stable/c/87039b83fb7bfd7d0e0499aaa8e6c049906b4d14
- https://git.kernel.org/stable/c/89b32ccb12ae67e630c6453d778ec30a592a212f
- https://git.kernel.org/stable/c/d0ff2443fcbb472206d45a5d2a90cc694065804e
- https://git.kernel.org/stable/c/d23982ea9aa438f35a8c8a6305943e98a8db90f6
- https://git.kernel.org/stable/c/d8f5ce3cb9adf0c72e2ad6089aba02d7a32469c2
- https://git.kernel.org/stable/c/40d7def67841343c10f8642a41031fecbb248bab
- https://git.kernel.org/stable/c/79d9a000f0220cdaba1682d2a23c0d0c61d620a3
- https://git.kernel.org/stable/c/7a18293fd8d8519c2f7a03753bc1583b18e3db69
- https://git.kernel.org/stable/c/87039b83fb7bfd7d0e0499aaa8e6c049906b4d14
- https://git.kernel.org/stable/c/89b32ccb12ae67e630c6453d778ec30a592a212f
- https://git.kernel.org/stable/c/d0ff2443fcbb472206d45a5d2a90cc694065804e
- https://git.kernel.org/stable/c/d23982ea9aa438f35a8c8a6305943e98a8db90f6
- https://git.kernel.org/stable/c/d8f5ce3cb9adf0c72e2ad6089aba02d7a32469c2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42098
In the Linux kernel, the following vulnerability has been resolved: crypto: ecdh - explicitly zeroize private_key private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first. Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails.
- https://git.kernel.org/stable/c/39173b04abda87872b43c331468a4a14f8f05ce8
- https://git.kernel.org/stable/c/73e5984e540a76a2ee1868b91590c922da8c24c9
- https://git.kernel.org/stable/c/80575b252ab0358b7e93895b2a510beb3cb3f975
- https://git.kernel.org/stable/c/d96187eb8e59b572a8e6a68b6a9837a867ea29df
- https://git.kernel.org/stable/c/fd7ef325911eba1b7191b83cb580463242f2090d
- https://git.kernel.org/stable/c/39173b04abda87872b43c331468a4a14f8f05ce8
- https://git.kernel.org/stable/c/73e5984e540a76a2ee1868b91590c922da8c24c9
- https://git.kernel.org/stable/c/80575b252ab0358b7e93895b2a510beb3cb3f975
- https://git.kernel.org/stable/c/d96187eb8e59b572a8e6a68b6a9837a867ea29df
- https://git.kernel.org/stable/c/fd7ef325911eba1b7191b83cb580463242f2090d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42101
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
- https://git.kernel.org/stable/c/1f32535238493008587a8c5cb17eb2ca097592ef
- https://git.kernel.org/stable/c/274cba8d2d1b48c72d8bd90e76c9e2dc1aa0a81d
- https://git.kernel.org/stable/c/744b229f09134ccd091427a6f9ea6d97302cfdd9
- https://git.kernel.org/stable/c/7db5411c5d0bd9c29b8c2ad93c36b5c16ea46c9e
- https://git.kernel.org/stable/c/80bec6825b19d95ccdfd3393cf8ec15ff2a749b4
- https://git.kernel.org/stable/c/9baf60323efa992b7c915094529f0a1882c34e7e
- https://git.kernel.org/stable/c/e36364f5f3785d054a94e57e971385284886d41a
- https://git.kernel.org/stable/c/f48dd3f19614022f2e1b794fbd169d2b4c398c07
- https://git.kernel.org/stable/c/1f32535238493008587a8c5cb17eb2ca097592ef
- https://git.kernel.org/stable/c/274cba8d2d1b48c72d8bd90e76c9e2dc1aa0a81d
- https://git.kernel.org/stable/c/744b229f09134ccd091427a6f9ea6d97302cfdd9
- https://git.kernel.org/stable/c/7db5411c5d0bd9c29b8c2ad93c36b5c16ea46c9e
- https://git.kernel.org/stable/c/80bec6825b19d95ccdfd3393cf8ec15ff2a749b4
- https://git.kernel.org/stable/c/9baf60323efa992b7c915094529f0a1882c34e7e
- https://git.kernel.org/stable/c/e36364f5f3785d054a94e57e971385284886d41a
- https://git.kernel.org/stable/c/f48dd3f19614022f2e1b794fbd169d2b4c398c07
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42102
In the Linux kernel, the following vulnerability has been resolved: Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again" Patch series "mm: Avoid possible overflows in dirty throttling". Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details). This patch (of 2): This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78. The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this). Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs. We have div64_ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot.
- https://git.kernel.org/stable/c/000099d71648504fb9c7a4616f92c2b70c3e44ec
- https://git.kernel.org/stable/c/145faa3d03688cbb7bbaaecbd84c01539852942c
- https://git.kernel.org/stable/c/23a28f5f3f6ca1e4184bd0e9631cd0944cf1c807
- https://git.kernel.org/stable/c/253f9ea7e8e53a5176bd80ceb174907b10724c1a
- https://git.kernel.org/stable/c/2820005edae13b140f2d54267d1bd6bb23915f59
- https://git.kernel.org/stable/c/30139c702048f1097342a31302cbd3d478f50c63
- https://git.kernel.org/stable/c/cbbe17a324437c0ff99881a3ee453da45b228a00
- https://git.kernel.org/stable/c/f6620df12cb6bdcad671d269debbb23573502f9d
- https://git.kernel.org/stable/c/000099d71648504fb9c7a4616f92c2b70c3e44ec
- https://git.kernel.org/stable/c/145faa3d03688cbb7bbaaecbd84c01539852942c
- https://git.kernel.org/stable/c/23a28f5f3f6ca1e4184bd0e9631cd0944cf1c807
- https://git.kernel.org/stable/c/253f9ea7e8e53a5176bd80ceb174907b10724c1a
- https://git.kernel.org/stable/c/2820005edae13b140f2d54267d1bd6bb23915f59
- https://git.kernel.org/stable/c/30139c702048f1097342a31302cbd3d478f50c63
- https://git.kernel.org/stable/c/cbbe17a324437c0ff99881a3ee453da45b228a00
- https://git.kernel.org/stable/c/f6620df12cb6bdcad671d269debbb23573502f9d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42104
In the Linux kernel, the following vulnerability has been resolved: nilfs2: add missing check for inode numbers on directory entries Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.
- https://git.kernel.org/stable/c/07c176e7acc5579c133bb923ab21316d192d0a95
- https://git.kernel.org/stable/c/1b7d549ed2c1fa202c751b69423a0d3a6bd5a180
- https://git.kernel.org/stable/c/265fff1a01cdc083aeaf0d934c929db5cc64aebf
- https://git.kernel.org/stable/c/2f2fa9cf7c3537958a82fbe8c8595a5eb0861ad7
- https://git.kernel.org/stable/c/3ab40870edb883b9633dc5cd55f5a2a11afa618d
- https://git.kernel.org/stable/c/b11e8fb93ea5eefb2e4e719497ea177a58ff6131
- https://git.kernel.org/stable/c/bb76c6c274683c8570ad788f79d4b875bde0e458
- https://git.kernel.org/stable/c/c33c2b0d92aa1c2262d999b2598ad6fbd53bd479
- https://git.kernel.org/stable/c/07c176e7acc5579c133bb923ab21316d192d0a95
- https://git.kernel.org/stable/c/1b7d549ed2c1fa202c751b69423a0d3a6bd5a180
- https://git.kernel.org/stable/c/265fff1a01cdc083aeaf0d934c929db5cc64aebf
- https://git.kernel.org/stable/c/2f2fa9cf7c3537958a82fbe8c8595a5eb0861ad7
- https://git.kernel.org/stable/c/3ab40870edb883b9633dc5cd55f5a2a11afa618d
- https://git.kernel.org/stable/c/b11e8fb93ea5eefb2e4e719497ea177a58ff6131
- https://git.kernel.org/stable/c/bb76c6c274683c8570ad788f79d4b875bde0e458
- https://git.kernel.org/stable/c/c33c2b0d92aa1c2262d999b2598ad6fbd53bd479
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42105
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix inode number range checks Patch series "nilfs2: fix potential issues related to reserved inodes". This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value. This patch (of 3): In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked. As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly. In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment. Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros. Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.
- https://git.kernel.org/stable/c/08cab183a624ba71603f3754643ae11cab34dbc4
- https://git.kernel.org/stable/c/1c91058425a01131ea30dda6cf43c67b17884d6a
- https://git.kernel.org/stable/c/3be4dcc8d7bea52ea41f87aa4bbf959efe7a5987
- https://git.kernel.org/stable/c/57235c3c88bb430043728d0d02f44a4efe386476
- https://git.kernel.org/stable/c/731011ac6c37cbe97ece229fc6daa486276052c5
- https://git.kernel.org/stable/c/9194f8ca57527958bee207919458e372d638d783
- https://git.kernel.org/stable/c/e2fec219a36e0993642844be0f345513507031f4
- https://git.kernel.org/stable/c/fae1959d6ab2c52677b113935e36ab4e25df37ea
- https://git.kernel.org/stable/c/08cab183a624ba71603f3754643ae11cab34dbc4
- https://git.kernel.org/stable/c/1c91058425a01131ea30dda6cf43c67b17884d6a
- https://git.kernel.org/stable/c/3be4dcc8d7bea52ea41f87aa4bbf959efe7a5987
- https://git.kernel.org/stable/c/57235c3c88bb430043728d0d02f44a4efe386476
- https://git.kernel.org/stable/c/731011ac6c37cbe97ece229fc6daa486276052c5
- https://git.kernel.org/stable/c/9194f8ca57527958bee207919458e372d638d783
- https://git.kernel.org/stable/c/e2fec219a36e0993642844be0f345513507031f4
- https://git.kernel.org/stable/c/fae1959d6ab2c52677b113935e36ab4e25df37ea
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42106
In the Linux kernel, the following vulnerability has been resolved: inet_diag: Initialize pad field in struct inet_diag_req_v2 KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future. [1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
- https://git.kernel.org/stable/c/0184bf0a349f4cf9e663abbe862ff280e8e4dfa2
- https://git.kernel.org/stable/c/61cf1c739f08190a4cbf047b9fbb192a94d87e3f
- https://git.kernel.org/stable/c/7094a5fd20ab66028f1da7f06e0f2692d70346f9
- https://git.kernel.org/stable/c/76965648fe6858db7c5f3c700fef7aa5f124ca1c
- https://git.kernel.org/stable/c/7ef519c8efde152e0d632337f2994f6921e0b7e4
- https://git.kernel.org/stable/c/8366720519ea8d322a20780debdfd23d9fc0904a
- https://git.kernel.org/stable/c/d6f487e0704de2f2d15f8dd5d7d723210f2b2fdb
- https://git.kernel.org/stable/c/f9b2010e8af49fac9d9562146fb81744d8a9b051
- https://git.kernel.org/stable/c/0184bf0a349f4cf9e663abbe862ff280e8e4dfa2
- https://git.kernel.org/stable/c/61cf1c739f08190a4cbf047b9fbb192a94d87e3f
- https://git.kernel.org/stable/c/7094a5fd20ab66028f1da7f06e0f2692d70346f9
- https://git.kernel.org/stable/c/76965648fe6858db7c5f3c700fef7aa5f124ca1c
- https://git.kernel.org/stable/c/7ef519c8efde152e0d632337f2994f6921e0b7e4
- https://git.kernel.org/stable/c/8366720519ea8d322a20780debdfd23d9fc0904a
- https://git.kernel.org/stable/c/d6f487e0704de2f2d15f8dd5d7d723210f2b2fdb
- https://git.kernel.org/stable/c/f9b2010e8af49fac9d9562146fb81744d8a9b051
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42109
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally flush pending work before notifier syzbot reports: KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45 [..] Workqueue: events nf_tables_trans_destroy_work Call Trace: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline] nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline] nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Problem is that the notifier does a conditional flush, but its possible that the table-to-be-removed is still referenced by transactions being processed by the worker, so we need to flush unconditionally. We could make the flush_work depend on whether we found a table to delete in nf-next to avoid the flush for most cases. AFAICS this problem is only exposed in nf-next, with commit e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects"), with this commit applied there is an unconditional fetch of table->family which is whats triggering the above splat.
- https://git.kernel.org/stable/c/09e650c3a3a7d804430260510534ccbf71c75b2e
- https://git.kernel.org/stable/c/3325628cb36b7f216c5716e7b5124d9dc81199e4
- https://git.kernel.org/stable/c/4c06c13317b9a08decedcd7aaf706691e336277c
- https://git.kernel.org/stable/c/55a40406aac555defe9bdd0adec9508116ce7cb1
- https://git.kernel.org/stable/c/9f6958ba2e902f9820c594869bd710ba74b7c4c0
- https://git.kernel.org/stable/c/09e650c3a3a7d804430260510534ccbf71c75b2e
- https://git.kernel.org/stable/c/3325628cb36b7f216c5716e7b5124d9dc81199e4
- https://git.kernel.org/stable/c/4c06c13317b9a08decedcd7aaf706691e336277c
- https://git.kernel.org/stable/c/55a40406aac555defe9bdd0adec9508116ce7cb1
- https://git.kernel.org/stable/c/9f6958ba2e902f9820c594869bd710ba74b7c4c0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42110
In the Linux kernel, the following vulnerability has been resolved:
net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()
The following is emitted when using idxd (DSA) dmanegine as the data
mover for ntb_transport that ntb_netdev uses.
[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526
[74412.556784] caller is netif_rx_internal+0x42/0x130
[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5
[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024
[74412.581699] Call Trace:
[74412.584514]
- https://git.kernel.org/stable/c/4b3b6c7efee69f077b86ef7f088fb96768e46e1f
- https://git.kernel.org/stable/c/858ae09f03677a4ab907a15516893bc2cc79d4c3
- https://git.kernel.org/stable/c/e15a5d821e5192a3769d846079bc9aa380139baf
- https://git.kernel.org/stable/c/e3af5b14e7632bf12058533d69055393e2d126c9
- https://git.kernel.org/stable/c/4b3b6c7efee69f077b86ef7f088fb96768e46e1f
- https://git.kernel.org/stable/c/858ae09f03677a4ab907a15516893bc2cc79d4c3
- https://git.kernel.org/stable/c/e15a5d821e5192a3769d846079bc9aa380139baf
- https://git.kernel.org/stable/c/e3af5b14e7632bf12058533d69055393e2d126c9
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-26
CVE-2024-42113
In the Linux kernel, the following vulnerability has been resolved: net: txgbe: initialize num_q_vectors for MSI/INTx interrupts When using MSI/INTx interrupts, wx->num_q_vectors is uninitialized. Thus there will be kernel panic in wx_alloc_q_vectors() to allocate queue vectors.
- https://git.kernel.org/stable/c/7c36711a2cd8059c2d24f5e5c1d76e8ea2d5613c
- https://git.kernel.org/stable/c/9edc7a83cd40ac96ff14fe3a17a38f7ace6611df
- https://git.kernel.org/stable/c/c98969226d1fe0c1dd779db8b1c444bc5294fc83
- https://git.kernel.org/stable/c/7c36711a2cd8059c2d24f5e5c1d76e8ea2d5613c
- https://git.kernel.org/stable/c/9edc7a83cd40ac96ff14fe3a17a38f7ace6611df
- https://git.kernel.org/stable/c/c98969226d1fe0c1dd779db8b1c444bc5294fc83
Modified: 2025-11-03
CVE-2024-42114
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
hardirqs last enabled at (131134): [
- https://git.kernel.org/stable/c/33ac5a4eb3d4bea2146658f1b6d1fa86d62d2b22
- https://git.kernel.org/stable/c/3fc06f6d142d2840735543216a60d0a8c345bdec
- https://git.kernel.org/stable/c/80ac0cc9c0bef984e29637b1efa93d7214b42f53
- https://git.kernel.org/stable/c/8a3ac7fb36962c34698f884bd697938054ff2afa
- https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993
- https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7
- https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993
- https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42115
In the Linux kernel, the following vulnerability has been resolved: jffs2: Fix potential illegal address access in jffs2_free_inode During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2_free_inode+0x24/0x48 [ 2430.665233] i_callback+0x24/0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] __do_softirq+0x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffs_inode_info structure. It was found that all variables in the jffs_inode_info structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2_i_init_once, while other members are initialized in the function jffs2_init_inode_info. The function jffs2_init_inode_info is called after iget_locked, but in the iget_locked function, the destroy_inode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, iget_locked may enter the destroy_inode branch as described in the code. Since the destroy_inode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2_i_init_once.
- https://git.kernel.org/stable/c/05fc1ef892f862c1197b11b288bc00f602d2df0c
- https://git.kernel.org/stable/c/0b3246052e01e61a55bb3a15b76acb006759fe67
- https://git.kernel.org/stable/c/5ca26334fc8a3711fed14db7f9eb1c621be4df65
- https://git.kernel.org/stable/c/6d6d94287f6365282bbf41e9a5b5281985970789
- https://git.kernel.org/stable/c/751987a5d8ead0cc405fad96e83ebbaa51c82dbc
- https://git.kernel.org/stable/c/af9a8730ddb6a4b2edd779ccc0aceb994d616830
- https://git.kernel.org/stable/c/b6c8b3e31eb88c85094d848a0bd8b4bafe67e4d8
- https://git.kernel.org/stable/c/d0bbbf31462a400bef4df33e22de91864f475455
- https://git.kernel.org/stable/c/05fc1ef892f862c1197b11b288bc00f602d2df0c
- https://git.kernel.org/stable/c/0b3246052e01e61a55bb3a15b76acb006759fe67
- https://git.kernel.org/stable/c/5ca26334fc8a3711fed14db7f9eb1c621be4df65
- https://git.kernel.org/stable/c/6d6d94287f6365282bbf41e9a5b5281985970789
- https://git.kernel.org/stable/c/751987a5d8ead0cc405fad96e83ebbaa51c82dbc
- https://git.kernel.org/stable/c/af9a8730ddb6a4b2edd779ccc0aceb994d616830
- https://git.kernel.org/stable/c/b6c8b3e31eb88c85094d848a0bd8b4bafe67e4d8
- https://git.kernel.org/stable/c/d0bbbf31462a400bef4df33e22de91864f475455
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42119
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip finding free audio for unknown engine_id [WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio. [HOW] Skip and return NULL. This fixes 2 OVERRUN issues reported by Coverity.
- https://git.kernel.org/stable/c/1357b2165d9ad94faa4c4a20d5e2ce29c2ff29c3
- https://git.kernel.org/stable/c/874261358d31fc772f2823604167e670983cc1ca
- https://git.kernel.org/stable/c/881fb6afc0004c5e6392ae2848f825bf051dae14
- https://git.kernel.org/stable/c/95ad20ee3c4efbb91f9a4ab08e070aa3697f5879
- https://git.kernel.org/stable/c/9eb4db08a808e3a3ba59193aeb84a57a6dc4d8c9
- https://git.kernel.org/stable/c/afaaebdee9bb9f26d9e13cc34b33bd0a7bf59488
- https://git.kernel.org/stable/c/eacca028a623f608607d02457122ee5284491e18
- https://git.kernel.org/stable/c/ffa7bd3ca9cfa902b857d1dc9a5f46fededf86c8
- https://git.kernel.org/stable/c/1357b2165d9ad94faa4c4a20d5e2ce29c2ff29c3
- https://git.kernel.org/stable/c/874261358d31fc772f2823604167e670983cc1ca
- https://git.kernel.org/stable/c/881fb6afc0004c5e6392ae2848f825bf051dae14
- https://git.kernel.org/stable/c/95ad20ee3c4efbb91f9a4ab08e070aa3697f5879
- https://git.kernel.org/stable/c/9eb4db08a808e3a3ba59193aeb84a57a6dc4d8c9
- https://git.kernel.org/stable/c/afaaebdee9bb9f26d9e13cc34b33bd0a7bf59488
- https://git.kernel.org/stable/c/eacca028a623f608607d02457122ee5284491e18
- https://git.kernel.org/stable/c/ffa7bd3ca9cfa902b857d1dc9a5f46fededf86c8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42120
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check pipe offset before setting vblank pipe_ctx has a size of MAX_PIPES so checking its index before accessing the array. This fixes an OVERRUN issue reported by Coverity.
- https://git.kernel.org/stable/c/0b3702f9d43d163fd05e43b7d7e22e766dbef329
- https://git.kernel.org/stable/c/5396a70e8cf462ec5ccf2dc8de103c79de9489e6
- https://git.kernel.org/stable/c/96bf81cc1bd058bb8af6e755a548e926e934dfd1
- https://git.kernel.org/stable/c/b2e9abc95583ac7bbb2c47da4d476a798146dfd6
- https://git.kernel.org/stable/c/c5ec2afeeee4c91cebc4eff6d4f1ecf4047259f4
- https://git.kernel.org/stable/c/d2c3645a4a5ae5d933b4116c305d9d82b8199dbf
- https://git.kernel.org/stable/c/0b3702f9d43d163fd05e43b7d7e22e766dbef329
- https://git.kernel.org/stable/c/5396a70e8cf462ec5ccf2dc8de103c79de9489e6
- https://git.kernel.org/stable/c/96bf81cc1bd058bb8af6e755a548e926e934dfd1
- https://git.kernel.org/stable/c/b2e9abc95583ac7bbb2c47da4d476a798146dfd6
- https://git.kernel.org/stable/c/c5ec2afeeee4c91cebc4eff6d4f1ecf4047259f4
- https://git.kernel.org/stable/c/d2c3645a4a5ae5d933b4116c305d9d82b8199dbf
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42121
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index msg_id before read or write [WHAT] msg_id is used as an array index and it cannot be a negative value, and therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1). [HOW] Check whether msg_id is valid before reading and setting. This fixes 4 OVERRUN issues reported by Coverity.
- https://git.kernel.org/stable/c/59d99deb330af206a4541db0c4da8f73880fba03
- https://git.kernel.org/stable/c/9933eca6ada0cd612e19522e7a319bcef464c0eb
- https://git.kernel.org/stable/c/a31ea49dc8064a557565725cf045944307476a6e
- https://git.kernel.org/stable/c/ae91ffbc8b8d942e3e7f188728cad557b7ed5ee4
- https://git.kernel.org/stable/c/b5b8837d066cc182ff69fb5629ad32ade5484567
- https://git.kernel.org/stable/c/fbb0701af9734cff13917a4b98b5ee9da2fde48d
- https://git.kernel.org/stable/c/59d99deb330af206a4541db0c4da8f73880fba03
- https://git.kernel.org/stable/c/9933eca6ada0cd612e19522e7a319bcef464c0eb
- https://git.kernel.org/stable/c/a31ea49dc8064a557565725cf045944307476a6e
- https://git.kernel.org/stable/c/ae91ffbc8b8d942e3e7f188728cad557b7ed5ee4
- https://git.kernel.org/stable/c/b5b8837d066cc182ff69fb5629ad32ade5484567
- https://git.kernel.org/stable/c/fbb0701af9734cff13917a4b98b5ee9da2fde48d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42124
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Make qedf_execute_tmf() non-preemptible Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]
- https://git.kernel.org/stable/c/0a8a91932b2772e75bf3f6d133ca4225d1d3e920
- https://git.kernel.org/stable/c/0d8b637c9c5eeaa1a4e3dfb336f3ff918eb64fec
- https://git.kernel.org/stable/c/2b9c7787cfcd1e76d873a78f16cf45bfa4b100ea
- https://git.kernel.org/stable/c/4f314aadeed8cdf42c8cf30769425b5e44702748
- https://git.kernel.org/stable/c/5ceb40cdee721e13cbe15a0515cacf984e11236b
- https://git.kernel.org/stable/c/b6ded5316ec56e973dcf5f9997945aad01a9f062
- https://git.kernel.org/stable/c/fa49c65a1cec6a3901ef884fdb24d98068b63493
- https://git.kernel.org/stable/c/0a8a91932b2772e75bf3f6d133ca4225d1d3e920
- https://git.kernel.org/stable/c/0d8b637c9c5eeaa1a4e3dfb336f3ff918eb64fec
- https://git.kernel.org/stable/c/2b9c7787cfcd1e76d873a78f16cf45bfa4b100ea
- https://git.kernel.org/stable/c/4f314aadeed8cdf42c8cf30769425b5e44702748
- https://git.kernel.org/stable/c/5ceb40cdee721e13cbe15a0515cacf984e11236b
- https://git.kernel.org/stable/c/b6ded5316ec56e973dcf5f9997945aad01a9f062
- https://git.kernel.org/stable/c/fa49c65a1cec6a3901ef884fdb24d98068b63493
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42126
In the Linux kernel, the following vulnerability has been resolved: powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area. Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area. With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early: [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded.
- https://git.kernel.org/stable/c/0db880fc865ffb522141ced4bfa66c12ab1fbb70
- https://git.kernel.org/stable/c/0f37946c62c48a907625348cbc720a7a0c547d1e
- https://git.kernel.org/stable/c/2c78c9411e685dbc9eac8c2845111b03501975b8
- https://git.kernel.org/stable/c/8d3f83dfb23674540c827a8d65fba20aa300b252
- https://git.kernel.org/stable/c/e2afb26615adf6c3ceaaa7732aa839bcd587a057
- https://git.kernel.org/stable/c/fb6675db04c4b79883373edc578d5df7bbc84848
- https://git.kernel.org/stable/c/0db880fc865ffb522141ced4bfa66c12ab1fbb70
- https://git.kernel.org/stable/c/0f37946c62c48a907625348cbc720a7a0c547d1e
- https://git.kernel.org/stable/c/2c78c9411e685dbc9eac8c2845111b03501975b8
- https://git.kernel.org/stable/c/8d3f83dfb23674540c827a8d65fba20aa300b252
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42127
In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix shared irq handling on driver remove lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.
- https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770
- https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9
- https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13
- https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af
- https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8
- https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e
- https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe
- https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770
- https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9
- https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13
- https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af
- https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8
- https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e
- https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-29
CVE-2024-42128
In the Linux kernel, the following vulnerability has been resolved: leds: an30259a: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.
- https://git.kernel.org/stable/c/3ead19aa341de89a8c3d88a091d8093ebea622e8
- https://git.kernel.org/stable/c/9dba44460bfca657ca43f03ea9bafa4f9f7dd077
- https://git.kernel.org/stable/c/c382e2e3eccb6b7ca8c7aff5092c1668428e7de6
- https://git.kernel.org/stable/c/3ead19aa341de89a8c3d88a091d8093ebea622e8
- https://git.kernel.org/stable/c/9dba44460bfca657ca43f03ea9bafa4f9f7dd077
- https://git.kernel.org/stable/c/c382e2e3eccb6b7ca8c7aff5092c1668428e7de6
Modified: 2025-11-03
CVE-2024-42131
In the Linux kernel, the following vulnerability has been resolved: mm: avoid overflows in dirty throttling logic The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX. This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.
- https://git.kernel.org/stable/c/2b2d2b8766db028bd827af34075f221ae9e9efff
- https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0bfe7e8b2
- https://git.kernel.org/stable/c/4d3817b64eda07491bdd86a234629fe0764fb42a
- https://git.kernel.org/stable/c/7a49389771ae7666f4dc3426e2a4594bf23ae290
- https://git.kernel.org/stable/c/8e0b5e7f2895eccef5c2a0018b589266f90c4805
- https://git.kernel.org/stable/c/a25e8536184516b55ef89ab91dd2eea429de28d2
- https://git.kernel.org/stable/c/bd16a7ee339aef3ee4c90cb23902afb6af379ea0
- https://git.kernel.org/stable/c/c83ed422c24f0d4b264f89291d4fabe285f80dbc
- https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0bfe7e8b2
- https://git.kernel.org/stable/c/7a49389771ae7666f4dc3426e2a4594bf23ae290
- https://git.kernel.org/stable/c/8e0b5e7f2895eccef5c2a0018b589266f90c4805
- https://git.kernel.org/stable/c/a25e8536184516b55ef89ab91dd2eea429de28d2
- https://git.kernel.org/stable/c/bd16a7ee339aef3ee4c90cb23902afb6af379ea0
- https://git.kernel.org/stable/c/c83ed422c24f0d4b264f89291d4fabe285f80dbc
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-12-11
CVE-2024-42132
In the Linux kernel, the following vulnerability has been resolved: bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX Syzbot hit warning in hci_conn_del() caused by freeing handle that was not allocated using ida allocator. This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by hci_le_big_sync_established_evt(), which makes code think it's unset connection. Add same check for handle upper bound as in hci_conn_set_handle() to prevent warning.
- https://git.kernel.org/stable/c/1cc18c2ab2e8c54c355ea7c0423a636e415a0c23
- https://git.kernel.org/stable/c/4970e48f83dbd21d2a6a7cdaaafc2a71f7f45dc4
- https://git.kernel.org/stable/c/d311036696fed778301d08a71a4bef737b86d8c5
- https://git.kernel.org/stable/c/1cc18c2ab2e8c54c355ea7c0423a636e415a0c23
- https://git.kernel.org/stable/c/4970e48f83dbd21d2a6a7cdaaafc2a71f7f45dc4
- https://git.kernel.org/stable/c/d311036696fed778301d08a71a4bef737b86d8c5
Modified: 2024-12-11
CVE-2024-42133
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Ignore too large handle values in BIG hci_le_big_sync_established_evt is necessary to filter out cases where the handle value is belonging to ida id range, otherwise ida will be erroneously released in hci_conn_cleanup.
- https://git.kernel.org/stable/c/015d79c96d62cd8a4a359fcf5be40d58088c936b
- https://git.kernel.org/stable/c/38263088b845abeeeb98dda5b87c0de3063b6dbb
- https://git.kernel.org/stable/c/dad0003ccc68457baf005a6ed75b4d321463fe3d
- https://git.kernel.org/stable/c/015d79c96d62cd8a4a359fcf5be40d58088c936b
- https://git.kernel.org/stable/c/38263088b845abeeeb98dda5b87c0de3063b6dbb
- https://git.kernel.org/stable/c/dad0003ccc68457baf005a6ed75b4d321463fe3d
Modified: 2024-12-11
CVE-2024-42135
In the Linux kernel, the following vulnerability has been resolved: vhost_task: Handle SIGKILL by flushing work and exiting Instead of lingering until the device is closed, this has us handle SIGKILL by: 1. marking the worker as killed so we no longer try to use it with new virtqueues and new flush operations. 2. setting the virtqueue to worker mapping so no new works are queued. 3. running all the exiting works.
- https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af
- https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233
- https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4
- https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af
- https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233
- https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4
Modified: 2026-03-24
CVE-2024-42136
In the Linux kernel, the following vulnerability has been resolved:
cdrom: rearrange last_media_change check to avoid unintentional overflow
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33
[ 366.021089] -9223372036854775808 - 346321 cannot be represented in type '__s64' (aka 'long long')
[ 366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO
[ 366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[ 366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 366.027518] Call Trace:
[ 366.027523]
- https://git.kernel.org/stable/c/0c97527e916054acc4a46ffb02842988acb2e92b
- https://git.kernel.org/stable/c/3ee21e14c8c329168a0b66bab00ecd18f5d0dee3
- https://git.kernel.org/stable/c/e809bc112712da8f7e15822674c6562da6cdf24c
- https://git.kernel.org/stable/c/efb905aeb44b0e99c0e6b07865b1885ae0471ebf
- https://git.kernel.org/stable/c/0c97527e916054acc4a46ffb02842988acb2e92b
- https://git.kernel.org/stable/c/3ee21e14c8c329168a0b66bab00ecd18f5d0dee3
- https://git.kernel.org/stable/c/e809bc112712da8f7e15822674c6562da6cdf24c
- https://git.kernel.org/stable/c/efb905aeb44b0e99c0e6b07865b1885ae0471ebf
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42137
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue: BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree.
- https://git.kernel.org/stable/c/215a26c2404fa34625c725d446967fa328a703eb
- https://git.kernel.org/stable/c/4ca6013cd18e58ac1044908c40d4006a92093a11
- https://git.kernel.org/stable/c/88e72239ead9814b886db54fc4ee39ef3c2b8f26
- https://git.kernel.org/stable/c/977b9dc65e14fb80de4763d949c7dec2ecb15b9b
- https://git.kernel.org/stable/c/e2d8aa4c763593704ac21e7591aed4f13e32f3b5
- https://git.kernel.org/stable/c/e6e200b264271f62a3fadb51ada9423015ece37b
- https://git.kernel.org/stable/c/215a26c2404fa34625c725d446967fa328a703eb
- https://git.kernel.org/stable/c/4ca6013cd18e58ac1044908c40d4006a92093a11
- https://git.kernel.org/stable/c/88e72239ead9814b886db54fc4ee39ef3c2b8f26
- https://git.kernel.org/stable/c/977b9dc65e14fb80de4763d949c7dec2ecb15b9b
- https://git.kernel.org/stable/c/e2d8aa4c763593704ac21e7591aed4f13e32f3b5
- https://git.kernel.org/stable/c/e6e200b264271f62a3fadb51ada9423015ece37b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42138
In the Linux kernel, the following vulnerability has been resolved: mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file In case of invalid INI file mlxsw_linecard_types_init() deallocates memory but doesn't reset pointer to NULL and returns 0. In case of any error occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init() calls mlxsw_linecard_types_fini() which performs memory deallocation again. Add pointer reset to NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/8ce34dccbe8fa7d2ef86f2d8e7db2a9b67cabfc3
- https://git.kernel.org/stable/c/9af7437669b72f804fc4269f487528dbbed142a2
- https://git.kernel.org/stable/c/ab557f5cd993a3201b09593633d04b891263d5c0
- https://git.kernel.org/stable/c/f8b55a465b0e8a500179808166fe9420f5c091a1
- https://git.kernel.org/stable/c/8ce34dccbe8fa7d2ef86f2d8e7db2a9b67cabfc3
- https://git.kernel.org/stable/c/9af7437669b72f804fc4269f487528dbbed142a2
- https://git.kernel.org/stable/c/ab557f5cd993a3201b09593633d04b891263d5c0
- https://git.kernel.org/stable/c/f8b55a465b0e8a500179808166fe9420f5c091a1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42140
In the Linux kernel, the following vulnerability has been resolved: riscv: kexec: Avoid deadlock in kexec crash path If the kexec crash code is called in the interrupt context, the machine_kexec_mask_interrupts() function will trigger a deadlock while trying to acquire the irqdesc spinlock and then deactivate irqchip in irq_set_irqchip_state() function. Unlike arm64, riscv only requires irq_eoi handler to complete EOI and keeping irq_set_irqchip_state() will only leave this possible deadlock without any use. So we simply remove it.
- https://git.kernel.org/stable/c/484dd545271d02d1571e1c6b62ea7df9dbe5e692
- https://git.kernel.org/stable/c/653deee48a4682ea17a05b96fb6842795ab5943c
- https://git.kernel.org/stable/c/7692c9b6baacdee378435f58f19baf0eb69e4155
- https://git.kernel.org/stable/c/bb80a7911218bbab2a69b5db7d2545643ab0073d
- https://git.kernel.org/stable/c/c562ba719df570c986caf0941fea2449150bcbc4
- https://git.kernel.org/stable/c/484dd545271d02d1571e1c6b62ea7df9dbe5e692
- https://git.kernel.org/stable/c/653deee48a4682ea17a05b96fb6842795ab5943c
- https://git.kernel.org/stable/c/7692c9b6baacdee378435f58f19baf0eb69e4155
- https://git.kernel.org/stable/c/bb80a7911218bbab2a69b5db7d2545643ab0073d
- https://git.kernel.org/stable/c/c562ba719df570c986caf0941fea2449150bcbc4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-12-11
CVE-2024-42141
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Check socket flag instead of hcon This fixes the following Smatch static checker warning: net/bluetooth/iso.c:1364 iso_sock_recvmsg() error: we previously assumed 'pi->conn->hcon' could be null (line 1359) net/bluetooth/iso.c 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg, 1348 size_t len, int flags) 1349 { 1350 struct sock *sk = sock->sk; 1351 struct iso_pinfo *pi = iso_pi(sk); 1352 1353 BT_DBG("sk %p", sk); 1354 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) { 1356 lock_sock(sk); 1357 switch (sk->sk_state) { 1358 case BT_CONNECT2: 1359 if (pi->conn->hcon && ^^^^^^^^^^^^^^ If ->hcon is NULL 1360 test_bit(HCI_CONN_PA_SYNC, &pi->conn->hcon->flags)) { 1361 iso_conn_big_sync(sk); 1362 sk->sk_state = BT_LISTEN; 1363 } else { --> 1364 iso_conn_defer_accept(pi->conn->hcon); ^^^^^^^^^^^^^^ then we're toast 1365 sk->sk_state = BT_CONFIG; 1366 } 1367 release_sock(sk); 1368 return 0; 1369 case BT_CONNECTED: 1370 if (test_bit(BT_SK_PA_SYNC,
- https://git.kernel.org/stable/c/045669710464a21c67e690ef14698fd71857cb11
- https://git.kernel.org/stable/c/33fabef489169c6db87843ef23351ed0d5e51ad8
- https://git.kernel.org/stable/c/596b6f081336e77764ca35cfeab66d0fcdbe544e
- https://git.kernel.org/stable/c/045669710464a21c67e690ef14698fd71857cb11
- https://git.kernel.org/stable/c/33fabef489169c6db87843ef23351ed0d5e51ad8
- https://git.kernel.org/stable/c/596b6f081336e77764ca35cfeab66d0fcdbe544e
Modified: 2025-11-03
CVE-2024-42142
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-switch, Create ingress ACL when needed Currently, ingress acl is used for three features. It is created only when vport metadata match and prio tag are enabled. But active-backup lag mode also uses it. It is independent of vport metadata match and prio tag. And vport metadata match can be disabled using the following devlink command: # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \ value false cmode runtime If ingress acl is not created, will hit panic when creating drop rule for active-backup lag mode. If always create it, there will be about 5% performance degradation. Fix it by creating ingress acl when needed. If esw_port_metadata is true, ingress acl exists, then create drop rule using existing ingress acl. If esw_port_metadata is false, create ingress acl and then create drop rule.
- https://git.kernel.org/stable/c/3e3551f8702978cd2221d2614ca6d6727e785324
- https://git.kernel.org/stable/c/83bc1a129f7fd0d7d05036ceb7ee69102624e320
- https://git.kernel.org/stable/c/b20c2fb45470d0c7a603613c9cfa5d45720e17f2
- https://git.kernel.org/stable/c/bc3ff8d3c05044de57865ebbb78cca8f7da3e595
- https://git.kernel.org/stable/c/3e3551f8702978cd2221d2614ca6d6727e785324
- https://git.kernel.org/stable/c/83bc1a129f7fd0d7d05036ceb7ee69102624e320
- https://git.kernel.org/stable/c/b20c2fb45470d0c7a603613c9cfa5d45720e17f2
- https://git.kernel.org/stable/c/bc3ff8d3c05044de57865ebbb78cca8f7da3e595
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-42144
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data Verify that lvts_data is not NULL before using it.
- https://git.kernel.org/stable/c/79ef1a5593fdb8aa4dbccf6085c48f1739338bc9
- https://git.kernel.org/stable/c/a1191a77351e25ddf091bb1a231cae12ee598b5d
- https://git.kernel.org/stable/c/fd7ae1cabfedd727be5bee774c87acbc7b10b886
- https://git.kernel.org/stable/c/79ef1a5593fdb8aa4dbccf6085c48f1739338bc9
- https://git.kernel.org/stable/c/a1191a77351e25ddf091bb1a231cae12ee598b5d
- https://git.kernel.org/stable/c/fd7ae1cabfedd727be5bee774c87acbc7b10b886
Modified: 2025-11-03
CVE-2024-42145
In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.
- https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb
- https://git.kernel.org/stable/c/62349fbf86b5e13b02721bdadf98c29afd1e7b5f
- https://git.kernel.org/stable/c/63d202d948bb6d3a28cd8e8b96b160fa53e18baa
- https://git.kernel.org/stable/c/a6627fba793cc75b7365d9504a0095fb2902dda4
- https://git.kernel.org/stable/c/b4913702419d064ec4c4bbf7270643c95cc89a1b
- https://git.kernel.org/stable/c/b8c5f635997f49c625178d1a0cb32a80ed33abe6
- https://git.kernel.org/stable/c/ca0b44e20a6f3032224599f02e7c8fb49525c894
- https://git.kernel.org/stable/c/d73cb8862e4d6760ccc94d3b57b9ef6271400607
- https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb
- https://git.kernel.org/stable/c/62349fbf86b5e13b02721bdadf98c29afd1e7b5f
- https://git.kernel.org/stable/c/63d202d948bb6d3a28cd8e8b96b160fa53e18baa
- https://git.kernel.org/stable/c/a6627fba793cc75b7365d9504a0095fb2902dda4
- https://git.kernel.org/stable/c/b4913702419d064ec4c4bbf7270643c95cc89a1b
- https://git.kernel.org/stable/c/b8c5f635997f49c625178d1a0cb32a80ed33abe6
- https://git.kernel.org/stable/c/ca0b44e20a6f3032224599f02e7c8fb49525c894
- https://git.kernel.org/stable/c/d73cb8862e4d6760ccc94d3b57b9ef6271400607
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42147
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/debugfs - Fix debugfs uninit process issue During the zip probe process, the debugfs failure does not stop the probe. When debugfs initialization fails, jumping to the error branch will also release regs, in addition to its own rollback operation. As a result, it may be released repeatedly during the regs uninit process. Therefore, the null check needs to be added to the regs uninit process.
- https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e
- https://git.kernel.org/stable/c/8be0913389718e8d27c4f1d4537b5e1b99ed7739
- https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3
- https://git.kernel.org/stable/c/eda60520cfe3aba9f088c68ebd5bcbca9fc6ac3c
- https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e
- https://git.kernel.org/stable/c/8be0913389718e8d27c4f1d4537b5e1b99ed7739
- https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3
- https://git.kernel.org/stable/c/eda60520cfe3aba9f088c68ebd5bcbca9fc6ac3c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42148
In the Linux kernel, the following vulnerability has been resolved: bnx2x: Fix multiple UBSAN array-index-out-of-bounds Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter. Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array: struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not. This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch /* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */ However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below. This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs. Stack traces: UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---
- https://git.kernel.org/stable/c/0edae06b4c227bcfaf3ce21208d49191e1009d3b
- https://git.kernel.org/stable/c/134061163ee5ca4759de5c24ca3bd71608891ba7
- https://git.kernel.org/stable/c/8b17cec33892a66bbd71f8d9a70a45e2072ae84f
- https://git.kernel.org/stable/c/9504a1550686f53b0bab4cab31d435383b1ee2ce
- https://git.kernel.org/stable/c/b9ea38e767459111a511ed4fb74abc37db95a59d
- https://git.kernel.org/stable/c/cbe53087026ad929cd3950508397e8892a6a2a0f
- https://git.kernel.org/stable/c/cfb04472ce33bee2579caf4dc9f4242522f6e26e
- https://git.kernel.org/stable/c/f1313ea92f82451923e28ab45a4aaa0e70e80b98
- https://git.kernel.org/stable/c/0edae06b4c227bcfaf3ce21208d49191e1009d3b
- https://git.kernel.org/stable/c/134061163ee5ca4759de5c24ca3bd71608891ba7
- https://git.kernel.org/stable/c/8b17cec33892a66bbd71f8d9a70a45e2072ae84f
- https://git.kernel.org/stable/c/9504a1550686f53b0bab4cab31d435383b1ee2ce
- https://git.kernel.org/stable/c/b9ea38e767459111a511ed4fb74abc37db95a59d
- https://git.kernel.org/stable/c/cbe53087026ad929cd3950508397e8892a6a2a0f
- https://git.kernel.org/stable/c/cfb04472ce33bee2579caf4dc9f4242522f6e26e
- https://git.kernel.org/stable/c/f1313ea92f82451923e28ab45a4aaa0e70e80b98
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42152
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.
- https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa
- https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1
- https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33
- https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da
- https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5
- https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4
- https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa
- https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1
- https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33
- https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da
- https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5
- https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42153
In the Linux kernel, the following vulnerability has been resolved: i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.
- https://git.kernel.org/stable/c/27cd3873fa76ebeb9f948baae40cb9a6d8692289
- https://git.kernel.org/stable/c/2849a1b747cf37aa5b684527104d3a53f1e296d2
- https://git.kernel.org/stable/c/3503372d0bf7b324ec0bd6b90606703991426176
- https://git.kernel.org/stable/c/3d32327f5cfc087ee3922a3bcdcc29880dcdb50f
- https://git.kernel.org/stable/c/92e494a7568b60ae80d57fc0deafcaf3a4029ab3
- https://git.kernel.org/stable/c/a349e5ab4dc9954746e836cd10b407ce48f9b2f6
- https://git.kernel.org/stable/c/effe0500afda017a86c94482b1e36bc37586c9af
- https://git.kernel.org/stable/c/f63b94be6942ba82c55343e196bd09b53227618e
- https://git.kernel.org/stable/c/27cd3873fa76ebeb9f948baae40cb9a6d8692289
- https://git.kernel.org/stable/c/2849a1b747cf37aa5b684527104d3a53f1e296d2
- https://git.kernel.org/stable/c/3503372d0bf7b324ec0bd6b90606703991426176
- https://git.kernel.org/stable/c/3d32327f5cfc087ee3922a3bcdcc29880dcdb50f
- https://git.kernel.org/stable/c/92e494a7568b60ae80d57fc0deafcaf3a4029ab3
- https://git.kernel.org/stable/c/a349e5ab4dc9954746e836cd10b407ce48f9b2f6
- https://git.kernel.org/stable/c/effe0500afda017a86c94482b1e36bc37586c9af
- https://git.kernel.org/stable/c/f63b94be6942ba82c55343e196bd09b53227618e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42154
In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).
- https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9
- https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c
- https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3
- https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321
- https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff
- https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99
- https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98
- https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6
- http://www.openwall.com/lists/oss-security/2024/09/24/3
- http://www.openwall.com/lists/oss-security/2024/09/24/4
- http://www.openwall.com/lists/oss-security/2024/09/25/3
- https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9
- https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c
- https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3
- https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321
- https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff
- https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99
- https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98
- https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://security.netapp.com/advisory/ntap-20240828-0010/
Modified: 2025-11-03
CVE-2024-42157
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe sensitive data on failure Wipe sensitive data from stack also if the copy_to_user() fails.
- https://git.kernel.org/stable/c/1d8c270de5eb74245d72325d285894a577a945d9
- https://git.kernel.org/stable/c/4889f117755b2f18c23045a0f57977f3ec130581
- https://git.kernel.org/stable/c/6e2e374403bf73140d0efc9541cb1b3bea55ac02
- https://git.kernel.org/stable/c/90a01aefb84b09ccb6024d75d85bb8f620bd3487
- https://git.kernel.org/stable/c/93c034c4314bc4c4450a3869cd5da298502346ad
- https://git.kernel.org/stable/c/b5eb9176ebd4697bc248bf8d145e66d782cf5250
- https://git.kernel.org/stable/c/c44a2151e5d21c66b070a056c26471f30719b575
- https://git.kernel.org/stable/c/c51795885c801b6b7e976717e0d6d45b1e5be0f0
- https://git.kernel.org/stable/c/1d8c270de5eb74245d72325d285894a577a945d9
- https://git.kernel.org/stable/c/4889f117755b2f18c23045a0f57977f3ec130581
- https://git.kernel.org/stable/c/6e2e374403bf73140d0efc9541cb1b3bea55ac02
- https://git.kernel.org/stable/c/90a01aefb84b09ccb6024d75d85bb8f620bd3487
- https://git.kernel.org/stable/c/93c034c4314bc4c4450a3869cd5da298502346ad
- https://git.kernel.org/stable/c/b5eb9176ebd4697bc248bf8d145e66d782cf5250
- https://git.kernel.org/stable/c/c44a2151e5d21c66b070a056c26471f30719b575
- https://git.kernel.org/stable/c/c51795885c801b6b7e976717e0d6d45b1e5be0f0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-03-25
CVE-2024-42159
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.
- https://git.kernel.org/stable/c/3668651def2c1622904e58b0280ee93121f2b10b
- https://git.kernel.org/stable/c/586b41060113ae43032ec6c4a16d518cef5da6e0
- https://git.kernel.org/stable/c/b869ec89d2ee923d46608b76e54c006680c9b4df
- https://git.kernel.org/stable/c/c8707901b53a48106d7501bdbd0350cefaefa4cf
- https://git.kernel.org/stable/c/3668651def2c1622904e58b0280ee93121f2b10b
- https://git.kernel.org/stable/c/586b41060113ae43032ec6c4a16d518cef5da6e0
- https://git.kernel.org/stable/c/b869ec89d2ee923d46608b76e54c006680c9b4df
- https://git.kernel.org/stable/c/c8707901b53a48106d7501bdbd0350cefaefa4cf
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-03-25
CVE-2024-42160
In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.
- https://git.kernel.org/stable/c/44958ca9e400f57bd0478115519ffc350fcee61e
- https://git.kernel.org/stable/c/4ed886b187f47447ad559619c48c086f432d2b77
- https://git.kernel.org/stable/c/6e5b601706ce05d94338cad598736d96bb8096c8
- https://git.kernel.org/stable/c/bc84dd2c33e0c10fd90d60f0cfc0bfb504d4692d
- https://git.kernel.org/stable/c/ecb641f424d6d1f055d149a15b892edcc92c504b
- https://git.kernel.org/stable/c/44958ca9e400f57bd0478115519ffc350fcee61e
- https://git.kernel.org/stable/c/4ed886b187f47447ad559619c48c086f432d2b77
- https://git.kernel.org/stable/c/bc84dd2c33e0c10fd90d60f0cfc0bfb504d4692d
- https://git.kernel.org/stable/c/ecb641f424d6d1f055d149a15b892edcc92c504b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42161
In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions.
- https://git.kernel.org/stable/c/009367099eb61a4fc2af44d4eb06b6b4de7de6db
- https://git.kernel.org/stable/c/3364c2ed1c241989847f19cf83e3db903ce689e3
- https://git.kernel.org/stable/c/7e5471b5efebc30dd0bc035cda86693a5c73d45f
- https://git.kernel.org/stable/c/a21d76bd0b0d39518e9a4c19f6cf7c042a974aff
- https://git.kernel.org/stable/c/b694989bb13ed5f166e633faa1eb0f21c6d261a6
- https://git.kernel.org/stable/c/ff941a8449e712eaf7efca1a13bfb9afd3d99fc2
- https://git.kernel.org/stable/c/009367099eb61a4fc2af44d4eb06b6b4de7de6db
- https://git.kernel.org/stable/c/3364c2ed1c241989847f19cf83e3db903ce689e3
- https://git.kernel.org/stable/c/7e5471b5efebc30dd0bc035cda86693a5c73d45f
- https://git.kernel.org/stable/c/a21d76bd0b0d39518e9a4c19f6cf7c042a974aff
- https://git.kernel.org/stable/c/b694989bb13ed5f166e633faa1eb0f21c6d261a6
- https://git.kernel.org/stable/c/ff941a8449e712eaf7efca1a13bfb9afd3d99fc2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42223
In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: tda10048: Fix integer overflow state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor. Create a new 64 bit variable to hold the calculations.
- https://git.kernel.org/stable/c/1121d8a5c6ed6b8fad492e43b63b386cb6a3a9d8
- https://git.kernel.org/stable/c/1663e2474e4d777187d749a5c90ae83232db32bd
- https://git.kernel.org/stable/c/1aa1329a67cc214c3b7bd2a14d1301a795760b07
- https://git.kernel.org/stable/c/5c72587d024f087aecec0221eaff2fe850d856ce
- https://git.kernel.org/stable/c/8167e4d7dc086d4f7ca7897dcff3827e4d22c99a
- https://git.kernel.org/stable/c/8ac224e9371dc3c4eb666033e6b42d05cf5184a1
- https://git.kernel.org/stable/c/bd5620439959a7e02012588c724c6ff5143b80af
- https://git.kernel.org/stable/c/e1ba22618758e95e09c9fd30c69ccce38edf94c0
- https://git.kernel.org/stable/c/1121d8a5c6ed6b8fad492e43b63b386cb6a3a9d8
- https://git.kernel.org/stable/c/1663e2474e4d777187d749a5c90ae83232db32bd
- https://git.kernel.org/stable/c/1aa1329a67cc214c3b7bd2a14d1301a795760b07
- https://git.kernel.org/stable/c/5c72587d024f087aecec0221eaff2fe850d856ce
- https://git.kernel.org/stable/c/8167e4d7dc086d4f7ca7897dcff3827e4d22c99a
- https://git.kernel.org/stable/c/8ac224e9371dc3c4eb666033e6b42d05cf5184a1
- https://git.kernel.org/stable/c/bd5620439959a7e02012588c724c6ff5143b80af
- https://git.kernel.org/stable/c/e1ba22618758e95e09c9fd30c69ccce38edf94c0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42224
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.
- https://git.kernel.org/stable/c/2a2fe25a103cef73cde356e6d09da10f607e93f5
- https://git.kernel.org/stable/c/3bf8d70e1455f87856640c3433b3660a31001618
- https://git.kernel.org/stable/c/3f25b5f1635449036692a44b771f39f772190c1d
- https://git.kernel.org/stable/c/47d28dde172696031c880c5778633cdca30394ee
- https://git.kernel.org/stable/c/4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b
- https://git.kernel.org/stable/c/8c2c3cca816d074c75a2801d1ca0dea7b0148114
- https://git.kernel.org/stable/c/aa03f591ef31ba603a4a99d05d25a0f21ab1cd89
- https://git.kernel.org/stable/c/f75625db838ade28f032dacd0f0c8baca42ecde4
- https://git.kernel.org/stable/c/2a2fe25a103cef73cde356e6d09da10f607e93f5
- https://git.kernel.org/stable/c/3bf8d70e1455f87856640c3433b3660a31001618
- https://git.kernel.org/stable/c/3f25b5f1635449036692a44b771f39f772190c1d
- https://git.kernel.org/stable/c/47d28dde172696031c880c5778633cdca30394ee
- https://git.kernel.org/stable/c/4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b
- https://git.kernel.org/stable/c/8c2c3cca816d074c75a2801d1ca0dea7b0148114
- https://git.kernel.org/stable/c/aa03f591ef31ba603a4a99d05d25a0f21ab1cd89
- https://git.kernel.org/stable/c/f75625db838ade28f032dacd0f0c8baca42ecde4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42225
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: replace skb_put with skb_put_zero Avoid potentially reusing uninitialized data
- https://git.kernel.org/stable/c/22ea2a7f0b64d323625950414a4496520fb33657
- https://git.kernel.org/stable/c/64f86337ccfe77fe3be5a9356b0dabde23fbb074
- https://git.kernel.org/stable/c/7f819a2f4fbc510e088b49c79addcf1734503578
- https://git.kernel.org/stable/c/dc7f14d00d0c4c21898f3504607f4a31079065a2
- https://git.kernel.org/stable/c/ff6b26be13032c5fbd6b6a0b24358f8eaac4f3af
- https://git.kernel.org/stable/c/22ea2a7f0b64d323625950414a4496520fb33657
- https://git.kernel.org/stable/c/64f86337ccfe77fe3be5a9356b0dabde23fbb074
- https://git.kernel.org/stable/c/7f819a2f4fbc510e088b49c79addcf1734503578
- https://git.kernel.org/stable/c/dc7f14d00d0c4c21898f3504607f4a31079065a2
- https://git.kernel.org/stable/c/ff6b26be13032c5fbd6b6a0b24358f8eaac4f3af
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42228
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)
- https://git.kernel.org/stable/c/3b505759447637dcccb50cbd98ec6f8d2a04fc46
- https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef
- https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70f9c0944
- https://git.kernel.org/stable/c/9ee1534ecdd5b4c013064663502d7fde824d2144
- https://git.kernel.org/stable/c/d35cf41c8eb5d9fe95b21ae6ee2910f9ba4878e8
- https://git.kernel.org/stable/c/da6a85d197888067e8d38b5d22c986b5b5cab712
- https://git.kernel.org/stable/c/df02642c21c984303fe34c3f7d72965792fb1a15
- https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440
- https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef
- https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70f9c0944
- https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42229
In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key.
- https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210
- https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534
- https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d
- https://git.kernel.org/stable/c/89b9b6fa4463daf820e6a5ef65c3b0c2db239513
- https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133
- https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb
- https://git.kernel.org/stable/c/b716e9c3603ee95ed45e938fe47227d22cf3ec35
- https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e
- https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210
- https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534
- https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d
- https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133
- https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb
- https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42230
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all.
- https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011
- https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3
- https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c
- https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5
- https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011
- https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3
- https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c
- https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42232
In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed
- https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf
- https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7
- https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a
- https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e
- https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c
- https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea
- https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883
- https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-08-08
CVE-2024-42235
In the Linux kernel, the following vulnerability has been resolved: s390/mm: Add NULL pointer check to crst_table_free() base_crst_free() crst_table_free() used to work with NULL pointers before the conversion to ptdescs. Since crst_table_free() can be called with a NULL pointer (error handling in crst_table_upgrade() add an explicit check. Also add the same check to base_crst_free() for consistency reasons. In real life this should not happen, since order two GFP_KERNEL allocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used.
Modified: 2025-11-03
CVE-2024-42236
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form `if (str[0 - 1] == '\n') followed closely by an OOB write in the form `str[0 - 1] = '\0'`. There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.
- https://git.kernel.org/stable/c/2d16f63d8030903e5031853e79d731ee5d474e70
- https://git.kernel.org/stable/c/6d3c721e686ea6c59e18289b400cc95c76e927e0
- https://git.kernel.org/stable/c/72b8ee0d9826e8ed00e0bdfce3e46b98419b37ce
- https://git.kernel.org/stable/c/a444c3fc264119801575ab086e03fb4952f23fd0
- https://git.kernel.org/stable/c/c95fbdde87e39e5e0ae27f28bf6711edfb985caa
- https://git.kernel.org/stable/c/d1205033e912f9332c1dbefa812e6ceb0575ce0a
- https://git.kernel.org/stable/c/e8474a10c535e6a2024c3b06e37e4a3a23beb490
- https://git.kernel.org/stable/c/eecfefad0953b2f31aaefa058f7f348ff39c4bba
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42237
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Validate payload length before processing block Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it.
- https://git.kernel.org/stable/c/259955eca9b7acf1299b1ac077d8cfbe12df35d8
- https://git.kernel.org/stable/c/3a9cd924aec1288d675df721f244da4dd7e16cff
- https://git.kernel.org/stable/c/6598afa9320b6ab13041616950ca5f8f938c0cf1
- https://git.kernel.org/stable/c/71d9e313d8f7e18c543a9c80506fe6b1eb1fe0c8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42238
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Return error if block header overflows file Return an error from cs_dsp_power_up() if a block header is longer than the amount of data left in the file. The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop while there was enough data left in the file for a valid region. This protected against overrunning the end of the file data, but it didn't abort the file processing with an error.
- https://git.kernel.org/stable/c/6eabd23383805725eff416c203688b7a390d4153
- https://git.kernel.org/stable/c/90ab191b7d181057d71234e8632e06b5844ac38e
- https://git.kernel.org/stable/c/959fe01e85b7241e3ec305d657febbe82da16a02
- https://git.kernel.org/stable/c/b8be70566b33abbd0180105070b4c67cfef8c44f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-08-08
CVE-2024-42239
In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_timer_start would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimer_cancel has finished executing, such that lockups can occur again. Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel.
Modified: 2025-11-03
CVE-2024-42240
In the Linux kernel, the following vulnerability has been resolved:
x86/bhi: Avoid warning in #DB handler due to BHI mitigation
When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set
then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the
clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler
(exc_debug_kernel()) to issue a warning because single-step is used outside the
entry_SYSENTER_compat() function.
To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY
after making sure the TF flag is cleared.
The problem can be reproduced with the following sequence:
$ cat sysenter_step.c
int main()
{ asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }
$ gcc -o sysenter_step sysenter_step.c
$ ./sysenter_step
Segmentation fault (core dumped)
The program is expected to crash, and the #DB handler will issue a warning.
Kernel log:
WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160
...
RIP: 0010:exc_debug_kernel+0xd2/0x160
...
Call Trace:
<#DB>
? show_regs+0x68/0x80
? __warn+0x8c/0x140
? exc_debug_kernel+0xd2/0x160
? report_bug+0x175/0x1a0
? handle_bug+0x44/0x90
? exc_invalid_op+0x1c/0x70
? asm_exc_invalid_op+0x1f/0x30
? exc_debug_kernel+0xd2/0x160
exc_debug+0x43/0x50
asm_exc_debug+0x1e/0x40
RIP: 0010:clear_bhb_loop+0x0/0xb0
...
#DB>
- https://git.kernel.org/stable/c/08518d48e5b744620524f0acd7c26c19bda7f513
- https://git.kernel.org/stable/c/a765679defe1dc1b8fa01928a6ad6361e72a1364
- https://git.kernel.org/stable/c/ac8b270b61d48fcc61f052097777e3b5e11591e0
- https://git.kernel.org/stable/c/dae3543db8f0cf8ac1a198c3bb4b6e3c24d576cf
- https://git.kernel.org/stable/c/db56615e96c439e13783d7715330e824b4fd4b84
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-08-08
CVE-2024-42241
In the Linux kernel, the following vulnerability has been resolved: mm/shmem: disable PMD-sized page cache if needed For shmem files, it's possible that PMD-sized page cache can't be supported by xarray. For example, 512MB page cache on ARM64 when the base page size is 64KB can't be supported by xarray. It leads to errors as the following messages indicate when this sort of xarray entry is split. WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 \ nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject \ nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs \ libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \ net_failover virtio_console virtio_blk failover dimlib virtio_mmio CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff8000882af5f0 x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768 x26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858 x23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0 x5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x720 truncate_inode_partial_folio+0xdc/0x160 shmem_undo_range+0x2bc/0x6a8 shmem_fallocate+0x134/0x430 vfs_fallocate+0x124/0x2e8 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger than MAX_PAGECACHE_ORDER. As Matthew Wilcox pointed, the page cache in a shmem file isn't represented by a multi-index entry and doesn't have this limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache").
Modified: 2024-08-08
CVE-2024-42243
In the Linux kernel, the following vulnerability has been resolved:
mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray
Patch series "mm/filemap: Limit page cache size to that supported by
xarray", v2.
Currently, xarray can't support arbitrary page cache size. More details
can be found from the WARN_ON() statement in xas_split_alloc(). In our
test whose code is attached below, we hit the WARN_ON() on ARM64 system
where the base page size is 64KB and huge page size is 512MB. The issue
was reported long time ago and some discussions on it can be found here
[1].
[1] https://www.spinics.net/lists/linux-xfs/msg75404.html
In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one
supported by xarray and avoid PMD-sized page cache if needed. The code
changes are suggested by David Hildenbrand.
PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray
PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path
PATCH[4] avoids PMD-sized page cache for shmem files if needed
Test program
============
# cat test.c
#define _GNU_SOURCE
#include
Modified: 2025-11-03
CVE-2024-42244
In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on resume Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
- https://git.kernel.org/stable/c/1094ed500987e67a9d18b0f95e1812f1cc720856
- https://git.kernel.org/stable/c/553e67dec846323b5575e78a776cf594c13f98c4
- https://git.kernel.org/stable/c/5ae6a64f18211851c8df6b4221381c438b9a7348
- https://git.kernel.org/stable/c/932a86a711c722b45ed47ba2103adca34d225b33
- https://git.kernel.org/stable/c/b14aa5673e0a8077ff4b74f0bb260735e7d5e6a4
- https://git.kernel.org/stable/c/c15a688e49987385baa8804bf65d570e362f8576
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42245
In the Linux kernel, the following vulnerability has been resolved: Revert "sched/fair: Make sure to try to detach at least one movable task" This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iteration in detach_tasks(), as we now must fully iterate every task on a cpu if all or most are pinned. Since this load balance code is done with rq lock held, and often in softirq context, it is very easy to trigger hard lockups. We observed such hard lockups with a user who affined O(10k) threads to a single cpu. When I discussed this with Vincent he initially suggested that we keep the limit on the number of tasks to detach, but increase the number of tasks we can search. However, after some back and forth on the mailing list, he recommended we instead revert the original patch, as it seems likely no one was actually getting hit by the original issue.
- https://git.kernel.org/stable/c/0fa6dcbfa2e2b97c1e6febbea561badf0931a38b
- https://git.kernel.org/stable/c/1e116c18e32b035a2d1bd460800072c8bf96bc44
- https://git.kernel.org/stable/c/2feab2492deb2f14f9675dd6388e9e2bf669c27a
- https://git.kernel.org/stable/c/d467194018dd536fe6c65a2fd3aedfcdb1424903
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42246
In the Linux kernel, the following vulnerability has been resolved: net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN. ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request().
- https://git.kernel.org/stable/c/02ee1976edb21a96ce8e3fd4ef563f14cc16d041
- https://git.kernel.org/stable/c/5d8254e012996cee1a0f9cc920531cb7e4d9a011
- https://git.kernel.org/stable/c/626dfed5fa3bfb41e0dffd796032b555b69f9cde
- https://git.kernel.org/stable/c/934247ea65bc5eca8bdb7f8c0ddc15cef992a5d6
- https://git.kernel.org/stable/c/bc790261218952635f846aaf90bcc0974f6f62c6
- https://git.kernel.org/stable/c/d6c686c01c5f12ff8f7264e0ddf71df6cb0d4414
- https://git.kernel.org/stable/c/f2431e7db0fe0daccb2f06bb0d23740affcd2fa6
- https://git.kernel.org/stable/c/f388cfd913a2b96c05339a335f365795db1b36b6
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42247
In the Linux kernel, the following vulnerability has been resolved: wireguard: allowedips: avoid unaligned 64-bit memory accesses On the parisc platform, the kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc) Avoid such unaligned memory accesses by instead using the get_unaligned_be64() helper macro. [Jason: replace src[8] in original patch with src+8]
- https://git.kernel.org/stable/c/217978a29c6ceca76d3c640bf94bdf50c268d801
- https://git.kernel.org/stable/c/2fb34bf76431e831f9863cd59adc0bd1f67b0fbf
- https://git.kernel.org/stable/c/6638a203abad35fa636d59ac47bdbc4bc100fd74
- https://git.kernel.org/stable/c/948f991c62a4018fb81d85804eeab3029c6209f8
- https://git.kernel.org/stable/c/ae630de24efb123d7199a43256396d7758f4cb75
- https://git.kernel.org/stable/c/b4764f0ad3d68de8a0b847c05f427afb86dd54e6
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-08-08
CVE-2024-42248
In the Linux kernel, the following vulnerability has been resolved: tty: serial: ma35d1: Add a NULL check for of_node The pdev->dev.of_node can be NULL if the "serial" node is absent. Add a NULL check to return an error in such cases.
Modified: 2024-09-06
CVE-2024-42251
In the Linux kernel, the following vulnerability has been resolved:
mm: page_ref: remove folio_try_get_rcu()
The below bug was reported on a non-SMP kernel:
[ 275.267158][ T4335] ------------[ cut here ]------------
[ 275.267949][ T4335] kernel BUG at include/linux/page_ref.h:275!
[ 275.268526][ T4335] invalid opcode: 0000 [#1] KASAN PTI
[ 275.269001][ T4335] CPU: 0 PID: 4335 Comm: trinity-c3 Not tainted 6.7.0-rc4-00061-gefa7df3e3bb5 #1
[ 275.269787][ T4335] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 275.270679][ T4335] RIP: 0010:try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))
[ 275.272813][ T4335] RSP: 0018:ffffc90005dcf650 EFLAGS: 00010202
[ 275.273346][ T4335] RAX: 0000000000000246 RBX: ffffea00066e0000 RCX: 0000000000000000
[ 275.274032][ T4335] RDX: fffff94000cdc007 RSI: 0000000000000004 RDI: ffffea00066e0034
[ 275.274719][ T4335] RBP: ffffea00066e0000 R08: 0000000000000000 R09: fffff94000cdc006
[ 275.275404][ T4335] R10: ffffea00066e0037 R11: 0000000000000000 R12: 0000000000000136
[ 275.276106][ T4335] R13: ffffea00066e0034 R14: dffffc0000000000 R15: ffffea00066e0008
[ 275.276790][ T4335] FS: 00007fa2f9b61740(0000) GS:ffffffff89d0d000(0000) knlGS:0000000000000000
[ 275.277570][ T4335] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 275.278143][ T4335] CR2: 00007fa2f6c00000 CR3: 0000000134b04000 CR4: 00000000000406f0
[ 275.278833][ T4335] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 275.279521][ T4335] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 275.280201][ T4335] Call Trace:
[ 275.280499][ T4335]
Modified: 2025-11-03
CVE-2024-42253
In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock race Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
- https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34
- https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904
- https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41
- https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42259
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
- https://git.kernel.org/stable/c/3e06073d24807f04b4694108a8474decb7b99e60
- https://git.kernel.org/stable/c/4b09513ce93b3dcb590baaaff2ce96f2d098312d
- https://git.kernel.org/stable/c/50111a8098fb9ade621eeff82228a997d42732ab
- https://git.kernel.org/stable/c/8bdd9ef7e9b1b2a73e394712b72b22055e0e26c3
- https://git.kernel.org/stable/c/911f8055f175c82775d0fd8cedcd0b75413f4ba7
- https://git.kernel.org/stable/c/a256d019eaf044864c7e50312f0a65b323c24f39
- https://git.kernel.org/stable/c/e8a68aa842d3f8dd04a46b9d632e5f67fde1da9b
- https://git.kernel.org/stable/c/ead9289a51ea82eb5b27029fcf4c34b2dd60cf06
- https://project-zero.issues.chromium.org/issues/42451707
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42265
In the Linux kernel, the following vulnerability has been resolved: protect the fetch of ->fd[fd] in do_dup2() from mispredictions both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.
- https://git.kernel.org/stable/c/08775b3d6ed117cf4518754ec7300ee42b6a5368
- https://git.kernel.org/stable/c/1171ceccabfd596ca370c5d2cbb47d110c3f2fe1
- https://git.kernel.org/stable/c/3f480493550b6a23d3a65d095d6569d4a7f56a0f
- https://git.kernel.org/stable/c/41a6c31df77bd8e050136b0a200b537da9e1084a
- https://git.kernel.org/stable/c/5db999fff545b924b24c9afd368ef5c17279b176
- https://git.kernel.org/stable/c/8aa37bde1a7b645816cda8b80df4753ecf172bf1
- https://git.kernel.org/stable/c/da72e783afd27d9f487836b2e6738146c0edd149
- https://git.kernel.org/stable/c/ed42e8ff509d2a61c6642d1825032072dab79f26
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42267
In the Linux kernel, the following vulnerability has been resolved: riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.
- https://git.kernel.org/stable/c/0c710050c47d45eb77b28c271cddefc5c785cb40
- https://git.kernel.org/stable/c/20dbdebc5580cd472a310d56a6e252275ee4c864
- https://git.kernel.org/stable/c/59be4a167782d68e21068a761b90b01fadc09146
- https://git.kernel.org/stable/c/917f598209f3f5e4ab175d5079d8aeb523e58b1f
- https://git.kernel.org/stable/c/d4e7db757e2d7f4c407a007e92c98477eab215d2
- https://git.kernel.org/stable/c/d7ccf2ca772bfe33e2c53ef80fa20d2d87eb6144
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42268
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix missing lock on sync reset reload
On sync reset reload work, when remote host updates devlink on reload
actions performed on that host, it misses taking devlink lock before
calling devlink_remote_reload_actions_performed() which results in
triggering lock assert like the following:
WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50
…
CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116
Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015
Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core]
RIP: 0010:devl_assert_locked+0x3e/0x50
…
Call Trace:
- https://git.kernel.org/stable/c/091268f3c27a5b6d7858a3bb2a0dbcc9cd26ddb5
- https://git.kernel.org/stable/c/572f9caa9e7295f8c8822e4122c7ae8f1c412ff9
- https://git.kernel.org/stable/c/5d07d1d40aabfd61bab21115639bd4f641db6002
- https://git.kernel.org/stable/c/98884e89c90d077f6fe6ba18e6cf6f914642f04e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42269
In the Linux kernel, the following vulnerability has been resolved: netfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init(). ip6table_nat_table_init() accesses net->gen->ptr[ip6table_nat_net_ops.id], but the function is exposed to user space before the entry is allocated via register_pernet_subsys(). Let's call register_pernet_subsys() before xt_register_template().
- https://git.kernel.org/stable/c/419ee6274c5153b89c4393c1946faa4c3cad4f9e
- https://git.kernel.org/stable/c/87dba44e9471b79b255d0736858a897332db9226
- https://git.kernel.org/stable/c/91b6df6611b7edb28676c4f63f90c56c30d3e601
- https://git.kernel.org/stable/c/c22921df777de5606f1047b1345b8d22ef1c0b34
- https://git.kernel.org/stable/c/e85b9b6a87be4cb3710082038b677e97f2389003
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42270
In the Linux kernel, the following vulnerability has been resolved:
netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init().
We had a report that iptables-restore sometimes triggered null-ptr-deref
at boot time. [0]
The problem is that iptable_nat_table_init() is exposed to user space
before the kernel fully initialises netns.
In the small race window, a user could call iptable_nat_table_init()
that accesses net_generic(net, iptable_nat_net_id), which is available
only after registering iptable_nat_net_ops.
Let's call register_pernet_subsys() before xt_register_template().
[0]:
bpfilter: Loaded bpfilter_umh pid 11702
Started bpfilter
BUG: kernel NULL pointer dereference, address: 0000000000000013
PF: supervisor write access in kernel mode
PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
PREEMPT SMP NOPTI
CPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1
Hardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017
RIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat
Code: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 <48> 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c
RSP: 0018:ffffbef902843cd0 EFLAGS: 00010246
RAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80
RDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0
RBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240
R10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000
R13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004
FS: 00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/08ed888b69a22647153fe2bec55b7cd0a46102cc
- https://git.kernel.org/stable/c/5830aa863981d43560748aa93589c0695191d95d
- https://git.kernel.org/stable/c/70014b73d7539fcbb6b4ff5f37368d7241d8e626
- https://git.kernel.org/stable/c/95590a4929027769af35b153645c0ab6fd22b29b
- https://git.kernel.org/stable/c/b98ddb65fa1674b0e6b52de8af9103b63f51b643
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42271
In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use after free in iucv_sock_close() iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn(). Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing. Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv. B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.
- https://git.kernel.org/stable/c/01437282fd3904810603f3dc98d2cac6b8b6fc84
- https://git.kernel.org/stable/c/37652fbef9809411cea55ea5fa1a170e299efcd0
- https://git.kernel.org/stable/c/69620522c48ce8215e5eb55ffbab8cafee8f407d
- https://git.kernel.org/stable/c/84f40b46787ecb67c7ad08a5bb1376141fa10c01
- https://git.kernel.org/stable/c/8b424c9e44111c5a76f41c6b741f8d4c4179d876
- https://git.kernel.org/stable/c/ac758e1f663fe9bc64f6b47212a2aa18697524f5
- https://git.kernel.org/stable/c/c65f72eec60a34ace031426e04e9aff8e5f04895
- https://git.kernel.org/stable/c/f558120cd709682b739207b48cf7479fd9568431
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42273
In the Linux kernel, the following vulnerability has been resolved: f2fs: assign CURSEG_ALL_DATA_ATGC if blkaddr is valid mkdir /mnt/test/comp f2fs_io setflags compression /mnt/test/comp dd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1 truncate --size 13 /mnt/test/comp/testfile In the above scenario, we can get a BUG_ON. kernel BUG at fs/f2fs/segment.c:3589! Call Trace: do_write_page+0x78/0x390 [f2fs] f2fs_outplace_write_data+0x62/0xb0 [f2fs] f2fs_do_write_data_page+0x275/0x740 [f2fs] f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs] f2fs_write_multi_pages+0x1e5/0xae0 [f2fs] f2fs_write_cache_pages+0xab1/0xc60 [f2fs] f2fs_write_data_pages+0x2d8/0x330 [f2fs] do_writepages+0xcf/0x270 __writeback_single_inode+0x44/0x350 writeback_sb_inodes+0x242/0x530 __writeback_inodes_wb+0x54/0xf0 wb_writeback+0x192/0x310 wb_workfn+0x30d/0x400 The reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the page was set the gcing flag by set_cluster_dirty().
- https://git.kernel.org/stable/c/0cd106612396656d6f1ca17ef192c6759bb60791
- https://git.kernel.org/stable/c/4239571c5db46a42f723b8fa8394039187c34439
- https://git.kernel.org/stable/c/5fd057160ab240dd816ae09b625395d54c297de1
- https://git.kernel.org/stable/c/8cb1f4080dd91c6e6b01dbea013a3f42341cb6a1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42274
In the Linux kernel, the following vulnerability has been resolved:
Revert "ALSA: firewire-lib: operate for period elapse event in process context"
Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event
in process context") removed the process context workqueue from
amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove
its overhead.
With RME Fireface 800, this lead to a regression since
Kernels 5.14.0, causing an AB/BA deadlock competition for the
substream lock with eventual system freeze under ALSA operation:
thread 0:
* (lock A) acquire substream lock by
snd_pcm_stream_lock_irq() in
snd_pcm_status64()
* (lock B) wait for tasklet to finish by calling
tasklet_unlock_spin_wait() in
tasklet_disable_in_atomic() in
ohci_flush_iso_completions() of ohci.c
thread 1:
* (lock B) enter tasklet
* (lock A) attempt to acquire substream lock,
waiting for it to be released:
snd_pcm_stream_lock_irqsave() in
snd_pcm_period_elapsed() in
update_pcm_pointers() in
process_ctx_payloads() in
process_rx_packets() of amdtp-stream.c
? tasklet_unlock_spin_wait
- https://git.kernel.org/stable/c/36c255db5a25edd42d1aca48e38b8e95ee5fd9ef
- https://git.kernel.org/stable/c/3dab73ab925a51ab05543b491bf17463a48ca323
- https://git.kernel.org/stable/c/7c07220cf634002f93a87ca2252a32766850f2d1
- https://git.kernel.org/stable/c/b239a37d68e8bc59f9516444da222841e3b13ba9
- https://git.kernel.org/stable/c/f5043e69aeb2786f32e84132817a007a6430aa7d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42276
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: add missing condition check for existence of mapped data nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference.
- https://git.kernel.org/stable/c/3f8ec1d6b0ebd8268307d52be8301973fa5a01ec
- https://git.kernel.org/stable/c/70100fe721840bf6d8e5abd25b8bffe4d2e049b7
- https://git.kernel.org/stable/c/77848b379e9f85a08048a2c8b3b4a7e8396f5f83
- https://git.kernel.org/stable/c/7cc1f4cd90a00b6191cb8cda2d1302fdce59361c
- https://git.kernel.org/stable/c/be23ae63080e0bf9e246ab20207200bca6585eba
- https://git.kernel.org/stable/c/c31fad1470389666ac7169fe43aa65bf5b7e2cfd
- https://git.kernel.org/stable/c/d135c3352f7c947a922da93c8e763ee6bc208b64
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42277
In the Linux kernel, the following vulnerability has been resolved: iommu: sprd: Avoid NULL deref in sprd_iommu_hw_en In sprd_iommu_cleanup() before calling function sprd_iommu_hw_en() dom->sdev is equal to NULL, which leads to null dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/630482ee0653decf9e2482ac6181897eb6cde5b8
- https://git.kernel.org/stable/c/8c79ceb4ecf823e6ec10fee6febb0fca3de79922
- https://git.kernel.org/stable/c/b62841e49a2b7938f6fdeaaf93fb57e4eb880bdb
- https://git.kernel.org/stable/c/d5fe884ce28c5005f8582c35333c195a168f841c
- https://git.kernel.org/stable/c/dfe90030a0cfa26dca4cb6510de28920e5ad22fb
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-10-02
CVE-2024-42279
In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer While transmitting with rx_len == 0, the RX FIFO is not going to be emptied in the interrupt handler. A subsequent transfer could then read crap from the previous transfer out of the RX FIFO into the start RX buffer. The core provides a register that will empty the RX and TX FIFOs, so do that before each transfer.
Modified: 2025-11-03
CVE-2024-42280
In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix a use after free in hfcmulti_tx() Don't dereference *sp after calling dev_kfree_skb(*sp).
- https://git.kernel.org/stable/c/4d8b642985ae24f4b3656438eb8489834a17bb80
- https://git.kernel.org/stable/c/61ab751451f5ebd0b98e02276a44e23a10110402
- https://git.kernel.org/stable/c/70db2c84631f50e02e6b32b543700699dd395803
- https://git.kernel.org/stable/c/7e4a539bca7d8d20f2c5d93c18cce8ef77cd78e0
- https://git.kernel.org/stable/c/8f4030277dfb9dbe04fd78566b19931097c9d629
- https://git.kernel.org/stable/c/9460ac3dd1ae033bc2b021a458fb535a0c36ddb2
- https://git.kernel.org/stable/c/d3e4d4a98c5629ccdcb762a0ff6c82ba9738a0c3
- https://git.kernel.org/stable/c/ddc79556641ee070d36be0de4a1f0a16a71f1fc7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42281
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a segment issue when downgrading gso_size Linearize the skb when downgrading gso_size because it may trigger a BUG_ON() later when the skb is segmented as described in [1,2].
- https://git.kernel.org/stable/c/11ec79f5c7f74261874744039bc1551023edd6b2
- https://git.kernel.org/stable/c/a689f5eb13a90f892a088865478b3cd39f53d5dc
- https://git.kernel.org/stable/c/c3496314c53e7e82ddb544c825defc3e8c0e45cf
- https://git.kernel.org/stable/c/dda518dea60d556a2d171c0122ca7d9fdb7d473a
- https://git.kernel.org/stable/c/ec4eea14d75f7b0491194dd413f540dd19b8c733
- https://git.kernel.org/stable/c/f6bb8c90cab97a3e03f8d30e3069efe6a742e0be
- https://git.kernel.org/stable/c/fa5ef655615a01533035c6139248c5b33aa27028
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42283
In the Linux kernel, the following vulnerability has been resolved: net: nexthop: Initialize all fields in dumped nexthops struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52 The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.
- https://git.kernel.org/stable/c/1377de719652d868f5317ba8398b7e74c5f0430b
- https://git.kernel.org/stable/c/5cc4d71dda2dd4f1520f40e634a527022e48ccd8
- https://git.kernel.org/stable/c/6d745cd0e9720282cd291d36b9db528aea18add2
- https://git.kernel.org/stable/c/7704460acd7f5d35eb07c52500987dc9b95313fb
- https://git.kernel.org/stable/c/9e8f558a3afe99ce51a642ce0d3637ddc2b5d5d0
- https://git.kernel.org/stable/c/a13d3864b76ac87085ec530b2ff8e37482a63a96
- https://git.kernel.org/stable/c/fd06cb4a5fc7bda3dea31712618a62af72a1c6cb
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42284
In the Linux kernel, the following vulnerability has been resolved: tipc: Return non-zero value from tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address.
- https://git.kernel.org/stable/c/253405541be2f15ffebdeac2f4cf4b7e9144d12f
- https://git.kernel.org/stable/c/2abe350db1aa599eeebc6892237d0bce0f1de62a
- https://git.kernel.org/stable/c/5eea127675450583680c8170358bcba43227bd69
- https://git.kernel.org/stable/c/728734352743a78b4c5a7285b282127696a4a813
- https://git.kernel.org/stable/c/76ddf84a52f0d8ec3f5db6ccce08faf202a17d28
- https://git.kernel.org/stable/c/7ec3335dd89c8d169e9650e4bac64fde71fdf15b
- https://git.kernel.org/stable/c/aa38bf74899de07cf70b50cd17f8ad45fb6654c8
- https://git.kernel.org/stable/c/fa96c6baef1b5385e2f0c0677b32b3839e716076
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42285
In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix a use-after-free related to destroying CM IDs iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler; rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished.
- https://git.kernel.org/stable/c/557d035fe88d78dd51664f4dc0e1896c04c97cf6
- https://git.kernel.org/stable/c/7f25f296fc9bd0435be14e89bf657cd615a23574
- https://git.kernel.org/stable/c/94ee7ff99b87435ec63211f632918dc7f44dac79
- https://git.kernel.org/stable/c/aee2424246f9f1dadc33faa78990c1e2eb7826e4
- https://git.kernel.org/stable/c/d91d253c87fd1efece521ff2612078a35af673c6
- https://git.kernel.org/stable/c/dc8074b8901caabb97c2d353abd6b4e7fa5a59a5
- https://git.kernel.org/stable/c/ee39384ee787e86e9db4efb843818ef0ea9cb8ae
- https://git.kernel.org/stable/c/ff5bbbdee08287d75d72e65b72a2b76d9637892a
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42286
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: validate nvme_local_port correctly The driver load failed with error message, qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef and with a kernel crash, BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 Workqueue: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000 RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Call Trace: qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx] Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port.
- https://git.kernel.org/stable/c/3eac973eb5cb2b874b3918f924798afc5affd46b
- https://git.kernel.org/stable/c/549aac9655320c9b245a24271b204668c5d40430
- https://git.kernel.org/stable/c/7cec2c3bfe84539c415f5e16f989228eba1d2f1e
- https://git.kernel.org/stable/c/a3ab508a4853a9f5ae25a7816a4889f09938f63c
- https://git.kernel.org/stable/c/cde43031df533751b4ead37d173922feee2f550f
- https://git.kernel.org/stable/c/e1f010844443c389bc552884ac5cfa47de34d54c
- https://git.kernel.org/stable/c/eb1d4ce2609584eeb7694866f34d4b213caa3af9
- https://git.kernel.org/stable/c/f6be298cc1042f24d521197af29c7c4eb95af4d5
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42287
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Complete command early within lock
A crash was observed while performing NPIV and FW reset,
BUG: kernel NULL pointer dereference, address: 000000000000001c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 1 PREEMPT_RT SMP NOPTI
RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0
RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034
R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000
R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000
FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/314efe3f87949a568f512f05df20bf47b81cf232
- https://git.kernel.org/stable/c/36fdc5319c4d0ec8b8938ec4769764098a246bfb
- https://git.kernel.org/stable/c/4475afa2646d3fec176fc4d011d3879b26cb26e3
- https://git.kernel.org/stable/c/57ba7563712227647f82a92547e82c96cd350553
- https://git.kernel.org/stable/c/814f4a53cc86f7ea8b501bfb1723f24fd29ef5ee
- https://git.kernel.org/stable/c/9117337b04d789bd08fdd9854a40bec2815cd3f6
- https://git.kernel.org/stable/c/af46649304b0c9cede4ccfc2be2561ce8ed6a2ea
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42288
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix for possible memory corruption Init Control Block is dereferenced incorrectly. Correctly dereference ICB
- https://git.kernel.org/stable/c/2a15b59a2c5afac89696e44acf5bbfc0599c6c5e
- https://git.kernel.org/stable/c/571d7f2a08836698c2fb0d792236424575b9829b
- https://git.kernel.org/stable/c/8192c533e89d9fb69b2490398939236b78cda79b
- https://git.kernel.org/stable/c/87db8d7b7520e99de71791260989f06f9c94953d
- https://git.kernel.org/stable/c/b0302ffc74123b6a99d7d1896fcd9b2e4072d9ce
- https://git.kernel.org/stable/c/c03d740152f78e86945a75b2ad541bf972fab92a
- https://git.kernel.org/stable/c/dae67169cb35a37ecccf60cfcd6bf93a1f4f5efb
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42289
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: During vport delete send async logout explicitly
During vport delete, it is observed that during unload we hit a crash
because of stale entries in outstanding command array. For all these stale
I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but
I/Os could not complete while vport delete is in process of deleting.
BUG: kernel NULL pointer dereference, address: 000000000000001c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
Workqueue: qla2xxx_wq qla_do_work [qla2xxx]
RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0
RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8
R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000
R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0
Call Trace:
- https://git.kernel.org/stable/c/086489256696eb774654a5410e86381c346356fe
- https://git.kernel.org/stable/c/171ac4b495f9473bc134356a00095b47e6409e52
- https://git.kernel.org/stable/c/76f480d7c717368f29a3870f7d64471ce0ff8fb2
- https://git.kernel.org/stable/c/87c25fcb95aafabb6a4914239f4ab41b07a4f9b7
- https://git.kernel.org/stable/c/b12c54e51ba83c1fbc619d35083d7872e42ecdef
- https://git.kernel.org/stable/c/b35d6d5a2f38605cddea7d5c64cded894fbe8ede
- https://git.kernel.org/stable/c/d28a2075bb530489715a3b011e1dd8765ba20313
- https://git.kernel.org/stable/c/e5ed6a26ffdec0c91cf0b6138afbd675c00ad5fc
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42290
In the Linux kernel, the following vulnerability has been resolved: irqchip/imx-irqsteer: Handle runtime power management correctly The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0 Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context. [ tglx: Rewrote change log, added Fixes tag ]
- https://git.kernel.org/stable/c/21bd3f9e7f924cd2fc892a484e7a50c7e1847565
- https://git.kernel.org/stable/c/33b1c47d1fc0b5f06a393bb915db85baacba18ea
- https://git.kernel.org/stable/c/3a2884a44e5cda192df1b28e9925661f79f599a1
- https://git.kernel.org/stable/c/58c56735facb225a5c46fa4b8bbbe7f31d1cb894
- https://git.kernel.org/stable/c/a590e8dea3df2639921f874d763be961dd74e8f9
- https://git.kernel.org/stable/c/f8ae38f1dfe652779c7c613facbc257cec00ac44
- https://git.kernel.org/stable/c/fa1803401e1c360efe6342fb41d161cc51748a11
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42291
In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.
- https://git.kernel.org/stable/c/292081c4e7f575a79017d5cbe1a0ec042783976f
- https://git.kernel.org/stable/c/6ebbe97a488179f5dc85f2f1e0c89b486e99ee97
- https://git.kernel.org/stable/c/8e02cd98a6e24389d476e28436d41e620ed8e559
- https://git.kernel.org/stable/c/d62389073a5b937413e2d1bc1da06ccff5103c0c
- https://git.kernel.org/stable/c/e81b674ead8e2172b2a69e7b45e079239ace4dbc
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42292
In the Linux kernel, the following vulnerability has been resolved: kobject_uevent: Fix OOB access within zap_modalias_env() zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.
- https://git.kernel.org/stable/c/57fe01d3d04276875c7e3a6dc763517fc05b8762
- https://git.kernel.org/stable/c/648d5490460d38436640da0812bf7f6351c150d2
- https://git.kernel.org/stable/c/68d63ace80b76395e7935687ecdb86421adc2168
- https://git.kernel.org/stable/c/81a15d28f32af01493ae8c5457e0d55314a4167d
- https://git.kernel.org/stable/c/b59a5e86a3934f1b6a5bd1368902dbc79bdecc90
- https://git.kernel.org/stable/c/c5ee8adc8d98a49703320d13878ba2b923b142f5
- https://git.kernel.org/stable/c/d4663536754defff75ff1eca0aaebc41da165a8d
- https://git.kernel.org/stable/c/dd6e9894b451e7c85cceb8e9dc5432679a70e7dc
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-08-19
CVE-2024-42294
In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between sd_remove & sd_release Our test report the following hung task: [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex) SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in this scenario. This is a classic ABBA deadlock. To fix the deadlock, make sure we don't try to acquire disk->open_mutex after freezing the queue.
Modified: 2025-11-03
CVE-2024-42295
In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle inconsistent state in nilfs_btnode_create_block() Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug. It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state. So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.
- https://git.kernel.org/stable/c/012be828a118bf496e666ef1fc47fc0e7358ada2
- https://git.kernel.org/stable/c/02b87e6334a38c65eef49848d3f1ac422f0b2a44
- https://git.kernel.org/stable/c/19cce46238ffe3546e44b9c74057103ff8b24c62
- https://git.kernel.org/stable/c/366c3f688dd0288cbe38af1d3a886b5c62372e4a
- https://git.kernel.org/stable/c/4811f7af6090e8f5a398fbdd766f903ef6c0d787
- https://git.kernel.org/stable/c/5f0a6800b8aec1b453c7fe4c44fcaac5ffe9d52e
- https://git.kernel.org/stable/c/be56dfc9be0604291267c07b0e27a69a6bda4899
- https://git.kernel.org/stable/c/e34191cce3ee63dfa5fb241904aaf2a042d5b6d8
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42296
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix return value of f2fs_convert_inline_inode() If device is readonly, make f2fs_convert_inline_inode() return EROFS instead of zero, otherwise it may trigger panic during writeback of inline inode's dirty page as below: f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888 f2fs_write_cache_pages fs/f2fs/data.c:3187 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3342 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369 do_writepages+0x359/0x870 mm/page-writeback.c:2634 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397 __filemap_fdatawrite_range mm/filemap.c:430 [inline] file_write_and_wait_range+0x1aa/0x290 mm/filemap.c:788 f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276 generic_write_sync include/linux/fs.h:2806 [inline] f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977 call_write_iter include/linux/fs.h:2114 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
- https://git.kernel.org/stable/c/077f0e24b27c4b44841593c7edbd1993be9eecb5
- https://git.kernel.org/stable/c/1e7725814361c8c008d131db195cef8274ff26b8
- https://git.kernel.org/stable/c/47a8ddcdcaccd9b891db4574795e46a33a121ac2
- https://git.kernel.org/stable/c/70f5ef5f33c333cfb286116fa3af74ac9bc84f1b
- https://git.kernel.org/stable/c/a8eb3de28e7a365690c61161e7a07a4fc7c60bbf
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42297
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't dirty inode for readonly filesystem syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode().
- https://git.kernel.org/stable/c/192b8fb8d1c8ca3c87366ebbef599fa80bb626b8
- https://git.kernel.org/stable/c/2434344559f6743efb3ac15d11af9a0db9543bd3
- https://git.kernel.org/stable/c/2d2916516577f2239b3377d9e8d12da5e6ccdfcf
- https://git.kernel.org/stable/c/54162974aea37a8cae00742470a78c7f6bd6f915
- https://git.kernel.org/stable/c/54bc4e88447e385c4d4ffa85d93e0dce628fcfa6
- https://git.kernel.org/stable/c/9ce8135accf103f7333af472709125878704fdd4
- https://git.kernel.org/stable/c/e62ff092a42f4a1bae3b310cf46673b4f3aac3b5
- https://git.kernel.org/stable/c/ec56571b4b146a1cfbedab49d5fcaf19fe8bf4f1
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-10
CVE-2024-42298
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: fsl_qmc_audio: Check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value.
Modified: 2025-11-03
CVE-2024-42299
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page().
- https://git.kernel.org/stable/c/0484adcb5fbcadd9ba0fd4485c42630f72e97da9
- https://git.kernel.org/stable/c/0a4ae2644e2a3b3b219aad9639fb2b0691d08420
- https://git.kernel.org/stable/c/2cac0df3324b5e287d8020bc0708f7d2dec88a6f
- https://git.kernel.org/stable/c/2fef55d8f78383c8e6d6d4c014b9597375132696
- https://git.kernel.org/stable/c/b90ceffdc975502bc085ce8e79c6adeff05f9521
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42301
In the Linux kernel, the following vulnerability has been resolved: dev/parport: fix the array out-of-bounds risk Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]
- https://git.kernel.org/stable/c/166a0bddcc27de41fe13f861c8348e8e53e988c8
- https://git.kernel.org/stable/c/47b3dce100778001cd76f7e9188944b5cb27a76d
- https://git.kernel.org/stable/c/7789a1d6792af410aa9b39a1eb237ed24fa2170a
- https://git.kernel.org/stable/c/7f4da759092a1a6ce35fb085182d02de8cc4cc84
- https://git.kernel.org/stable/c/a44f88f7576bc1916d8d6293f5c62fbe7cbe03e0
- https://git.kernel.org/stable/c/ab11dac93d2d568d151b1918d7b84c2d02bacbd5
- https://git.kernel.org/stable/c/b579ea3516c371ecf59d073772bc45dfd28c8a0e
- https://git.kernel.org/stable/c/c719b393374d3763e64900ee19aaed767d5a08d6
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-03-27
CVE-2024-42302
In the Linux kernel, the following vulnerability has been resolved: PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal Keith reports a use-after-free when a DPC event occurs concurrently to hot-removal of the same portion of the hierarchy: The dpc_handler() awaits readiness of the secondary bus below the Downstream Port where the DPC event occurred. To do so, it polls the config space of the first child device on the secondary bus. If that child device is concurrently removed, accesses to its struct pci_dev cause the kernel to oops. That's because pci_bridge_wait_for_secondary_bus() neglects to hold a reference on the child device. Before v6.3, the function was only called on resume from system sleep or on runtime resume. Holding a reference wasn't necessary back then because the pciehp IRQ thread could never run concurrently. (On resume from system sleep, IRQs are not enabled until after the resume_noirq phase. And runtime resume is always awaited before a PCI device is removed.) However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset"), which introduced that, failed to appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a reference on the child device because dpc_handler() and pciehp may indeed run concurrently. The commit was backported to v5.10+ stable kernels, so that's the oldest one affected. Add the missing reference acquisition. Abridged stack trace: BUG: unable to handle page fault for address: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() pcie_do_recovery() dpc_handler()
- https://git.kernel.org/stable/c/11a1f4bc47362700fcbde717292158873fb847ed
- https://git.kernel.org/stable/c/2c111413f38ca5cf87557cab89f6d82b0e3433e7
- https://git.kernel.org/stable/c/2cc8973bdc4d6c928ebe38b88090a2cdfe81f42f
- https://git.kernel.org/stable/c/b16f3ea1db47a6766a9f1169244cf1fc287a7c62
- https://git.kernel.org/stable/c/c52f9e1a9eb40f13993142c331a6cfd334d4b91d
- https://git.kernel.org/stable/c/f63df70b439bb8331358a306541893bf415bf1da
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-29
CVE-2024-42303
In the Linux kernel, the following vulnerability has been resolved: media: imx-pxp: Fix ERR_PTR dereference in pxp_probe() devm_regmap_init_mmio() can fail, add a check and bail out in case of error.
Modified: 2025-11-03
CVE-2024-42304
In the Linux kernel, the following vulnerability has been resolved: ext4: make sure the first directory block is not a hole The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported. After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash. Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.
- https://git.kernel.org/stable/c/299bc6ffa57e04e74c6cce866d6c0741fb4897a1
- https://git.kernel.org/stable/c/9771e3d8365ae1dd5e8846a204cb9af14e3e656a
- https://git.kernel.org/stable/c/b609753cbbd38f8c0affd4956c0af178348523ac
- https://git.kernel.org/stable/c/c3893d9de8ee153baac56d127d844103488133b5
- https://git.kernel.org/stable/c/d81d7e347d1f1f48a5634607d39eb90c161c8afe
- https://git.kernel.org/stable/c/de2a011a13a46468a6e8259db58b1b62071fe136
- https://git.kernel.org/stable/c/e02f9941e8c011aa3eafa799def6a134ce06bcfa
- https://git.kernel.org/stable/c/f9ca51596bbfd0f9c386dd1c613c394c78d9e5e6
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42305
In the Linux kernel, the following vulnerability has been resolved:
ext4: check dot and dotdot of dx_root before making dir indexed
Syzbot reports a issue as follows:
============================================
BUG: unable to handle page fault for address: ffffed11022e24fe
PGD 23ffee067 P4D 23ffee067 PUD 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0
Call Trace:
- https://git.kernel.org/stable/c/19e13b4d7f0303186fcc891aba8d0de7c8fdbda8
- https://git.kernel.org/stable/c/42d420517072028fb0eb852c358056b7717ba5aa
- https://git.kernel.org/stable/c/50ea741def587a64e08879ce6c6a30131f7111e7
- https://git.kernel.org/stable/c/8afe06ed3be7a874b3cd82ef5f8959aca8d6429a
- https://git.kernel.org/stable/c/9d241b7a39af192d1bb422714a458982c7cc67a2
- https://git.kernel.org/stable/c/abb411ac991810c0bcbe51c2e76d2502bf611b5c
- https://git.kernel.org/stable/c/b80575ffa98b5bb3a5d4d392bfe4c2e03e9557db
- https://git.kernel.org/stable/c/cdd345321699042ece4a9d2e70754d2397d378c5
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42306
In the Linux kernel, the following vulnerability has been resolved: udf: Avoid using corrupted block bitmap buffer When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not.
- https://git.kernel.org/stable/c/2199e157a465aaf98294d3932797ecd7fce942d5
- https://git.kernel.org/stable/c/271cab2ca00652bc984e269cf1208699a1e09cdd
- https://git.kernel.org/stable/c/57053b3bcf3403b80db6f65aba284d7dfe7326af
- https://git.kernel.org/stable/c/6a43e3c210df6c5f00570f4be49a897677dbcb64
- https://git.kernel.org/stable/c/8ca170c39eca7cad6e0cfeb24e351d8f8eddcd65
- https://git.kernel.org/stable/c/a90d4471146de21745980cba51ce88e7926bcc4f
- https://git.kernel.org/stable/c/cae9e59cc41683408b70b9ab569f8654866ba914
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42309
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
- https://git.kernel.org/stable/c/13b5f3ee94bdbdc4b5f40582aab62977905aedee
- https://git.kernel.org/stable/c/2df7aac81070987b0f052985856aa325a38debf6
- https://git.kernel.org/stable/c/46d2ef272957879cbe30a884574320e7f7d78692
- https://git.kernel.org/stable/c/475a5b3b7c8edf6e583a9eb59cf28ea770602e14
- https://git.kernel.org/stable/c/6735d02ead7dd3adf74eb8b70aebd09e0ce78ec9
- https://git.kernel.org/stable/c/7e52c62ff029f95005915c0a11863b5fb5185c8c
- https://git.kernel.org/stable/c/d6ad202f73f8edba0cbc0065aa57a79ffe8fdcdc
- https://git.kernel.org/stable/c/f70ffeca546452d1acd3a70ada56ecb2f3e7f811
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42310
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
- https://git.kernel.org/stable/c/08f45102c81ad8bc9f85f7a25e9f64e128edb87d
- https://git.kernel.org/stable/c/2d209b2f862f6b8bff549ede541590a8d119da23
- https://git.kernel.org/stable/c/977ee4fe895e1729cd36cc26916bbb10084713d6
- https://git.kernel.org/stable/c/a658ae2173ab74667c009e2550455e6de5b33ddc
- https://git.kernel.org/stable/c/b6ac46a00188cde50ffba233e6efb366354a1de5
- https://git.kernel.org/stable/c/cb520c3f366c77e8d69e4e2e2781a8ce48d98e79
- https://git.kernel.org/stable/c/e74eb5e8089427c8c49e0dd5067e5f39ce3a4d56
- https://git.kernel.org/stable/c/f392c36cebf4c1d6997a4cc2c0f205254acef42a
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42311
In the Linux kernel, the following vulnerability has been resolved: hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode() Syzbot reports uninitialized value access issue as below: loop0: detected capacity change from 0 to 64 ===================================================== BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b It missed to initialize .tz_secondswest, .cached_start and .cached_blocks fields in struct hfs_inode_info after hfs_alloc_inode(), fix it.
- https://git.kernel.org/stable/c/10f7163bfb5f8b4e0c9c05a939f20b8540e33c65
- https://git.kernel.org/stable/c/26a2ed107929a855155429b11e1293b83e6b2a8b
- https://git.kernel.org/stable/c/4a52861cd76e79f1a593beb23d096523eb9732c2
- https://git.kernel.org/stable/c/58d83fc160505a7009c39dec64effaac5129b971
- https://git.kernel.org/stable/c/9c4e40b9b731220f9464975e49da75496e3865c4
- https://git.kernel.org/stable/c/d3493d6f0dfb1ab5225b62faa77732983f2187a1
- https://git.kernel.org/stable/c/d55aae5c1730d6b70d5d8eaff00113cd34772ea3
- https://git.kernel.org/stable/c/f7316b2b2f11cf0c6de917beee8d3de728be24db
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42312
In the Linux kernel, the following vulnerability has been resolved: sysctl: always initialize i_uid/i_gid Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed.
- https://git.kernel.org/stable/c/1deae34db9f4f8e0e03f891be2e2e15c15c8ac05
- https://git.kernel.org/stable/c/34a86adea1f2b3c3f9d864c8cce09dca644601ab
- https://git.kernel.org/stable/c/98ca62ba9e2be5863c7d069f84f7166b45a5b2f4
- https://git.kernel.org/stable/c/b2591c89a6e2858796111138c38fcb6851aa1955
- https://git.kernel.org/stable/c/c7e2f43d182f5dde473389dbb39f16c9f0d64536
- https://git.kernel.org/stable/c/ffde3af4b29bf97d62d82e1d45275587e10a991a
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42313
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free in vdec_close There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close.
- https://git.kernel.org/stable/c/4c9d235630d35db762b85a4149bbb0be9d504c36
- https://git.kernel.org/stable/c/66fa52edd32cdbb675f0803b3c4da10ea19b6635
- https://git.kernel.org/stable/c/6a96041659e834dc0b172dda4b2df512d63920c2
- https://git.kernel.org/stable/c/72aff311194c8ceda934f24fd6f250b8827d7567
- https://git.kernel.org/stable/c/a0157b5aa34eb43ec4c5510f9c260bbb03be937e
- https://git.kernel.org/stable/c/ad8cf035baf29467158e0550c7a42b7bb43d1db6
- https://git.kernel.org/stable/c/da55685247f409bf7f976cc66ba2104df75d8dad
- https://git.kernel.org/stable/c/f8e9a63b982a8345470c225679af4ba86e4a7282
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-03-27
CVE-2024-42314
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map use-after-free when adding pages to compressed bio At add_ra_bio_pages() we are accessing the extent map to calculate 'add_size' after we dropped our reference on the extent map, resulting in a use-after-free. Fix this by computing 'add_size' before dropping our extent map reference.
- https://git.kernel.org/stable/c/8e7860543a94784d744c7ce34b78a2e11beefa5c
- https://git.kernel.org/stable/c/b7859ff398b6b656e1689daa860eb34837b4bb89
- https://git.kernel.org/stable/c/c1cc3326e27b0bd7a2806b40bc48e49afaf951e7
- https://git.kernel.org/stable/c/c205565e0f2f439f278a4a94ee97b67ef7b56ae8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42315
In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential deadlock on __exfat_get_dentry_set When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock) To fix this, let's allocate bh-array with GFP_NOFS.
- https://git.kernel.org/stable/c/1d1970493c289e3f44b9ec847ed26a5dbdf56a62
- https://git.kernel.org/stable/c/632fb232b6bbf8277edcbe9ecd4b4d98ecb122eb
- https://git.kernel.org/stable/c/89fc548767a2155231128cb98726d6d2ea1256c9
- https://git.kernel.org/stable/c/a7ac198f8dba791e3144c4da48a5a9b95773ee4b
- https://git.kernel.org/stable/c/c052f775ee6ccacd3c97e4cf41a2a657e63d4259
- https://git.kernel.org/stable/c/cd1c7858641384191ff7033fb1fc65dfcd559c6f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-42316
In the Linux kernel, the following vulnerability has been resolved: mm/mglru: fix div-by-zero in vmpressure_calc_level() evict_folios() uses a second pass to reclaim folios that have gone through page writeback and become clean before it finishes the first pass, since folio_rotate_reclaimable() cannot handle those folios due to the isolation. The second pass tries to avoid potential double counting by deducting scan_control->nr_scanned. However, this can result in underflow of nr_scanned, under a condition where shrink_folio_list() does not increment nr_scanned, i.e., when folio_trylock() fails. The underflow can cause the divisor, i.e., scale=scanned+reclaimed in vmpressure_calc_level(), to become zero, resulting in the following crash: [exception RIP: vmpressure_work_fn+101] process_one_work at ffffffffa3313f2b Since scan_control->nr_scanned has no established semantics, the potential double counting has minimal risks. Therefore, fix the problem by not deducting scan_control->nr_scanned in evict_folios().
- https://git.kernel.org/stable/c/8b671fe1a879923ecfb72dda6caf01460dd885ef
- https://git.kernel.org/stable/c/8de7bf77f21068a5f602bb1e59adbc5ab533509d
- https://git.kernel.org/stable/c/a39e38be632f0e1c908d70d1c9cd071c03faf895
- https://git.kernel.org/stable/c/d6510f234c7d117790397f9bb150816b0a954a04
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42318
In the Linux kernel, the following vulnerability has been resolved: landlock: Don't lose track of restrictions on cred_transfer When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost. This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself. Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.)
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2566
- https://git.kernel.org/stable/c/0d74fd54db0bd0c0c224bef0da8fc95ea9c9f36c
- https://git.kernel.org/stable/c/16896914bace82d7811c62f3b6d5320132384f49
- https://git.kernel.org/stable/c/39705a6c29f8a2b93cf5b99528a55366c50014d1
- https://git.kernel.org/stable/c/916c648323fa53b89eedb34a0988ddaf01406117
- https://git.kernel.org/stable/c/b14cc2cf313bd29056fadbc8ecd7f957cf5791ff
- https://lore.kernel.org/all/20240817.shahka3Ee1iy@digikod.net/
- https://www.openwall.com/lists/oss-security/2024/08/17/2
- http://www.openwall.com/lists/oss-security/2024/08/17/2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42320
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error checks in dasd_copy_pair_store() dasd_add_busid() can return an error via ERR_PTR() if an allocation fails. However, two callsites in dasd_copy_pair_store() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with IS_ERR() and returning the error up the stack.
- https://git.kernel.org/stable/c/68d4c3722290ad300c295fb3435e835d200d5cb2
- https://git.kernel.org/stable/c/8e64d2356cbc800b4cd0e3e614797f76bcf0cdb8
- https://git.kernel.org/stable/c/cc8b7284d5076722e0b8062373b68d8e47c3bace
- https://git.kernel.org/stable/c/e511167e65d332d07b3c7a3d5a741ee9c19a8c27
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42321
In the Linux kernel, the following vulnerability has been resolved:
net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE
The following splat is easy to reproduce upstream as well as in -stable
kernels. Florian Westphal provided the following commit:
d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net")
but this complementary fix has been also suggested by Willem de Bruijn
and it can be easily backported to -stable kernel which consists in
using DEBUG_NET_WARN_ON_ONCE instead to silence the following splat
given __skb_get_hash() is used by the nftables tracing infrastructure to
to identify packets in traces.
[69133.561393] ------------[ cut here ]------------
[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/
[...]
[69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379
[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0
[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff
ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8
[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246
[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19
[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418
[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000
[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400
[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28
[69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000
[69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0
[69133.562040] Call Trace:
[69133.562044]
- https://git.kernel.org/stable/c/120f1c857a73e52132e473dee89b340440cb692b
- https://git.kernel.org/stable/c/4afbac11f2f629d1e62817c4e210bdfaa7521107
- https://git.kernel.org/stable/c/c5d21aabf1b31a79f228508af33aee83456bc1b0
- https://git.kernel.org/stable/c/eb03d9826aa646577342a952d658d4598381c035
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42322
In the Linux kernel, the following vulnerability has been resolved: ipvs: properly dereference pe in ip_vs_add_service Use pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression
- https://git.kernel.org/stable/c/211168339657f36f32fb597afd0e3ac82d726119
- https://git.kernel.org/stable/c/36c997f1e03601475ad0fda0e0f59b7a209e756b
- https://git.kernel.org/stable/c/3dd428039e06e1967ce294e2cd6342825aaaad77
- https://git.kernel.org/stable/c/b2c664df3bb46aabac6a5fd78aaa5bd614cfad97
- https://git.kernel.org/stable/c/c420cd5d5bc6797f3a8824e7d74f38f0c286fca5
- https://git.kernel.org/stable/c/cbd070a4ae62f119058973f6d2c984e325bce6e7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-11-03
CVE-2024-43817
In the Linux kernel, the following vulnerability has been resolved:
net: missing check virtio
Two missing check in virtio_net_hdr_to_skb() allowed syzbot
to crash kernels again
1. After the skb_segment function the buffer may become non-linear
(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere
the __skb_linearize function will not be executed, then the buffer will
remain non-linear. Then the condition (offset >= skb_headlen(skb))
becomes true, which causes WARN_ON_ONCE in skb_checksum_help.
2. The struct sk_buff and struct virtio_net_hdr members must be
mathematically related.
(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.
(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.
(remainder) may be 0 if division is without remainder.
offset+2 (4191) > skb_headlen() (1116)
WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303
Modules linked in:
CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303
Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef
RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209
RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001
RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c
R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d
FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/27874ca77bd2b05a3779c7b3a5c75d8dd7f0b40f
- https://git.kernel.org/stable/c/5b1997487a3f3373b0f580c8a20b56c1b64b0775
- https://git.kernel.org/stable/c/90d41ebe0cd4635f6410471efc1dd71b33e894cf
- https://git.kernel.org/stable/c/e269d79c7d35aa3808b1f3c1737d63dab504ddc8
- https://git.kernel.org/stable/c/e9164903b8b303c34723177b02fe91e49e3c4cd7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43818
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: Adjust error handling in case of absent codec device acpi_get_first_physical_node() can return NULL in several cases (no such device, ACPI table error, reference count drop to 0, etc). Existing check just emit error message, but doesn't perform return. Then this NULL pointer is passed to devm_acpi_dev_add_driver_gpios() where it is dereferenced. Adjust this error handling by adding error code return. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/1ba9856cf7f6492b47c1edf853137f320d583db5
- https://git.kernel.org/stable/c/5080808c3339de2220c602ab7c7fa23dc6c1a5a3
- https://git.kernel.org/stable/c/99b642dac24f6d09ba3ebf1d690be8aefff86164
- https://git.kernel.org/stable/c/b1173d64edd276c957b6d09e1f971c85b38f1519
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-03
CVE-2024-43821
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix a possible null pointer dereference In function lpfc_xcvr_data_show, the memory allocation with kmalloc might fail, thereby making rdp_context a null pointer. In the following context and functions that use this pointer, there are dereferencing operations, leading to null pointer dereference. To fix this issue, a null pointer check should be added. If it is null, use scnprintf to notify the user and return len.
Modified: 2025-11-03
CVE-2024-43823
In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs() If IORESOURCE_MEM is not provided in Device Tree due to any error, resource_list_first_type() will return NULL and pci_parse_request_of_pci_ranges() will just emit a warning. This will cause a NULL pointer dereference. Fix this bug by adding NULL return check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/0a6f1b5fe8ef8268aaa069035639968ceeea0a23
- https://git.kernel.org/stable/c/a231707a91f323af1e5d9f1722055ec2fc1c7775
- https://git.kernel.org/stable/c/bbba48ad67c53feea05936ea1e029dcca8057506
- https://git.kernel.org/stable/c/dbcdd1863ba2ec9b76ec131df25d797709e05597
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-30
CVE-2024-43825
In the Linux kernel, the following vulnerability has been resolved: iio: Fix the sorting functionality in iio_gts_build_avail_time_table The sorting in iio_gts_build_avail_time_table is not working as intended. It could result in an out-of-bounds access when the time is zero. Here are more details: 1. When the gts->itime_table[i].time_us is zero, e.g., the time sequence is `3, 0, 1`, the inner for-loop will not terminate and do out-of-bound writes. This is because once `times[j] > new`, the value `new` will be added in the current position and the `times[j]` will be moved to `j+1` position, which makes the if-condition always hold. Meanwhile, idx will be added one, making the loop keep running without termination and out-of-bound write. 2. If none of the gts->itime_table[i].time_us is zero, the elements will just be copied without being sorted as described in the comment "Sort times from all tables to one and remove duplicates". For more details, please refer to https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com.
Modified: 2025-11-03
CVE-2024-43828
In the Linux kernel, the following vulnerability has been resolved: ext4: fix infinite loop when replaying fast_commit When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable. Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039. This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range(). Thanks to Zhang Yi, for figuring out the real problem!
- https://git.kernel.org/stable/c/0619f7750f2b178a1309808832ab20d85e0ad121
- https://git.kernel.org/stable/c/181e63cd595c688194e07332f9944b3a63193de2
- https://git.kernel.org/stable/c/5ed0496e383cb6de120e56991385dce70bbb87c1
- https://git.kernel.org/stable/c/81f819c537d29932e4b9267f02411cbc8b355178
- https://git.kernel.org/stable/c/907c3fe532253a6ef4eb9c4d67efb71fab58c706
- https://git.kernel.org/stable/c/c6e67df64783e99a657ef2b8c834ba2bf54c539c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43829
In the Linux kernel, the following vulnerability has been resolved: drm/qxl: Add check for drm_cvt_mode Add check for the return value of drm_cvt_mode() and return the error if it fails in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/3efe34f95b1ac8c138a46b14ce75956db0d6ee7c
- https://git.kernel.org/stable/c/4b1f303bdeceac049e56e4b20eb5280bd9e02f4f
- https://git.kernel.org/stable/c/4e87f592a46bb804d8f833da6ce702ae4b55053f
- https://git.kernel.org/stable/c/62ef8d7816c8e4a6088275553818b9afc0ffaa03
- https://git.kernel.org/stable/c/7bd09a2db0f617377027a2bb0b9179e6959edff3
- https://git.kernel.org/stable/c/d4c57354a06cb4a77998ff8aa40af89eee30e07b
- https://git.kernel.org/stable/c/f28b353c0c6c7831a70ccca881bf2db5e6785cdd
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43830
In the Linux kernel, the following vulnerability has been resolved: leds: trigger: Unregister sysfs attributes before calling deactivate() Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups().
- https://git.kernel.org/stable/c/0788a6f3523d3686a9eed5ea1e6fcce6841277b2
- https://git.kernel.org/stable/c/09c1583f0e10c918855d6e7540a79461a353e5d6
- https://git.kernel.org/stable/c/3fb6a9d67cfd812a547ac73ec02e1077c26c640d
- https://git.kernel.org/stable/c/734ba6437e80dfc780e9ee9d95f912392d12b5ea
- https://git.kernel.org/stable/c/c0dc9adf9474ecb7106e60e5472577375aedaed3
- https://git.kernel.org/stable/c/c3b7a650c8717aa89df318364609c86cbc040156
- https://git.kernel.org/stable/c/cb8aa9d2a4c8a15d6a43ccf901ef3d094aa60374
- https://git.kernel.org/stable/c/d1415125b701ef13370e2761f691ec632a5eb93a
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43831
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Handle invalid decoder vsi Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is valid for future use.
- https://git.kernel.org/stable/c/1c109f23b271a02b9bb195c173fab41e3285a8db
- https://git.kernel.org/stable/c/59d438f8e02ca641c58d77e1feffa000ff809e9f
- https://git.kernel.org/stable/c/cdf05ae76198c513836bde4eb55f099c44773280
- https://git.kernel.org/stable/c/dbd3e4adb98e50ede74f00b3fa956fa29ef95e6c
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2024-43832
In the Linux kernel, the following vulnerability has been resolved: s390/uv: Don't call folio_wait_writeback() without a folio reference folio_wait_writeback() requires that no spinlocks are held and that a folio reference is held, as documented. After we dropped the PTL, the folio could get freed concurrently. So grab a temporary reference.
- https://git.kernel.org/stable/c/1a1eb2f3fc453dcd52726d13e863938561489cb7
- https://git.kernel.org/stable/c/3f29f6537f54d74e64bac0a390fb2e26da25800d
- https://git.kernel.org/stable/c/8736604ef53359a718c246087cd21dcec232d2fb
- https://git.kernel.org/stable/c/b21aba72aadd94bdac275deab021fc84d6c72b16
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43833
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Fix NULL pointer dereference in adding ancillary links In v4l2_async_create_ancillary_links(), ancillary links are created for lens and flash sub-devices. These are sub-device to sub-device links and if the async notifier is related to a V4L2 device, the source sub-device of the ancillary link is NULL, leading to a NULL pointer dereference. Check the notifier's sd field is non-NULL in v4l2_async_create_ancillary_links(). [Sakari Ailus: Reword the subject and commit messages slightly.]
- https://git.kernel.org/stable/c/249212ceb4187783af3801c57b92a5a25d410621
- https://git.kernel.org/stable/c/9b4667ea67854f0b116fe22ad11ef5628c5b5b5f
- https://git.kernel.org/stable/c/b87e28050d9b0959de24574d587825cfab2f13fb
- https://git.kernel.org/stable/c/fe0f92fd5320b393e44ca210805e653ea90cc982
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43834
In the Linux kernel, the following vulnerability has been resolved:
xdp: fix invalid wait context of page_pool_destroy()
If the driver uses a page pool, it creates a page pool with
page_pool_create().
The reference count of page pool is 1 as default.
A page pool will be destroyed only when a reference count reaches 0.
page_pool_destroy() is used to destroy page pool, it decreases a
reference count.
When a page pool is destroyed, ->disconnect() is called, which is
mem_allocator_disconnect().
This function internally acquires mutex_lock().
If the driver uses XDP, it registers a memory model with
xdp_rxq_info_reg_mem_model().
The xdp_rxq_info_reg_mem_model() internally increases a page pool
reference count if a memory model is a page pool.
Now the reference count is 2.
To destroy a page pool, the driver should call both page_pool_destroy()
and xdp_unreg_mem_model().
The xdp_unreg_mem_model() internally calls page_pool_destroy().
Only page_pool_destroy() decreases a reference count.
If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we
will face an invalid wait context warning.
Because xdp_unreg_mem_model() calls page_pool_destroy() with
rcu_read_lock().
The page_pool_destroy() internally acquires mutex_lock().
Splat looks like:
=============================
[ BUG: Invalid wait context ]
6.10.0-rc6+ #4 Tainted: G W
-----------------------------
ethtool/1806 is trying to lock:
ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150
other info that might help us debug this:
context-{5:5}
3 locks held by ethtool/1806:
stack backtrace:
CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed
Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021
Call Trace:
- https://git.kernel.org/stable/c/12144069209eec7f2090ce9afa15acdcc2c2a537
- https://git.kernel.org/stable/c/3fc1be360b99baeea15cdee3cf94252cd3a72d26
- https://git.kernel.org/stable/c/59a931c5b732ca5fc2ca727f5a72aeabaafa85ec
- https://git.kernel.org/stable/c/6c390ef198aa69795427a5cb5fd7cb4bc7e6cd7a
- https://git.kernel.org/stable/c/be9d08ff102df3ac4f66e826ea935cf3af63a4bd
- https://git.kernel.org/stable/c/bf0ce5aa5f2525ed1b921ba36de96e458e77f482
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43837
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT When loading a EXT program without specifying `attr->attach_prog_fd`, the `prog->aux->dst_prog` will be null. At this time, calling resolve_prog_type() anywhere will result in a null pointer dereference. Example stack trace: [ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 8.108262] Mem abort info: [ 8.108384] ESR = 0x0000000096000004 [ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.108722] SET = 0, FnV = 0 [ 8.108827] EA = 0, S1PTW = 0 [ 8.108939] FSC = 0x04: level 0 translation fault [ 8.109102] Data abort info: [ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000 [ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000 [ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 8.112783] Modules linked in: [ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1 [ 8.113230] Hardware name: linux,dummy-virt (DT) [ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0 [ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8 [ 8.113798] sp : ffff80008283b9f0 [ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001 [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000 [ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000 [ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff [ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720 [ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 [ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4 [ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f [ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c [ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000 [ 8.114126] Call trace: [ 8.114159] may_access_direct_pkt_data+0x24/0xa0 [ 8.114202] bpf_check+0x3bc/0x28c0 [ 8.114214] bpf_prog_load+0x658/0xa58 [ 8.114227] __sys_bpf+0xc50/0x2250 [ 8.114240] __arm64_sys_bpf+0x28/0x40 [ 8.114254] invoke_syscall.constprop.0+0x54/0xf0 [ 8.114273] do_el0_svc+0x4c/0xd8 [ 8.114289] el0_svc+0x3c/0x140 [ 8.114305] el0t_64_sync_handler+0x134/0x150 [ 8.114331] el0t_64_sync+0x168/0x170 [ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403) [ 8.118672] ---[ end trace 0000000000000000 ]--- One way to fix it is by forcing `attach_prog_fd` non-empty when bpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type` API broken which use verifier log to probe prog type and will log nothing if we reject invalid EXT prog before bpf_check(). Another way is by adding null check in resolve_prog_type(). The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wanted to correct type resolution for BPF_PROG_TYPE_TRACING programs. Before that, the type resolution of BPF_PROG_TYPE_EXT prog actually follows the logic below: prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type; It implies that when EXT program is not yet attached to `dst_prog`, the prog type should be EXT itself. This code worked fine in the past. So just keep using it. Fix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog` is not present in resolve_prog_type().
- https://git.kernel.org/stable/c/9d40fd516aeae6779e3c84c6b96700ca76285847
- https://git.kernel.org/stable/c/b29a880bb145e1f1c1df5ab88ed26b1495ff9f09
- https://git.kernel.org/stable/c/f7866c35873377313ff94398f17d425b28b71de1
- https://git.kernel.org/stable/c/fcac5feb06f31ee4c88bca9bf98d8bc3ca7d2615
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-03-27
CVE-2024-43839
In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace.
- https://git.kernel.org/stable/c/6ce46045f9b90d952602e2c0b8886cfadf860bf1
- https://git.kernel.org/stable/c/6d20c4044ab4d0e6a99aa35853e66f0aed5589e3
- https://git.kernel.org/stable/c/ab748dd10d8742561f2980fea08ffb4f0cacfdef
- https://git.kernel.org/stable/c/b0ff0cd0847b03c0a0abe20cfa900eabcfcb9e43
- https://git.kernel.org/stable/c/c90b1cd7758fd4839909e838ae195d19f8065d76
- https://git.kernel.org/stable/c/c9741a03dc8e491e57b95fba0058ab46b7e506da
- https://git.kernel.org/stable/c/e0f48f51d55fb187400e9787192eda09fa200ff5
- https://git.kernel.org/stable/c/f121740f69eda4da2de9a20a6687a13593e72540
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43841
In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: avoid reporting connection success with wrong SSID When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code.
- https://git.kernel.org/stable/c/05c4488a0e446c6ccde9f22b573950665e1cd414
- https://git.kernel.org/stable/c/36e92b5edc8e0daa18e9325674313802ce3fbc29
- https://git.kernel.org/stable/c/416d3c1538df005195721a200b0371d39636e05d
- https://git.kernel.org/stable/c/93e898a264b4e0a475552ba9f99a016eb43ef942
- https://git.kernel.org/stable/c/994fc2164a03200c3bf42fb45b3d49d9d6d33a4d
- https://git.kernel.org/stable/c/b5d14b0c6716fad7f0c94ac6e1d6f60a49f985c7
- https://git.kernel.org/stable/c/d3cc85a10abc8eae48988336cdd3689ab92581b3
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43842
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size. But then 'rate->he_gi' is used as array index instead of 'status->he_gi'. This can lead to go beyond array boundaries in case of 'rate->he_gi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake. Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/7a0edc3d83aff3a48813d78c9cad9daf38decc74
- https://git.kernel.org/stable/c/85099c7ce4f9e64c66aa397cd9a37473637ab891
- https://git.kernel.org/stable/c/96ae4de5bc4c8ba39fd072369398f59495b73f58
- https://git.kernel.org/stable/c/a2a095c08b95372d6d0c5819b77f071af5e75366
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-06-19
CVE-2024-43845
In the Linux kernel, the following vulnerability has been resolved: udf: Fix bogus checksum computation in udf_rename() Syzbot reports uninitialized memory access in udf_rename() when updating checksum of '..' directory entry of a moved directory. This is indeed true as we pass on-stack diriter.fi to the udf_update_tag() and because that has only struct fileIdentDesc included in it and not the impUse or name fields, the checksumming function is going to checksum random stack contents beyond the end of the structure. This is actually harmless because the following udf_fiiter_write_fi() will recompute the checksum from on-disk buffers where everything is properly included. So all that is needed is just removing the bogus calculation.
Modified: 2025-11-03
CVE-2024-43846
In the Linux kernel, the following vulnerability has been resolved:
lib: objagg: Fix general protection fault
The library supports aggregation of objects into other objects only if
the parent object does not have a parent itself. That is, nesting is not
supported.
Aggregation happens in two cases: Without and with hints, where hints
are a pre-computed recommendation on how to aggregate the provided
objects.
Nesting is not possible in the first case due to a check that prevents
it, but in the second case there is no check because the assumption is
that nesting cannot happen when creating objects based on hints. The
violation of this assumption leads to various warnings and eventually to
a general protection fault [1].
Before fixing the root cause, error out when nesting happens and warn.
[1]
general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80
[...]
Call Trace:
- https://git.kernel.org/stable/c/1936fa05a180834c3b52e0439a6bddc07814d3eb
- https://git.kernel.org/stable/c/22ae17a267f4812861f0c644186c3421ff97dbfc
- https://git.kernel.org/stable/c/499f742fed42e74f1321f4b12ca196a66a2b49fc
- https://git.kernel.org/stable/c/565213e005557eb6cc4e42189d26eb300e02f170
- https://git.kernel.org/stable/c/5adc61d29bbb461d7f7c2b48dceaa90ecd182eb7
- https://git.kernel.org/stable/c/8161263362154cbebfbf4808097b956a6a8cb98a
- https://git.kernel.org/stable/c/b4a3a89fffcdf09702b1f161b914e52abca1894d
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-25
CVE-2024-43847
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix invalid memory access while processing fragmented packets The monitor ring and the reo reinject ring share the same ring mask index. When the driver receives an interrupt for the reo reinject ring, the monitor ring is also processed, leading to invalid memory access. Since monitor support is not yet enabled in ath12k, the ring mask for the monitor ring should be removed. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1
Modified: 2025-11-03
CVE-2024-43849
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: protect locator_addr with the main mutex If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock.
- https://git.kernel.org/stable/c/107924c14e3ddd85119ca43c26a4ee1056fa9b84
- https://git.kernel.org/stable/c/3e815626d73e05152a8142f6e44aecc4133e6e08
- https://git.kernel.org/stable/c/475a77fb3f0e1d527f56c60b79f5879661df5b80
- https://git.kernel.org/stable/c/8543269567e2fb3d976a8255c5e348aed14f98bc
- https://git.kernel.org/stable/c/d0870c4847e77a49c2f91bb2a8e0fa3c1f8dea5c
- https://git.kernel.org/stable/c/eab05737ee22216250fe20d27f5a596da5ea6eb7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-30
CVE-2024-43850
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove The following warning is seen during bwmon_remove due to refcount imbalance, fix this by releasing the OPPs after use. Logs: WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158 Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Call trace: _opp_table_kref_release+0x150/0x158 dev_pm_opp_remove_table+0x100/0x1b4 devm_pm_opp_of_table_release+0x10/0x1c devm_action_release+0x14/0x20 devres_release_all+0xa4/0x104 device_unbind_cleanup+0x18/0x60 device_release_driver_internal+0x1ec/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 bwmon_driver_exit+0x18/0x524 [icc_bwmon] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x34/0xdc el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 --[ end trace 0000000000000000 ]---
Modified: 2025-11-03
CVE-2024-43851
In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: rename cpu_number1 to dummy_cpu_number The per cpu variable cpu_number1 is passed to xlnx_event_handler as argument "dev_id", but it is not used in this function. So drop the initialization of this variable and rename it to dummy_cpu_number. This patch is to fix the following call trace when the kernel option CONFIG_DEBUG_ATOMIC_SLEEP is enabled: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53 Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT) Call trace: dump_backtrace+0xd0/0xe0 show_stack+0x18/0x40 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x34 __might_resched+0x10c/0x140 __might_sleep+0x4c/0xa0 __kmem_cache_alloc_node+0xf4/0x168 kmalloc_trace+0x28/0x38 __request_percpu_irq+0x74/0x138 xlnx_event_manager_probe+0xf8/0x298 platform_probe+0x68/0xd8
- https://git.kernel.org/stable/c/4a95449dd975e2ea6629a034f3e74b46c9634916
- https://git.kernel.org/stable/c/a5e507fadab76393cbc12344ebd65a417a09aa46
- https://git.kernel.org/stable/c/a96e60a6ea6818fd37b1853283a512c49af38cf5
- https://git.kernel.org/stable/c/f762acdaff9e54688be16e6c832c73a61533c1df
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43853
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Prevent UAF in proc_cpuset_show()
An UAF can happen when /proc/cpuset is read as reported in [1].
This can be reproduced by the following methods:
1.add an mdelay(1000) before acquiring the cgroup_lock In the
cgroup_path_ns function.
2.$cat /proc/
- https://git.kernel.org/stable/c/10aeaa47e4aa2432f29b3e5376df96d7dac5537a
- https://git.kernel.org/stable/c/1be59c97c83ccd67a519d8a49486b3a8a73ca28a
- https://git.kernel.org/stable/c/27d6dbdc6485d68075a0ebf8544d6425c1ed84bb
- https://git.kernel.org/stable/c/29a8d4e02fd4840028c38ceb1536cc8f82a257d4
- https://git.kernel.org/stable/c/29ac1d238b3bf126af36037df80d7ecc4822341e
- https://git.kernel.org/stable/c/4e8d6ac8fc9f843e940ab7389db8136634e07989
- https://git.kernel.org/stable/c/688325078a8b5badd6e07ae22b27cd04e9947aec
- https://git.kernel.org/stable/c/96226fbed566f3f686f53a489a29846f2d538080
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43854
In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes.
- https://git.kernel.org/stable/c/129f95948a96105c1fad8e612c9097763e88ac5f
- https://git.kernel.org/stable/c/23a19655fb56f241e592041156dfb1c6d04da644
- https://git.kernel.org/stable/c/3fd11fe4f20756b4c0847f755a64cd96f8c6a005
- https://git.kernel.org/stable/c/899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f
- https://git.kernel.org/stable/c/9f4af4cf08f9a0329ade3d938f55d2220c40d0a6
- https://git.kernel.org/stable/c/cf6b45ea7a8df0f61bded1dc4a8561ac6ad143d2
- https://git.kernel.org/stable/c/d418313bd8f55c079a7da12651951b489a638ac1
- https://git.kernel.org/stable/c/ebc0e91ba76dc6544fff9f5b66408b1982806a00
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43855
In the Linux kernel, the following vulnerability has been resolved: md: fix deadlock between mddev_suspend and flush bio Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue. T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3. T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed. Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context.
- https://git.kernel.org/stable/c/2d0738a8322bf4e5bfe693d16b3111928a9ccfbf
- https://git.kernel.org/stable/c/32226070813140234b6c507084738e8e8385c5c6
- https://git.kernel.org/stable/c/611d5cbc0b35a752e657a83eebadf40d814d006b
- https://git.kernel.org/stable/c/ca963eefbc3331222b6121baa696d49ba2008811
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43856
In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03
- https://git.kernel.org/stable/c/1fe97f68fce1ba24bf823bfb0eb0956003473130
- https://git.kernel.org/stable/c/22094f5f52e7bc16c5bf9613365049383650b02e
- https://git.kernel.org/stable/c/257193083e8f43907e99ea633820fc2b3bcd24c7
- https://git.kernel.org/stable/c/28e8b7406d3a1f5329a03aa25a43aa28e087cb20
- https://git.kernel.org/stable/c/2f7bbdc744f2e7051d1cb47c8e082162df1923c9
- https://git.kernel.org/stable/c/87b34c8c94e29fa01d744e5147697f592998d954
- https://git.kernel.org/stable/c/f993a4baf6b622232e4c190d34c220179e5d61eb
- https://git.kernel.org/stable/c/fe2d246080f035e0af5793cb79067ba125e4fb63
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43858
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix array-index-out-of-bounds in diFree
- https://git.kernel.org/stable/c/538a27c8048f081a5ddd286f886eb986fbbc7f80
- https://git.kernel.org/stable/c/55b732c8b09b41148eaab2fa8e31b0af47671e00
- https://git.kernel.org/stable/c/63f7fdf733add82f126ea00e2e48f6eba15ac4b9
- https://git.kernel.org/stable/c/6aa6892a90a5a7fabffe5692ab9f06a7a46c6e42
- https://git.kernel.org/stable/c/8d8f9a477de0d7962342eedf2a599215b7c63d28
- https://git.kernel.org/stable/c/9b3a4345957f5372041bc4f59de322f62653e862
- https://git.kernel.org/stable/c/f73f969b2eb39ad8056f6c7f3a295fa2f85e313a
- https://git.kernel.org/stable/c/ff14eadc278663cac69d57d3ca7fb2f394e1f8a7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43859
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate preallocated blocks in f2fs_file_open() chenyuwen reports a f2fs bug as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011 fscrypt_set_bio_crypt_ctx+0x78/0x1e8 f2fs_grab_read_bio+0x78/0x208 f2fs_submit_page_read+0x44/0x154 f2fs_get_read_data_page+0x288/0x5f4 f2fs_get_lock_data_page+0x60/0x190 truncate_partial_data_page+0x108/0x4fc f2fs_do_truncate_blocks+0x344/0x5f0 f2fs_truncate_blocks+0x6c/0x134 f2fs_truncate+0xd8/0x200 f2fs_iget+0x20c/0x5ac do_garbage_collect+0x5d0/0xf6c f2fs_gc+0x22c/0x6a4 f2fs_disable_checkpoint+0xc8/0x310 f2fs_fill_super+0x14bc/0x1764 mount_bdev+0x1b4/0x21c f2fs_mount+0x20/0x30 legacy_get_tree+0x50/0xbc vfs_get_tree+0x5c/0x1b0 do_new_mount+0x298/0x4cc path_mount+0x33c/0x5fc __arm64_sys_mount+0xcc/0x15c invoke_syscall+0x60/0x150 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec It is because inode.i_crypt_info is not initialized during below path: - mount - f2fs_fill_super - f2fs_disable_checkpoint - f2fs_gc - f2fs_iget - f2fs_truncate So, let's relocate truncation of preallocated blocks to f2fs_file_open(), after fscrypt_file_open().
- https://git.kernel.org/stable/c/298b1e4182d657c3e388adcc29477904e9600ed5
- https://git.kernel.org/stable/c/3ba0ae885215b325605ff7ebf6de12ac2adf204d
- https://git.kernel.org/stable/c/5f04969136db674f133781626e0b692c5f2bf2f0
- https://git.kernel.org/stable/c/f44a25a8bfe0c15d33244539696cd9119cf44d18
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43860
In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Skip over memory region when node value is NULL In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. [Fixed title to fit within the prescribed 70-75 charcters]
- https://git.kernel.org/stable/c/2fa26ca8b786888673689ccc9da6094150939982
- https://git.kernel.org/stable/c/4e13b7c23988c0a13fdca92e94296a3bc2ff9f21
- https://git.kernel.org/stable/c/6884fd0283e0831be153fb8d82d9eda8a55acaaa
- https://git.kernel.org/stable/c/6b50462b473fdccdc0dfad73001147e40ff19a66
- https://git.kernel.org/stable/c/6c9ea3547fad252fe9ae5d3ed7e066e2085bf3a2
- https://git.kernel.org/stable/c/84beb7738459cac0ff9f8a7c4654b8ff82a702c0
- https://git.kernel.org/stable/c/9a17cf8b2ce483fa75258bc2cdcf628f24bcf5f8
- https://git.kernel.org/stable/c/c877a5f5268d4ab8224b9c9fbce3d746e4e72bc9
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43861
In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: fix memory leak for not ip packets Free the unused skb when not ip packets arrive.
- https://git.kernel.org/stable/c/37c093449704017870604994ba9b813cdb9475a4
- https://git.kernel.org/stable/c/3c90a69533b5bba73401ef884d033ea49ee99662
- https://git.kernel.org/stable/c/7ab107544b777c3bd7feb9fe447367d8edd5b202
- https://git.kernel.org/stable/c/c4251a3deccad852b27e60625f31fba6cc14372f
- https://git.kernel.org/stable/c/c6c5b91424fafc0f83852d961c10c7e43a001882
- https://git.kernel.org/stable/c/da518cc9b64df391795d9952aed551e0f782e446
- https://git.kernel.org/stable/c/e87f52225e04a7001bf55bbd7a330fa4252327b5
- https://git.kernel.org/stable/c/f2c353227de14b0289298ffc3ba92058c4768384
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43863
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock.
- https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc
- https://git.kernel.org/stable/c/9908dc0d2ef0e4aec8a242c098455729c0e2f017
- https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237
- https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e
- https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3
- https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-09-29
CVE-2024-43864
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks of modify header context The cited commit allocates a new modify header to replace the old one when updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support, modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry is freed, the right modify header context will be freed. And the panic of accessing error pointer is also fixed.
Modified: 2025-11-03
CVE-2024-43866
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.
- https://git.kernel.org/stable/c/1b75da22ed1e6171e261bc9265370162553d5393
- https://git.kernel.org/stable/c/5005e2e159b300c1b8c6820a1e13a62eb0127b9b
- https://git.kernel.org/stable/c/6048dec754554a1303d632be6042d3feb3295285
- https://git.kernel.org/stable/c/6b6c2ebd83f2bf97e8f221479372aaca97a4a9b2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43867
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcount underflow Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)
- https://git.kernel.org/stable/c/16998763c62bb465ebc409d0373b9cdcef1a61a6
- https://git.kernel.org/stable/c/2a1b327d57a8ac080977633a18999f032d7e9e3f
- https://git.kernel.org/stable/c/3bcb8bba72ce89667fa863054956267c450c47ef
- https://git.kernel.org/stable/c/906372e753c5027a1dc88743843b6aa2ad1aaecf
- https://git.kernel.org/stable/c/a9bf3efc33f1fbf88787a277f7349459283c9b95
- https://git.kernel.org/stable/c/ebebba4d357b6c67f96776a48ddbaf0060fa4c10
- https://git.kernel.org/stable/c/f23cd66933fe76b84d8e282e5606b4d99068c320
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43869
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix event leak upon exec and file release
The perf pending task work is never waited upon the matching event
release. In the case of a child event, released via free_event()
directly, this can potentially result in a leaked event, such as in the
following scenario that doesn't even require a weak IRQ work
implementation to trigger:
schedule()
prepare_task_switch()
=======>
- https://git.kernel.org/stable/c/104e258a004037bc7dba9f6085c71dad6af57ad4
- https://git.kernel.org/stable/c/3a5465418f5fd970e86a86c7f4075be262682840
- https://git.kernel.org/stable/c/9ad46f1fef421d43cdab3a7d1744b2f43b54dae0
- https://git.kernel.org/stable/c/ed2c202dac55423a52d7e2290f2888bf08b8ee99
- https://git.kernel.org/stable/c/f34d8307a73a18de5320fcc6f40403146d061891
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43870
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix event leak upon exit
When a task is scheduled out, pending sigtrap deliveries are deferred
to the target task upon resume to userspace via task_work.
However failures while adding an event's callback to the task_work
engine are ignored. And since the last call for events exit happen
after task work is eventually closed, there is a small window during
which pending sigtrap can be queued though ignored, leaking the event
refcount addition such as in the following scenario:
TASK A
-----
do_exit()
exit_task_work(tsk);
- https://git.kernel.org/stable/c/05d3fd599594abf79aad4484bccb2b26e1cb0b51
- https://git.kernel.org/stable/c/2fd5ad3f310de22836cdacae919dd99d758a1f1b
- https://git.kernel.org/stable/c/3d7a63352a93bdb8a1cdf29606bf617d3ac1c22a
- https://git.kernel.org/stable/c/67fad724f1b568b356c1065d50df46e6b30eb2f7
- https://git.kernel.org/stable/c/70882d7fa74f0731492a0d493e8515a4f7131831
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43871
In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().
- https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96
- https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d
- https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85
- https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43dc6c87c
- https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf
- https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701
- https://git.kernel.org/stable/c/bd50a974097bb82d52a458bd3ee39fb723129a0c
- https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43873
In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features
- https://git.kernel.org/stable/c/1e1fdcbdde3b7663e5d8faeb2245b9b151417d22
- https://git.kernel.org/stable/c/3062cb100787a9ddf45de30004b962035cd497fb
- https://git.kernel.org/stable/c/30bd4593669443ac58515e23557dc8cef70d8582
- https://git.kernel.org/stable/c/ea558f10fb05a6503c6e655a1b7d81fdf8e5924c
- https://git.kernel.org/stable/c/eab96e8716cbfc2834b54f71cc9501ad4eec963b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43875
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Clean up error handling in vpci_scan_bus() Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure.
- https://git.kernel.org/stable/c/0e27e2e8697b8ce96cdef43f135426525d9d1f8f
- https://git.kernel.org/stable/c/24414c842a24d0fd498f9db6d2a762a8dddf1832
- https://git.kernel.org/stable/c/7d368de78b60088ec9031c60c88976c0063ea4c0
- https://git.kernel.org/stable/c/8e0f5a96c534f781e8c57ca30459448b3bfe5429
- https://git.kernel.org/stable/c/b9e8695246bcfc028341470cbf92630cdc1ba36b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43876
In the Linux kernel, the following vulnerability has been resolved: PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup() Avoid large backtrace, it is sufficient to warn the user that there has been a link problem. Either the link has failed and the system is in need of maintenance, or the link continues to work and user has been informed. The message from the warning can be looked up in the sources. This makes an actual link issue less verbose. First of all, this controller has a limitation in that the controller driver has to assist the hardware with transition to L1 link state by writing L1IATN to PMCTRL register, the L1 and L0 link state switching is not fully automatic on this controller. In case of an ASMedia ASM1062 PCIe SATA controller which does not support ASPM, on entry to suspend or during platform pm_test, the SATA controller enters D3hot state and the link enters L1 state. If the SATA controller wakes up before rcar_pcie_wakeup() was called and returns to D0, the link returns to L0 before the controller driver even started its transition to L1 link state. At this point, the SATA controller did send an PM_ENTER_L1 DLLP to the PCIe controller and the PCIe controller received it, and the PCIe controller did set PMSR PMEL1RX bit. Once rcar_pcie_wakeup() is called, if the link is already back in L0 state and PMEL1RX bit is set, the controller driver has no way to determine if it should perform the link transition to L1 state, or treat the link as if it is in L0 state. Currently the driver attempts to perform the transition to L1 link state unconditionally, which in this specific case fails with a PMSR L1FAEG poll timeout, however the link still works as it is already back in L0 state. Reduce this warning verbosity. In case the link is really broken, the rcar_pcie_config_access() would fail, otherwise it will succeed and any system with this controller and ASM1062 can suspend without generating a backtrace.
- https://git.kernel.org/stable/c/2ae4769332dfdb97f4b6f5dc9ac8f46d02aaa3df
- https://git.kernel.org/stable/c/3ff3bdde950f1840df4030726cef156758a244d7
- https://git.kernel.org/stable/c/526a877c6273d4cd0d0aede84c1d620479764b1c
- https://git.kernel.org/stable/c/59c78e8fddc1fe68f14011450a09b3418127d2ad
- https://git.kernel.org/stable/c/c93637e6a4c4e1d0e85ef7efac78d066bbb24d96
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43877
In the Linux kernel, the following vulnerability has been resolved: media: pci: ivtv: Add check for DMA map result In case DMA fails, 'dma->SG_length' is 0. This value is later used to access 'dma->SGarray[dma->SG_length - 1]', which will cause out of bounds access. Add check to return early on invalid value. Adjust warnings accordingly. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/24062aa7407091dee3e45a8e8037df437e848718
- https://git.kernel.org/stable/c/38f72c7e7c6b55614f9407555fd5ce9d019b0fa4
- https://git.kernel.org/stable/c/3d8fd92939e21ff0d45100ab208f8124af79402a
- https://git.kernel.org/stable/c/629913d6d79508b166c66e07e4857e20233d85a9
- https://git.kernel.org/stable/c/81d0664bed91a858c7b50c263954b59d65f1b414
- https://git.kernel.org/stable/c/c766065e8272085ea9c436414b7ddf1f12e7787b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43879
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.
- https://git.kernel.org/stable/c/16ad67e73309db0c20cc2a651992bd01c05e6b27
- https://git.kernel.org/stable/c/19eaf4f2f5a981f55a265242ada2bf92b0c742dd
- https://git.kernel.org/stable/c/2e201b3d162c6c49417c438ffb30b58c9f85769f
- https://git.kernel.org/stable/c/45d20a1c54be4f3173862c7b950d4468447814c9
- https://git.kernel.org/stable/c/576c64622649f3ec07e97bac8fec8b8a2ef4d086
- https://git.kernel.org/stable/c/67b5f1054197e4f5553047759c15c1d67d4c8142
- https://git.kernel.org/stable/c/b289ebb0516526cb4abae081b7ec29fd4fa1209d
- https://git.kernel.org/stable/c/bcbd771cd5d68c0c52567556097d75f9fc4e7cd6
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43880
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_erp: Fix object nesting warning
ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM
(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can
contain more ACLs (i.e., tc filters), but the number of masks in each
region (i.e., tc chain) is limited.
In order to mitigate the effects of the above limitation, the device
allows filters to share a single mask if their masks only differ in up
to 8 consecutive bits. For example, dst_ip/25 can be represented using
dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the
number of masks being used (and therefore does not support mask
aggregation), but can contain a limited number of filters.
The driver uses the "objagg" library to perform the mask aggregation by
passing it objects that consist of the filter's mask and whether the
filter is to be inserted into the A-TCAM or the C-TCAM since filters in
different TCAMs cannot share a mask.
The set of created objects is dependent on the insertion order of the
filters and is not necessarily optimal. Therefore, the driver will
periodically ask the library to compute a more optimal set ("hints") by
looking at all the existing objects.
When the library asks the driver whether two objects can be aggregated
the driver only compares the provided masks and ignores the A-TCAM /
C-TCAM indication. This is the right thing to do since the goal is to
move as many filters as possible to the A-TCAM. The driver also forbids
two identical masks from being aggregated since this can only happen if
one was intentionally put in the C-TCAM to avoid a conflict in the
A-TCAM.
The above can result in the following set of hints:
H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta
H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta
After getting the hints from the library the driver will start migrating
filters from one region to another while consulting the computed hints
and instructing the device to perform a lookup in both regions during
the transition.
Assuming a filter with mask X is being migrated into the A-TCAM in the
new region, the hints lookup will return H1. Since H2 is the parent of
H1, the library will try to find the object associated with it and
create it if necessary in which case another hints lookup (recursive)
will be performed. This hints lookup for {mask Y, A-TCAM} will either
return H2 or H3 since the driver passes the library an object comparison
function that ignores the A-TCAM / C-TCAM indication.
This can eventually lead to nested objects which are not supported by
the library [1].
Fix by removing the object comparison function from both the driver and
the library as the driver was the only user. That way the lookup will
only return exact matches.
I do not have a reliable reproducer that can reproduce the issue in a
timely manner, but before the fix the issue would reproduce in several
minutes and with the fix it does not reproduce in over an hour.
Note that the current usefulness of the hints is limited because they
include the C-TCAM indication and represent aggregation that cannot
actually happen. This will be addressed in net-next.
[1]
WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0
Modules linked in:
CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42
Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0
[...]
Call Trace:
- https://git.kernel.org/stable/c/0e59c2d22853266704e127915653598f7f104037
- https://git.kernel.org/stable/c/25c6fd9648ad05da493a5d30881896a78a08b624
- https://git.kernel.org/stable/c/36a9996e020dd5aa325e0ecc55eb2328288ea6bb
- https://git.kernel.org/stable/c/4dc09f6f260db3c4565a4ec52ba369393598f2fb
- https://git.kernel.org/stable/c/97d833ceb27dc19f8777d63f90be4a27b5daeedf
- https://git.kernel.org/stable/c/9a5261a984bba4f583d966c550fa72c33ff3714e
- https://git.kernel.org/stable/c/fb5d4fc578e655d113f09565f6f047e15f7ab578
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-26
CVE-2024-43881
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: change DMA direction while mapping reinjected packets For fragmented packets, ath12k reassembles each fragment as a normal packet and then reinjects it into HW ring. In this case, the DMA direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise, an invalid payload may be reinjected into the HW and subsequently delivered to the host. Given that arbitrary memory can be allocated to the skb buffer, knowledge about the data contained in the reinjected buffer is lacking. Consequently, there’s a risk of private information being leaked. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1
Modified: 2025-11-03
CVE-2024-43882
In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal.
- https://git.kernel.org/stable/c/15469d46ba34559bfe7e3de6659115778c624759
- https://git.kernel.org/stable/c/368f6985d46657b8b466a421dddcacd4051f7ada
- https://git.kernel.org/stable/c/90dfbba89ad4f0d9c9744ecbb1adac4aa2ff4f3e
- https://git.kernel.org/stable/c/9b424c5d4130d56312e2a3be17efb0928fec4d64
- https://git.kernel.org/stable/c/d2a2a4714d80d09b0f8eb6438ab4224690b7121e
- https://git.kernel.org/stable/c/d5c3c7e26275a2d83b894d30f7582a42853a958f
- https://git.kernel.org/stable/c/f50733b45d865f91db90919f8311e2127ce5a0cb
- https://git.kernel.org/stable/c/f6cfc6bcfd5e1cf76115b6450516ea4c99897ae1
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43883
In the Linux kernel, the following vulnerability has been resolved: usb: vhci-hcd: Do not drop references before new references are gained At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.
- https://git.kernel.org/stable/c/128e82e41cf7d74a562726c1587d9d2ede1a0a37
- https://git.kernel.org/stable/c/4dacdb9720aaab10b6be121eae55820174d97174
- https://git.kernel.org/stable/c/585e6bc7d0a9bf73a8be3d3fb34e86b90cc61a14
- https://git.kernel.org/stable/c/5a3c473b28ae1c1f7c4dc129e30cb19ae6e96f89
- https://git.kernel.org/stable/c/9c3746ce8d8fcb3a2405644fc0eec7fc5312de80
- https://git.kernel.org/stable/c/afdcfd3d6fcdeca2735ca8d994c5f2d24a368f0a
- https://git.kernel.org/stable/c/c3d0857b7fc2c49f68f89128a5440176089a8f54
- https://git.kernel.org/stable/c/e8c1e606dab8c56cf074b43b98d0805de7322ba2
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43889
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix possible divide-by-0 panic in padata_mt_helper()
We are hit with a not easily reproducible divide-by-0 panic in padata.c at
bootup time.
[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI
[ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1
[ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021
[ 10.017908] Workqueue: events_unbound padata_mt_helper
[ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0
:
[ 10.017963] Call Trace:
[ 10.017968]
- https://git.kernel.org/stable/c/6d45e1c948a8b7ed6ceddb14319af69424db730c
- https://git.kernel.org/stable/c/8f5ffd2af7274853ff91d6cd62541191d9fbd10d
- https://git.kernel.org/stable/c/924f788c906dccaca30acab86c7124371e1d6f2c
- https://git.kernel.org/stable/c/a29cfcb848c31f22b4de6a531c3e1d68c9bfe09f
- https://git.kernel.org/stable/c/ab8b397d5997d8c37610252528edc54bebf9f6d3
- https://git.kernel.org/stable/c/da0ffe84fcc1627a7dff82c80b823b94236af905
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43890
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix overflow in get_free_elt() "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt".
- https://git.kernel.org/stable/c/236bb4690773ab6869b40bedc7bc8d889e36f9d6
- https://git.kernel.org/stable/c/302ceb625d7b990db205a15e371f9a71238de91c
- https://git.kernel.org/stable/c/788ea62499b3c18541fd6d621964d8fafbc4aec5
- https://git.kernel.org/stable/c/a172c7b22bc2feaf489cfc6d6865f7237134fdf8
- https://git.kernel.org/stable/c/bcf86c01ca4676316557dd482c8416ece8c2e143
- https://git.kernel.org/stable/c/cd10d186a5409a1fe6e976df82858e9773a698da
- https://git.kernel.org/stable/c/d3e4dbc2858fe85d1dbd2e72a9fc5dea988b5c18
- https://git.kernel.org/stable/c/eb223bf01e688dfe37e813c8988ee11c8c9f8d0a
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43892
In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one.
- https://git.kernel.org/stable/c/37a060b64ae83b76600d187d76591ce488ab836b
- https://git.kernel.org/stable/c/51c0b1bb7541f8893ec1accba59eb04361a70946
- https://git.kernel.org/stable/c/56fd70f4aa8b82199dbe7e99366b1fd7a04d86fb
- https://git.kernel.org/stable/c/912736a0435ef40e6a4ae78197ccb5553cb80b05
- https://git.kernel.org/stable/c/9972605a238339b85bd16b084eed5f18414d22db
- https://git.kernel.org/stable/c/e6cc9ff2ac0b5df9f25eb790934c3104f6710278
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43893
In the Linux kernel, the following vulnerability has been resolved:
serial: core: check uartclk for zero to avoid divide by zero
Calling ioctl TIOCSSERIAL with an invalid baud_base can
result in uartclk being zero, which will result in a
divide by zero error in uart_get_divisor(). The check for
uartclk being zero in uart_set_info() needs to be done
before other settings are made as subsequent calls to
ioctl TIOCSSERIAL for the same port would be impacted if
the uartclk check was done where uartclk gets set.
Oops: divide error: 0000 PREEMPT SMP KASAN PTI
RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)
Call Trace:
- https://git.kernel.org/stable/c/3bbd90fca824e6fd61fb20f6dd2b0fa5f8b14bba
- https://git.kernel.org/stable/c/52b138f1021113e593ee6ad258ce08fe90693a9e
- https://git.kernel.org/stable/c/55b2a5d331a6ceb1c4372945fdb77181265ba24f
- https://git.kernel.org/stable/c/68dc02f319b9ee54dc23caba742a5c754d1cccc8
- https://git.kernel.org/stable/c/6eabce6608d6f3440f4c03aa3d3ef50a47a3d193
- https://git.kernel.org/stable/c/9196e42a3b8eeff1707e6ef769112b4b6096be49
- https://git.kernel.org/stable/c/e13ba3fe5ee070f8a9dab60029d52b1f61da5051
- https://git.kernel.org/stable/c/e3ad503876283ac3fcca922a1bf243ef9eb0b0e2
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43894
In the Linux kernel, the following vulnerability has been resolved: drm/client: fix null pointer dereference in drm_client_modeset_probe In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
- https://git.kernel.org/stable/c/113fd6372a5bb3689aba8ef5b8a265ed1529a78f
- https://git.kernel.org/stable/c/24ddda932c43ffe156c7f3c568bed85131c63ae6
- https://git.kernel.org/stable/c/5291d4f73452c91e8a11f71207617e3e234d418e
- https://git.kernel.org/stable/c/612cae53e99ce32a58cb821b3b67199eb6e92dff
- https://git.kernel.org/stable/c/c763dfe09425152b6bb0e348900a637c62c2ce52
- https://git.kernel.org/stable/c/d64847c383100423aecb6ac5f18be5f4316d9d62
- https://git.kernel.org/stable/c/d64fc94f7bb24fc2be0d6bd5df8df926da461a6d
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43900
In the Linux kernel, the following vulnerability has been resolved: media: xc2028: avoid use-after-free in load_firmware_cb() syzkaller reported use-after-free in load_firmware_cb() [1]. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free. The process is as follows: task-6504 worker_thread tuner_probe <= alloc dvb_frontend [2] ... request_firmware_nowait <= create a worker ... tuner_remove <= free dvb_frontend ... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freed To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is null, report a warning and just return. [1]: ================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504 Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800) The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.
- https://git.kernel.org/stable/c/208deb6d8c3cb8c3acb1f41eb31cf68ea08726d5
- https://git.kernel.org/stable/c/68594cec291ff9523b9feb3f43fd853dcddd1f60
- https://git.kernel.org/stable/c/850304152d367f104d21c77cfbcc05806504218b
- https://git.kernel.org/stable/c/ef517bdfc01818419f7bd426969a0c86b14f3e0e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43902
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null checker before passing variables Checks null pointer before passing variables to functions. This fixes 3 NULL_RETURNS issues reported by Coverity.
- https://git.kernel.org/stable/c/1686675405d07f35eae7ff3d13a530034b899df2
- https://git.kernel.org/stable/c/4cc2a94d96caeb3c975acdae7351c2f997c32175
- https://git.kernel.org/stable/c/8092aa3ab8f7b737a34b71f91492c676a843043a
- https://git.kernel.org/stable/c/83c7f509ef087041604e9572938f82e18b724c9d
- https://git.kernel.org/stable/c/d0b8b23b9c2ebec693a36fea518d8f13493ad655
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43905
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr Check return value and conduct null pointer handling to avoid null pointer dereference.
- https://git.kernel.org/stable/c/0fa11f9df96217c2785b040629ff1a16900fb51c
- https://git.kernel.org/stable/c/2ac9deb7e087f0b461c3559d9eaa6b9cf19d3fa8
- https://git.kernel.org/stable/c/2e538944996d0dd497faf8ee81f8bfcd3aca7d80
- https://git.kernel.org/stable/c/50151b7f1c79a09117837eb95b76c2de76841dab
- https://git.kernel.org/stable/c/69a441473fec2fc2aa2cf56122d6c42c4266a239
- https://git.kernel.org/stable/c/c2629daf218a325f4d69754452cd42fe8451c15b
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-08-27
CVE-2024-43906
In the Linux kernel, the following vulnerability has been resolved: drm/admgpu: fix dereferencing null pointer context When user space sets an invalid ta type, the pointer context will be empty. So it need to check the pointer context before using it
Modified: 2025-11-03
CVE-2024-43907
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules Check the pointer value to fix potential null pointer dereference
- https://git.kernel.org/stable/c/0c065e50445aea2e0a1815f12e97ee49e02cbaac
- https://git.kernel.org/stable/c/13937a40aae4efe64592ba48c057ac3c72f7fe82
- https://git.kernel.org/stable/c/3a01bf2ca9f860fdc88c358567b8fa3033efcf30
- https://git.kernel.org/stable/c/c1749313f35b98e2e655479f037db37f19756622
- https://git.kernel.org/stable/c/d19fb10085a49b77578314f69fff21562f7cd054
- https://git.kernel.org/stable/c/e04d18c29954441aa1054af649f957ffad90a201
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43908
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the null pointer dereference to ras_manager Check ras_manager before using it
- https://git.kernel.org/stable/c/033187a70ba9743c73a810a006816e5553d1e7d4
- https://git.kernel.org/stable/c/48cada0ac79e4775236d642e9ec5998a7c7fb7a4
- https://git.kernel.org/stable/c/4c11d30c95576937c6c35e6f29884761f2dddb43
- https://git.kernel.org/stable/c/56e848034ccabe44e8f22ffcf49db771c17b0d0a
- https://git.kernel.org/stable/c/b89616333979114bb0da5fa40fb6e4a2f5294ca2
- https://git.kernel.org/stable/c/d81c1eeb333d84b3012a91c0500189dc1d71e46c
- https://git.kernel.org/stable/c/ff5c4eb71ee8951c789b079f6e948f86708b04ed
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43909
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix the null pointer dereference for smu7 optimize the code to avoid pass a null pointer (hwmgr->backend) to function smu7_update_edc_leakage_table.
- https://git.kernel.org/stable/c/09544cd95c688d3041328a4253bd7514972399bb
- https://git.kernel.org/stable/c/1b8aa82b80bd947b68a8ab051d960a0c7935e22d
- https://git.kernel.org/stable/c/37b9df457cbcf095963d18f17d6cb7dfa0a03fce
- https://git.kernel.org/stable/c/7f56f050f02c27ed89cce1ea0c04b34abce32751
- https://git.kernel.org/stable/c/c02c1960c93eede587576625a1221205a68a904f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43912
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: disallow setting special AP channel widths Setting the AP channel width is meant for use with the normal 20/40/... MHz channel width progression, and switching around in S1G or narrow channels isn't supported. Disallow that.
- https://git.kernel.org/stable/c/23daf1b4c91db9b26f8425cc7039cf96d22ccbfe
- https://git.kernel.org/stable/c/3d42f2125f6c89e1e71c87b9f23412afddbba45e
- https://git.kernel.org/stable/c/ac3bf6e47fd8da9bfe8027e1acfe0282a91584fc
- https://git.kernel.org/stable/c/c6ea738e3feb407a3283197d9a25d0788f4f3cee
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-43914
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid BUG_ON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:
kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
- https://git.kernel.org/stable/c/2c92f8c1c456d556f15cbf51667b385026b2e6a0
- https://git.kernel.org/stable/c/305a5170dc5cf3d395bb4c4e9239bca6d0b54b49
- https://git.kernel.org/stable/c/3b33740c1750a39e046339ff9240e954f0156707
- https://git.kernel.org/stable/c/4811d6e5d9f4090c3e0ff9890eb24077108046ab
- https://git.kernel.org/stable/c/6b33c468d543f6a83de2d61f09fec74b27e19fd2
- https://git.kernel.org/stable/c/775a9ba16c9ffe98fe54ebf14e55d5660f2bf600
- https://git.kernel.org/stable/c/bf0ff69a42a3d2d46876d0514ecf13dffc516666
- https://git.kernel.org/stable/c/c384dd4f1fb3b14a2fd199360701cc163ea88705
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44931
In the Linux kernel, the following vulnerability has been resolved: gpio: prevent potential speculation leaks in gpio_device_get_desc() Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc(). This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.
- https://git.kernel.org/stable/c/18504710442671b02d00e6db9804a0ad26c5a479
- https://git.kernel.org/stable/c/1b955f786a4bcde8c0ccb2b7d519def2acb6f3cc
- https://git.kernel.org/stable/c/672c19165fc96dfad531a5458e0b3cdab414aae4
- https://git.kernel.org/stable/c/9ae2d8e75b741dbcb0da374753f972410e83b5f3
- https://git.kernel.org/stable/c/9d682e89c44bd5819b01f3fbb45a8e3681a4b6d0
- https://git.kernel.org/stable/c/c65ab97efcd438cb4e9f299400f2ea55251f3a67
- https://git.kernel.org/stable/c/d776c0486b03a5c4afca65b8ff44573592bf93bb
- https://git.kernel.org/stable/c/d795848ecce24a75dfd46481aee066ae6fe39775
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-44934
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: wait for previous gc cycles when removing port
syzbot hit a use-after-free[1] which is caused because the bridge doesn't
make sure that all previous garbage has been collected when removing a
port. What happens is:
CPU 1 CPU 2
start gc cycle remove port
acquire gc lock first
wait for lock
call br_multicasg_gc() directly
acquire lock now but free port
the port can be freed
while grp timers still
running
Make sure all previous gc cycles have finished by using flush_work before
freeing the port.
[1]
BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861
Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699
CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
Call Trace:
- https://git.kernel.org/stable/c/0d8b26e10e680c01522d7cc14abe04c3265a928f
- https://git.kernel.org/stable/c/1e16828020c674b3be85f52685e8b80f9008f50f
- https://git.kernel.org/stable/c/92c4ee25208d0f35dafc3213cdf355fbe449e078
- https://git.kernel.org/stable/c/b2f794b168cf560682ff976b255aa6d29d14a658
- https://git.kernel.org/stable/c/e3145ca904fa8dbfd1a5bf0187905bc117b0efce
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44935
In the Linux kernel, the following vulnerability has been resolved:
sctp: Fix null-ptr-deref in reuseport_add_sock().
syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in
reuseport_add_sock(). [0]
The repro first creates a listener with SO_REUSEPORT. Then, it creates
another listener on the same port and concurrently closes the first
listener.
The second listen() calls reuseport_add_sock() with the first listener as
sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,
but the close() does clear it by reuseport_detach_sock().
The problem is SCTP does not properly synchronise reuseport_alloc(),
reuseport_add_sock(), and reuseport_detach_sock().
The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must
provide synchronisation for sockets that are classified into the same
reuseport group.
Otherwise, such sockets form multiple identical reuseport groups, and
all groups except one would be silently dead.
1. Two sockets call listen() concurrently
2. No socket in the same group found in sctp_ep_hashtable[]
3. Two sockets call reuseport_alloc() and form two reuseport groups
4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives
incoming packets
Also, the reported null-ptr-deref could occur.
TCP/UDP guarantees that would not happen by holding the hash bucket lock.
Let's apply the locking strategy to __sctp_hash_endpoint() and
__sctp_unhash_endpoint().
[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350
Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14
RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012
RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385
R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0
R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/05e4a0fa248240efd99a539853e844f0f0a9e6a5
- https://git.kernel.org/stable/c/1407be30fc17eff918a98e0a990c0e988f11dc84
- https://git.kernel.org/stable/c/52319d9d2f522ed939af31af70f8c3a0f0f67e6c
- https://git.kernel.org/stable/c/54b303d8f9702b8ab618c5032fae886b16356928
- https://git.kernel.org/stable/c/9ab0faa7f9ffe31296dbb9bbe6f76c72c14eea18
- https://git.kernel.org/stable/c/c9b3fc4f157867e858734e31022ebee8a24f0de7
- https://git.kernel.org/stable/c/e809a84c802377ef61525a298a1ec1728759b913
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44938
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix shift-out-of-bounds in dbDiscardAG When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative. This patch fixes the issue by exiting the loop directly when negative shift is found.
- https://git.kernel.org/stable/c/234e6ea0855cdb5673d54ecaf7dc5c78f3e84630
- https://git.kernel.org/stable/c/4de2c04c3acd5b84f50b0d2f8f09e9b2f42374b9
- https://git.kernel.org/stable/c/7063b80268e2593e58bee8a8d709c2f3ff93e2f2
- https://git.kernel.org/stable/c/bb7c605a754823b86dd74f6537ccb9d38a9dec5a
- https://git.kernel.org/stable/c/bd04a149e3a29e7f71b7956ed41dba34e42d539e
- https://git.kernel.org/stable/c/f650148b43949ca9e37e820804bb6026fff404f3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-11-03
CVE-2024-44939
In the Linux kernel, the following vulnerability has been resolved: jfs: fix null ptr deref in dtInsertEntry [syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time. [Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL.
- https://git.kernel.org/stable/c/53023ab11836ac56fd75f7a71ec1356e50920fa9
- https://git.kernel.org/stable/c/6ea10dbb1e6c58384136e9adfd75f81951e423f6
- https://git.kernel.org/stable/c/9c2ac38530d1a3ee558834dfa16c85a40fd0e702
- https://git.kernel.org/stable/c/ce6dede912f064a855acf6f04a04cbb2c25b8c8c
- https://git.kernel.org/stable/c/f98bf80b20f4a930589cda48a35f751a64fe0dc2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-01
CVE-2024-44940
In the Linux kernel, the following vulnerability has been resolved: fou: remove warn in gue_gro_receive on unsupported protocol Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler. Such a packet is easily constructed. Syzbot generates them and sets off this warning. Remove the warning as it is expected and not actionable. The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks").
- https://git.kernel.org/stable/c/3db4395332e7050ef9ddeb3052e6b5019f2a2a59
- https://git.kernel.org/stable/c/440ab7f97261bc28501636a13998e1b1946d2e79
- https://git.kernel.org/stable/c/5a2e37bc648a2503bf6d687aed27b9f4455d82eb
- https://git.kernel.org/stable/c/a925a200299a6dfc7c172f54da6f374edc930053
- https://git.kernel.org/stable/c/b1453a5616c7bd8acd90633ceba4e59105ba3b51
- https://git.kernel.org/stable/c/dd89a81d850fa9a65f67b4527c0e420d15bf836c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2026-04-01
CVE-2024-44941
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to cover read extent cache access with lock
syzbot reports a f2fs bug as below:
BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46
Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097
CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
Modified: 2024-08-27
CVE-2024-44942
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback. Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.
Modified: 2025-04-16
CVE-2024-44943
In the Linux kernel, the following vulnerability has been resolved:
mm: gup: stop abusing try_grab_folio
A kernel warning was reported when pinning folio in CMA memory when
launching SEV virtual machine. The splat looks like:
[ 464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_pages+0x423/0x520
[ 464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6
[ 464.325477] RIP: 0010:__get_user_pages+0x423/0x520
[ 464.325515] Call Trace:
[ 464.325520]
Modified: 2025-11-03
CVE-2024-44944
In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use helper function to calculate expect ID Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.
- https://git.kernel.org/stable/c/24f407042cf90b0872de667460230d8d50c06c39
- https://git.kernel.org/stable/c/27662b46f2adaa52c1665a82af4b21c42c4337fd
- https://git.kernel.org/stable/c/5e2c24f7b0911b15c29aefce760bcf770542fb61
- https://git.kernel.org/stable/c/64c0b8e64be8368617ef08dfc59a3160563a1435
- https://git.kernel.org/stable/c/66e7650dbbb8e236e781c670b167edc81e771450
- https://git.kernel.org/stable/c/74de442b8e12a207c07953ee068009a7701aff8f
- https://git.kernel.org/stable/c/782161895eb4ac45cf7cfa8db375bd4766cb8299
- https://git.kernel.org/stable/c/eb4ca1a97e08ff5b920664ba292e576257e2d184
- https://www.zerodayinitiative.com/advisories/ZDI-24-1182/
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44946
In the Linux kernel, the following vulnerability has been resolved: kcm: Serialise kcm_sendmsg() for the same socket. syzkaller reported UAF in kcm_release(). [0] The scenario is 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb. 2. Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory() 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue 4. Thread A faces an error and finally frees skb that is already in the write queue 5. kcm_release() does double-free the skb in the write queue When a thread is building a MSG_MORE skb, another thread must not touch it. Let's add a per-sk mutex and serialise kcm_sendmsg(). [0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167 CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated---
- https://git.kernel.org/stable/c/00425508f30baa5ab6449a1f478480ca7cffa6da
- https://git.kernel.org/stable/c/6633b17840bf828921254d788ccd15602843fe9b
- https://git.kernel.org/stable/c/72da240aafb142630cf16adc803ccdacb3780849
- https://git.kernel.org/stable/c/807067bf014d4a3ae2cc55bd3de16f22a01eb580
- https://git.kernel.org/stable/c/8c9cdbf600143bd6835c8b8351e5ac956da79aec
- https://git.kernel.org/stable/c/9c8d544ed619f704e2b70e63e08ab75630c2ea23
- https://git.kernel.org/stable/c/eb06c8d3022ce6738711191c89f9b3e9cfb91914
- https://git.kernel.org/stable/c/fa6c23fe6dcac8c8bd63920ee8681292a2bd544e
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44947
In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate. The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap(). This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter).
- https://git.kernel.org/stable/c/18a067240817bee8a9360539af5d79a4bf5398a5
- https://git.kernel.org/stable/c/33168db352c7b56ae18aa55c2cae1a1c5905d30e
- https://git.kernel.org/stable/c/3c0da3d163eb32f1f91891efaade027fa9b245b9
- https://git.kernel.org/stable/c/4690e2171f651e2b415e3941ce17f2f7b813aff6
- https://git.kernel.org/stable/c/49934861514d36d0995be8e81bb3312a499d8d9a
- https://git.kernel.org/stable/c/831433527773e665bdb635ab5783d0b95d1246f4
- https://git.kernel.org/stable/c/8c78303eafbf85a728dd84d1750e89240c677dd9
- https://git.kernel.org/stable/c/ac42e0f0eb66af966015ee33fd355bc6f5d80cd6
- https://project-zero.issues.chromium.org/issues/42451729
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44948
In the Linux kernel, the following vulnerability has been resolved: x86/mtrr: Check if fixed MTRRs exist before saving them MTRRs have an obsolete fixed variant for fine grained caching control of the 640K-1MB region that uses separate MSRs. This fixed variant has a separate capability bit in the MTRR capability MSR. So far all x86 CPUs which support MTRR have this separate bit set, so it went unnoticed that mtrr_save_state() does not check the capability bit before accessing the fixed MTRR MSRs. Though on a CPU that does not support the fixed MTRR capability this results in a #GP. The #GP itself is harmless because the RDMSR fault is handled gracefully, but results in a WARN_ON(). Add the missing capability check to prevent this.
- https://git.kernel.org/stable/c/06c1de44d378ec5439db17bf476507d68589bfe9
- https://git.kernel.org/stable/c/34f36e6ee5bd7eff8b2adcd9fcaef369f752d82e
- https://git.kernel.org/stable/c/388f1c954019f253a8383f7eb733f38d541e10b6
- https://git.kernel.org/stable/c/450b6b22acdaac67a18eaf5ed498421ffcf10051
- https://git.kernel.org/stable/c/8a90d3fc7c24608548d3a750671f9dac21d1a462
- https://git.kernel.org/stable/c/8aa79dfb216b865e96ff890bc4ea71650f9bc8d7
- https://git.kernel.org/stable/c/919f18f961c03d6694aa726c514184f2311a4614
- https://git.kernel.org/stable/c/ca7d00c5656d1791e28369919e3e10febe9c3b16
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44949
In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size.
- https://git.kernel.org/stable/c/00baca74fb5879e5f9034b6156671301f500f8ee
- https://git.kernel.org/stable/c/533de2f470baac40d3bf622fe631f15231a03c9f
- https://git.kernel.org/stable/c/642a0b7453daff0295310774016fcb56d1f5bc7f
- https://git.kernel.org/stable/c/7ae04ba36b381bffe2471eff3a93edced843240f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44954
In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.
- https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1
- https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5
- https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a
- https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747
- https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81
- https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d
- https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e
- https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-06
CVE-2024-44957
In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Switch from mutex to spinlock for irqfds irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock. Fix it by switching over to a spin lock.
Modified: 2025-11-03
CVE-2024-44958
In the Linux kernel, the following vulnerability has been resolved:
sched/smt: Fix unbalance sched_smt_present dec/inc
I got the following warn report while doing stress test:
jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0
Call Trace:
- https://git.kernel.org/stable/c/2a3548c7ef2e135aee40e7e5e44e7d11b893e7c4
- https://git.kernel.org/stable/c/2cf7665efe451e48d27953e6b5bc627d518c902b
- https://git.kernel.org/stable/c/65727331b60197b742089855ac09464c22b96f66
- https://git.kernel.org/stable/c/d0c87a3c6be10a57aa3463c32c3fc6b2a47c3dab
- https://git.kernel.org/stable/c/e22f910a26cc2a3ac9c66b8e935ef2a7dd881117
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44960
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: core: Check for unset descriptor Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets.
- https://git.kernel.org/stable/c/1a9df57d57452b104c46c918569143cf21d7ebf1
- https://git.kernel.org/stable/c/50c5248b0ea8aae0529fdf28dac42a41312d3b62
- https://git.kernel.org/stable/c/716cba46f73a92645cf13eded8d257ed48afc2a4
- https://git.kernel.org/stable/c/7cc9ebcfe58be22f18056ad8bc6272d120bdcb3e
- https://git.kernel.org/stable/c/973a57891608a98e894db2887f278777f564de18
- https://git.kernel.org/stable/c/a0362cd6e503278add954123957fd47990e8d9bf
- https://git.kernel.org/stable/c/ba15815dd24cc5ec0d23e2170dc58c7db1e03b4a
- https://git.kernel.org/stable/c/df8e734ae5e605348aa0ca2498aedb73e815f244
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-04
CVE-2024-44961
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Forward soft recovery errors to userspace As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ (cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)
Modified: 2024-10-04
CVE-2024-44962
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming. panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,c0000000,40028143,1000721b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
Modified: 2025-11-03
CVE-2024-44965
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix pti_clone_pgtable() alignment assumption Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard. It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386. These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text? Use the correct increment form for addr to avoid alignment assumptions.
- https://git.kernel.org/stable/c/18da1b27ce16a14a9b636af9232acb4fb24f4c9e
- https://git.kernel.org/stable/c/25a727233a40a9b33370eec9f0cad67d8fd312f8
- https://git.kernel.org/stable/c/41e71dbb0e0a0fe214545fe64af031303a08524c
- https://git.kernel.org/stable/c/4d143ae782009b43b4f366402e5c37f59d4e4346
- https://git.kernel.org/stable/c/5c580c1050bcbc15c3e78090859d798dcf8c9763
- https://git.kernel.org/stable/c/ca07aab70dd3b5e7fddb62d7a6ecd7a7d6d0b2ed
- https://git.kernel.org/stable/c/d00c9b4bbc442d99e1dafbdfdab848bc1ead73f6
- https://git.kernel.org/stable/c/df3eecb5496f87263d171b254ca6e2758ab3c35c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44966
In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix corruption when not offsetting data start Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it.
- https://git.kernel.org/stable/c/3a684499261d0f7ed5ee72793025c88c2276809c
- https://git.kernel.org/stable/c/3eb3cd5992f7a0c37edc8d05b4c38c98758d8671
- https://git.kernel.org/stable/c/49df34d2b7da9e57c839555a2f7877291ce45ad1
- https://git.kernel.org/stable/c/9350ba06ee61db392c486716ac68ecc20e030f7c
- https://git.kernel.org/stable/c/af65d5383854cc3f172a7d0843b628758bf462c8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44967
In the Linux kernel, the following vulnerability has been resolved: drm/mgag200: Bind I2C lifetime to DRM device Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc. Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter.
- https://git.kernel.org/stable/c/55a6916db77102765b22855d3a0add4751988b7c
- https://git.kernel.org/stable/c/81d34df843620e902dd04aa9205c875833d61c17
- https://git.kernel.org/stable/c/9d96b91e03cba9dfcb4ac370c93af4dbc47d5191
- https://git.kernel.org/stable/c/eb1ae34e48a09b7a1179c579aed042b032e408f4
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44969
In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Prevent release of buffer in I/O When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.
- https://git.kernel.org/stable/c/1e8b7fb427af6b2ddd54eff66a6b428a81c96633
- https://git.kernel.org/stable/c/1ec5ea9e25f582fd6999393e2f2c3bf56f234e05
- https://git.kernel.org/stable/c/2429ea3b4330e3653b72b210a0d5f2a717359506
- https://git.kernel.org/stable/c/46f67233b011385d53cf14d272431755de3a7c79
- https://git.kernel.org/stable/c/7a7e60ed23d471a07dbbe72565d2992ee8244bbe
- https://git.kernel.org/stable/c/a3e52a4c22c846858a6875e1c280030a3849e148
- https://git.kernel.org/stable/c/a88a49473c94ccfd8dce1e766aacf3c627278463
- https://git.kernel.org/stable/c/bf365071ea92b9579d5a272679b74052a5643e35
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44970
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again.
- https://git.kernel.org/stable/c/50d8009a0ac02c3311b23a0066511f8337bd88d9
- https://git.kernel.org/stable/c/650e24748e1e0a7ff91d5c72b72a2f2a452b5b76
- https://git.kernel.org/stable/c/7b379353e9144e1f7460ff15f39862012c9d0d78
- https://git.kernel.org/stable/c/fba8334721e266f92079632598e46e5f89082f30
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44971
In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register() bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak. This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount.
- https://git.kernel.org/stable/c/7feef10768ea71d468d9bbc1e0d14c461876768c
- https://git.kernel.org/stable/c/a7d2808d67570e6acae45c2a96e0d59986888e4c
- https://git.kernel.org/stable/c/b7b8d9f5e679af60c94251fd6728dde34be69a71
- https://git.kernel.org/stable/c/c05516c072903f6fb9134b8e7e1ad4bffcdc4819
- https://git.kernel.org/stable/c/e3862093ee93fcfbdadcb7957f5f8974fffa806a
- https://git.kernel.org/stable/c/f3d5efe18a11f94150fee8b3fda9d62079af640a
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-09
CVE-2024-44974
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: avoid possible UaF when selecting endp select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free. A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.
- https://git.kernel.org/stable/c/0201d65d9806d287a00e0ba96f0321835631f63f
- https://git.kernel.org/stable/c/2b4f46f9503633dade75cb796dd1949d0e6581a1
- https://git.kernel.org/stable/c/48e50dcbcbaaf713d82bf2da5c16aeced94ad07d
- https://git.kernel.org/stable/c/9a9afbbc3fbfca4975eea4aa5b18556db5a0c0b8
- https://git.kernel.org/stable/c/ddee5b4b6a1cc03c1e9921cf34382e094c2009f1
- https://git.kernel.org/stable/c/f2c865e9e3ca44fc06b5f73b29a954775e4dbb38
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-09
CVE-2024-44977
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Validate TA binary size Add TA binary size validation to avoid OOB write. (cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442)
- https://git.kernel.org/stable/c/50553ea7cbd3344fbf40afb065f6a2d38171c1ad
- https://git.kernel.org/stable/c/5ab8793b9a6cc059f503cbe6fe596f80765e0f19
- https://git.kernel.org/stable/c/c99769bceab4ecb6a067b9af11f9db281eea3e2a
- https://git.kernel.org/stable/c/e562415248f402203e7fb6d8c38c1b32fa99220f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44982
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails
If the dpu_format_populate_layout() fails, then FB is prepared, but not
cleaned up. This ends up leaking the pin_count on the GEM object and
causes a splat during DRM file closure:
msm_obj->pin_count
WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc
[...]
Call trace:
update_lru_locked+0xc4/0xcc
put_pages+0xac/0x100
msm_gem_free_object+0x138/0x180
drm_gem_object_free+0x1c/0x30
drm_gem_object_handle_put_unlocked+0x108/0x10c
drm_gem_object_release_handle+0x58/0x70
idr_for_each+0x68/0xec
drm_gem_release+0x28/0x40
drm_file_free+0x174/0x234
drm_release+0xb0/0x160
__fput+0xc0/0x2c8
__fput_sync+0x50/0x5c
__arm64_sys_close+0x38/0x7c
invoke_syscall+0x48/0x118
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x4c/0x120
el0t_64_sync_handler+0x100/0x12c
el0t_64_sync+0x190/0x194
irq event stamp: 129818
hardirqs last enabled at (129817): [
- https://git.kernel.org/stable/c/02193c70723118889281f75b88722b26b58bf4ae
- https://git.kernel.org/stable/c/7ecf85542169012765e4c2817cd3be6c2e009962
- https://git.kernel.org/stable/c/9b8b65211a880af8fe8330a101e1e239a2d4008f
- https://git.kernel.org/stable/c/a3c5815b07f4ee19d0b7e2ddf91ff9f03ecbf27d
- https://git.kernel.org/stable/c/bfa1a6283be390947d3649c482e5167186a37016
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44983
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate vlan header Ensure there is sufficient room to access the protocol field of the VLAN header, validate it once before the flowtable lookup. ===================================================== BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5440 [inline]
- https://git.kernel.org/stable/c/0279c35d242d037abeb73d60d06a6d1bb7f672d9
- https://git.kernel.org/stable/c/043a18bb6cf16adaa2f8642acfde6e8956a9caaa
- https://git.kernel.org/stable/c/6ea14ccb60c8ab829349979b22b58a941ec4a3ee
- https://git.kernel.org/stable/c/c05155cc455785916164aa5e1b4605a2ae946537
- https://git.kernel.org/stable/c/d9384ae7aec46036d248d1c2c2757e471ab486c3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-10
CVE-2024-44984
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix double DMA unmapping for XDP_REDIRECT Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en] __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0
Modified: 2025-11-03
CVE-2024-44985
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UAF in ip6_xmit() If skb_expand_head() returns NULL, skb has been freed and the associated dst/idev could also have been freed. We must use rcu_read_lock() to prevent a possible UAF.
- https://git.kernel.org/stable/c/124b428fe28064c809e4237b0b38e97200a8a4a8
- https://git.kernel.org/stable/c/2d5ff7e339d04622d8282661df36151906d0e1c7
- https://git.kernel.org/stable/c/38a21c026ed2cc7232414cb166efc1923f34af17
- https://git.kernel.org/stable/c/975f764e96f71616b530e300c1bb2ac0ce0c2596
- https://git.kernel.org/stable/c/b3a3d5333c13a1be57499581eab4a8fc94d57f36
- https://git.kernel.org/stable/c/c47e022011719fc5727bca661d662303180535ba
- https://git.kernel.org/stable/c/fc88d6c1f2895a5775795d82ec581afdff7661d1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-09
CVE-2024-44986
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in ip6_finish_output2() If skb_expand_head() returns NULL, skb has been freed and associated dst/idev could also have been freed. We need to hold rcu_read_lock() to make sure the dst and associated idev are alive.
- https://git.kernel.org/stable/c/3574d28caf9a09756ae87ad1ea096c6f47b6101e
- https://git.kernel.org/stable/c/56efc253196751ece1fc535a5b582be127b0578a
- https://git.kernel.org/stable/c/6ab6bf731354a6fdbaa617d1ec194960db61cf3b
- https://git.kernel.org/stable/c/da273b377ae0d9bd255281ed3c2adb228321687b
- https://git.kernel.org/stable/c/e891b36de161fcd96f12ff83667473e5067b9037
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44987
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent UAF in ip6_send_skb()
syzbot reported an UAF in ip6_send_skb() [1]
After ip6_local_out() has returned, we no longer can safely
dereference rt, unless we hold rcu_read_lock().
A similar issue has been fixed in commit
a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")
Another potential issue in ip6_finish_output2() is handled in a
separate patch.
[1]
BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530
CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
- https://git.kernel.org/stable/c/24e93695b1239fbe4c31e224372be77f82dab69a
- https://git.kernel.org/stable/c/571567e0277008459750f0728f246086b2659429
- https://git.kernel.org/stable/c/9a3e55afa95ed4ac9eda112d4f918af645d72f25
- https://git.kernel.org/stable/c/af1dde074ee2ed7dd5bdca4e7e8ba17f44e7b011
- https://git.kernel.org/stable/c/cb5880a0de12c7f618d2bdd84e2d985f1e06ed7e
- https://git.kernel.org/stable/c/ce2f6cfab2c637d0bd9762104023a15d0ab7c0a8
- https://git.kernel.org/stable/c/e44bd76dd072756e674f45c5be00153f4ded68b2
- https://git.kernel.org/stable/c/faa389b2fbaaec7fd27a390b4896139f9da662e3
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44988
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix out-of-bound access If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).
- https://git.kernel.org/stable/c/050e7274ab2150cd212b2372595720e7b83a15bd
- https://git.kernel.org/stable/c/18b2e833daf049223ab3c2efdf8cdee08854c484
- https://git.kernel.org/stable/c/4a88fca95c8df3746b71e31f44a02d35f06f9864
- https://git.kernel.org/stable/c/528876d867a23b5198022baf2e388052ca67c952
- https://git.kernel.org/stable/c/a10d0337115a6d223a1563d853d4455f05d0b2e3
- https://git.kernel.org/stable/c/d39f5be62f098fe367d672b4dd4bc4b2b80e08e7
- https://git.kernel.org/stable/c/f7d8c2fabd39250cf2333fbf8eef67e837f90a5d
- https://git.kernel.org/stable/c/f87ce03c652dba199aef15ac18ade3991db5477e
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44989
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix xfrm real_dev null pointer dereference
We shouldn't set real_dev to NULL because packets can be in transit and
xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume
real_dev is set.
Example trace:
kernel: BUG: unable to handle page fault for address: 0000000000001030
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: #PF: supervisor write access in kernel mode
kernel: #PF: error_code(0x0002) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops: 0002 [#1] PREEMPT SMP
kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12
kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246
kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
kernel:
kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60
kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00
kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014
kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000
kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000
kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0
kernel: bond0: (slave eni0np1): making interface the new active one
kernel: Call Trace:
kernel:
- https://git.kernel.org/stable/c/21816b696c172c19d53a30d45ee005cce246ed21
- https://git.kernel.org/stable/c/2f72c6a66bcd7e0187ec085237fee5db27145294
- https://git.kernel.org/stable/c/4582d4ff413a07d4ed8a4823c652dc5207760548
- https://git.kernel.org/stable/c/7fa9243391ad2afe798ef4ea2e2851947b95754f
- https://git.kernel.org/stable/c/89fc1dca79db5c3e7a2d589ecbf8a3661c65f436
- https://git.kernel.org/stable/c/f8cde9805981c50d0c029063dc7d82821806fc44
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44990
In the Linux kernel, the following vulnerability has been resolved: bonding: fix null pointer deref in bond_ipsec_offload_ok We must check if there is an active slave before dereferencing the pointer.
- https://git.kernel.org/stable/c/0707260a18312bbcd2a5668584e3692d0a29e3f6
- https://git.kernel.org/stable/c/2f5bdd68c1ce64bda6bef4d361a3de23b04ccd59
- https://git.kernel.org/stable/c/32a0173600c63aadaf2103bf02f074982e8602ab
- https://git.kernel.org/stable/c/81216b9352be43f8958092d379f6dec85443c309
- https://git.kernel.org/stable/c/95c90e4ad89d493a7a14fa200082e466e2548f9d
- https://git.kernel.org/stable/c/b70b0ddfed31fc92c8dc722d0afafc8e14cb550c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44991
In the Linux kernel, the following vulnerability has been resolved: tcp: prevent concurrent execution of tcp_sk_exit_batch Its possible that two threads call tcp_sk_exit_batch() concurrently, once from the cleanup_net workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns. tcp_sk_exit_batch() calls tcp_twsk_purge(). Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"), this function picks up twsk in any dying netns, not just the one passed in via exit_batch list. This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns. This allows the netns exit worker to proceed to call WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); without the expected 1 -> 0 transition, which then splats. At same time, error unwind path that is also running inet_twsk_purge() will splat as well: WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [inline] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... because refcount_dec() of tw_refcount unexpectedly dropped to 0. This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check. Add a mutex to force strict ordering: the task that calls tcp_twsk_purge() blocks other task from doing final _dec_and_test before mutex-owner has removed all tw sockets of dying netns.
- https://git.kernel.org/stable/c/565d121b69980637f040eb4d84289869cdaabedf
- https://git.kernel.org/stable/c/99580ae890ec8bd98b21a2a9c6668f8f1555b62e
- https://git.kernel.org/stable/c/e3d9de3742f4d5c47ae35f888d3023a5b54fcd2f
- https://git.kernel.org/stable/c/f6fd2dbf584a4047ba88d1369ff91c9851261ec1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44995
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix a deadlock problem when config TC during resetting When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.
- https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc
- https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16
- https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8
- https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ced30a109
- https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1
- https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9
- https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-16
CVE-2024-44996
In the Linux kernel, the following vulnerability has been resolved: vsock: fix recursive ->recvmsg calls After a vsock socket has been added to a BPF sockmap, its prot->recvmsg has been replaced with vsock_bpf_recvmsg(). Thus the following recursiion could happen: vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() again We need to fix it by calling the original ->recvmsg() without any BPF sockmap logic in __vsock_recvmsg().
Modified: 2024-09-06
CVE-2024-44997
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_wed: fix use-after-free panic in mtk_wed_setup_tc_block_cb() When there are multiple ap interfaces on one band and with WED on, turning the interface down will cause a kernel panic on MT798X. Previously, cb_priv was freed in mtk_wed_setup_tc_block() without marking NULL,and mtk_wed_setup_tc_block_cb() didn't check the value, too. Assign NULL after free cb_priv in mtk_wed_setup_tc_block() and check NULL in mtk_wed_setup_tc_block_cb(). ---------- Unable to handle kernel paging request at virtual address 0072460bca32b4f5 Call trace: mtk_wed_setup_tc_block_cb+0x4/0x38 0xffffffc0794084bc tcf_block_playback_offloads+0x70/0x1e8 tcf_block_unbind+0x6c/0xc8 ... ---------
Modified: 2025-11-03
CVE-2024-44998
In the Linux kernel, the following vulnerability has been resolved: atm: idt77252: prevent use after free in dequeue_rx() We can't dereference "skb" after calling vcc->push() because the skb is released.
- https://git.kernel.org/stable/c/09e086a5f72ea27c758b3f3b419a69000c32adc1
- https://git.kernel.org/stable/c/1cece837e387c039225f19028df255df87a97c0d
- https://git.kernel.org/stable/c/24cf390a5426aac9255205e9533cdd7b4235d518
- https://git.kernel.org/stable/c/379a6a326514a3e2f71b674091dfb0e0e7522b55
- https://git.kernel.org/stable/c/628ea82190a678a56d2ec38cda3addf3b3a6248d
- https://git.kernel.org/stable/c/91b4850e7165a4b7180ef1e227733bcb41ccdf10
- https://git.kernel.org/stable/c/a9a18e8f770c9b0703dab93580d0b02e199a4c79
- https://git.kernel.org/stable/c/ef23c18ab88e33ce000d06a5c6aad0620f219bfd
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-44999
In the Linux kernel, the following vulnerability has been resolved: gtp: pull network headers in gtp_dev_xmit() syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1] We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them. Use pskb_inet_may_pull() to fix this issue. [1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
- https://git.kernel.org/stable/c/137d565ab89ce3584503b443bc9e00d44f482593
- https://git.kernel.org/stable/c/1f6b62392453d8f36685d19b761307a8c5617ac1
- https://git.kernel.org/stable/c/34ba4f29f3d9eb52dee37512059efb2afd7e966f
- https://git.kernel.org/stable/c/3939d787139e359b77aaf9485d1e145d6713d7b9
- https://git.kernel.org/stable/c/3a3be7ff9224f424e485287b54be00d2c6bd9c40
- https://git.kernel.org/stable/c/3d89d0c4a1c6d4d2a755e826351b0a101dbc86f3
- https://git.kernel.org/stable/c/cbb9a969fc190e85195d1b0f08038e7f6199044e
- https://git.kernel.org/stable/c/f5dda8db382c5751c4e572afc7c99df7da1f83ca
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45000
In the Linux kernel, the following vulnerability has been resolved:
fs/netfs/fscache_cookie: add missing "n_accesses" check
This fixes a NULL pointer dereference bug due to a data race which
looks like this:
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43
Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
Workqueue: events_unbound netfs_rreq_write_to_cache_work
RIP: 0010:cachefiles_prepare_write+0x30/0xa0
Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
Call Trace:
- https://git.kernel.org/stable/c/0a4d41fa14b2a0efd40e350cfe8ec6a4c998ac1d
- https://git.kernel.org/stable/c/b8a50877f68efdcc0be3fcc5116e00c31b90e45b
- https://git.kernel.org/stable/c/dfaa39b05a6cf34a16c525a2759ee6ab26b5fef6
- https://git.kernel.org/stable/c/f71aa06398aabc2e3eaac25acdf3d62e0094ba70
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45001
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix RX buf alloc_size alignment and atomic op panic The MANA driver's RX buffer alloc_size is passed into napi_build_skb() to create SKB. skb_shinfo(skb) is located at the end of skb, and its alignment is affected by the alloc_size passed into napi_build_skb(). The size needs to be aligned properly for better performance and atomic operations. Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic operations may panic on the skb_shinfo(skb)->dataref due to alignment fault. To fix this bug, add proper alignment to the alloc_size calculation. Sample panic info: [ 253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce [ 253.300900] Mem abort info: [ 253.301760] ESR = 0x0000000096000021 [ 253.302825] EC = 0x25: DABT (current EL), IL = 32 bits [ 253.304268] SET = 0, FnV = 0 [ 253.305172] EA = 0, S1PTW = 0 [ 253.306103] FSC = 0x21: alignment fault Call trace: __skb_clone+0xfc/0x198 skb_clone+0x78/0xe0 raw6_local_deliver+0xfc/0x228 ip6_protocol_deliver_rcu+0x80/0x500 ip6_input_finish+0x48/0x80 ip6_input+0x48/0xc0 ip6_sublist_rcv_finish+0x50/0x78 ip6_sublist_rcv+0x1cc/0x2b8 ipv6_list_rcv+0x100/0x150 __netif_receive_skb_list_core+0x180/0x220 netif_receive_skb_list_internal+0x198/0x2a8 __napi_poll+0x138/0x250 net_rx_action+0x148/0x330 handle_softirqs+0x12c/0x3a0
Modified: 2025-11-03
CVE-2024-45002
In the Linux kernel, the following vulnerability has been resolved: rtla/osnoise: Prevent NULL dereference in error handling If the "tool->data" allocation fails then there is no need to call osnoise_free_top() and, in fact, doing so will lead to a NULL dereference.
- https://git.kernel.org/stable/c/753f1745146e03abd17eec8eee95faffc96d743d
- https://git.kernel.org/stable/c/90574d2a675947858b47008df8d07f75ea50d0d0
- https://git.kernel.org/stable/c/abdb9ddaaab476e62805e36cce7b4ef8413ffd01
- https://git.kernel.org/stable/c/fc575212c6b75d538e1a0a74f4c7e2ac73bc46ac
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45003
In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---
- https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8
- https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d
- https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72
- https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98
- https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f
- https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32
- https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-09
CVE-2024-45005
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix validity interception issue when gisa is switched off We might run into a SIE validity if gisa has been disabled either via using kernel parameter "kvm.use_gisa=0" or by setting the related sysfs attribute to N (echo N >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys() before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm] [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70 [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0 [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>] __warn_printk+0xe8/0xf0
Modified: 2025-11-03
CVE-2024-45006
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference. Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint(). On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.
- https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59
- https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d
- https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea
- https://git.kernel.org/stable/c/6b99de301d78e1f5249e57ef2c32e1dec3df2bb1
- https://git.kernel.org/stable/c/8fb9d412ebe2f245f13481e4624b40e651570cbd
- https://git.kernel.org/stable/c/a57b0ebabe6862dce0a2e0f13e17941ad72fc56b
- https://git.kernel.org/stable/c/af8e119f52e9c13e556be9e03f27957554a84656
- https://git.kernel.org/stable/c/ef0a0e616b2789bb804a0ce5e161db03170a85b6
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45007
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Don't destroy workqueue from work item running on it Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance.
- https://git.kernel.org/stable/c/409b495f8e3300d5fba08bc817fa8825dae48cc9
- https://git.kernel.org/stable/c/5d3567caff2a1d678aa40cc74a54e1318941fad3
- https://git.kernel.org/stable/c/a7ad105b12256ec7fb6d6d1a0e2e60f00b7da157
- https://git.kernel.org/stable/c/aa1a19724fa2c31e97a9be48baedd4692b265157
- https://git.kernel.org/stable/c/ccbde4b128ef9c73d14d0d7817d68ef795f6d131
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45008
In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). Since nobody knows possible max slots, this patch chose 1024.
- https://git.kernel.org/stable/c/05dd9aabd04f9b5eb04dab9bb83d8c3e982d7549
- https://git.kernel.org/stable/c/2829c80614890624456337e47320289112785f3e
- https://git.kernel.org/stable/c/87f610a1a7fbdb1f2e3d90b54c955bd3b8a0c322
- https://git.kernel.org/stable/c/8f04edd554d191834e9e1349ef030318ea6b11ba
- https://git.kernel.org/stable/c/94736334b8a25e4fae8daa6934e54a31f099be43
- https://git.kernel.org/stable/c/95f73d01f547dfc67fda3022c51e377a0454b505
- https://git.kernel.org/stable/c/99d3bf5f7377d42f8be60a6b9cb60fb0be34dceb
- https://git.kernel.org/stable/c/cd19f1799c32ba7b874474b1b968815ce5364f73
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45009
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR.
- https://git.kernel.org/stable/c/1c1f721375989579e46741f59523e39ec9b2a9bd
- https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c
- https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d
- https://git.kernel.org/stable/c/85b866e4c4e63a1d7afb58f1e24273caad03d0b7
- https://git.kernel.org/stable/c/d20bf2c96d7ffd171299b32f562f70e5bf5dc608
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45010
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only mark 'subflow' endp as available Adding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... before decrementing the local_addr_used counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests. Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed. Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before.
- https://git.kernel.org/stable/c/322ea3778965da72862cca2a0c50253aacf65fe6
- https://git.kernel.org/stable/c/43cf912b0b0fc7b4fd12cbc735d1f5afb8e1322d
- https://git.kernel.org/stable/c/7fdc870d08960961408a44c569f20f50940e7d4f
- https://git.kernel.org/stable/c/9849cfc67383ceb167155186f8f8fe8a896b60b3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45011
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Check USB endpoints when probing device Ensure, as the driver probes the device, that all endpoints that the driver may attempt to access exist and are of the correct type. All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at address 1. This is verified in xillyusb_setup_base_eps(). On top of that, a XillyUSB device may have additional Bulk OUT endpoints. The information about these endpoints' addresses is deduced from a data structure (the IDT) that the driver fetches from the device while probing it. These endpoints are checked in setup_channels(). A XillyUSB device never has more than one IN endpoint, as all data towards the host is multiplexed in this single Bulk IN endpoint. This is why setup_channels() only checks OUT endpoints.
- https://git.kernel.org/stable/c/1371d32b95972d39c1e6e4bae8b6d0df1b573731
- https://git.kernel.org/stable/c/2374bf7558de915edc6ec8cb10ec3291dfab9594
- https://git.kernel.org/stable/c/25ee8b2908200fc862c0434e5ad483817d50ceda
- https://git.kernel.org/stable/c/4267131278f5cc98f8db31d035d64bdbbfe18658
- https://git.kernel.org/stable/c/5cff754692ad45d5086b75fef8cc3a99c30a1005
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-13
CVE-2024-45012
In the Linux kernel, the following vulnerability has been resolved:
nouveau/firmware: use dma non-coherent allocator
Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a
BUG() on startup, when the iommu is enabled:
kernel BUG at include/linux/scatterlist.h:187!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30
Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019
RIP: 0010:sg_init_one+0x85/0xa0
Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54
24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b
0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00
RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000
RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000
R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508
R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018
FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0
Call Trace:
Modified: 2024-09-13
CVE-2024-45015
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable() For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set(). This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call. Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state. Patchwork: https://patchwork.freedesktop.org/patch/606729/
Modified: 2025-11-03
CVE-2024-45016
In the Linux kernel, the following vulnerability has been resolved: netem: fix return value if duplicate enqueue fails There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free. This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR. There are two ways for the bug happen: - If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped. - If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped. In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc. The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS.
- https://git.kernel.org/stable/c/0486d31dd8198e22b63a4730244b38fffce6d469
- https://git.kernel.org/stable/c/52d99a69f3d556c6426048c9d481b912205919d8
- https://git.kernel.org/stable/c/577d6c0619467fe90f7e8e57e45cb5bd9d936014
- https://git.kernel.org/stable/c/759e3e8c4a6a6b4e52ebc4547123a457f0ce90d4
- https://git.kernel.org/stable/c/c07ff8592d57ed258afee5a5e04991a48dbaf382
- https://git.kernel.org/stable/c/c414000da1c2ea1ba9a5e5bb1a4ba774e51e202d
- https://git.kernel.org/stable/c/e5bb2988a310667abed66c7d3ffa28880cf0f883
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45018
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: initialise extack before use Fix missing initialisation of extack in flow offload.
- https://git.kernel.org/stable/c/119be227bc04f5035efa64cb823b8a5ca5e2d1c1
- https://git.kernel.org/stable/c/356beb911b63a8cff34cb57f755c2a2d2ee9dec7
- https://git.kernel.org/stable/c/7eafeec6be68ebd6140a830ce9ae68ad5b67ec78
- https://git.kernel.org/stable/c/c7b760499f7791352b49b11667ed04b23d7f5b0f
- https://git.kernel.org/stable/c/e5ceff2196dc633c995afb080f6f44a72cff6e1d
- https://git.kernel.org/stable/c/e9767137308daf906496613fd879808a07f006a2
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45019
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Take state lock during tx timeout reporter mlx5e_safe_reopen_channels() requires the state lock taken. The referenced changed in the Fixes tag removed the lock to fix another issue. This patch adds it back but at a later point (when calling mlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the Fixes tag.
- https://git.kernel.org/stable/c/03d3734bd692affe4d0e9c9d638f491aaf37411b
- https://git.kernel.org/stable/c/8e57e66ecbdd2fddc9fbf3e984b1c523b70e9809
- https://git.kernel.org/stable/c/b3b9a87adee97854bcd71057901d46943076267e
- https://git.kernel.org/stable/c/e6b5afd30b99b43682a7764e1a74a42fe4d5f4b3
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-13
CVE-2024-45020
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a kernel verifier crash in stacksafe() Daniel Hodges reported a kernel verifier crash when playing with sched-ext. Further investigation shows that the crash is due to invalid memory access in stacksafe(). More specifically, it is the following code: if (exact != NOT_EXACT && old->stack[spi].slot_type[i % BPF_REG_SIZE] != cur->stack[spi].slot_type[i % BPF_REG_SIZE]) return false; The 'i' iterates old->allocated_stack. If cur->allocated_stack < old->allocated_stack the out-of-bound access will happen. To fix the issue add 'i >= cur->allocated_stack' check such that if the condition is true, stacksafe() should fail. Otherwise, cur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal.
Modified: 2025-11-03
CVE-2024-45021
In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane).
- https://git.kernel.org/stable/c/046667c4d3196938e992fba0dfcde570aa85cd0e
- https://git.kernel.org/stable/c/0fbe2a72e853a1052abe9bc2b7df8ddb102da227
- https://git.kernel.org/stable/c/1b37ec85ad95b612307627758c6018cd9d92cca8
- https://git.kernel.org/stable/c/21b578f1d599edb87462f11113c5b0fc7a04ac61
- https://git.kernel.org/stable/c/43768fa80fd192558737e24ed6548f74554611d7
- https://git.kernel.org/stable/c/ad149f5585345e383baa65f1539d816cd715fd3b
- https://git.kernel.org/stable/c/f1aa7c509aa766080db7ab3aec2e31b1df09e57c
- https://git.kernel.org/stable/c/fa5bfdf6cb5846a00e712d630a43e3cf55ccb411
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45022
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 The __vmap_pages_range_noflush() assumes its argument pages** contains pages with the same page shift. However, since commit e9c3cda4d86e ("mm, vmalloc: fix high order __GFP_NOFAIL allocations"), if gfp_flags includes __GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation failed for high order, the pages** may contain two different page shifts (high order and order-0). This could lead __vmap_pages_range_noflush() to perform incorrect mappings, potentially resulting in memory corruption. Users might encounter this as follows (vmap_allow_huge = true, 2M is for PMD_SIZE): kvmalloc(2M, __GFP_NOFAIL|GFP_X) __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0 vmap_pages_range() vmap_pages_range_noflush() __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens We can remove the fallback code because if a high-order allocation fails, __vmalloc_node_range_noprof() will retry with order-0. Therefore, it is unnecessary to fallback to order-0 here. Therefore, fix this by removing the fallback code.
- https://git.kernel.org/stable/c/61ebe5a747da649057c37be1c37eb934b4af79ca
- https://git.kernel.org/stable/c/c91618816f4d21fc574d7577a37722adcd4075b2
- https://git.kernel.org/stable/c/de7bad86345c43cd040ed43e20d9fad78a3ee59f
- https://git.kernel.org/stable/c/fd1ffbb50ef4da5e1378a46616b6d7407dc795da
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45025
In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c
- https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff
- https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058
- https://git.kernel.org/stable/c/9a2fa1472083580b6c66bdaf291f591e1170123a
- https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958
- https://git.kernel.org/stable/c/dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a
- https://git.kernel.org/stable/c/fe5bf14881701119aeeda7cf685f3c226c7380df
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45026
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case.
- https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246
- https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8
- https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc
- https://git.kernel.org/stable/c/7db4042336580dfd75cb5faa82c12cd51098c90b
- https://git.kernel.org/stable/c/93a7e2856951680cd7fe6ebd705ac10c8a8a5efd
- https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e3d0fc8fd490e00316a
- https://git.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45028
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_test: Fix NULL dereference on allocation failure If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success.
- https://git.kernel.org/stable/c/2b507b03991f44dfb202fc2a82c9874d1b1f0c06
- https://git.kernel.org/stable/c/3b4e76ceae5b5a46c968bd952f551ce173809f63
- https://git.kernel.org/stable/c/9b9ba386d7bfdbc38445932c90fa9444c0524bea
- https://git.kernel.org/stable/c/a1e627af32ed60713941cbfc8075d44cad07f6dd
- https://git.kernel.org/stable/c/cac2815f49d343b2f0acc4973d2c14918ac3ab0c
- https://git.kernel.org/stable/c/e40515582141a9e7c84b269be699c05236a499a6
- https://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9
- https://git.kernel.org/stable/c/ecb15b8ca12c0cbdab81e307e9795214d8b90890
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-45029
In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: Do not mark ACPI devices as irq safe On ACPI machines, the tegra i2c module encounters an issue due to a mutex being called inside a spinlock. This leads to the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 ... Call trace: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xfer The problem arises because during __pm_runtime_resume(), the spinlock &dev->power.lock is acquired before rpm_resume() is called. Later, rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on mutexes, triggering the error. To address this issue, devices on ACPI are now marked as not IRQ-safe, considering the dependency of acpi_subsys_runtime_resume() on mutexes.
- https://git.kernel.org/stable/c/14d069d92951a3e150c0a81f2ca3b93e54da913b
- https://git.kernel.org/stable/c/2853e1376d8161b04c9ff18ba82b43f08a049905
- https://git.kernel.org/stable/c/6861faf4232e4b78878f2de1ed3ee324ddae2287
- https://git.kernel.org/stable/c/a89aef1e6cc43fa019a58080ed05c839e6c77876
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-13
CVE-2024-45030
In the Linux kernel, the following vulnerability has been resolved: igb: cope with large MAX_SKB_FRAGS Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX. An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320 The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head. Address the issue by checking if 2K buffers are insufficient.
Modified: 2024-09-13
CVE-2024-46672
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion wpa_supplicant 2.11 sends since 1efdba5fdc2c ("Handle PMKSA flush in the driver for SAE/OWE offload cases") SSID based PMKSA del commands. brcmfmac is not prepared and tries to dereference the NULL bssid and pmkid pointers in cfg80211_pmksa. PMKID_V3 operations support SSID based updates so copy the SSID.
Modified: 2025-11-03
CVE-2024-46673
In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free.
- https://git.kernel.org/stable/c/4b540ec7c0045c2d01c4e479f34bbc8f147afa4c
- https://git.kernel.org/stable/c/564e1986b00c5f05d75342f8407f75f0a17b94df
- https://git.kernel.org/stable/c/60962c3d8e18e5d8dfa16df788974dd7f35bd87a
- https://git.kernel.org/stable/c/85449b28ff6a89c4513115e43ddcad949b5890c9
- https://git.kernel.org/stable/c/8a3995a3ffeca280a961b59f5c99843d81b15929
- https://git.kernel.org/stable/c/919ddf8336f0b84c0453bac583808c9f165a85c2
- https://git.kernel.org/stable/c/9e96dea7eff6f2bbcd0b42a098012fc66af9eb69
- https://git.kernel.org/stable/c/d237c7d06ffddcdb5d36948c527dc01284388218
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46674
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources.
- https://git.kernel.org/stable/c/060f41243ad7f6f5249fa7290dda0c01f723d12d
- https://git.kernel.org/stable/c/1de989668708ce5875efc9d669d227212aeb9a90
- https://git.kernel.org/stable/c/4c6735299540f3c82a5033d35be76a5c42e0fb18
- https://git.kernel.org/stable/c/6aee4c5635d81f4809c3b9f0c198a65adfbb2ada
- https://git.kernel.org/stable/c/b0979a885b9d4df2a25b88e9d444ccaa5f9f495c
- https://git.kernel.org/stable/c/ddfcfeba891064b88bb844208b43bef2ef970f0c
- https://git.kernel.org/stable/c/e1e5e8ea2731150d5ba7c707f9e02fafebcfeb49
- https://git.kernel.org/stable/c/f3498650df0805c75b4e1c94d07423c46cbf4ce1
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46675
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Prevent USB core invalid event buffer address access This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address. To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.
- https://git.kernel.org/stable/c/111277b881def3153335acfe0d1f43e6cd83ac93
- https://git.kernel.org/stable/c/14e497183df28c006603cc67fd3797a537eef7b9
- https://git.kernel.org/stable/c/2189fd13c577d7881f94affc09c950a795064c4b
- https://git.kernel.org/stable/c/7bb11a75dd4d3612378b90e2a4aa49bdccea28ab
- https://git.kernel.org/stable/c/b72da4d89b97da71e056cc4d1429b2bc426a9c2f
- https://git.kernel.org/stable/c/d2afc2bffec77316b90d530b07695e3f534df914
- https://git.kernel.org/stable/c/e23f6ad8d110bf632f7471482e10b43dc174fb72
- https://git.kernel.org/stable/c/eca3f543f817da87c00d1a5697b473efb548204f
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46676
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Add poll mod list filling check In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/56ad559cf6d87f250a8d203b555dfc3716afa946
- https://git.kernel.org/stable/c/64513d0e546a1f19e390f7e5eba3872bfcbdacf5
- https://git.kernel.org/stable/c/7535db0624a2dede374c42040808ad9a9101d723
- https://git.kernel.org/stable/c/7ecd3dd4f8eecd3309432156ccfe24768e009ec4
- https://git.kernel.org/stable/c/8ddaea033de051ed61b39f6b69ad54a411172b33
- https://git.kernel.org/stable/c/c5e05237444f32f6cfe5d907603a232c77a08b31
- https://git.kernel.org/stable/c/febccb39255f9df35527b88c953b2e0deae50e53
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46677
In the Linux kernel, the following vulnerability has been resolved: gtp: fix a potential NULL pointer dereference When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case. Fix it by returning an error pointer with the error code carried from sockfd_lookup(). (I found this bug during code inspection.)
- https://git.kernel.org/stable/c/28c67f0f84f889fe9f4cbda8354132b20dc9212d
- https://git.kernel.org/stable/c/4643b91691e969b1b9ad54bf552d7a990cfa3b87
- https://git.kernel.org/stable/c/612edd35f2a3910ab1f61c1f2338889d4ba99fa2
- https://git.kernel.org/stable/c/620fe9809752fae91b4190e897b81ed9976dfb39
- https://git.kernel.org/stable/c/8bbb9e4e0e66a39282e582d0440724055404b38c
- https://git.kernel.org/stable/c/bdd99e5f0ad5fa727b16f2101fe880aa2bff2f8e
- https://git.kernel.org/stable/c/defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda
- https://git.kernel.org/stable/c/e8b9930b0eb045d19e883c65ff9676fc89320c70
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-23
CVE-2024-46678
In the Linux kernel, the following vulnerability has been resolved:
bonding: change ipsec_lock from spin lock to mutex
In the cited commit, bond->ipsec_lock is added to protect ipsec_list,
hence xdo_dev_state_add and xdo_dev_state_delete are called inside
this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,
"scheduling while atomic" will be triggered when changing bond's
active slave.
[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200
[ 101.055726] Modules linked in:
[ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1
[ 101.058760] Hardware name:
[ 101.059434] Call Trace:
[ 101.059436]
Modified: 2025-11-03
CVE-2024-46679
In the Linux kernel, the following vulnerability has been resolved: ethtool: check device is present when getting link settings A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show"). There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check. Move this check into ethtool to protect all callers.
- https://git.kernel.org/stable/c/1d6d9b5b1b95bfeccb84386a51b7e6c510ec13b2
- https://git.kernel.org/stable/c/7a8d98b6d6484d3ad358510366022da080c37cbc
- https://git.kernel.org/stable/c/842a40c7273ba1c1cb30dda50405b328de1d860e
- https://git.kernel.org/stable/c/94ab317024ba373d37340893d1c0358638935fbb
- https://git.kernel.org/stable/c/9bba5955eed160102114d4cc00c3d399be9bdae4
- https://git.kernel.org/stable/c/a699781c79ecf6cfe67fb00a0331b4088c7c8466
- https://git.kernel.org/stable/c/ec7b4f7f644018ac293cb1b02528a40a32917e62
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-23
CVE-2024-46680
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix random crash seen while removing driver This fixes the random kernel crash seen while removing the driver, when running the load/unload test over multiple iterations. 1) modprobe btnxpuart 2) hciconfig hci0 reset 3) hciconfig (check hci0 interface up with valid BD address) 4) modprobe -r btnxpuart Repeat steps 1 to 4 The ps_wakeup() call in btnxpuart_close() schedules the psdata->work(), which gets scheduled after module is removed, causing a kernel crash. This hidden issue got highlighted after enabling Power Save by default in 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on startup) The new ps_cleanup() deasserts UART break immediately while closing serdev device, cancels any scheduled ps_work and destroys the ps_lock mutex. [ 85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258 [ 85.884624] Mem abort info: [ 85.884625] ESR = 0x0000000086000007 [ 85.884628] EC = 0x21: IABT (current EL), IL = 32 bits [ 85.884633] SET = 0, FnV = 0 [ 85.884636] EA = 0, S1PTW = 0 [ 85.884638] FSC = 0x07: level 3 translation fault [ 85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000 [ 85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000 [ 85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP [ 85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)] [ 85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G O 6.1.36+g937b1be4345a #1 [ 85.936176] Hardware name: FSL i.MX8MM EVK board (DT) [ 85.936182] Workqueue: events 0xffffd4a61638f380 [ 85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 85.952817] pc : 0xffffd4a61638f258 [ 85.952823] lr : 0xffffd4a61638f258 [ 85.952827] sp : ffff8000084fbd70 [ 85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000 [ 85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305 [ 85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970 [ 85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000 [ 85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090 [ 85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139 [ 85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50 [ 85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8 [ 85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000 [ 85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000 [ 85.977443] Call trace: [ 85.977446] 0xffffd4a61638f258 [ 85.977451] 0xffffd4a61638f3e8 [ 85.977455] process_one_work+0x1d4/0x330 [ 85.977464] worker_thread+0x6c/0x430 [ 85.977471] kthread+0x108/0x10c [ 85.977476] ret_from_fork+0x10/0x20 [ 85.977488] Code: bad PC value [ 85.977491] ---[ end trace 0000000000000000 ]--- Preset since v6.9.11
Modified: 2025-11-03
CVE-2024-46685
In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference in pcs_get_function() pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function(). Found by code review.
- https://git.kernel.org/stable/c/0a2bab5ed161318f57134716accba0a30f3af191
- https://git.kernel.org/stable/c/1c38a62f15e595346a1106025722869e87ffe044
- https://git.kernel.org/stable/c/292151af6add3e5ab11b2e9916cffa5f52859a1f
- https://git.kernel.org/stable/c/2cea369a5c2e85ab14ae716da1d1cc6d25c85e11
- https://git.kernel.org/stable/c/4e9436375fcc9bd2a60ee96aba6ed53f7a377d10
- https://git.kernel.org/stable/c/4ed45fe99ec9e3c9478bd634624cd05a57d002f7
- https://git.kernel.org/stable/c/6341c2856785dca7006820b127278058a180c075
- https://git.kernel.org/stable/c/8f0bd526921b6867c2f10a83cd4fd14139adcd92
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46686
In the Linux kernel, the following vulnerability has been resolved: smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() This happens when called from SMB2_read() while using rdma and reaching the rdma_readwrite_threshold.
- https://git.kernel.org/stable/c/6df57c63c200cd05e085c3b695128260e21959b7
- https://git.kernel.org/stable/c/a01859dd6aebf826576513850a3b05992809e9d2
- https://git.kernel.org/stable/c/b902fb78ab21299e4dd1775e7e8d251d5c0735bc
- https://git.kernel.org/stable/c/c724b2ab6a46435b4e7d58ad2fbbdb7a318823cf
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-14
CVE-2024-46687
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk() [BUG] There is an internal report that KASAN is reporting use-after-free, with the following backtrace: BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs] Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] submit_extent_page+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs] btrfs_submit_bio+0x33/0x70 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSE] Although I cannot reproduce the error, the report itself is good enough to pin down the cause. The call trace is the regular endio workqueue context, but the free-by-task trace is showing that during btrfs_submit_chunk() we already hit a critical error, and is calling btrfs_bio_end_io() to error out. And the original endio function called bio_put() to free the whole bio. This means a double freeing thus causing use-after-free, e.g.: 1. Enter btrfs_submit_bio() with a read bio The read bio length is 128K, crossing two 64K stripes. 2. The first run of btrfs_submit_chunk() 2.1 Call btrfs_map_block(), which returns 64K 2.2 Call btrfs_split_bio() Now there are two bios, one referring to the first 64K, the other referring to the second 64K. 2.3 The first half is submitted. 3. The second run of btrfs_submit_chunk() 3.1 Call btrfs_map_block(), which by somehow failed Now we call btrfs_bio_end_io() to handle the error 3.2 btrfs_bio_end_io() calls the original endio function Which is end_bbio_data_read(), and it calls bio_put() for the original bio. Now the original bio is freed. 4. The submitted first 64K bio finished Now we call into btrfs_check_read_bio() and tries to advance the bio iter. But since the original bio (thus its iter) is already freed, we trigger the above use-after free. And even if the memory is not poisoned/corrupted, we will later call the original endio function, causing a double freeing. [FIX] Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(), which has the extra check on split bios and do the pr ---truncated---
Modified: 2025-11-03
CVE-2024-46689
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen.
- https://git.kernel.org/stable/c/0ee9594c974368a17e85a431e9fe1c14fb65c278
- https://git.kernel.org/stable/c/62c2d63605ca25b5db78a347ed303c0a0a77d5b4
- https://git.kernel.org/stable/c/d9d48d70e922b272875cda60d2ada89291c840cf
- https://git.kernel.org/stable/c/eaff392c1e34fb77cc61505a31b0191e5e46e271
- https://git.kernel.org/stable/c/ef80520be0ff78ae5ed44cb6eee1525e65bebe70
- https://git.kernel.org/stable/c/f5a5a5a0e95f36e2792d48e6e4b64e665eb01374
- https://git.kernel.org/stable/c/f9bb896eab221618927ae6a2f1d566567999839d
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-13
CVE-2024-46692
In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Mark get_wq_ctx() as atomic call Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call.
Modified: 2024-09-13
CVE-2024-46693
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pmic_glink: Fix race during initialization
As pointed out by Stephen Boyd it is possible that during initialization
of the pmic_glink child drivers, the protection-domain notifiers fires,
and the associated work is scheduled, before the client registration
returns and as a result the local "client" pointer has been initialized.
The outcome of this is a NULL pointer dereference as the "client"
pointer is blindly dereferenced.
Timeline provided by Stephen:
CPU0 CPU1
---- ----
ucsi->client = NULL;
devm_pmic_glink_register_client()
client->pdr_notify(client->priv, pg->client_state)
pmic_glink_ucsi_pdr_notify()
schedule_work(&ucsi->register_work)
Modified: 2025-11-03
CVE-2024-46694
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)
- https://git.kernel.org/stable/c/093ee72ed35c2338c87c26b6ba6f0b7789c9e14e
- https://git.kernel.org/stable/c/3b9a33235c773c7a3768060cf1d2cf8a9153bc37
- https://git.kernel.org/stable/c/49e1b214f3239b78967c6ddb8f8ec47ae047b051
- https://git.kernel.org/stable/c/f6f5e39a3fe7cbdba190f42b28b40bdff03c8cf0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46695
In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label.
- https://git.kernel.org/stable/c/2dbc4b7bac60b02cc6e70d05bf6a7dfd551f9dda
- https://git.kernel.org/stable/c/459584258d47ec3cc6245a82e8a49c9d08eb8b57
- https://git.kernel.org/stable/c/76a0e79bc84f466999fa501fce5bf7a07641b8a7
- https://git.kernel.org/stable/c/eebec98791d0137e455cc006411bb92a54250924
- https://git.kernel.org/stable/c/f71ec019257ba4f7ab198bd948c5902a207bad96
- https://git.kernel.org/stable/c/fe0cd53791119f6287b6532af8ce41576d664930
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-46702
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router.
- https://git.kernel.org/stable/c/18b3ad2a3cc877dd4b16f48d84aa27b78d53bf1d
- https://git.kernel.org/stable/c/23ce6ba3b95488a2b9e9f6d43b340da0c15395dc
- https://git.kernel.org/stable/c/747bc154577de6e6af4bc99abfa859b8419bb4d8
- https://git.kernel.org/stable/c/7ca24cf9163c112bb6b580c6fb57c04a1f8b76e1
- https://git.kernel.org/stable/c/80ac8d194831eca0c2f4fd862f7925532fda320c
- https://git.kernel.org/stable/c/e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-19
CVE-2024-46706
In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: mark last busy before uart_add_one_port With "earlycon initcall_debug=1 loglevel=8" in bootargs, kernel sometimes boot hang. It is because normal console still is not ready, but runtime suspend is called, so early console putchar will hang in waiting TRDE set in UARTSTAT. The lpuart driver has auto suspend delay set to 3000ms, but during uart_add_one_port, a child device serial ctrl will added and probed with its pm runtime enabled(see serial_ctrl.c). The runtime suspend call path is: device_add |-> bus_probe_device |->device_initial_probe |->__device_attach |-> pm_runtime_get_sync(dev->parent); |-> pm_request_idle(dev); |-> pm_runtime_put(dev->parent); So in the end, before normal console ready, the lpuart get runtime suspended. And earlycon putchar will hang. To address the issue, mark last busy just after pm_runtime_enable, three seconds is long enough to switch from bootconsole to normal console.
Modified: 2025-11-03
CVE-2024-46707
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception.
- https://git.kernel.org/stable/c/15818af2f7aa55eff375333cb7689df15d3f24ef
- https://git.kernel.org/stable/c/2073132f6ed3079369e857a8deb33d11bdd983bc
- https://git.kernel.org/stable/c/3e6245ebe7ef341639e9a7e402b3ade8ad45a19f
- https://git.kernel.org/stable/c/94d4fbad01b19ec5eab3d6b50aaec4f9db8b2d8d
- https://git.kernel.org/stable/c/96b076e8ee5bc3a1126848c8add0f74bd30dc9d1
- https://git.kernel.org/stable/c/9d7629bec5c3f80bd0e3bf8103c06a2f7046bd92
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46711
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix ID 0 endp usage after multiple re-creations 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once.
- https://git.kernel.org/stable/c/119806ae4e46cf239db8e6ad92bc2fd3daae86dc
- https://git.kernel.org/stable/c/53e2173172d26c0617b29dd83618b71664bed1fb
- https://git.kernel.org/stable/c/9366922adc6a71378ca01f898c41be295309f044
- https://git.kernel.org/stable/c/c9c744666f7308a4daba520191e29d395260bcfe
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46713
In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.
- https://git.kernel.org/stable/c/2ab9d830262c132ab5db2f571003d80850d56b2a
- https://git.kernel.org/stable/c/52d13d224fdf1299c8b642807fa1ea14d693f5ff
- https://git.kernel.org/stable/c/7882923f1cb88dc1a17f2bf0c81b1fc80d44db82
- https://git.kernel.org/stable/c/9dc7ad2b67772cfb94ceb3b0c9c4023c2463215d
- https://git.kernel.org/stable/c/b9b6882e243b653d379abbeaa64a500182aba370
- https://git.kernel.org/stable/c/c4b69bee3f4ef76809288fe6827bc14d4ae788ef
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46714
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip wbscl_set_scaler_filter if filter is null Callers can pass null in filter (i.e. from returned from the function wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is not the case. This fixes 4 NULL_RETURNS issues reported by Coverity.
- https://git.kernel.org/stable/c/0364f1f17a86d89dc39040beea4f099e60189f1b
- https://git.kernel.org/stable/c/1726914cb17cedab233820d26b86764dc08857b4
- https://git.kernel.org/stable/c/54834585e91cab13e9f82d3a811deb212a4df786
- https://git.kernel.org/stable/c/6d94c05a13fadd80c3e732f14c83b2632ebfaa50
- https://git.kernel.org/stable/c/c083c8be6bdd046049884bec076660d4ec9a19ca
- https://git.kernel.org/stable/c/c4d31653c03b90e51515b1380115d1aedad925dd
- https://git.kernel.org/stable/c/e3a95f29647ae45d1ec9541cd7df64f40bf2120a
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-18
CVE-2024-46715
In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/0cc7e0ee31e5c44904e98e2229d591e093282a70
- https://git.kernel.org/stable/c/2b961d5786b4b31c367c719a2f918569b444c007
- https://git.kernel.org/stable/c/72f022ebb9deac28663fa4c04ba315ed5d6654d1
- https://git.kernel.org/stable/c/c4ec8dedca961db056ec85cb7ca8c9f7e2e92252
- https://git.kernel.org/stable/c/dc537a72f64890d883d24ae4ac58733fc5bc523d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46716
In the Linux kernel, the following vulnerability has been resolved: dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor Remove list_del call in msgdma_chan_desc_cleanup, this should be the role of msgdma_free_descriptor. In consequence replace list_add_tail with list_move_tail in msgdma_free_descriptor. This fixes the path: msgdma_free_chan_resources -> msgdma_free_descriptors -> msgdma_free_desc_list -> msgdma_free_descriptor which does not correctly free the descriptors as first nodes were not removed from the list.
- https://git.kernel.org/stable/c/20bf2920a869f9dbda0ef8c94c87d1901a64a716
- https://git.kernel.org/stable/c/54e4ada1a4206f878e345ae01cf37347d803d1b1
- https://git.kernel.org/stable/c/a3480e59fdbe5585d2d1eff0bed7671583acf725
- https://git.kernel.org/stable/c/db67686676c7becc1910bf1d6d51505876821863
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46717
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix incorrect page release Under the following conditions: 1) No skb created yet 2) header_size == 0 (no SHAMPO header) 3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page) a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from header_index is released. This is wrong and it leads to SHAMPO header pages being released more than once.
- https://git.kernel.org/stable/c/03924d117625ecb10ee3c9b65930bcb2c37ae629
- https://git.kernel.org/stable/c/70bd03b89f20b9bbe51a7f73c4950565a17a45f7
- https://git.kernel.org/stable/c/ae9018e3f61ba5cc1f08a6e51d3c0bef0a79f3ab
- https://git.kernel.org/stable/c/c909ab41df2b09cde919801c7a7b6bb2cc37ea22
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46719
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix null pointer dereference in trace ucsi_register_altmode checks IS_ERR for the alt pointer and treats NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled, ucsi_register_displayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typec_port_register_altmode to register DisplayPort alternate mode as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.
- https://git.kernel.org/stable/c/3aa56313b0de06ce1911950b2cc0c269614a87a9
- https://git.kernel.org/stable/c/3b9f2d9301ae67070fe77a0c06758722fd7172b7
- https://git.kernel.org/stable/c/7e64cabe81c303bdf6fd26b6a09a3289b33bc870
- https://git.kernel.org/stable/c/8095bf0579ed4906a33f7bec675bfb29b6b16a3b
- https://git.kernel.org/stable/c/99331fe68a8eaa4097143a33fb0c12d5e5e8e830
- https://git.kernel.org/stable/c/99516f76db48e1a9d54cdfed63c1babcee4e71a5
- https://git.kernel.org/stable/c/b4243c05d7e3db0bdbf9124e6fa59b4ca7c807ae
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46720
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix dereference after null check check the pointer hive before use.
- https://git.kernel.org/stable/c/00b9594d6310eb33e14d3f07b54866499efe0d50
- https://git.kernel.org/stable/c/0aad97bf6d0bc7a34a19f266b0b9fb2861efe64c
- https://git.kernel.org/stable/c/1b73ea3d97cc23f9b16d10021782b48397d2b517
- https://git.kernel.org/stable/c/b1f7810b05d1950350ac2e06992982974343e441
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-01-05
CVE-2024-46721
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix possible NULL pointer dereference
profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made
from __create_missing_ancestors(..) and 'ent->old' is NULL in
aa_replace_profiles(..).
In that case, it must return an error code and the code, -ENOENT represents
its state that the path of its parent is not existed yet.
BUG: kernel NULL pointer dereference, address: 0000000000000030
PGD 0 P4D 0
PREEMPT SMP PTI
CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/3dd384108d53834002be5630132ad5c3f32166ad
- https://git.kernel.org/stable/c/59f742e55a469ef36c5c1533b6095a103b61eda8
- https://git.kernel.org/stable/c/c49bbe69ee152bd9c1c1f314c0f582e76c578f64
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46722
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix mc_data out-of-bounds read warning Clear warning that read mc_data[i-1] may out-of-bounds.
- https://git.kernel.org/stable/c/2097edede72ec5bb3869cf0205337d392fb2a553
- https://git.kernel.org/stable/c/310b9d8363b88e818afec97ca7652bd7fe3d0650
- https://git.kernel.org/stable/c/345bd3ad387f9e121aaad9c95957b80895e2f2ec
- https://git.kernel.org/stable/c/51dfc0a4d609fe700750a62f41447f01b8c9ea50
- https://git.kernel.org/stable/c/578ae965e8b90cd09edeb0252b50fa0503ea35c5
- https://git.kernel.org/stable/c/5fa4df25ecfc7b6c9006f5b871c46cfe25ea8826
- https://git.kernel.org/stable/c/b862a0bc5356197ed159fed7b1c647e77bc9f653
- https://git.kernel.org/stable/c/d0a43bf367ed640e527e8ef3d53aac1e71f80114
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46723
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix ucode out-of-bounds read warning Clear warning that read ucode[] may out-of-bounds.
- https://git.kernel.org/stable/c/0bef65e069d84d1cd77ce757aea0e437b8e2bd33
- https://git.kernel.org/stable/c/23fefef859c6057e6770584242bdd938254f8ddd
- https://git.kernel.org/stable/c/5f09fa5e0ad45fbca71933a0e024ca52da47d59b
- https://git.kernel.org/stable/c/82ac8f1d02886b5d8aeb9e058989d3bd6fc581e2
- https://git.kernel.org/stable/c/8944acd0f9db33e17f387fdc75d33bb473d7936f
- https://git.kernel.org/stable/c/8981927ebc6c12fa76b30c4178acb462bab15f54
- https://git.kernel.org/stable/c/e789e05388854a5436b2b5d8695fdb864c9bcc27
- https://git.kernel.org/stable/c/f2b7a9f3839e92f43559b2795b34640ca8cf839f
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46724
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number Check the fb_channel_number range to avoid the array out-of-bounds read error
- https://git.kernel.org/stable/c/32915dc909ff502823babfe07d5416c5b6e8a8b1
- https://git.kernel.org/stable/c/45f7b02afc464c208e8f56bcbc672ef5c364c815
- https://git.kernel.org/stable/c/725b728cc0c8c5fafdfb51cb0937870d33a40fa4
- https://git.kernel.org/stable/c/d768394fa99467bcf2703bde74ddc96eeb0b71fa
- https://git.kernel.org/stable/c/db7a86676fd624768a5d907faf34ad7bb4ff25f4
- https://git.kernel.org/stable/c/f9267972490f9fcffe146e79828e97acc0da588c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-21
CVE-2024-46725
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds write warning Check the ring type value to fix the out-of-bounds write warning
- https://git.kernel.org/stable/c/130bee397b9cd52006145c87a456fd8719390cb5
- https://git.kernel.org/stable/c/919f9bf9997b8dcdc132485ea96121e7d15555f9
- https://git.kernel.org/stable/c/a60d1f7ff62e453dde2d3b4907e178954d199844
- https://git.kernel.org/stable/c/be1684930f5262a622d40ce7a6f1423530d87f89
- https://git.kernel.org/stable/c/c253b87c7c37ec40a2e0c84e4a6b636ba5cd66b2
- https://git.kernel.org/stable/c/cf2db220b38301b6486a0f11da24a0f317de558c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46726
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Ensure index calculation will not overflow [WHY & HOW] Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will never overflow and exceess array size. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.
- https://git.kernel.org/stable/c/3dc6bb57dab36b38b7374af0ac916174c146b6ed
- https://git.kernel.org/stable/c/733ae185502d30bbe79575167b6178cfb6c5d6bd
- https://git.kernel.org/stable/c/8e2734bf444767fed787305ccdcb36a2be5301a2
- https://git.kernel.org/stable/c/d705b5869f6b1b46ad5ceb1bd2a08c04f7e5003b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-26
CVE-2024-46728
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index for aux_rd_interval before using aux_rd_interval has size of 7 and should be checked. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.
Modified: 2025-11-03
CVE-2024-46731
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix the Out-of-bounds read warning using index i - 1U may beyond element index for mc_data[] when i = 0.
- https://git.kernel.org/stable/c/12c6967428a099bbba9dfd247bb4322a984fcc0b
- https://git.kernel.org/stable/c/20c6373a6be93039f9d66029bb1e21038a060be1
- https://git.kernel.org/stable/c/3317966efcdc5101e93db21514b68917e7eb34ea
- https://git.kernel.org/stable/c/38e32a0d837443c91c4b615a067b976cfb925376
- https://git.kernel.org/stable/c/d83fb9f9f63e9a120bf405b078f829f0b2e58934
- https://git.kernel.org/stable/c/f1e261ced9bcad772a45a2fcdf413c3490e87299
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46732
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Assign linear_pitch_alignment even for VM [Description] Assign linear_pitch_alignment so we don't cause a divide by 0 error in VM environments
- https://git.kernel.org/stable/c/4bd7710f2fecfc5fb2dda1ca2adc69db8a66b8b6
- https://git.kernel.org/stable/c/984debc133efa05e62f5aa1a7a1dd8ca0ef041f4
- https://git.kernel.org/stable/c/c44b568931d23aed9d37ecbb31fb5fbdd198bf7b
- https://git.kernel.org/stable/c/d219f902b16d42f0cb8c499ea8f31cf3c0f36349
- https://git.kernel.org/stable/c/d2fe7ac613a1ea8c346c9f5c89dc6ecc27232997
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46735
In the Linux kernel, the following vulnerability has been resolved:
ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery()
When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the
first one sets 'ubq->ubq_daemon' to NULL, and the second one triggers
WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference
issue.
Fix it by adding the check in ublk_ctrl_start_recovery() and return
immediately in case of zero 'ub->nr_queues_ready'.
BUG: kernel NULL pointer dereference, address: 0000000000000028
RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180
Call Trace:
- https://git.kernel.org/stable/c/136a29d8112df4ea0a57f9602ddf3579e04089dc
- https://git.kernel.org/stable/c/7c890ef60bf417d3fe5c6f7a9f6cef0e1d77f74f
- https://git.kernel.org/stable/c/ca249435893dda766f3845c15ca77ca5672022d8
- https://git.kernel.org/stable/c/e58f5142f88320a5b1449f96a146f2f24615c5c7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46737
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix kernel crash if commands allocation fails If the commands allocation fails in nvmet_tcp_alloc_cmds() the kernel crashes in nvmet_tcp_release_queue_work() because of a NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Fix the bug by setting queue->nr_cmds to zero in case nvmet_tcp_alloc_cmd() fails.
- https://git.kernel.org/stable/c/03e1fd0327fa5e2174567f5fe9290fe21d21b8f4
- https://git.kernel.org/stable/c/489f2913a63f528cfe3f21722583fb981967ecda
- https://git.kernel.org/stable/c/50632b877ce55356f5d276b9add289b1e7ddc683
- https://git.kernel.org/stable/c/5572a55a6f830ee3f3a994b6b962a5c327d28cb3
- https://git.kernel.org/stable/c/6c04d1e3ab22cc5394ef656429638a5947f87244
- https://git.kernel.org/stable/c/7957c731fc2b23312f8935812dee5a0b14b04e2d
- https://git.kernel.org/stable/c/91dad30c5607e62864f888e735d0965567827bdf
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46738
In the Linux kernel, the following vulnerability has been resolved:
VMCI: Fix use-after-free when removing resource in vmci_resource_remove()
When removing a resource from vmci_resource_table in
vmci_resource_remove(), the search is performed using the resource
handle by comparing context and resource fields.
It is possible though to create two resources with different types
but same handle (same context and resource fields).
When trying to remove one of the resources, vmci_resource_remove()
may not remove the intended one, but the object will still be freed
as in the case of the datagram type in vmci_datagram_destroy_handle().
vmci_resource_table will still hold a pointer to this freed resource
leading to a use-after-free vulnerability.
BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
Call Trace:
- https://git.kernel.org/stable/c/00fe5292f081f8d773e572df8e03bf6e1855fe49
- https://git.kernel.org/stable/c/39e7e593418ccdbd151f2925fa6be1a616d16c96
- https://git.kernel.org/stable/c/48b9a8dabcc3cf5f961b2ebcd8933bf9204babb7
- https://git.kernel.org/stable/c/6c563a29857aa8053b67ee141191f69757f27f6e
- https://git.kernel.org/stable/c/b243d52b5f6f59f9d39e69b191fb3d58b94a43b1
- https://git.kernel.org/stable/c/b9efdf333174468651be40390cbc79c9f55d9cce
- https://git.kernel.org/stable/c/ef5f4d0c5ee22d4f873116fec844ff6edaf3fa7d
- https://git.kernel.org/stable/c/f6365931bf7c07b2b397dbb06a4f6573cc9fae73
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46739
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only. Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel.
- https://git.kernel.org/stable/c/1d8e020e51ab07e40f9dd00b52f1da7d96fec04c
- https://git.kernel.org/stable/c/2be373469be1774bbe03b0fa7e2854e65005b1cc
- https://git.kernel.org/stable/c/3005091cd537ef8cdb7530dcb2ecfba8d2ef475c
- https://git.kernel.org/stable/c/3d414b64ecf6fd717d7510ffb893c6f23acbf50e
- https://git.kernel.org/stable/c/928e399e84f4e80307dce44e89415115c473275b
- https://git.kernel.org/stable/c/de6946be9c8bc7d2279123433495af7c21011b99
- https://git.kernel.org/stable/c/f38f46da80a2ab7d1b2f8fcb444c916034a2dac4
- https://git.kernel.org/stable/c/fb1adbd7e50f3d2de56d0a2bb0700e2e819a329e
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46740
In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF caused by offsets overwrite Binder objects are processed and copied individually into the target buffer during transactions. Any raw data in-between these objects is copied as well. However, this raw data copy lacks an out-of-bounds check. If the raw data exceeds the data section size then the copy overwrites the offsets section. This eventually triggers an error that attempts to unwind the processed objects. However, at this point the offsets used to index these objects are now corrupted. Unwinding with corrupted offsets can result in decrements of arbitrary nodes and lead to their premature release. Other users of such nodes are left with a dangling pointer triggering a use-after-free. This issue is made evident by the following KASAN report (trimmed): ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c Write of size 4 at addr ffff47fc91598f04 by task binder-util/743 CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1 Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x19c binder_free_buf+0x128/0x434 binder_thread_write+0x8a4/0x3260 binder_ioctl+0x18f0/0x258c [...] Allocated by task 743: __kmalloc_cache_noprof+0x110/0x270 binder_new_node+0x50/0x700 binder_transaction+0x413c/0x6da8 binder_thread_write+0x978/0x3260 binder_ioctl+0x18f0/0x258c [...] Freed by task 745: kfree+0xbc/0x208 binder_thread_read+0x1c5c/0x37d4 binder_ioctl+0x16d8/0x258c [...] ================================================================== To avoid this issue, let's check that the raw data copy is within the boundaries of the data section.
- https://git.kernel.org/stable/c/109e845c1184c9f786d41516348ba3efd9112792
- https://git.kernel.org/stable/c/1f33d9f1d9ac3f0129f8508925000900c2fe5bb0
- https://git.kernel.org/stable/c/3a8154bb4ab4a01390a3abf1e6afac296e037da4
- https://git.kernel.org/stable/c/4df153652cc46545722879415937582028c18af5
- https://git.kernel.org/stable/c/4f79e0b80dc69bd5eaaed70f0df1b558728b4e59
- https://git.kernel.org/stable/c/5a32bfd23022ffa7e152f273fa3fa29befb7d929
- https://git.kernel.org/stable/c/eef79854a04feac5b861f94d7b19cbbe79874117
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-20
CVE-2024-46741
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix double free of 'buf' in error path smatch warning: drivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of 'buf' In fastrpc_req_mmap() error path, the fastrpc buffer is freed in fastrpc_req_munmap_impl() if unmap is successful. But in the end, there is an unconditional call to fastrpc_buf_free(). So the above case triggers the double free of fastrpc buf.
Modified: 2025-11-03
CVE-2024-46742
In the Linux kernel, the following vulnerability has been resolved: smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open() null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE) and parse_lease_state() return NULL. Fix this by check if 'lease_ctx_info' is NULL. Additionally, remove the redundant parentheses in parse_durable_handle_context().
- https://git.kernel.org/stable/c/07f384c5be1f8633b13f0a22616e227570450bc6
- https://git.kernel.org/stable/c/3b692794b81f2ecad69a4adbba687f3836824ada
- https://git.kernel.org/stable/c/4e8771a3666c8f216eefd6bd2fd50121c6c437db
- https://git.kernel.org/stable/c/878f32878351104448b86ef5b85d1f8ed6f599fb
- https://git.kernel.org/stable/c/ec28c35029b7930f31117f9284874b63bea4f31b
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-11-03
CVE-2024-46743
In the Linux kernel, the following vulnerability has been resolved: of/irq: Prevent device address out-of-bounds read in interrupt map walk When of_irq_parse_raw() is invoked with a device address smaller than the interrupt parent node (from #address-cells property), KASAN detects the following out-of-bounds read when populating the initial match table (dyndbg="func of_irq_parse_* +p"): OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764 CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dump_backtrace+0xdc/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0x6c/0x84 print_report+0x150/0x448 kasan_report+0x98/0x140 __asan_load4+0x78/0xa0 of_irq_parse_raw+0x2b8/0x8d0 of_irq_parse_one+0x24c/0x270 parse_interrupts+0xc0/0x120 of_fwnode_add_links+0x100/0x2d0 fw_devlink_parse_fwtree+0x64/0xc0 device_add+0xb38/0xc30 of_device_add+0x64/0x90 of_platform_device_create_pdata+0xd0/0x170 of_platform_bus_create+0x244/0x600 of_platform_notify+0x1b0/0x254 blocking_notifier_call_chain+0x9c/0xd0 __of_changeset_entry_notify+0x1b8/0x230 __of_changeset_apply_notify+0x54/0xe4 of_overlay_fdt_apply+0xc04/0xd94 ... The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680) The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it ! Prevent the out-of-bounds read by copying the device address into a buffer of sufficient size.
- https://git.kernel.org/stable/c/7ead730af11ee7da107f16fc77995613c58d292d
- https://git.kernel.org/stable/c/8ff351ea12e918db1373b915c4c268815929cbe5
- https://git.kernel.org/stable/c/9d1e9f0876b03d74d44513a0ed3ed15ef8f2fed5
- https://git.kernel.org/stable/c/b739dffa5d570b411d4bdf4bb9b8dfd6b7d72305
- https://git.kernel.org/stable/c/baaf26723beab3a04da578d3008be3544f83758f
- https://git.kernel.org/stable/c/bf68acd840b6a5bfd3777e0d5aaa204db6b461a9
- https://git.kernel.org/stable/c/d2a79494d8a5262949736fb2c3ac44d20a51b0d8
- https://git.kernel.org/stable/c/defcaa426ba0bc89ffdafb799d2e50b52f74ffc4
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46744
In the Linux kernel, the following vulnerability has been resolved: Squashfs: sanity check symbolic link size Syzkiller reports a "KMSAN: uninit-value in pick_link" bug. This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk. The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events: 1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size. 2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number. 3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page. This patch adds a sanity check which checks that the symbolic link size is not larger than expected. -- V2: fix spelling mistake.
- https://git.kernel.org/stable/c/087f25b2d36adae19951114ffcbb7106ed405ebb
- https://git.kernel.org/stable/c/1b9451ba6f21478a75288ea3e3fca4be35e2a438
- https://git.kernel.org/stable/c/5c8906de98d0d7ad42ff3edf2cb6cd7e0ea658c4
- https://git.kernel.org/stable/c/810ee43d9cd245d138a2733d87a24858a23f577d
- https://git.kernel.org/stable/c/c3af7e460a526007e4bed1ce3623274a1a6afe5e
- https://git.kernel.org/stable/c/ef4e249971eb77ec33d74c5c3de1e2576faf6c90
- https://git.kernel.org/stable/c/f82cb7f24032ed023fc67d26ea9bf322d8431a90
- https://git.kernel.org/stable/c/fac5e82ab1334fc8ed6ff7183702df634bd1d93d
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46745
In the Linux kernel, the following vulnerability has been resolved: Input: uinput - reject requests with unreasonable number of slots When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request. Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.
- https://git.kernel.org/stable/c/206f533a0a7c683982af473079c4111f4a0f9f5e
- https://git.kernel.org/stable/c/51fa08edd80003db700bdaa099385c5900d27f4b
- https://git.kernel.org/stable/c/597ff930296c4c8fc6b6a536884d4f1a7187ec70
- https://git.kernel.org/stable/c/61df76619e270a46fd427fbdeb670ad491c42de2
- https://git.kernel.org/stable/c/9719687398dea8a6a12a10321a54dd75eec7ab2d
- https://git.kernel.org/stable/c/9c6d189f0c1c59ba9a32326ec82a0b367a3cd47b
- https://git.kernel.org/stable/c/a4858b00a1ec57043697fb935565fe267f161833
- https://git.kernel.org/stable/c/d76fc0f0b18d49b7e721c9e4975ef4bffde2f3e7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-23
CVE-2024-46746
In the Linux kernel, the following vulnerability has been resolved:
HID: amd_sfh: free driver_data after destroying hid device
HID driver callbacks aren't called anymore once hid_destroy_device() has
been called. Hence, hid driver_data should be freed only after the
hid_destroy_device() function returned as driver_data is used in several
callbacks.
I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling
KASAN to debug memory allocation, I got this output:
[ 13.050438] ==================================================================
[ 13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]
[ 13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3
[ 13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479
[ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0
[ 13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024
[ 13.067860] Call Trace:
[ 13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8
[ 13.071486]
- https://git.kernel.org/stable/c/60dc4ee0428d70bcbb41436b6729d29f1cbdfb89
- https://git.kernel.org/stable/c/775125c7fe38533aaa4b20769f5b5e62cc1170a0
- https://git.kernel.org/stable/c/86b4f5cf91ca03c08e3822ac89476a677a780bcc
- https://git.kernel.org/stable/c/97155021ae17b86985121b33cf8098bcde00d497
- https://git.kernel.org/stable/c/adb3e3c1ddb5a23b8b7122ef1913f528d728937c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46747
In the Linux kernel, the following vulnerability has been resolved: HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it
- https://git.kernel.org/stable/c/30e9ce7cd5591be639b53595c95812f1a2afdfdc
- https://git.kernel.org/stable/c/34185de73d74fdc90e8651cfc472bfea6073a13f
- https://git.kernel.org/stable/c/48b2108efa205f4579052c27fba2b22cc6ad8aa0
- https://git.kernel.org/stable/c/890dde6001b651be79819ef7a3f8c71fc8f9cabf
- https://git.kernel.org/stable/c/a6e9c391d45b5865b61e569146304cff72821a5d
- https://git.kernel.org/stable/c/e239e44dcd419b13cf840e2a3a833204e4329714
- https://git.kernel.org/stable/c/e4a602a45aecd6a98b4b37482f5c9f8f67a32ddd
- https://git.kernel.org/stable/c/fac3cb3c6428afe2207593a183b5bc4742529dfd
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-20
CVE-2024-46749
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush() This adds a check before freeing the rx->skb in flush and close functions to handle the kernel crash seen while removing driver after FW download fails or before FW download completes. dmesg log: [ 54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 [ 54.643398] Mem abort info: [ 54.646204] ESR = 0x0000000096000004 [ 54.649964] EC = 0x25: DABT (current EL), IL = 32 bits [ 54.655286] SET = 0, FnV = 0 [ 54.658348] EA = 0, S1PTW = 0 [ 54.661498] FSC = 0x04: level 0 translation fault [ 54.666391] Data abort info: [ 54.669273] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 54.674768] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 54.674771] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000 [ 54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000 [ 54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse [ 54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2 [ 54.744364] Hardware name: FSL i.MX8MM EVK board (DT) [ 54.744368] Workqueue: hci0 hci_power_on [ 54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 54.757249] pc : kfree_skb_reason+0x18/0xb0 [ 54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart] [ 54.782921] sp : ffff8000805ebca0 [ 54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000 [ 54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230 [ 54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92 [ 54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff [ 54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857 [ 54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642 [ 54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688 [ 54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000 [ 54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac [ 54.857599] Call trace: [ 54.857601] kfree_skb_reason+0x18/0xb0 [ 54.863878] btnxpuart_flush+0x40/0x58 [btnxpuart] [ 54.863888] hci_dev_open_sync+0x3a8/0xa04 [ 54.872773] hci_power_on+0x54/0x2e4 [ 54.881832] process_one_work+0x138/0x260 [ 54.881842] worker_thread+0x32c/0x438 [ 54.881847] kthread+0x118/0x11c [ 54.881853] ret_from_fork+0x10/0x20 [ 54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400) [ 54.896410] ---[ end trace 0000000000000000 ]---
Modified: 2025-11-03
CVE-2024-46750
In the Linux kernel, the following vulnerability has been resolved:
PCI: Add missing bridge lock to pci_bus_lock()
One of the true positives that the cfg_access_lock lockdep effort
identified is this sequence:
WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70
RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70
Call Trace:
- https://git.kernel.org/stable/c/04e85a3285b0e5c5af6fd2c0fd6e95ffecc01945
- https://git.kernel.org/stable/c/0790b89c7e911003b8c50ae50e3ac7645de1fae9
- https://git.kernel.org/stable/c/7253b4fed46471cc247c6cacefac890a8472c083
- https://git.kernel.org/stable/c/78c6e39fef5c428960aff742149bba302dd46f5a
- https://git.kernel.org/stable/c/81c68e218ab883dfa368460a59b674084c0240da
- https://git.kernel.org/stable/c/a4e772898f8bf2e7e1cf661a12c60a5612c4afab
- https://git.kernel.org/stable/c/df77a678c33871a6e4ac5b54a71662f1d702335b
- https://git.kernel.org/stable/c/e2355d513b89a2cb511b4ded0deb426cdb01acd0
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46752
In the Linux kernel, the following vulnerability has been resolved: btrfs: replace BUG_ON() with error handling at update_ref_for_cow() Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory).
- https://git.kernel.org/stable/c/0fbac73a97286a7ec72229cb9b42d760a2c717ac
- https://git.kernel.org/stable/c/41a0f85e268d72fe04f731b8ceea4748c2d65491
- https://git.kernel.org/stable/c/b50857b96429a09fd3beed9f7f21b7bb7c433688
- https://git.kernel.org/stable/c/b56329a782314fde5b61058e2a25097af7ccb675
- https://git.kernel.org/stable/c/f895db00c65e5d77c437cce946da9ec29dcdf563
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46755
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()
mwifiex_get_priv_by_id() returns the priv pointer corresponding to
the bss_num and bss_type, but without checking if the priv is actually
currently in use.
Unused priv pointers do not have a wiphy attached to them which can
lead to NULL pointer dereferences further down the callstack. Fix
this by returning only used priv pointers which have priv->bss_mode
set to something else than NL80211_IFTYPE_UNSPECIFIED.
Said NULL pointer dereference happened when an Accesspoint was started
with wpa_supplicant -i mlan0 with this config:
network={
ssid="somessid"
mode=2
frequency=2412
key_mgmt=WPA-PSK WPA-PSK-SHA256
proto=RSN
group=CCMP
pairwise=CCMP
psk="12345678"
}
When waiting for the AP to be established, interrupting wpa_supplicant
with
- https://git.kernel.org/stable/c/1a05d8d02cfa3540ea5dbd6b39446bd3f515521f
- https://git.kernel.org/stable/c/9813770f25855b866b8ead8155b8806b2db70f6d
- https://git.kernel.org/stable/c/a12cf97cbefa139ef8d95081f2ea047cbbd74b7a
- https://git.kernel.org/stable/c/c145eea2f75ff7949392aebecf7ef0a81c1f6c14
- https://git.kernel.org/stable/c/c16916dd6c16fa7e13ca3923eb6b9f50d848ad03
- https://git.kernel.org/stable/c/c2618dcb26c7211342b54520b5b148c0d3471c8a
- https://git.kernel.org/stable/c/cb67b2e51b75f1a17bee7599c8161b96e1808a70
- https://git.kernel.org/stable/c/d834433ff313838a259bb6607055ece87b895b66
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46759
In the Linux kernel, the following vulnerability has been resolved: hwmon: (adc128d818) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
- https://git.kernel.org/stable/c/019ef2d396363ecddc46e826153a842f8603799b
- https://git.kernel.org/stable/c/05419d0056dcf7088687e561bb583cc06deba777
- https://git.kernel.org/stable/c/2a3add62f183459a057336381ef3a896da01ce38
- https://git.kernel.org/stable/c/6891b11a0c6227ca7ed15786928a07b1c0e4d4af
- https://git.kernel.org/stable/c/7645d783df23878342d5d8d22030c3861d2d5426
- https://git.kernel.org/stable/c/8cad724c8537fe3e0da8004646abc00290adae40
- https://git.kernel.org/stable/c/b0bdb43852bf7f55ba02f0cbf00b4ea7ca897bff
- https://git.kernel.org/stable/c/f7f5101af5b47a331cdbfa42ba64c507b47dd1fe
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-23
CVE-2024-46760
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: schedule rx work after everything is set up Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status.
Modified: 2025-11-03
CVE-2024-46761
In the Linux kernel, the following vulnerability has been resolved: pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB. The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash. The patch fixes the check during unregistration path to prevent invoking pci_disable_msi/msix() since its data structure is already freed.
- https://git.kernel.org/stable/c/335e35b748527f0c06ded9eebb65387f60647fda
- https://git.kernel.org/stable/c/438d522227374042b5c8798f8ce83bbe479dca4d
- https://git.kernel.org/stable/c/4eb4085c1346d19d4a05c55246eb93e74e671048
- https://git.kernel.org/stable/c/b82d4d5c736f4fd2ed224c35f554f50d1953d21e
- https://git.kernel.org/stable/c/bc1faed19db95abf0933b104910a3fb01b138f59
- https://git.kernel.org/stable/c/bfc44075b19740d372f989f21dd03168bfda0689
- https://git.kernel.org/stable/c/c0d8094dc740cfacf3775bbc6a1c4720459e8de4
- https://git.kernel.org/stable/c/c4c681999d385e28f84808bbf3a85ea8e982da55
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-23
CVE-2024-46762
In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Fix possible access to a freed kirqfd instance Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd created and added to the irqfds_list by privcmd_irqfd_assign() may get removed by another thread executing privcmd_irqfd_deassign(), while the former is still using it after dropping the locks. This can lead to a situation where an already freed kirqfd instance may be accessed and cause kernel oops. Use SRCU locking to prevent the same, as is done for the KVM implementation for irqfds.
Modified: 2025-11-03
CVE-2024-46763
In the Linux kernel, the following vulnerability has been resolved:
fou: Fix null-ptr-deref in GRO.
We observed a null-ptr-deref in fou_gro_receive() while shutting down
a host. [0]
The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol
in struct fou.
When fou_release() is called due to netns dismantle or explicit tunnel
teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.
Then, the tunnel socket is destroyed after a single RCU grace period.
So, in-flight udp4_gro_receive() could find the socket and execute the
FOU GRO handler, where sk->sk_user_data could be NULL.
Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL
checks in FOU GRO handlers.
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0
SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1
Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017
RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]
Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42
RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297
RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010
RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08
RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002
R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400
R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0
FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/1df42be305fe478ded1ee0c1d775f4ece713483b
- https://git.kernel.org/stable/c/231c235d2f7a66f018f172e26ffd47c363f244ef
- https://git.kernel.org/stable/c/4494bccb52ffda22ce5a1163a776d970e6229e08
- https://git.kernel.org/stable/c/7e4196935069947d8b70b09c1660b67b067e75cb
- https://git.kernel.org/stable/c/c46cd6aaca81040deaea3500ba75126963294bd9
- https://git.kernel.org/stable/c/d7567f098f54cb53ee3cee1c82e3d0ed9698b6b3
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-26
CVE-2024-46765
In the Linux kernel, the following vulnerability has been resolved:
ice: protect XDP configuration with a mutex
The main threat to data consistency in ice_xdp() is a possible asynchronous
PF reset. It can be triggered by a user or by TX timeout handler.
XDP setup and PF reset code access the same resources in the following
sections:
* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked
* ice_vsi_rebuild() for the PF VSI - not protected
* ice_vsi_open() - already rtnl-locked
With an unfortunate timing, such accesses can result in a crash such as the
one below:
[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14
[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18
[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms
[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001
[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14
[ +0.394718] ice 0000:b1:00.0: PTP reset successful
[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098
[ +0.000045] #PF: supervisor read access in kernel mode
[ +0.000023] #PF: error_code(0x0000) - not-present page
[ +0.000023] PGD 0 P4D 0
[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1
[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021
[ +0.000036] Workqueue: ice ice_service_task [ice]
[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]
[...]
[ +0.000013] Call Trace:
[ +0.000016]
Modified: 2025-09-26
CVE-2024-46767
In the Linux kernel, the following vulnerability has been resolved: net: phy: Fix missing of_node_put() for leds The call of of_get_child_by_name() will cause refcount incremented for leds, if it succeeds, it should call of_node_put() to decrease it, fix it.
Modified: 2024-11-20
CVE-2024-46768
In the Linux kernel, the following vulnerability has been resolved: hwmon: (hp-wmi-sensors) Check if WMI event data exists The BIOS can choose to return no event data in response to a WMI event, so the ACPI object passed to the WMI notify handler can be NULL. Check for such a situation and ignore the event in such a case.
Modified: 2025-11-03
CVE-2024-46770
In the Linux kernel, the following vulnerability has been resolved:
ice: Add netif_device_attach/detach into PF reset flow
Ethtool callbacks can be executed while reset is in progress and try to
access deleted resources, e.g. getting coalesce settings can result in a
NULL pointer dereference seen below.
Reproduction steps:
Once the driver is fully initialized, trigger reset:
# echo 1 > /sys/class/net/
- https://git.kernel.org/stable/c/36486c9e8e01b84faaee47203eac0b7e9cc7fa4a
- https://git.kernel.org/stable/c/9e3ffb839249eca113062587659224f856fe14e5
- https://git.kernel.org/stable/c/d11a67634227f9f9da51938af085fb41a733848f
- https://git.kernel.org/stable/c/efe8effe138044a4747d1112ebb8c454d1663723
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46771
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: Remove proc entry when dev is unregistered.
syzkaller reported a warning in bcm_connect() below. [0]
The repro calls connect() to vxcan1, removes vxcan1, and calls
connect() with ifindex == 0.
Calling connect() for a BCM socket allocates a proc entry.
Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().
However, removing the bound device resets bcm_sk(sk)->bound to 0
in bcm_notify().
The 2nd connect() tries to allocate a proc entry with the same
name and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking the
original proc entry.
Since the proc entry is available only for connect()ed sockets,
let's clean up the entry when the bound netdev is unregistered.
[0]:
proc_dir_entry 'can-bcm/2456' already registered
WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375
Modules linked in:
CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375
Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48
RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246
RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0
R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec
FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/10bfacbd5e8d821011d857bee73310457c9c989a
- https://git.kernel.org/stable/c/33ed4ba73caae39f34ab874ba79138badc2c65dd
- https://git.kernel.org/stable/c/3b39dc2901aa7a679a5ca981a3de9f8d5658afe8
- https://git.kernel.org/stable/c/4377b79323df62eb5d310354f19b4d130ff58d50
- https://git.kernel.org/stable/c/5c680022c4e28ba18ea500f3e29f0428271afa92
- https://git.kernel.org/stable/c/76fe372ccb81b0c89b6cd2fec26e2f38c958be85
- https://git.kernel.org/stable/c/abb0a615569ec008e8a93d9f3ab2d5b418ea94d4
- https://git.kernel.org/stable/c/aec92dbebdbec7567d9f56d7c9296a572b8fd849
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46773
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check denominator pbn_div before used [WHAT & HOW] A denominator cannot be 0, and is checked before used. This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.
- https://git.kernel.org/stable/c/116a678f3a9abc24f5c9d2525b7393d18d9eb58e
- https://git.kernel.org/stable/c/11f997143c67680d6e40a13363618380cd57a414
- https://git.kernel.org/stable/c/20e7164c52d9bfbb9d9862b833fa989624a61345
- https://git.kernel.org/stable/c/dfafee0a7b51c7c9612edd2d991401294964d02f
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-20
CVE-2024-46776
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Run DC_LOG_DC after checking link->link_enc [WHAT] The DC_LOG_DC should be run after link->link_enc is checked, not before. This fixes 1 REVERSE_INULL issue reported by Coverity.
Modified: 2025-11-03
CVE-2024-46777
In the Linux kernel, the following vulnerability has been resolved: udf: Avoid excessive partition lengths Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap.
- https://git.kernel.org/stable/c/0173999123082280cf904bd640015951f194a294
- https://git.kernel.org/stable/c/1497a4484cdb2cf6c37960d788fb6ba67567bdb7
- https://git.kernel.org/stable/c/2ddf831451357c6da4b64645eb797c93c1c054d1
- https://git.kernel.org/stable/c/551966371e17912564bc387fbeb2ac13077c3db1
- https://git.kernel.org/stable/c/925fd8ee80d5348a5e965548e5484d164d19221d
- https://git.kernel.org/stable/c/a56330761950cb83de1dfb348479f20c56c95f90
- https://git.kernel.org/stable/c/c0c23130d38e8bc28e9ef581443de9b1fc749966
- https://git.kernel.org/stable/c/ebbe26fd54a9621994bc16b14f2ba8f84c089693
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46780
In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect references to superblock parameters exposed in sysfs The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem". Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so fix it.
- https://git.kernel.org/stable/c/157c0d94b4c40887329418c70ef4edd1a8d6b4ed
- https://git.kernel.org/stable/c/19cfeba0e4b8eda51484fcf8cf7d150418e1d880
- https://git.kernel.org/stable/c/683408258917541bdb294cd717c210a04381931e
- https://git.kernel.org/stable/c/8c6e43b3d5f109cf9c61bc188fcc8175404e924f
- https://git.kernel.org/stable/c/962562d4c70c5cdeb4e955d63ff2017c4eca1aad
- https://git.kernel.org/stable/c/b14e7260bb691d7f563f61da07d61e3c8b59a614
- https://git.kernel.org/stable/c/b90beafac05931cbfcb6b1bd4f67c1923f47040e
- https://git.kernel.org/stable/c/ba97ba173f9625d5f34a986088979eae8b80d38e
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46781
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix missing cleanup on rollforward recovery error In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug. It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the ns_dirty_files list of the nilfs object and were not freed. Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log writer starts.
- https://git.kernel.org/stable/c/07e4dc2fe000ab008bcfe90be4324ef56b5b4355
- https://git.kernel.org/stable/c/1cf1f7e8cd47244fa947d357ef1f642d91e219a3
- https://git.kernel.org/stable/c/35a9a7a7d94662146396199b0cfd95f9517cdd14
- https://git.kernel.org/stable/c/5787fcaab9eb5930f5378d6a1dd03d916d146622
- https://git.kernel.org/stable/c/8e2d1e9d93c4ec51354229361ac3373058529ec4
- https://git.kernel.org/stable/c/9d8c3a585d564d776ee60d4aabec59b404be7403
- https://git.kernel.org/stable/c/ca92c4bff2833cb30d493b935168d6cccd5c805d
- https://git.kernel.org/stable/c/da02f9eb333333b2e4f25d2a14967cff785ac82e
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46782
In the Linux kernel, the following vulnerability has been resolved:
ila: call nf_unregister_net_hooks() sooner
syzbot found an use-after-free Read in ila_nf_input [1]
Issue here is that ila_xlat_exit_net() frees the rhashtable,
then call nf_unregister_net_hooks().
It should be done in the reverse way, with a synchronize_rcu().
This is a good match for a pre_exit() method.
[1]
BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]
BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16
CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
- https://git.kernel.org/stable/c/031ae72825cef43e4650140b800ad58bf7a6a466
- https://git.kernel.org/stable/c/18a5a16940464b301ea91bf5da3a324aedb347b2
- https://git.kernel.org/stable/c/43d34110882b97ba1ec66cc8234b18983efb9abf
- https://git.kernel.org/stable/c/47abd8adddbc0aecb8f231269ef659148d5dabe4
- https://git.kernel.org/stable/c/925c18a7cff93d8a4320d652351294ff7d0ac93c
- https://git.kernel.org/stable/c/93ee345ba349922834e6a9d1dadabaedcc12dce6
- https://git.kernel.org/stable/c/bda4d84ac0d5421b346faee720011f58bdb99673
- https://git.kernel.org/stable/c/dcaf4e2216824839d26727a15b638c6a677bd9fc
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46783
In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: fix return value of tcp_bpf_sendmsg() When we cork messages in psock->cork, the last message triggers the flushing will result in sending a sk_msg larger than the current message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes negative at least in the following case: 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES; Therefore, it could lead to the following BUG with a proper value of 'copied' (thanks to syzbot). We should not use negative 'copied' as a return value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/126d72b726c4cf1119f3a7fe413a78d341c3fea9
- https://git.kernel.org/stable/c/3efe53eb221a38e207c1e3f81c51e4ca057d50c2
- https://git.kernel.org/stable/c/6f9fdf5806cced888c43512bccbdf7fefd50f510
- https://git.kernel.org/stable/c/78bb38d9c5a311c5f8bdef7c9557d7d81ca30e4a
- https://git.kernel.org/stable/c/810a4e7d92dea4074cb04c25758320909d752193
- https://git.kernel.org/stable/c/c8219a27fa43a2cbf99f5176f6dddfe73e7a24ae
- https://git.kernel.org/stable/c/fe1910f9337bd46a9343967b547ccab26b4b2c6e
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46784
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup Currently napi_disable() gets called during rxq and txq cleanup, even before napi is enabled and hrtimer is initialized. It causes kernel panic. ? page_fault_oops+0x136/0x2b0 ? page_counter_cancel+0x2e/0x80 ? do_user_addr_fault+0x2f2/0x640 ? refill_obj_stock+0xc4/0x110 ? exc_page_fault+0x71/0x160 ? asm_exc_page_fault+0x27/0x30 ? __mmdrop+0x10/0x180 ? __mmdrop+0xec/0x180 ? hrtimer_active+0xd/0x50 hrtimer_try_to_cancel+0x2c/0xf0 hrtimer_cancel+0x15/0x30 napi_disable+0x65/0x90 mana_destroy_rxq+0x4c/0x2f0 mana_create_rxq.isra.0+0x56c/0x6d0 ? mana_uncfg_vport+0x50/0x50 mana_alloc_queues+0x21b/0x320 ? skb_dequeue+0x5f/0x80
- https://git.kernel.org/stable/c/386617efacab10bf5bb40bde403467c57cc00470
- https://git.kernel.org/stable/c/4982a47154f0b50de81ee0a0b169a3fc74120a65
- https://git.kernel.org/stable/c/9178eb8ebcd887ab75e54ac40d538e54bb9c7788
- https://git.kernel.org/stable/c/9e0bff4900b5d412a9bafe4baeaa6facd34f671c
- https://git.kernel.org/stable/c/b6ecc662037694488bfff7c9fd21c405df8411f2
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-20
CVE-2024-46785
In the Linux kernel, the following vulnerability has been resolved: eventfs: Use list_del_rcu() for SRCU protected list variable Chi Zhiling reported: We found a null pointer accessing in tracefs[1], the reason is that the variable 'ei_child' is set to LIST_POISON1, that means the list was removed in eventfs_remove_rec. so when access the ei_child->is_freed, the panic triggered. by the way, the following script can reproduce this panic loop1 (){ while true do echo "p:kp submit_bio" > /sys/kernel/debug/tracing/kprobe_events echo "" > /sys/kernel/debug/tracing/kprobe_events done } loop2 (){ while true do tree /sys/kernel/debug/tracing/events/kprobes/ done } loop1 & loop2 [1]: [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150 [ 1147.968239][T17331] Mem abort info: [ 1147.971739][T17331] ESR = 0x0000000096000004 [ 1147.976172][T17331] EC = 0x25: DABT (current EL), IL = 32 bits [ 1147.982171][T17331] SET = 0, FnV = 0 [ 1147.985906][T17331] EA = 0, S1PTW = 0 [ 1147.989734][T17331] FSC = 0x04: level 0 translation fault [ 1147.995292][T17331] Data abort info: [ 1147.998858][T17331] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1148.005023][T17331] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1148.010759][T17331] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls] [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G W ------- ---- 6.6.43 #2 [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650 [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020 [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398 [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398 [ 1148.115969][T17331] sp : ffff80008d56bbd0 [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000 [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100 [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10 [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000 [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0 [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0 [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862 [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068 [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001 [ 1148.198131][T17331] Call trace: [ 1148.201259][T17331] eventfs_iterate+0x2c0/0x398 [ 1148.205864][T17331] iterate_dir+0x98/0x188 [ 1148.210036][T17331] __arm64_sys_getdents64+0x78/0x160 [ 1148.215161][T17331] invoke_syscall+0x78/0x108 [ 1148.219593][T17331] el0_svc_common.constprop.0+0x48/0xf0 [ 1148.224977][T17331] do_el0_svc+0x24/0x38 [ 1148.228974][T17331] el0_svc+0x40/0x168 [ 1148.232798][T17 ---truncated---
Modified: 2026-04-23
CVE-2024-46786
In the Linux kernel, the following vulnerability has been resolved:
fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF
The fscache_cookie_lru_timer is initialized when the fscache module
is inserted, but is not deleted when the fscache module is removed.
If timer_reduce() is called before removing the fscache module,
the fscache_cookie_lru_timer will be added to the timer list of
the current cpu. Afterwards, a use-after-free will be triggered
in the softIRQ after removing the fscache module, as follows:
==================================================================
BUG: unable to handle page fault for address: fffffbfff803c9e9
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855
Tainted: [W]=WARN
RIP: 0010:__run_timer_base.part.0+0x254/0x8a0
Call Trace:
Modified: 2024-11-20
CVE-2024-46787
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: fix checks for huge PMDs
Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.
The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:
1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
the right two race windows) - I've tested this in a kernel build with
some extra mdelay() calls. See the commit message for a description
of the race scenario.
On older kernels (before 6.5), I think the same bug can even
theoretically lead to accessing transhuge page contents as a page table
if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
detecting PMDs that don't point to page tables.
On older kernels (before 6.5), you'd just have to win a single fairly
wide race to hit this.
I've tested this on 6.1 stable by racing migration (with a mdelay()
patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed
to yank page tables out from under us (though I haven't tested that),
so I think the BUG_ON() checks in mfill_atomic() are just wrong.
I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backported to kernels
affected by bugs 1+2.
This patch (of 2):
This fixes two issues.
I discovered that the following race can occur:
mfill_atomic other thread
============ ============
Modified: 2024-11-22
CVE-2024-46788
In the Linux kernel, the following vulnerability has been resolved:
tracing/osnoise: Use a cpumask to know what threads are kthreads
The start_kthread() and stop_thread() code was not always called with the
interface_lock held. This means that the kthread variable could be
unexpectedly changed causing the kthread_stop() to be called on it when it
should not have been, leading to:
while true; do
rtla timerlat top -u -q & PID=$!;
sleep 5;
kill -INT $PID;
sleep 0.001;
kill -TERM $PID;
wait $PID;
done
Causing the following OOPS:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:hrtimer_active+0x58/0x300
Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 <0f> b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f
RSP: 0018:ffff88811d97f940 EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b
RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28
RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60
R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d
R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28
FS: 0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0
Call Trace:
Modified: 2025-11-03
CVE-2024-46791
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open
The mcp251x_hw_wake() function is called with the mpc_lock mutex held and
disables the interrupt handler so that no interrupts can be processed while
waking the device. If an interrupt has already occurred then waiting for
the interrupt handler to complete will deadlock because it will be trying
to acquire the same mutex.
CPU0 CPU1
---- ----
mcp251x_open()
mutex_lock(&priv->mcp_lock)
request_threaded_irq()
- https://git.kernel.org/stable/c/3a49b6b1caf5cefc05264d29079d52c99cb188e0
- https://git.kernel.org/stable/c/513c8fc189b52f7922e36bdca58997482b198f0e
- https://git.kernel.org/stable/c/7dd9c26bd6cf679bcfdef01a8659791aa6487a29
- https://git.kernel.org/stable/c/8fecde9c3f9a4b97b68bb97c9f47e5b662586ba7
- https://git.kernel.org/stable/c/e554113a1cd2a9cfc6c7af7bdea2141c5757e188
- https://git.kernel.org/stable/c/f7ab9e14b23a3eac6714bdc4dba244d8aa1ef646
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46794
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix data leak in mmio_read() The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM. Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM. This variable is only needed as an output value. It did not need to be passed to the VMM in the first place. Do not send the original value of *val to the VMM. [ dhansen: clarify what 'val' is used for. ]
- https://git.kernel.org/stable/c/26c6af49d26ffc377e392e30d4086db19eed0ef7
- https://git.kernel.org/stable/c/b55ce742afcb8e8189d82f2f1e635ba1b5a461fa
- https://git.kernel.org/stable/c/b6fb565a2d15277896583d471b21bc14a0c99661
- https://git.kernel.org/stable/c/ef00818c50cf55a3a56bd9a9fae867c92dfb84e7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46795
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: unset the binding mark of a reused connection
Steve French reported null pointer dereference error from sha256 lib.
cifs.ko can send session setup requests on reused connection.
If reused connection is used for binding session, conn->binding can
still remain true and generate_preauth_hash() will not set
sess->Preauth_HashValue and it will be NULL.
It is used as a material to create an encryption key in
ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer
dereference error from crypto_shash_update().
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 8 PID: 429254 Comm: kworker/8:39
Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )
Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]
- https://git.kernel.org/stable/c/41bc256da7e47b679df87c7fc7a5b393052b9cce
- https://git.kernel.org/stable/c/4c8496f44f5bb5c06cdef5eb130ab259643392a1
- https://git.kernel.org/stable/c/78c5a6f1f630172b19af4912e755e1da93ef0ab5
- https://git.kernel.org/stable/c/93d54a4b59c4b3d803d20aa645ab5ca71f3b3b02
- https://git.kernel.org/stable/c/9914f1bd61d5e838bb1ab15a71076d37a6db65d1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-09-29
CVE-2024-46797
In the Linux kernel, the following vulnerability has been resolved: powerpc/qspinlock: Fix deadlock in MCS queue If an interrupt occurs in queued_spin_lock_slowpath() after we increment qnodesp->count and before node->lock is initialized, another CPU might see stale lock values in get_tail_qnode(). If the stale lock value happens to match the lock on that CPU, then we write to the "next" pointer of the wrong qnode. This causes a deadlock as the former CPU, once it becomes the head of the MCS queue, will spin indefinitely until it's "next" pointer is set by its successor in the queue. Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in occasional lockups similar to the following: $ stress-ng --all 128 --vm-bytes 80% --aggressive \ --maximize --oomable --verify --syslog \ --metrics --times --timeout 5m watchdog: CPU 15 Hard LOCKUP ...... NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 Call Trace: 0xc000002cfffa3bf0 (unreliable) _raw_spin_lock+0x6c/0x90 raw_spin_rq_lock_nested.part.135+0x4c/0xd0 sched_ttwu_pending+0x60/0x1f0 __flush_smp_call_function_queue+0x1dc/0x670 smp_ipi_demux_relaxed+0xa4/0x100 xive_muxed_ipi_action+0x20/0x40 __handle_irq_event_percpu+0x80/0x240 handle_irq_event_percpu+0x2c/0x80 handle_percpu_irq+0x84/0xd0 generic_handle_irq+0x54/0x80 __do_irq+0xac/0x210 __do_IRQ+0x74/0xd0 0x0 do_IRQ+0x8c/0x170 hardware_interrupt_common_virt+0x29c/0x2a0 --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490 ...... NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 --- interrupt: 500 0xc0000029c1a41d00 (unreliable) _raw_spin_lock+0x6c/0x90 futex_wake+0x100/0x260 do_futex+0x21c/0x2a0 sys_futex+0x98/0x270 system_call_exception+0x14c/0x2f0 system_call_vectored_common+0x15c/0x2ec The following code flow illustrates how the deadlock occurs. For the sake of brevity, assume that both locks (A and B) are contended and we call the queued_spin_lock_slowpath() function. CPU0 CPU1 ---- ---- spin_lock_irqsave(A) | spin_unlock_irqrestore(A) | spin_lock(B) | | | ▼ | id = qnodesp->count++; | (Note that nodes[0].lock == A) | | | ▼ | Interrupt | (happens before "nodes[0].lock = B") | | | ▼ | spin_lock_irqsave(A) | | | ▼ | id = qnodesp->count++ | nodes[1].lock = A | | | ▼ | Tail of MCS queue | | spin_lock_irqsave(A) ▼ | Head of MCS queue ▼ | CPU0 is previous tail ▼ | Spin indefinitely ▼ (until "nodes[1].next != NULL") prev = get_tail_qnode(A, CPU0) | ▼ prev == &qnodes[CPU0].nodes[0] (as qnodes ---truncated---
Modified: 2025-11-03
CVE-2024-46798
In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object When using kernel with the following extra config, - CONFIG_KASAN=y - CONFIG_KASAN_GENERIC=y - CONFIG_KASAN_INLINE=y - CONFIG_KASAN_VMALLOC=y - CONFIG_FRAME_WARN=4096 kernel detects that snd_pcm_suspend_all() access a freed 'snd_soc_pcm_runtime' object when the system is suspended, which leads to a use-after-free bug: [ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270 [ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330 [ 52.047785] Call trace: [ 52.047787] dump_backtrace+0x0/0x3c0 [ 52.047794] show_stack+0x34/0x50 [ 52.047797] dump_stack_lvl+0x68/0x8c [ 52.047802] print_address_description.constprop.0+0x74/0x2c0 [ 52.047809] kasan_report+0x210/0x230 [ 52.047815] __asan_report_load1_noabort+0x3c/0x50 [ 52.047820] snd_pcm_suspend_all+0x1a8/0x270 [ 52.047824] snd_soc_suspend+0x19c/0x4e0 The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' before making any access. So we need to always set 'substream->runtime' to NULL everytime we kfree() it.
- https://git.kernel.org/stable/c/3033ed903b4f28b5e1ab66042084fbc2c48f8624
- https://git.kernel.org/stable/c/5d13afd021eb43868fe03cef6da34ad08831ad6d
- https://git.kernel.org/stable/c/6a14fad8be178df6c4589667efec1789a3307b4e
- https://git.kernel.org/stable/c/8ca21e7a27c66b95a4b215edc8e45e5d66679f9f
- https://git.kernel.org/stable/c/993b60c7f93fa1d8ff296b58f646a867e945ae89
- https://git.kernel.org/stable/c/b4a90b543d9f62d3ac34ec1ab97fc5334b048565
- https://git.kernel.org/stable/c/fe5046ca91d631ec432eee3bdb1f1c49b09c8b5e
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46800
In the Linux kernel, the following vulnerability has been resolved: sch/netem: fix use after free in netem_dequeue If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails") Commands to trigger KASAN UaF: ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF
- https://git.kernel.org/stable/c/14f91ab8d391f249b845916820a56f42cf747241
- https://git.kernel.org/stable/c/295ad5afd9efc5f67b86c64fce28fb94e26dc4c9
- https://git.kernel.org/stable/c/32008ab989ddcff1a485fa2b4906234c25dc5cd6
- https://git.kernel.org/stable/c/3b3a2a9c6349e25a025d2330f479bc33a6ccb54a
- https://git.kernel.org/stable/c/98c75d76187944296068d685dfd8a1e9fd8c4fdc
- https://git.kernel.org/stable/c/db2c235682913a63054e741fe4e19645fdf2d68e
- https://git.kernel.org/stable/c/dde33a9d0b80aae0c69594d1f462515d7ff1cb3d
- https://git.kernel.org/stable/c/f0bddb4de043399f16d1969dad5ee5b984a64e7b
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46802
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: added NULL check at start of dc_validate_stream [Why] prevent invalid memory access [How] check if dc and stream are NULL
- https://git.kernel.org/stable/c/154a50bf4221a6a6ccf88d565b8184da7c40a2dd
- https://git.kernel.org/stable/c/26c56049cc4f1705b498df013949427692a4b0d5
- https://git.kernel.org/stable/c/356fcce9cdbfe338a275e9e1836adfdd7f5c52a9
- https://git.kernel.org/stable/c/6bf920193ba1853bad780bba565a789246d9003c
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-04
CVE-2024-46803
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check debug trap enable before write dbg_ev_file In interrupt context, write dbg_ev_file will be run by work queue. It will cause write dbg_ev_file execution after debug_trap_disable, which will cause NULL pointer access. v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL.
Modified: 2025-11-03
CVE-2024-46804
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add array index check for hdcp ddc access [Why] Coverity reports OVERRUN warning. Do not check if array index valid. [How] Check msg_id valid and valid array index.
- https://git.kernel.org/stable/c/0ee4387c5a4b57ec733c3fb4365188d5979cd9c7
- https://git.kernel.org/stable/c/2a63c90c7a90ab2bd23deebc2814fc5b52abf6d2
- https://git.kernel.org/stable/c/4e70c0f5251c25885c31ee84a31f99a01f7cf50e
- https://git.kernel.org/stable/c/8b5ccf3d011969417be653b5a145c72dbd30472c
- https://git.kernel.org/stable/c/a3b5ee22a9d3a30045191da5678ca8451ebaea30
- https://git.kernel.org/stable/c/f338f99f6a04d03c802087d82a83561cbd5bdc99
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46805
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix the waring dereferencing hive Check the amdgpu_hive_info *hive that maybe is NULL.
- https://git.kernel.org/stable/c/01cd55b971131b07b7ff8d622fa93bb4f8be07df
- https://git.kernel.org/stable/c/1940708ccf5aff76de4e0b399f99267c93a89193
- https://git.kernel.org/stable/c/4ab720b6aa1ef5e71db1e534b5b45c80ac4ec58a
- https://git.kernel.org/stable/c/d3f927ef0607b3c8c3f79ab6d9a4ebead3e35f4c
- https://git.kernel.org/stable/c/f20d1d5cbb39802f68be24458861094f3e66f356
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-02
CVE-2024-46806
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the warning division or modulo by zero Checks the partition mode and returns an error for an invalid mode.
Modified: 2025-11-03
CVE-2024-46807
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: Check tbo resource pointer Validate tbo resource pointer, skip if NULL
- https://git.kernel.org/stable/c/2be1eb6304d9623ba21dd6f3e68ffb753a759635
- https://git.kernel.org/stable/c/4dfec5f5501a27e0a0da00e136d65ef9011ded4c
- https://git.kernel.org/stable/c/6cd2b872643bb29bba01a8ac739138db7bd79007
- https://git.kernel.org/stable/c/e55e3904ffeaff81715256a711b1a61f4ad5258a
- https://git.kernel.org/stable/c/e8765364d4f3aaf88c7abe0a4fc99089d059ab49
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46809
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check BIOS images before it is used BIOS images may fail to load and null checks are added before they are used. This fixes 6 NULL_RETURNS issues reported by Coverity.
- https://git.kernel.org/stable/c/4fcd903a5d9e897420d7d8b3ca55c6e5dbb47379
- https://git.kernel.org/stable/c/8b0ddf19cca2a352b2a7e01d99d3ba949a99c84c
- https://git.kernel.org/stable/c/c5cb98554c4c6265b494d040c1c62f1db2fa28a6
- https://git.kernel.org/stable/c/e46b70a7cfed71cb84e985c785c39c16df5c28cb
- https://git.kernel.org/stable/c/e50bec62acaeec03afc6fa5dfb2426e52d049cf5
- https://git.kernel.org/stable/c/eef7301e674438913134539e77dd887960949f20
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-46810
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ Make sure the connector is fully initialized before signalling any HPD events via drm_kms_helper_hotplug_event(), otherwise this may lead to NULL pointer dereference.
- https://git.kernel.org/stable/c/162e48cb1d84c2c966b649b8ac5c9d4f75f6d44f
- https://git.kernel.org/stable/c/1fb13693953737783b424aa4712f0a27a9eaf5a8
- https://git.kernel.org/stable/c/9d567126474e68f959b2c2543c375f3bb32e948a
- https://git.kernel.org/stable/c/adc5674c23b8191e596ed0dbaa9600265ac896a8
- https://git.kernel.org/stable/c/e1b121f21bbc56a6ae035aa5b77daac62bfb9be5
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-07
CVE-2024-46811
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box [Why] Coverity reports OVERRUN warning. soc.num_states could be 40. But array range of bw_params->clk_table.entries is 8. [How] Assert if soc.num_states greater than 8.
Modified: 2025-11-03
CVE-2024-46812
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration [Why] Coverity reports Memory - illegal accesses. [How] Skip inactive planes.
- https://git.kernel.org/stable/c/2fd32a65f2e78eff0862c8fdf7815ca6bb44fb2e
- https://git.kernel.org/stable/c/3300a039caf850376bc3416c808cd8879da412bb
- https://git.kernel.org/stable/c/4331ae2788e779b11f3aad40c04be6c64831f2a2
- https://git.kernel.org/stable/c/8406158a546441b73f0b216aedacbf9a1e5748fb
- https://git.kernel.org/stable/c/a54f7e866cc73a4cb71b8b24bb568ba35c8969df
- https://git.kernel.org/stable/c/ee9d6df6d9172917d9ddbd948bb882652d5ecd29
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-11-03
CVE-2024-46814
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check msg_id before processing transcation [WHY & HOW] HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid array index, and it needs checking before used. This fixes 4 OVERRUN issues reported by Coverity.
- https://git.kernel.org/stable/c/0147505f08220c89b3a9c90eb608191276e263a8
- https://git.kernel.org/stable/c/6590643c5de74098d27933b7d224d5ac065d7755
- https://git.kernel.org/stable/c/916083054670060023d3f8a8ace895d710e268f4
- https://git.kernel.org/stable/c/cb63090a17d3abb87f132851fa3711281249b7d2
- https://git.kernel.org/stable/c/fa71face755e27dc44bc296416ebdf2c67163316
- https://git.kernel.org/stable/c/fe63daf7b10253b0faaa60c55d6153cd276927aa
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46815
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[] [WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1]. This fixes an OVERRUN issue reported by Coverity.
- https://git.kernel.org/stable/c/21f9cb44f8c60bf6c26487d428b1a09ad3e8aebf
- https://git.kernel.org/stable/c/6a4a08e45e614cfa7a56498cdfaeb7fae2f07fa0
- https://git.kernel.org/stable/c/7c47dd2e92341f2989ab73dbed07f8894593ad7b
- https://git.kernel.org/stable/c/a72d4996409569027b4609414a14a87679b12267
- https://git.kernel.org/stable/c/b36e9b3104c4ba0f2f5dd083dcf6159cb316c996
- https://git.kernel.org/stable/c/b38a4815f79b87efb196cd5121579fc51e29a7fb
- https://git.kernel.org/stable/c/c4a7f7c0062fe2c73f70bb7e335199e25bd71492
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46817
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 [Why] Coverity reports OVERRUN warning. Should abort amdgpu_dm initialize. [How] Return failure to amdgpu_dm_init.
- https://git.kernel.org/stable/c/21bbb39863f10f5fb4bf772d15b07d5d13590e9d
- https://git.kernel.org/stable/c/28b515c458aa9c92bfcb99884c94713a5f471cea
- https://git.kernel.org/stable/c/754321ed63f0a4a31252ca72e0bd89a9e1888018
- https://git.kernel.org/stable/c/84723eb6068c50610c5c0893980d230d7afa2105
- https://git.kernel.org/stable/c/94cb77700fa4ae6200486bfa0ba2ac547534afd2
- https://git.kernel.org/stable/c/d398c74c881dee695f6eb6138c9891644e1c3d9d
- https://git.kernel.org/stable/c/d619b91d3c4af60ac422f1763ce53d721fb91262
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46818
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check gpio_id before used as array index [WHY & HOW] GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance. This fixes 5 OVERRUN issues reported by Coverity.
- https://git.kernel.org/stable/c/0184cca30cad74d88f5c875d4e26999e26325700
- https://git.kernel.org/stable/c/08e7755f754e3d2cef7d3a7da538d33526bd6f7c
- https://git.kernel.org/stable/c/276e3fd93e3beb5894eb1cc8480f9f417d51524d
- https://git.kernel.org/stable/c/2a5626eeb3b5eec7a36886f9556113dd93ec8ed6
- https://git.kernel.org/stable/c/3d4198ab612ad48f73383ad3bb5663e6f0cdf406
- https://git.kernel.org/stable/c/40c2e8bc117cab8bca8814735f28a8b121654a84
- https://git.kernel.org/stable/c/8520fdc8ecc38f240a8e9e7af89cca6739c3e790
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46819
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: the warning dereferencing obj for nbio_v7_4 if ras_manager obj null, don't print NBIO err data
- https://git.kernel.org/stable/c/130c2dc75c8c40acc3c96ededea6af80e03c14b8
- https://git.kernel.org/stable/c/614564a5b28983de53b23a358ebe6c483a2aa21e
- https://git.kernel.org/stable/c/70e8ec21fcb8c51446899d3bfe416b31adfa3661
- https://git.kernel.org/stable/c/7d265772e44d403071a2b573eac0db60250b1c21
- https://git.kernel.org/stable/c/d04ded1e73f1dcf19a71ec8b9cda3faa7acd8828
- https://git.kernel.org/stable/c/d190b459b2a4304307c3468ed97477b808381011
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46821
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix negative array index read Avoid using the negative values for clk_idex as an index into an array pptable->DpmDescriptor. V2: fix clk_index return check (Tim Huang)
- https://git.kernel.org/stable/c/06a3810010b525b9958424e344f0c25b09e128fa
- https://git.kernel.org/stable/c/4711b1347cb9f0c3083da6d87c624d75f9bd1d50
- https://git.kernel.org/stable/c/60f4a4bc3329e5cb8c4df0cc961f0d5ffd96e22d
- https://git.kernel.org/stable/c/befd1dc693c98bad69a701ede3a298698f0f9436
- https://git.kernel.org/stable/c/c8c19ebf7c0b202a6a2d37a52ca112432723db5f
- https://git.kernel.org/stable/c/e549cd6da1f21c34ba0f65adeca6a8aa9860b381
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-11-03
CVE-2024-46822
In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed. If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible for the entry in cpu_madt_gicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility.
- https://git.kernel.org/stable/c/2488444274c70038eb6b686cba5f1ce48ebb9cdd
- https://git.kernel.org/stable/c/40cae0df42e5e7f7a1c0f32deed9c4027c1ba94e
- https://git.kernel.org/stable/c/4c3b21204abb4fa3ab310fbbb5cf7f0e85f3a1bc
- https://git.kernel.org/stable/c/62ca6d3a905b4c40cd942f3cc645a6718f8bc7e7
- https://git.kernel.org/stable/c/945be49f4e832a9184c313fdf8917475438a795b
- https://git.kernel.org/stable/c/bc7fbb37e3d2df59336eadbd6a56be632e3c7df7
- https://git.kernel.org/stable/c/f57769ff6fa7f97f1296965f20e8a2bb3ee9fd0f
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-20
CVE-2024-46825
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is normally called with input from the firmware, so it should use IWL_FW_CHECK() instead of WARN_ON().
Modified: 2025-11-03
CVE-2024-46826
In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec.
- https://git.kernel.org/stable/c/1cf8cd80903073440b6ea055811d04edd24fe4f7
- https://git.kernel.org/stable/c/1f81d51141a234ad0a3874b4d185dc27a521cd27
- https://git.kernel.org/stable/c/2a97388a807b6ab5538aa8f8537b2463c6988bd2
- https://git.kernel.org/stable/c/53f17409abf61f66b6f05aff795e938e5ba811d1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-20
CVE-2024-46827
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix firmware crash due to invalid peer nss Currently, if the access point receives an association request containing an Extended HE Capabilities Information Element with an invalid MCS-NSS, it triggers a firmware crash. This issue arises when EHT-PHY capabilities shows support for a bandwidth and MCS-NSS set for that particular bandwidth is filled by zeros and due to this, driver obtains peer_nss as 0 and sending this value to firmware causes crash. Address this issue by implementing a validation step for the peer_nss value before passing it to the firmware. If the value is greater than zero, proceed with forwarding it to the firmware. However, if the value is invalid, reject the association request to prevent potential firmware crashes. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Modified: 2025-11-03
CVE-2024-46828
In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: fix bulk flow accounting logic for host fairness In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state. This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again). Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the *increment* was made conditional, but the *decrement* was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX). AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right. This patch fixes the issue by introducing the same conditional check on decrement as is used on increment. The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.
- https://git.kernel.org/stable/c/4a4eeefa514db570be025ab46d779af180e2c9bb
- https://git.kernel.org/stable/c/546ea84d07e3e324644025e2aae2d12ea4c5896e
- https://git.kernel.org/stable/c/549e407569e08459d16122341d332cb508024094
- https://git.kernel.org/stable/c/7725152b54d295b7da5e34c2f419539b30d017bd
- https://git.kernel.org/stable/c/cde71a5677971f4f1b69b25e854891dbe78066a4
- https://git.kernel.org/stable/c/d4a9039a7b3d8005b90c7b1a55a306444f0e5447
- https://git.kernel.org/stable/c/d7c01c0714c04431b5e18cf17a9ea68a553d1c3c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46829
In the Linux kernel, the following vulnerability has been resolved: rtmutex: Drop rt_mutex::wait_lock before scheduling rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning. Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop. [ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ]
- https://git.kernel.org/stable/c/1401da1486dc1cdbef6025fd74a3977df3a3e5d0
- https://git.kernel.org/stable/c/432efdbe7da5ecfcbc0c2180cfdbab1441752a38
- https://git.kernel.org/stable/c/6a976e9a47e8e5b326de671811561cab12e6fb1f
- https://git.kernel.org/stable/c/85f03ca98e07cd0786738b56ae73740bce0ac27f
- https://git.kernel.org/stable/c/93f44655472d9cd418293d328f9d141ca234ad83
- https://git.kernel.org/stable/c/a92d81c9efec9280681c27a2c0a963fd0f1338e0
- https://git.kernel.org/stable/c/d33d26036a0274b472299d7dcdaa5fb34329f91b
- https://git.kernel.org/stable/c/f13b5afc5c4889569d84c3011ce449f61fccfb28
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-01-19
CVE-2024-46830
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly
leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX
reads guest memory.
Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN
via sync_regs(), which already holds SRCU. I.e. trying to precisely use
kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause
problems. Acquiring SRCU isn't all that expensive, so for simplicity,
grab it unconditionally for KVM_SET_VCPU_EVENTS.
=============================
WARNING: suspicious RCU usage
6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
-----------------------------
include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by repro/1071:
#0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
stack backtrace:
CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:
- https://git.kernel.org/stable/c/4bcdd831d9d01e0fb64faea50732b59b2ee88da1
- https://git.kernel.org/stable/c/5f35099fa3d59caf10bda88b033538e90086684e
- https://git.kernel.org/stable/c/939375737b5a0b1bf9b1e75129054e11bc9ca65e
- https://git.kernel.org/stable/c/ecdbe8ac86fb5538ccc623a41f88ec96c7168ab9
- https://git.kernel.org/stable/c/fa297c33faefe51e10244e8a378837fca4963228
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-02
CVE-2024-46831
In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap: Fix use-after-free error in kunit test This is a clear use-after-free error. We remove it, and rely on checking the return code of vcap_del_rule.
Modified: 2025-11-03
CVE-2024-46832
In the Linux kernel, the following vulnerability has been resolved: MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed This avoids warning: [ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 Caused by get_c0_compare_int on secondary CPU. We also skipped saving IRQ number to struct clock_event_device *cd as it's never used by clockevent core, as per comments it's only meant for "non CPU local devices".
- https://git.kernel.org/stable/c/189d3ed3b25beee26ffe2abed278208bece13f52
- https://git.kernel.org/stable/c/32ee0520159f1e8c2d6597c19690df452c528f30
- https://git.kernel.org/stable/c/50f2b98dc83de7809a5c5bf0ccf9af2e75c37c13
- https://git.kernel.org/stable/c/b1d2051373bfc65371ce4ac8911ed984d0178c98
- https://git.kernel.org/stable/c/d3ff0f98a52f0aafe35aa314d1c442f4318be3db
- https://git.kernel.org/stable/c/e6cd871627abbb459d0ff6521d6bb9cf9d9f7522
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46835
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix smatch static checker warning adev->gfx.imu.funcs could be NULL
- https://git.kernel.org/stable/c/8bc7b3ce33e64c74211ed17aec823fc4e523426a
- https://git.kernel.org/stable/c/bdbdc7cecd00305dc844a361f9883d3a21022027
- https://git.kernel.org/stable/c/c2056c7a840f0dbf293bc3b0d91826d001668fb0
- https://git.kernel.org/stable/c/d40c2c3dd0395fe7fdc19bd96551e87251426d66
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46836
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: validate endpoint index for ast udc We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array. Found by static analysis.
- https://git.kernel.org/stable/c/31bd4fab49c0adc6228848357c1b1df9395858af
- https://git.kernel.org/stable/c/6fe9ca2ca389114c8da66e534c18273497843e8a
- https://git.kernel.org/stable/c/b2a50ffdd1a079869a62198a8d1441355c513c7c
- https://git.kernel.org/stable/c/ee0d382feb44ec0f445e2ad63786cd7f3f6a8199
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-09
CVE-2024-46838
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: don't BUG_ON() if khugepaged yanks our page table Since khugepaged was changed to allow retracting page tables in file mappings without holding the mmap lock, these BUG_ON()s are wrong - get rid of them. We could also remove the preceding "if (unlikely(...))" block, but then we could reach pte_offset_map_lock() with transhuge pages not just for file mappings but also for anonymous mappings - which would probably be fine but I think is not necessarily expected.
Modified: 2025-11-03
CVE-2024-46840
In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.
- https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16
- https://git.kernel.org/stable/c/71291aa7246645ef622621934d2067400380645e
- https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32
- https://git.kernel.org/stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9
- https://git.kernel.org/stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b
- https://git.kernel.org/stable/c/b8ccef048354074a548f108e51d0557d6adfd3a3
- https://git.kernel.org/stable/c/c60676b81fab456b672796830f6d8057058f029c
- https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-08
CVE-2024-46843
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it.
Modified: 2025-11-03
CVE-2024-46844
In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line().
- https://git.kernel.org/stable/c/289979d64573f43df1d0e6bc6435de63a0d69cdf
- https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5
- https://git.kernel.org/stable/c/43f782c27907f306c664b6614fd6f264ac32cce6
- https://git.kernel.org/stable/c/824ac4a5edd3f7494ab1996826c4f47f8ef0f63d
- https://git.kernel.org/stable/c/96301fdc2d533a196197c055af875fe33d47ef84
- https://git.kernel.org/stable/c/c8944d449fda9f58c03bd99649b2df09948fc874
- https://git.kernel.org/stable/c/ec5b47a370177d79ae7773858042c107e21f8ecc
- https://git.kernel.org/stable/c/fc843d3837ebcb1c16d3768ef3eb55e25d5331f2
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-02
CVE-2024-46845
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Only clear timer if a kthread exists The timerlat tracer can use user space threads to check for osnoise and timer latency. If the program using this is killed via a SIGTERM, the threads are shutdown one at a time and another tracing instance can start up resetting the threads before they are fully closed. That causes the hrtimer assigned to the kthread to be shutdown and freed twice when the dying thread finally closes the file descriptors, causing a use-after-free bug. Only cancel the hrtimer if the associated thread is still around. Also add the interface_lock around the resetting of the tlat_var->kthread. Note, this is just a quick fix that can be backported to stable. A real fix is to have a better synchronization between the shutdown of old threads and the starting of new ones.
Modified: 2025-11-03
CVE-2024-46846
In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure.
- https://git.kernel.org/stable/c/0efbad8445fbba7896402500a1473450a299a08a
- https://git.kernel.org/stable/c/14f970a8d03d882b15b97beb83bd84ac8ba6298c
- https://git.kernel.org/stable/c/be721b451affbecc4ba4eaac3b71cdbdcade1b1b
- https://git.kernel.org/stable/c/d034bff62faea1a2219e0d2f3d17263265f24087
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46848
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Limit the period on Haswell
Running the ltp test cve-2015-3290 concurrently reports the following
warnings.
perfevents: irq loop stuck!
WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
intel_pmu_handle_irq+0x285/0x370
Call Trace:
- https://git.kernel.org/stable/c/0eaf812aa1506704f3b78be87036860e5d0fe81d
- https://git.kernel.org/stable/c/15210b7c8caff4929f25d049ef8404557f8ae468
- https://git.kernel.org/stable/c/25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b
- https://git.kernel.org/stable/c/8717dc35c0e5896f4110f4b3882f7ff787a5f73d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46871
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it.
- https://git.kernel.org/stable/c/800a5ab673c4a61ca220cce177386723d91bdb37
- https://git.kernel.org/stable/c/9f404b0bc2df3880758fb3c3bc7496f596f347d7
- https://git.kernel.org/stable/c/ad28d7c3d989fc5689581664653879d664da76f0
- https://git.kernel.org/stable/c/c592b6355b9b57b8e59fc5978ce1e14f64488a98
- https://git.kernel.org/stable/c/e1896f381d27466c26cb44b4450eae05cd59dfd0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-23
CVE-2024-47658
In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.
Modified: 2025-11-03
CVE-2024-47659
In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.
- https://git.kernel.org/stable/c/0776bcf9cb6de46fdd94d10118de1cf9b05f83b9
- https://git.kernel.org/stable/c/0aea09e82eafa50a373fc8a4b84c1d4734751e2c
- https://git.kernel.org/stable/c/2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550
- https://git.kernel.org/stable/c/4be9fd15c3c88775bdf6fa37acabe6de85beebff
- https://git.kernel.org/stable/c/5b4b304f196c070342e32a4752e1fa2e22fc0671
- https://git.kernel.org/stable/c/a948ec993541db4ef392b555c37a1186f4d61670
- https://git.kernel.org/stable/c/d3703fa94116fed91f64c7d1c7d284fb4369070f
- https://git.kernel.org/stable/c/d3f56c653c65f170b172d3c23120bc64ada645d8
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-47660
In the Linux kernel, the following vulnerability has been resolved: fsnotify: clear PARENT_WATCHED flags lazily In some setups directories can have many (usually negative) dentries. Hence __fsnotify_update_child_dentry_flags() function can take a significant amount of time. Since the bulk of this function happens under inode->i_lock this causes a significant contention on the lock when we remove the watch from the directory as the __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask() races with __fsnotify_update_child_dentry_flags() calls from __fsnotify_parent() happening on children. This can lead upto softlockup reports reported by users. Fix the problem by calling fsnotify_update_children_dentry_flags() to set PARENT_WATCHED flags only when parent starts watching children. When parent stops watching children, clear false positive PARENT_WATCHED flags lazily in __fsnotify_parent() for each accessed child.
- https://git.kernel.org/stable/c/172e422ffea20a89bfdc672741c1aad6fbb5044e
- https://git.kernel.org/stable/c/3f3ef1d9f66b93913ce2171120d9226b55acd41d
- https://git.kernel.org/stable/c/7ef1d2e240c32b1f337a37232d037b07e3919e1a
- https://git.kernel.org/stable/c/d8c42405fc3507cc43ba7e4986a773c3fc633f6e
- https://git.kernel.org/stable/c/f9a48bc3dd9099935751458a5bbbea4b7c28abc8
- https://git.kernel.org/stable/c/fc1b1e135c3f72382f792e6c319fc088d5523ad5
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-47663
In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9834: Validate frequency parameter value In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/0e727707a239d5c519fc9abc2f0fd913516a7e47
- https://git.kernel.org/stable/c/3ba9abfcaa9e16bb91ed7e0e2b42e94a157a953e
- https://git.kernel.org/stable/c/41cc91e3138fe52f8da92a81bebcd0e6cf488c53
- https://git.kernel.org/stable/c/5edc3a45ef428501000a7b23d0e1777a548907f6
- https://git.kernel.org/stable/c/8961b245e8f92bccbaacfbbdf69eba60e3e7c227
- https://git.kernel.org/stable/c/b48aa991758999d4e8f9296c5bbe388f293ef465
- https://git.kernel.org/stable/c/d8b09a5edc4a634373158c1a405491de3c52e58a
- https://git.kernel.org/stable/c/dc12e49f970b08d8b007b8981b97e2eb93c0e89d
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-23
CVE-2024-47664
In the Linux kernel, the following vulnerability has been resolved: spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned.
Modified: 2025-11-03
CVE-2024-47665
In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup Definitely condition dma_get_cache_alignment * defined value > 256 during driver initialization is not reason to BUG_ON(). Turn that to graceful error out with -EINVAL.
- https://git.kernel.org/stable/c/2666085335bdfedf90d91f4071490ad3980be785
- https://git.kernel.org/stable/c/5a022269abb22809f2a174b90f200fc4b9526058
- https://git.kernel.org/stable/c/8a2be2f1db268ec735419e53ef04ca039fc027dc
- https://git.kernel.org/stable/c/cacb76df247a7cd842ff29755a523b1cba6c0508
- https://git.kernel.org/stable/c/e2d14bfda9eb5393f8a17008afe2aa7fe0a29815
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-12-06
CVE-2024-47666
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Set phy->enable_completion only when we wait for it pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash.
- https://git.kernel.org/stable/c/7b1d779647afaea9185fa2f150b1721e7c1aae89
- https://git.kernel.org/stable/c/a5d954802bda1aabcba49633cd94bad91c94113f
- https://git.kernel.org/stable/c/ddc501f4130f4baa787cb6cfa309af697179f475
- https://git.kernel.org/stable/c/e23ee0cc5bded07e700553aecc333bb20c768546
- https://git.kernel.org/stable/c/e4f949ef1516c0d74745ee54a0f4882c1f6c7aea
- https://git.kernel.org/stable/c/f14d3e1aa613311c744af32d75125e95fc8ffb84
Modified: 2025-11-03
CVE-2024-47667
In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf
- https://git.kernel.org/stable/c/135843c351c08df72bdd4b4ebea53c8052a76881
- https://git.kernel.org/stable/c/576d0fb6f8d4bd4695e70eee173a1b9c7bae9572
- https://git.kernel.org/stable/c/86f271f22bbb6391410a07e08d6ca3757fda01fa
- https://git.kernel.org/stable/c/af218c803fe298ddf00abef331aa526b20d7ea61
- https://git.kernel.org/stable/c/cfb006e185f64edbbdf7869eac352442bc76b8f6
- https://git.kernel.org/stable/c/dd47051c76c8acd8cb983f01b4d1265da29cb66a
- https://git.kernel.org/stable/c/ebbdbbc580c1695dec283d0ba6448729dc993246
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-47668
In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path.
- https://git.kernel.org/stable/c/0f078f8ca93b28a34e20bd050f12cd4efeee7c0f
- https://git.kernel.org/stable/c/0f27f4f445390cb7f73d4209cb2bf32834dc53da
- https://git.kernel.org/stable/c/99418ec776a39609f50934720419e0b464ca2283
- https://git.kernel.org/stable/c/ad5ee9feebc2eb8cfc76ed74a2d6e55343b0e169
- https://git.kernel.org/stable/c/b2f11c6f3e1fc60742673b8675c95b78447f3dae
- https://git.kernel.org/stable/c/d942e855324a60107025c116245095632476613e
- https://git.kernel.org/stable/c/ebeff038744c498a036e7a92eb8e433ae0a386d7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-47669
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix state management in error path of log writing function After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.
- https://git.kernel.org/stable/c/036441e8438b29111fa75008f0ce305fb4e83c0a
- https://git.kernel.org/stable/c/0a1a961bde4351dc047ffdeb2f1311ca16a700cc
- https://git.kernel.org/stable/c/30562eff4a6dd35c4b5be9699ef61ad9f5f20a06
- https://git.kernel.org/stable/c/3e349d7191f0688fc9808ef24fd4e4b4ef5ca876
- https://git.kernel.org/stable/c/40a2757de2c376ef8a08d9ee9c81e77f3c750adf
- https://git.kernel.org/stable/c/6576dd6695f2afca3f4954029ac4a64f82ba60ab
- https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe7f7737b
- https://git.kernel.org/stable/c/efdde00d4a1ef10bb71e09ebc67823a3d3ad725b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-12-06
CVE-2024-57947
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo: fix initial map fill The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size. After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map. This makes pipapo find an incorrect matching results for sets where first field size is not the largest. Followup patch adds a test case to nft_concat_range.sh selftest script. Thanks to Stefano Brivio for pointing out that we need to zero out the remainder explicitly, only correcting memset() argument isn't enough.
- https://git.kernel.org/stable/c/69b6a67f7052905e928d75a0c5871de50e686986
- https://git.kernel.org/stable/c/77bf0c4ab928ca4c9a99311f4f70ba0c17fecba9
- https://git.kernel.org/stable/c/791a615b7ad2258c560f91852be54b0480837c93
- https://git.kernel.org/stable/c/8058c88ac0df21239daee54b5934d5c80ca9685f
- https://git.kernel.org/stable/c/957a4d1c4c5849e4515c9fb4db21bf85318103dc
- https://git.kernel.org/stable/c/9625c46ce6fd4f922595a4b32b1de5066d70464f
Modified: 2025-11-19
CVE-2024-58238
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btnxpuart: Resolve TX timeout error in power save stress test
This fixes the tx timeout issue seen while running a stress test on
btnxpuart for couple of hours, such that the interval between two HCI
commands coincide with the power save timeout value of 2 seconds.
Test procedure using bash script:
Closed bugs
Прошу обновить libdecor до 0.2.2
Package alterator-netinst updated to version 1.9.1-alt9 for branch sisyphus in task 359226.
Closed bugs
Загрузка образа по ссылке завершается с ошибкой
Package firmware-intel-ucode updated to version 28-alt1.20240910 for branch sisyphus in task 359282.
Closed vulnerabilities
Modified: 2026-03-12
BDU:2024-08651
Уязвимость интерфейса RAPL Interface микропрограммного обеспечения процессоров Intel, связанная с раскрытием информации через несоответствие, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2026-03-12
BDU:2024-08654
Уязвимость компонента FSM микропрограммного обеспечения процессоров Intel, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-15
CVE-2024-23984
Observable discrepancy in RAPL interface for some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.
Modified: 2026-04-15
CVE-2024-24968
Improper finite state machines (FSMs) in hardware logic in some Intel(R) Processors may allow an privileged user to potentially enable a denial of service via local access.
Closed bugs
Не хватает python3-module-bsddb3
Closed vulnerabilities
Modified: 2026-03-04
BDU:2024-09460
Уязвимость программного средства управления и запуска OCI-контейнеров Podman, связанная с неправильной проверкой входных данных, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-03-04
BDU:2024-09461
Уязвимость библиотеки containers-common языка программирования Golang, связанная с неправильным разрешением ссылки перед доступом к файлу, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2024-12-11
CVE-2024-9341
A flaw was found in Go. When FIPS mode is enabled on a system, container runtimes may incorrectly handle certain file paths due to improper validation in the containers/common Go library. This flaw allows an attacker to exploit symbolic links and trick the system into mounting sensitive host directories inside a container. This issue also allows attackers to access critical host files, bypassing the intended isolation between containers and the host system.
- https://access.redhat.com/errata/RHSA-2024:10147
- https://access.redhat.com/errata/RHSA-2024:10818
- https://access.redhat.com/errata/RHSA-2024:7925
- https://access.redhat.com/errata/RHSA-2024:8039
- https://access.redhat.com/errata/RHSA-2024:8112
- https://access.redhat.com/errata/RHSA-2024:8238
- https://access.redhat.com/errata/RHSA-2024:8263
- https://access.redhat.com/errata/RHSA-2024:8428
- https://access.redhat.com/errata/RHSA-2024:8690
- https://access.redhat.com/errata/RHSA-2024:8694
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/security/cve/CVE-2024-9341
- https://bugzilla.redhat.com/show_bug.cgi?id=2315691
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L169
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L349
Modified: 2026-04-15
CVE-2024-9407
A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files.
- https://access.redhat.com/errata/RHSA-2024:10147
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:9051
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/errata/RHSA-2024:9926
- https://access.redhat.com/security/cve/CVE-2024-9407
- https://bugzilla.redhat.com/show_bug.cgi?id=2315887
- https://github.com/advisories/GHSA-fhqq-8f65-5xfc
- https://security.netapp.com/advisory/ntap-20241220-0010/
Modified: 2024-12-20
GHSA-fhqq-8f65-5xfc
Improper Input Validation in Buildah and Podman
- https://nvd.nist.gov/vuln/detail/CVE-2024-9407
- https://github.com/containers/buildah/commit/e4e2ad5ca2088d7c388109394135ead7aaf1f4f4
- https://access.redhat.com/errata/RHSA-2024:10147
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:9051
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/errata/RHSA-2024:9926
- https://access.redhat.com/security/cve/CVE-2024-9407
- https://bugzilla.redhat.com/show_bug.cgi?id=2315887
- https://github.com/containers/podman/releases/tag/v5.2.4
- https://pkg.go.dev/vuln/GO-2024-3169
- https://security.netapp.com/advisory/ntap-20241220-0010
Modified: 2024-12-11
GHSA-mc76-5925-c5p6
Link Following in github.com/containers/common
- https://nvd.nist.gov/vuln/detail/CVE-2024-9341
- https://github.com/containers/common/commit/e7db06585c32e1a782c1d9aa3b71ccd708f5e23f
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L349
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L169
- https://github.com/containers/common
- https://bugzilla.redhat.com/show_bug.cgi?id=2315691
- https://access.redhat.com/security/cve/CVE-2024-9341
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:8694
- https://access.redhat.com/errata/RHSA-2024:8690
- https://access.redhat.com/errata/RHSA-2024:8428
- https://access.redhat.com/errata/RHSA-2024:8263
- https://access.redhat.com/errata/RHSA-2024:8238
- https://access.redhat.com/errata/RHSA-2024:8112
- https://access.redhat.com/errata/RHSA-2024:8039
- https://access.redhat.com/errata/RHSA-2024:7925
- https://access.redhat.com/errata/RHSA-2024:10818
- https://access.redhat.com/errata/RHSA-2024:10147
Closed vulnerabilities
Modified: 2026-03-04
BDU:2024-09460
Уязвимость программного средства управления и запуска OCI-контейнеров Podman, связанная с неправильной проверкой входных данных, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-03-04
BDU:2024-09461
Уязвимость библиотеки containers-common языка программирования Golang, связанная с неправильным разрешением ссылки перед доступом к файлу, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2024-12-11
CVE-2024-9341
A flaw was found in Go. When FIPS mode is enabled on a system, container runtimes may incorrectly handle certain file paths due to improper validation in the containers/common Go library. This flaw allows an attacker to exploit symbolic links and trick the system into mounting sensitive host directories inside a container. This issue also allows attackers to access critical host files, bypassing the intended isolation between containers and the host system.
- https://access.redhat.com/errata/RHSA-2024:10147
- https://access.redhat.com/errata/RHSA-2024:10818
- https://access.redhat.com/errata/RHSA-2024:7925
- https://access.redhat.com/errata/RHSA-2024:8039
- https://access.redhat.com/errata/RHSA-2024:8112
- https://access.redhat.com/errata/RHSA-2024:8238
- https://access.redhat.com/errata/RHSA-2024:8263
- https://access.redhat.com/errata/RHSA-2024:8428
- https://access.redhat.com/errata/RHSA-2024:8690
- https://access.redhat.com/errata/RHSA-2024:8694
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/security/cve/CVE-2024-9341
- https://bugzilla.redhat.com/show_bug.cgi?id=2315691
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L169
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L349
Modified: 2026-04-15
CVE-2024-9407
A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files.
- https://access.redhat.com/errata/RHSA-2024:10147
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:9051
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/errata/RHSA-2024:9926
- https://access.redhat.com/security/cve/CVE-2024-9407
- https://bugzilla.redhat.com/show_bug.cgi?id=2315887
- https://github.com/advisories/GHSA-fhqq-8f65-5xfc
- https://security.netapp.com/advisory/ntap-20241220-0010/
Modified: 2024-12-20
GHSA-fhqq-8f65-5xfc
Improper Input Validation in Buildah and Podman
- https://nvd.nist.gov/vuln/detail/CVE-2024-9407
- https://github.com/containers/buildah/commit/e4e2ad5ca2088d7c388109394135ead7aaf1f4f4
- https://access.redhat.com/errata/RHSA-2024:10147
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:9051
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/errata/RHSA-2024:9926
- https://access.redhat.com/security/cve/CVE-2024-9407
- https://bugzilla.redhat.com/show_bug.cgi?id=2315887
- https://github.com/containers/podman/releases/tag/v5.2.4
- https://pkg.go.dev/vuln/GO-2024-3169
- https://security.netapp.com/advisory/ntap-20241220-0010
Modified: 2024-12-11
GHSA-mc76-5925-c5p6
Link Following in github.com/containers/common
- https://nvd.nist.gov/vuln/detail/CVE-2024-9341
- https://github.com/containers/common/commit/e7db06585c32e1a782c1d9aa3b71ccd708f5e23f
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L349
- https://github.com/containers/common/blob/384f77532f67afc8a73d8e0c4adb0d195df57714/pkg/subscriptions/subscriptions.go#L169
- https://github.com/containers/common
- https://bugzilla.redhat.com/show_bug.cgi?id=2315691
- https://access.redhat.com/security/cve/CVE-2024-9341
- https://access.redhat.com/errata/RHSA-2024:9459
- https://access.redhat.com/errata/RHSA-2024:9454
- https://access.redhat.com/errata/RHSA-2024:8846
- https://access.redhat.com/errata/RHSA-2024:8694
- https://access.redhat.com/errata/RHSA-2024:8690
- https://access.redhat.com/errata/RHSA-2024:8428
- https://access.redhat.com/errata/RHSA-2024:8263
- https://access.redhat.com/errata/RHSA-2024:8238
- https://access.redhat.com/errata/RHSA-2024:8112
- https://access.redhat.com/errata/RHSA-2024:8039
- https://access.redhat.com/errata/RHSA-2024:7925
- https://access.redhat.com/errata/RHSA-2024:10818
- https://access.redhat.com/errata/RHSA-2024:10147
Closed bugs
cannot load such file -- rack/handler
Closed vulnerabilities
Modified: 2026-03-04
BDU:2024-07777
Уязвимость HTTP-сервера для Ruby/Rack приложений Puma, позволяющая нарушителю выполнить произвольный код
Modified: 2025-11-03
CVE-2024-45614
Puma is a Ruby/Rack web server built for parallelism. In affected versions clients could clobber values set by intermediate proxies (such as X-Forwarded-For) by providing a underscore version of the same header (X-Forwarded_For). Any users relying on proxy set variables is affected. v6.4.3/v5.6.9 now discards any headers using underscores if the non-underscore version also exists. Effectively, allowing the proxy defined headers to always win. Users are advised to upgrade. Nginx has a underscores_in_headers configuration variable to discard these headers at the proxy level as a mitigation. Any users that are implicitly trusting the proxy defined headers for security should immediately cease doing so until upgraded to the fixed versions.
Modified: 2025-11-04
GHSA-9hf4-67fc-4vf4
Puma's header normalization allows for client to clobber proxy set headers
- https://github.com/puma/puma/security/advisories/GHSA-9hf4-67fc-4vf4
- https://nvd.nist.gov/vuln/detail/CVE-2024-45614
- https://github.com/puma/puma/commit/cac3fd18cf29ed43719ff5d52d9cfec215f0a043
- https://github.com/puma/puma/commit/f196b23be24712fb8fb16051cc124798cc84f70e
- https://github.com/puma/puma
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/puma/CVE-2024-45614.yml
- https://lists.debian.org/debian-lts-announce/2024/11/msg00004.html
- https://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers
Closed vulnerabilities
BDU:2024-08371
Уязвимость функции extractFromZipFile() пакета model.go системы для запуска и управления большими языковыми моделями (LLM) Ollama, позволяющая нарушителю оказать влияние на конфиденциальность и целостность защищаемой информации
Modified: 2024-08-30
CVE-2024-45436
extractFromZipFile in model.go in Ollama before 0.1.47 can extract members of a ZIP archive outside of the parent directory.
Modified: 2024-08-29
GHSA-846m-99qv-67mg
Ollama can extract members of a ZIP archive outside of the parent directory
