ALT-BU-2024-13485-9
Branch p10 update bulletin.
Closed bugs
Обновить или добавить пакет(ы) RHVoice
Package kernel-image-un-def updated to version 6.1.111-alt1 for branch p10 in task 357828.
Closed vulnerabilities
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: 2025-08-19
BDU:2024-07483
Уязвимость функции fcntl_setlk() ядра операционной системы 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: 2025-05-06
BDU:2024-07937
Уязвимость функции cachefiles_withdraw_volumes() ядра операционной системы 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-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-10-24
BDU:2024-08087
Уязвимость функции amdgpu_ring_init() драйвера amdgpu ядра операционной системы 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-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-06
BDU:2024-08188
Уязвимость компонента tcp_bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-01
BDU:2024-08189
Уязвимость компонента mcp251x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08229
Уязвимость функции do_hardware_base_addr() драйвера параллельного порта ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08231
Уязвимость функции squashfs_read_inode() файловой системы squashfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08232
Уязвимость функции cma_heap_vm_fault() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2024-08233
Уязвимость функции axg_card_add_tdm_loopback() ядра операционной системы 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-08-19
BDU:2024-08237
Уязвимость функции mptcp_pm_del_add_timer() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08296
Уязвимость функции amdtp_hid_remove() драйвера AMD Sensor Fusion Hub ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08303
Уязвимость функции kvm_spapr_tce_attach_iommu_group() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux на платформе PowerPC, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08305
Уязвимость функций __jfs_getxattr() и jfs_listxattr() файловой системы jfs ядра операционной системы 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-05-06
BDU:2024-08320
Уязвимость функции fuse_notify_store() файловой системы fuse ядра операционной системы 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-05-06
BDU:2024-08333
Уязвимость функции st_dwc3_probe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08346
Уязвимость функции proc_cpuset_show() (kernel/cgroup/cpuset.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-08517
Уязвимость функции dpaa_start_xmit() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-05-02
BDU:2024-08518
Уязвимость функции acpi_pcc_hotkey_add() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2024-08519
Уязвимость функции nxp_fspi_fill_txfifo() драйвера Serial Peripheral Interface (SPI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08520
Уязвимость функции ast_udc_getstatus() драйвера usb gadget ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-08525
Уязвимость функций read() и write() драйвера amdpgu ядра операционной системы 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-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: 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-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-10-24
BDU:2024-09861
Уязвимость функции bprm_fill_uid() ядра операционной системы 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: 2025-05-06
BDU:2024-10976
Уязвимость компонента qmi_wwan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-00021
Уязвимость функции remap_pfn_range_notrack() в модуле mm/memory.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-00776
Уязвимость компонента drivers/net/dsa/mv88e6xxx/global1_atu.c ядра операционной системы 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-08-19
BDU:2025-00996
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01089
Уязвимость функции sdma_v4_0_process_trap_irq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01091
Уязвимость компонента ocfs2 ядра операционной системы 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-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: 2025-03-21
BDU:2025-01405
Уязвимость компонента sched ядра операционной системы 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-05-06
BDU:2025-01416
Уязвимость компонентов drm/i915/gem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2025-01417
Уязвимость компонента apparmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01421
Уязвимость компонента udf ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2025-01422
Уязвимость компонента cifs ядра операционной системы 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-01429
Уязвимость компонента sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01430
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01431
Уязвимость компонентов drm/gma500 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01434
Уязвимость компонентов fs/file ядра операционной системы 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-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: 2026-01-20
BDU:2025-01457
Уязвимость компонентов fs/ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-01574
Уязвимость функции eeh_pe_bus_get() (arch/powerpc/kernel/eeh_pe.c) ядра операционной системы 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-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-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: 2026-03-11
BDU:2025-01714
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01716
Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01717
Уязвимость компонента block ядра операционной системы 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-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-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-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-06
BDU:2025-01786
Уязвимость компонентов net/mlx5e ядра операционной системы 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-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-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-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-01922
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01923
Уязвимость компонентов drm/client ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01926
Уязвимость компонента tracing ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-01927
Уязвимость компонента padata ядра операционной системы 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-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-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-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-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-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-08-19
BDU:2025-03024
Уязвимость функции ext4_xattr_set_entry() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03097
Уязвимость функции __nl80211_set_channel() модуля net/wireless/nl80211.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03254
Уязвимость функции mlx5_eswitch_set_vepa() драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03256
Уязвимость функции load_elf_binary() файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03379
Уязвимость компонента Landlock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-18
BDU:2025-03390
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03442
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03448
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03585
Уязвимость функции mana_destroy_txq() драйвера ядра операционной системы 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-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-06-09
BDU:2025-03751
Уязвимость функции mptcp_pm_nl_rm_addr_or_subflow() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-04173
Уязвимость компонента tun.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-04193
Уязвимость компонента tap.c ядра операционной системы 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-07-01
BDU:2025-05921
Уязвимость функции ice_prepare_for_reset() драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05930
Уязвимость функции resource_build_bit_depth_reduction_params() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-05976
Уязвимость функции gfx_v11_0_hw_init() драйвера поддержки инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-06971
Уязвимость компонента f2fs ядра операционной системы 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: 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-08029
Уязвимость компонента s390/uv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08032
Уязвимость компонента flow_dissector ядра операционной системы 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: 2025-10-24
BDU:2025-08085
Уязвимость компонента omap_prm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02205
Уязвимость функции load_firmware_cb() драйвера тюнеров XCeive xc2028/xc3028 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
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-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-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-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-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-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-11-03
CVE-2024-41022
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq() The "instance" variable needs to be signed for the error handling to work.
- https://git.kernel.org/stable/c/298e2ce222e712ffafa47288c5b2fcf33d72fda3
- https://git.kernel.org/stable/c/3dd9734878a9042f0358301d19a2b006a0fc4d06
- https://git.kernel.org/stable/c/4edb0a84e6b32e75dc9bd6dd085b2c2ff19ec287
- https://git.kernel.org/stable/c/544fa213f15d27f0370795845d55eeb3e00080d2
- https://git.kernel.org/stable/c/6769a23697f17f9bf9365ca8ed62fe37e361a05a
- https://git.kernel.org/stable/c/a5224e2123ce21102f346f518db80f004d5053a7
- https://git.kernel.org/stable/c/d347c9a398bf7eab9408d207c0a50fb720f9de7d
- https://git.kernel.org/stable/c/e8dfbf83a82bbfb9680921719fbe65e535af59ea
- https://git.kernel.org/stable/c/298e2ce222e712ffafa47288c5b2fcf33d72fda3
- https://git.kernel.org/stable/c/3dd9734878a9042f0358301d19a2b006a0fc4d06
- https://git.kernel.org/stable/c/4edb0a84e6b32e75dc9bd6dd085b2c2ff19ec287
- https://git.kernel.org/stable/c/544fa213f15d27f0370795845d55eeb3e00080d2
- https://git.kernel.org/stable/c/6769a23697f17f9bf9365ca8ed62fe37e361a05a
- https://git.kernel.org/stable/c/a5224e2123ce21102f346f518db80f004d5053a7
- https://git.kernel.org/stable/c/d347c9a398bf7eab9408d207c0a50fb720f9de7d
- https://git.kernel.org/stable/c/e8dfbf83a82bbfb9680921719fbe65e535af59ea
- 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-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: 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: 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-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-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-42272
In the Linux kernel, the following vulnerability has been resolved: sched: act_ct: take care of padding in struct zones_ht_key Blamed commit increased lookup key size from 2 bytes to 16 bytes, because zones_ht_key got a struct net pointer. Make sure rhashtable_lookup() is not using the padding bytes which are not initialized. BUG: KMSAN: uninit-value in rht_ptr_rcu include/linux/rhashtable.h:376 [inline] BUG: KMSAN: uninit-value in __rhashtable_lookup include/linux/rhashtable.h:607 [inline] BUG: KMSAN: uninit-value in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KMSAN: uninit-value in rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] BUG: KMSAN: uninit-value in tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329 rht_ptr_rcu include/linux/rhashtable.h:376 [inline] __rhashtable_lookup include/linux/rhashtable.h:607 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329 tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408 tcf_action_init_1+0x6cc/0xb30 net/sched/act_api.c:1425 tcf_action_init+0x458/0xf00 net/sched/act_api.c:1488 tcf_action_add net/sched/act_api.c:2061 [inline] tc_ctl_action+0x4be/0x19d0 net/sched/act_api.c:2118 rtnetlink_rcv_msg+0x12fc/0x1410 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2550 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6665 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2597 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2651 __sys_sendmsg net/socket.c:2680 [inline] __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2687 x64_sys_call+0x2dd6/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:47 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 Local variable key created at: tcf_ct_flow_table_get+0x4a/0x2260 net/sched/act_ct.c:324 tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408
- https://git.kernel.org/stable/c/2191a54f63225b548fd8346be3611c3219a24738
- https://git.kernel.org/stable/c/3a5b68869dbe14f1157c6a24ac71923db060eeab
- https://git.kernel.org/stable/c/3ddefcb8f75e312535e2e7d5fef9932019ba60f2
- https://git.kernel.org/stable/c/7c03ab555eb1ba26c77fd7c25bdf44a0ac23edee
- https://git.kernel.org/stable/c/d06daf0ad645d9225a3ff6958dd82e1f3988fa64
- https://git.kernel.org/stable/c/d7cc186d0973afce0e1237c37f7512c01981fb79
- 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-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-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: 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: 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-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-42307
In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path Dan Carpenter reported a Smack static checker warning: fs/smb/client/cifsfs.c:1981 init_cifs() error: we previously assumed 'serverclose_wq' could be null (see line 1895) The patch which introduced the serverclose workqueue used the wrong oredering in error paths in init_cifs() for freeing it on errors.
- https://git.kernel.org/stable/c/160235efb4f9b55212dedff5de0094c606c4b303
- https://git.kernel.org/stable/c/193cc89ea0ca1da311877d2b4bb5e9f03bcc82a2
- https://git.kernel.org/stable/c/3739d711246d8fbc95ff73dbdace9741cdce4777
- https://git.kernel.org/stable/c/6018971710fdc7739f8655c1540832b4bb903671
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-10-09
CVE-2024-42308
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
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-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-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: 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: 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-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-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: 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: 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-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-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-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-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-12-29
CVE-2024-43895
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Modified: 2025-11-03
CVE-2024-43897
In the Linux kernel, the following vulnerability has been resolved: net: drop bad gso csum_start and offset in virtio_net_hdr Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first. This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests.
- https://git.kernel.org/stable/c/2edbb3e8838c672cd7e247e47989df9d03fc6668
- https://git.kernel.org/stable/c/413e785a89f8bde0d4156a54b8ac2fa003c06756
- https://git.kernel.org/stable/c/6772c4868a8e7ad5305957cdb834ce881793acb7
- https://git.kernel.org/stable/c/89add40066f9ed9abe5f7f886fe5789ff7e0c50e
- https://git.kernel.org/stable/c/f01c5e335fbb7fb612d40f14a3c02e2612a43d3b
- 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: 2024-12-19
CVE-2024-43903
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
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: 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-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: 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: 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: 2024-11-09
CVE-2024-44952
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
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: 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: 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: 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: 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-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: 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: 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: 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: 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: 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: 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: 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: 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-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: 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: 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: 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: 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-01-09
CVE-2024-46756
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Modified: 2025-01-09
CVE-2024-46757
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Modified: 2025-01-09
CVE-2024-46758
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
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: 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: 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: 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: 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: 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: 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: 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: 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-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: 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: 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: 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: 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: 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: 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: 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-46849
In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194
- https://git.kernel.org/stable/c/4f9a71435953f941969a4f017e2357db62d85a86
- https://git.kernel.org/stable/c/5a2cc2bb81399e9ebc72560541137eb04d61dc3d
- https://git.kernel.org/stable/c/7d318166bf55e9029d56997c3b134f4ac2ae2607
- https://git.kernel.org/stable/c/a33145f494e6cb82f3e018662cc7c4febf271f22
- https://git.kernel.org/stable/c/e1a199ec31617242e1a0ea8f312341e682d0c037
- https://git.kernel.org/stable/c/e43364f578cdc2f8083abbc0cb743ea55e827c29
- https://git.kernel.org/stable/c/fb0530025d502cb79d2b2801b14a9d5261833f1a
- 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-46852
In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix off-by-one in CMA heap fault handler Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping.
- https://git.kernel.org/stable/c/79cce5e81d20fa9ad553be439d665ac3302d3c95
- https://git.kernel.org/stable/c/84175dc5b2c932266a50c04e5ce342c30f817a2f
- https://git.kernel.org/stable/c/e79050882b857c37634baedbdcf7c2047c24cbff
- https://git.kernel.org/stable/c/ea5ff5d351b520524019f7ff7f9ce418de2dad87
- https://git.kernel.org/stable/c/eb7fc8b65cea22f9038c52398c8b22849e9620ea
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46853
In the Linux kernel, the following vulnerability has been resolved: spi: nxp-fspi: fix the KASAN report out-of-bounds bug Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---
- https://git.kernel.org/stable/c/09af8b0ba70072be831f3ec459f4063d570f9e24
- https://git.kernel.org/stable/c/2a8787c1cdc7be24fdd8953ecd1a8743a1006235
- https://git.kernel.org/stable/c/491f9646f7ac31af5fca71be1a3e5eb8aa7663ad
- https://git.kernel.org/stable/c/609260542cf86b459c57618b8cdec8020394b7ad
- https://git.kernel.org/stable/c/aa05db44db5f409f6d91c27b5737efb49fb45d9f
- https://git.kernel.org/stable/c/af9ca9ca3e44f48b2a191e100d452fbf850c3d87
- https://git.kernel.org/stable/c/d1a1dfcec77c57b1181da93d11a3db1bc4eefa97
- 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-46854
In the Linux kernel, the following vulnerability has been resolved: net: dpaa: Pad packets to ETH_ZLEN When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running $ ping -s 11 destination
- https://git.kernel.org/stable/c/1f31f51bfc8214a6deaac2920e6342cb9d019133
- https://git.kernel.org/stable/c/34fcac26216ce17886af3eb392355b459367af1a
- https://git.kernel.org/stable/c/38f5db5587c0ee53546b28c50ba128253181ac83
- https://git.kernel.org/stable/c/cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0
- https://git.kernel.org/stable/c/cd5b9d657ecd44ad5f254c3fea3a6ab1cf0e2ef7
- https://git.kernel.org/stable/c/ce8eabc912fe9b9a62be1a5c6af5ad2196e90fc2
- https://git.kernel.org/stable/c/dc43a096cfe65b5c32168313846c5cd135d08f1d
- https://git.kernel.org/stable/c/f43190e33224c49e1c7ebbc25923ff400d87ec00
- 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-46855
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_socket: fix sk refcount leaks We must put 'sk' reference before returning.
- https://git.kernel.org/stable/c/076d281e90aaf4192799ecb9a1ed82321e133ecd
- https://git.kernel.org/stable/c/1f68e097e20d3c695281a9c6433acc37be47fe11
- https://git.kernel.org/stable/c/33c2258bf8cb17fba9e58b111d4c4f4cf43a4896
- https://git.kernel.org/stable/c/6572440f78b724c46070841a68254ebc534cde24
- https://git.kernel.org/stable/c/83e6fb59040e8964888afcaa5612cc1243736715
- https://git.kernel.org/stable/c/8b26ff7af8c32cb4148b3e147c52f9e4c695209c
- https://git.kernel.org/stable/c/ddc7c423c4a5386bf865474c694b48178efd311a
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-03
CVE-2024-46857
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix bridge mode operations when there are no VFs
Currently, trying to set the bridge mode attribute when numvfs=0 leads to a
crash:
bridge link set dev eth2 hwmode vepa
[ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030
[...]
[ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]
[...]
[ 168.976037] Call Trace:
[ 168.976188]
- https://git.kernel.org/stable/c/505ae01f75f839b54329164bbfecf24cc1361b31
- https://git.kernel.org/stable/c/52c4beb79e095e0631b5cac46ed48a2aefe51985
- https://git.kernel.org/stable/c/65feee671e37f3b6eda0b6af28f204b5bcf7fa50
- https://git.kernel.org/stable/c/b1d305abef4640af1b4f1b4774d513cd81b10cfc
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-12-24
CVE-2024-46858
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: Fix uaf in __timer_delete_sync There are two paths to access mptcp_pm_del_add_timer, result in a race condition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry) In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1). Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer". Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.
- https://git.kernel.org/stable/c/0e7814b028cd50b3ff79659d23dfa9da6a1e75e1
- https://git.kernel.org/stable/c/12134a652b0a10064844ea235173e70246eba6dc
- https://git.kernel.org/stable/c/3554482f4691571fc4b5490c17ae26896e62171c
- https://git.kernel.org/stable/c/6452b162549c7f9ef54655d3fb9977b9192e6e5b
- https://git.kernel.org/stable/c/67409b358500c71632116356a0b065f112d7b707
- https://git.kernel.org/stable/c/b4cd80b0338945a94972ac3ed54f8338d2da2076
- 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-46859
In the Linux kernel, the following vulnerability has been resolved: platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses The panasonic laptop code in various places uses the SINF array with index values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array is big enough. Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute. Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller. For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these.
- https://git.kernel.org/stable/c/6821a82616f60aa72c5909b3e252ad97fb9f7e2a
- https://git.kernel.org/stable/c/9291fadbd2720a869b1d2fcf82305648e2e62a16
- https://git.kernel.org/stable/c/b38c19783286a71693c2194ed1b36665168c09c4
- https://git.kernel.org/stable/c/b7c2f692307fe704be87ea80d7328782b33c3cef
- https://git.kernel.org/stable/c/f52e98d16e9bd7dd2b3aef8e38db5cbc9899d6a4
- 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: 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: 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-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-11-03
CVE-2024-47674
In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.
- https://git.kernel.org/stable/c/3213fdcab961026203dd587a4533600c70b3336b
- https://git.kernel.org/stable/c/35770ca6180caa24a2b258c99a87bd437a1ee10f
- https://git.kernel.org/stable/c/5b2c8b34f6d76bfbd1dd4936eb8a0fbfb9af3959
- https://git.kernel.org/stable/c/65d0db500d7c07f0f76fc24a4d837791c4862cd2
- https://git.kernel.org/stable/c/79a61cc3fc0466ad2b7b89618a6157785f0293b3
- https://git.kernel.org/stable/c/954fd4c81f22c4b6ba65379a81fd252971bf4ef3
- https://git.kernel.org/stable/c/a95a24fcaee1b892e47d5e6dcc403f713874ee80
- https://project-zero.issues.chromium.org/issues/366053091
- 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-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
Closed bugs
CONFIG_CONSOLE_LOGLEVEL_QUIET=3
Не работает с модемом Quectel Wireless Solutions Co., Ltd. EM120R-GL LTE Modem
