ALT-PU-2024-6818-18
Package kernel-image-rpi-un updated to version 6.6.23-alt1 for branch sisyphus in task 345422.
Closed vulnerabilities
Modified: 2024-04-27
BDU:2022-07344
Уязвимость функции find_prog_by_sec_insn() (tools/lib/bpf/libbpf.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00381
Уязвимость функции rawv6_push_pending_frames() (net/ipv6/raw.c) службы обработки трафика ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00748
Уязвимость видеодрайвера vivid ядра операционной системы Linux, позволяющая локальному нарушителю вызвать отказ в обслуживании
Modified: 2024-10-08
BDU:2023-01125
Уязвимость компонента drivers/tty/vcc.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-01206
Уязвимость функции asus_kbd_backlight_set() (drivers/hid/hid-asus.c) драйвера ASUS USB клавиатуры ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-24
BDU:2023-01215
Уязвимость функции memory_tier_init() (mm/memory-tiers.c) подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2023-01276
Уязвимость функции smb2_is_status_io_timeout() компоненты SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2023-01277
Уязвимость функции setup_async_work() (fs/ksmbd/smb2pdu.c) подсистеме SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2023-01279
Уязвимость функции __sys_socket_file() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01282
Уязвимость функции az6027_i2c_xfer() (drivers/media/usb/dvb-usb/az6027.c) драйвера Azurewave DVB-S/S2 USB2.0 AZ6027 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-01726
Уязвимость функции kvm_vcpu_ioctl_x86_get_debugregs() (arch/x86/kvm/x86.c) подсистемы виртуализации KVM ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2024-04-03
BDU:2023-01778
Уязвимость функции hci_init_stage_sync() (net/bluetooth/hci_sync.c) ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-01-29
BDU:2023-01800
Уязвимость функции sock_hash_delete_elem() в модуле net/core/sock_map.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-01962
Уязвимость функции xgene_hwmon_remove (drivers/hwmon/xgene-hwmon.c) драйвера мониторинга оборудования xgene-hwmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании и раскрыть защищаемую информацию
Modified: 2025-02-24
BDU:2023-02090
Уязвимость функции da9150_charger_remove() драйвера drivers/power/supply/da9150-charger.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2023-02115
Уязвимость функции prctl ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-02118
Уязвимость подсистемы проверки разрешений Bluetooth ядра операционной системы Linux, позволяющая нарушителю выполнять произвольные команды
Modified: 2025-08-19
BDU:2023-02162
Уязвимость функции nested_vmx_check_guest_state() модуля arch/x86/kvm/vmx/nested.c подсистемы виртуализации (KVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании гостевой операционной системы.
Modified: 2025-01-29
BDU:2023-02166
Уязвимость функции xen_9pfs_front_remove() в модуле net/9p/trans_xen.c гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-02229
Уязвимость функции ndlc_remove() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-10-20
BDU:2023-02522
Уязвимость функции io_cqring_event_overflow() в модуле uring/msg_ring.c ядра операционной системы Linux, позволяющая нарушителю повысить привилегии или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02524
Уязвимость функции slimpro_i2c_blkwr() в модуле drivers/i2c/busses/i2c-xgene-slimpro.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2024-11-11
BDU:2023-02526
Уязвимость драйвера Infiniband ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-08-19
BDU:2023-02528
Уязвимость драйвере SCSI ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-02529
Уязвимость файловой системы XFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-02-27
BDU:2023-02800
Уязвимость драйвера сетевого устройства Qualcomm ядра операционной системы Linux в функции emac_remove(), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-02-27
BDU:2023-02801
Уязвимость функции bq24190_remove() в модуле drivers/power/supply/bq24190_charger.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-02-24
BDU:2023-02997
Уязвимость драйвере файловой системы ext4 ядра операционной системы Linux в функции ext4_group_desc_csum(), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2024-09-30
BDU:2023-03110
Уязвимость функции hfsplus_put_super() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03169
Уязвимость функции gfs2_evict_inode() в модуле fs/gfs2/super.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03170
Уязвимость функции fbcon_set_font() в модуле drivers/video/fbdev/core/fbcon.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-07-28
BDU:2023-03435
Уязвимость функции ravb_remove() в модуле drivers/net/ethernet/renesas/ravb_main.c драйвера сетевых устройств Renesas ядра операционной системы Linux в функции ravb_remove(), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2023-03494
Уязвимость функции dpu_crtc_atomic_check() в модуле drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c драйвера MSM DRM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03495
Уязвимость реализации файловой системы relayfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или раскрыть защищаемую информацию
Modified: 2025-08-19
BDU:2023-03499
Уязвимость функции saa7134_finidev() в модуле drivers/media/pci/saa7134/saa7134-core.c драйвера Philips SAA7134 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-08-19
BDU:2023-03500
Уязвимость функции dm1105_remove() в модуле drivers/media/pci/dm1105/dm1105.c драйвера TV Tuner на микросхеме DM1105 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2024-09-30
BDU:2023-03641
Уязвимость функции ishtp_cl_get_dma_send_buf() драйвера Integrated Sensor Hub (ISH) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03642
Уязвимость реализации протокола IPv6 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-07-19
BDU:2023-03644
Уязвимость функции brcm_nvram_parse() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2023-03725
Уязвимость функции dn_nsp_send() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-03727
Уязвимость функции io_poll_update() в модуле io_uring/io_uring.c ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-03782
Уязвимость функции vcs_read() в модуле drivers/tty/vt/vc_screen.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-03783
Уязвимость функции read_descriptors() в модуле drivers/usb/core/sysfs.c драйвера USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-08
BDU:2023-03784
Уязвимость функции vmw_user_bo_lookup() в модуле drivers/gpu/drm/vmwgfx/vmwgfx_bo.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-08
BDU:2023-03786
Уязвимость функции udf_close_lvid() в модуле fs/udf/super.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-03958
Уязвимость функции set_con2fb_map() в модуле drivers/video/fbdev/core/fbcon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03960
Уязвимость функции u32_set_parms() в модуле net/sched/cls_u32.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных
Modified: 2024-12-04
BDU:2023-04069
Уязвимость драйвера vmwgfx ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-11-07
BDU:2023-04271
Уязвимость функции nfc_llcp_find_local() в модуле net/nfc/llcp_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-04-27
BDU:2023-04647
Уязвимость функции parse_usdt_arg() в модуле tools/lib/bpf/usdt.c компоненты BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2023-04654
Уязвимость функции do_submit_urb() в модуле drivers/media/usb/siano/smsusb.c драйвера цифрового ТВ siano ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-04655
Уязвимость функции cxgb4_cleanup_tc_flower() в модуле drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c драйвера Chelsio cxgb4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
BDU:2023-04656
Уязвимость функции cyttsp4_stop_wd_timer() в модуле drivers/input/touchscreen/cyttsp4_core.c драйвера сенсорного устройства Cypress TrueTouch Gen4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-04
BDU:2023-04659
Уязвимость функции tap_open() в модуле drivers/net/tap.c драйвере TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных или повысить свои привилегии
Modified: 2024-04-27
BDU:2023-04661
Уязвимость функции exfat_get_uniname_from_ext_entry() в модуле fs/exfat/dir.c файловой системе exFAT ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-06
BDU:2023-05142
Уязвимость функции nft_set_catchall_flush() в модуле net/netfilter/nf_tables_api.c компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-01-09
BDU:2023-05143
Уязвимость функции do_mbind() в модуле mm/mempolicy.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-05481
Уязвимость компонента nf_tables операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-05963
Уязвимость функции kmalloc_reserve() в модуле net/core/skbuff.c сетевой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-24
BDU:2023-06159
Уязвимость функции __ip_set_put_netlink() в модуле net/netfilter/ipset/ip_set_core.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-06161
Уязвимость функции rsvp_change() в модуле net/sched/cls_rsvp.h компонента net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-12
BDU:2023-06203
Уязвимость подсистемы eBPF ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-06271
Уязвимость функции u32_match_it подсистемы Netfilter ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-06340
Уязвимость функции match_flags подсистемы Netfilter ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-06420
Уязвимость функции ipv4_send_dest_unreach() в модуле net/ipv4/route.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-06613
Уязвимость функции nf_osf_match_one() подсистемы Netfilter ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или получить несанкционированный доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-06751
Уязвимость функции xfrm_dump_sa() модуля net/xfrm/xfrm_user.c подсистемы XFRM ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2024-01-09
BDU:2023-06996
Уязвимость функции extract_user_to_sg() в модуле lib/scatterlist.c библиотеки scatterlist ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-02-27
BDU:2023-06997
Уязвимость функции ms_lib_process_bootblock() в модуле drivers/usb/storage/ene_ub6250.c драйвера ene_usb6250 кард-ридера ENE SD/MS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2023-06998
Уязвимость функции fill_kobj_path() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-08-19
BDU:2023-07236
Уязвимость ядра операционной системы Linux, вызванная ошибками синхронизации при использовании общего ресурса, позволяющая нарушителю выполнить произвольный код.
Modified: 2025-08-19
BDU:2023-07317
Уязвимость функции svm_set_x2apic_msr_interception() модуля arch/x86/kvm/svm/svm.c подсистемы KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2023-07513
Уязвимость функции io_uring_show_fdinfo() в модуле io_uring/fdinfo.c подсистемы io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-24
BDU:2023-07688
Уязвимость функции brcmf_cfg80211_detach() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c драйвера беспроводной связи brcm80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2023-07947
Уязвимость функции lan78xx_disconnect (drivers/net/usb/lan78xx.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-07977
Уязвимость функции qxl_gem_object_create_with_handle() модуля drivers/gpu/drm/qxl/qxl_gem.c драйвера QXL ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2023-08635
Уязвимость функции __io_uaddr_map() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-08636
Уязвимость функции nft_dynset_init() (net/netfilter/nft_dynset.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-09114
Уязвимость функции gsm_cleanup_mux() драйвера N_GSM ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-07
BDU:2024-00097
Уязвимость функции ctnetlink_create_conntrack() в модуле net/netfilter/nf_conntrack_netlink.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю с полномочиями CAP_NET_ADMIN вызвать отказ в обслуживании.
Modified: 2024-11-11
BDU:2024-00101
Уязвимость функции rose_ioctl() в модуле net/rose/af_rose.c реализации протокола Amateur Radio X.25 PLP (Rose) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-00102
Уязвимость функции atalk_ioctl() в модуле net/appletalk/ddp.c реализации протокола Appletalk в ядре операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-00104
Уязвимость функции do_vcc_ioctl() в модуле net/atm/ioctl.c реализации сетевого протокола ATM (Asynchronous Transfer Mode) ядра операционной системы Linux , позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-00258
Уязвимость функции vhost_new_msg() в модуле drivers/vhost/vhost.c драйвера vhost ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-04-28
BDU:2024-00636
Уязвимость функции tipc_crypto_key_revoke модуля net/tipc/crypto.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-28
BDU:2024-00673
Уязвимость функции sctp_auto_asconf_init (net/sctp/socket.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2024-00776
Уязвимость функции __ext4_remount() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-07-28
BDU:2024-00836
Уязвимость функции smb2_get_data_area_len (fs/smb/server/smb2misc.c) файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-07-28
BDU:2024-00837
Уязвимость функции drm_atomic_state_init (driver/gpu/drm/drm_atomic.c) ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код.
Modified: 2025-02-27
BDU:2024-00865
Уязвимость функции send_acknowledge() в модуле net/nfc/nci/spi.c ядра операционной системы Linux в функции send_acknowledge(), позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2024-00866
Уязвимость функции amdgpu_cs_wait_all_fences() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c драйвера amdgpu видеокарт AMD Radeon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-00985
Уязвимость функции hugetlbfs_fill_super системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2026-01-20
BDU:2024-01034
Уязвимость модуля net/bluetooth/af_bluetooth.c драйвера bluetooth ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2024-01036
Уязвимость функции ip6_dst_gc() (net/ipv6/route.c) реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-02-26
BDU:2024-01189
Уязвимость функции exynos_drm_crtc_atomic_disable() в модуле drivers/gpu/drm/exynos/exynos_drm_crtc.c драйвера Samsung SoC Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01190
Уязвимость функции snd_hdac_regmap_sync() в модуле sound/hda/hdac_regmap.c драйвера High-Definition Audio (HDA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2024-01192
Уязвимость функции lpfc_unregister_fcf_rescan() в модуле drivers/scsi/lpfc/lpfc_hbadisc.c подсистемы SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-01213
Уязвимость функции mas_prev_slot() подсистемы управления памятью Memory Management (MM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2024-01589
Уязвимость функции tls_decrypt_done (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2024-01601
Уязвимость функции tls_encrypt_done (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2024-01602
Уязвимость функций crypto_aead_encrypt и crypto_aead_decrypt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-01673
Уязвимость функции smb2_parse_contexts() в модуле fs/smb/client/smb2pdu.c клиента SMB ядра операционной системы Linux , позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01681
Уязвимость функции tls_decrypt_done() модуля net/tls/tls_sw.c реализации протокола TLS (Transport Layer Security) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-01724
Уязвимость функции nft_set_rbtree (net/netfilter/nft_set_rbtree.c) компонента Netfilter операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2024-01736
Уязвимость функции sys_membarrier компонента membarrier ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-01747
Уязвимость функции binder_enqueue_thread_work_ilocked() в модуле drivers/android/binder.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01832
Уязвимость функции i801_block_transaction_by_block() в модуле drivers/i2c/busses/i2c-i801.c драйвера шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01840
Уязвимость функции mlxsw_sp_acl_tcam_init() в модуле drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c драйвера сетевых карт Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
Modified: 2025-10-14
BDU:2024-01846
Уязвимость функции mlxsw_sp_acl_tcam_region_destroy() в модуле drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c драйвера сетевых карт Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-01847
Уязвимость функции nsim_destroy() в модуле drivers/net/netdevsim/netdev.c драйвера виртуального сетевого netdevsim устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-12
BDU:2024-01850
Уязвимость функции check_stack_slot_within_bounds() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-04
BDU:2024-01853
Уязвимость функции ext4_mb_generate_buddy() в модуле fs/ext4/mballoc.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01854
Уязвимость функции restore_fpregs_from_user() в модуле arch/x86/kernel/fpu/signal.c драйвера FPU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-04
BDU:2024-01861
Уязвимость функции z_erofs_do_map_blocks() в модуле fs/erofs/zmap.c файловой системы erofs (Enhanced Read-Only File System) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01863
Уязвимость функциях map_usb_set_vbus() и omap_usb_start_srp() в модуле drivers/phy/ti/phy-omap-usb2.c драйвера USB устройств TI (Texas Instruments) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-20
BDU:2024-01977
Уязвимость функции skb_segment компонента Net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03614
Уязвимость функции i2c_hid_of_probe() драйвера HID устройств шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-03620
Уязвимость функции nci_free_device() реализации NFC Controller Interface (NCI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2024-03621
Уязвимость функции __prep_cap() файловой системы ceph ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-03622
Уязвимость функции __sev_platform_shutdown_locked() драйвера крипографического сопроцессора AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03623
Уязвимость функции ext4_move_extents() в модуле fs/ext4/move_extent.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-05-21
BDU:2024-03624
Уязвимость функции dwc3_gadget_suspend() драйвера USB DesignWare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03642
Уязвимость функции mtk_spi_interrupt() в модуле drivers/spi/spi-mt65xx.c драйвера Mediatek SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03643
Уязвимость функции dvb_register_device() в модуле drivers/media/dvb-core/dvbdev.c драйвера DVB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-04
BDU:2024-03656
Уязвимость функции check_for_locks() в модуле fs/nfsd/nfs4state.c сервера файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03662
Уязвимость функции link_set_dsc_pps_packet() в модуле drivers/gpu/drm/amd/display/dc/link/link_dpms.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-16
BDU:2024-03663
Уязвимость функции stack_map_alloc() в модуле kernel/bpf/stackmap.c подсистемы BPF ядра операционной системы Linux на 32-битных архитектурах, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-26
BDU:2024-03664
Уязвимость функции htab_map_alloc() в модуле kernel/bpf/hashtab.c подсистемы BPF ядра операционной системы Linux на 32-битных архитектурах, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03665
Уязвимость функции dev_map_init_map() в модуле kernel/bpf/devmap.c подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-03666
Уязвимость функции set_eth_seg() в модуле drivers/infiniband/hw/mlx5/wr.c драйвера Mellanox 5-го поколения сетевых адаптеров (серии ConnectX) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-12
BDU:2024-03667
Уязвимость функции sof_ipc3_fw_parse_ext_man() в модуле sound/soc/sof/ipc3-loader.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-24
BDU:2024-03676
Уязвимость функции sk_psock_verdict_data_ready() в модуле net/core/skmsg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03678
Уязвимость функции seg6_init() в модуле net/ipv6/seg6.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03679
Уязвимость функции cdns3_gadget_giveback() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера USB Cadence ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-03680
Уязвимость функции cdns3_gadget_ep_disable() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера USB Cadence ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2024-11-26
BDU:2024-03681
Уязвимость функции gtp_init() в модуле drivers/net/gtp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03682
Уязвимость функции mptcp_sk_clone_init() в модуле net/mptcp/protocol.c реализации протокола Multipath TCP (MPTCP) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03685
Уязвимость функции gtp_init() в модуле drivers/net/gtp.c реализации протокола GPRS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03686
Уязвимость функции hci_error_reset() в модуле net/bluetooth/hci_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-03695
Уязвимость функции tcp_twsk_purge() в модуле net/ipv4/tcp_minisocks.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03696
Уязвимость функции sparx5_del_mact_entry() в модуле drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c драйвера sparx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03697
Уязвимость функции bnx2x_set_fw_mac_addr() в модуле drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h драйвера Broadcom NetXtremeII 10Gb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-08-26
BDU:2024-03698
Уязвимость функции fsl_lpspi_probe() в модуле drivers/spi/spi-fsl-lpspi.c драйвера SPI (Serial Peripheral Interface) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03700
Уязвимость функции wilc_netdev_cleanup() в модуле drivers/net/wireless/microchip/wilc1000/netdev.c драйвера Atmel WILC1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03701
Уязвимость функции dm_sw_fini() в модуле drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-10-24
BDU:2024-03702
Уязвимость функции smc_chan_free() в модуле drivers/firmware/arm_scmi/smc.c реализации протокола ARM System Control and Management Interface (SCMI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-03708
Уязвимость функции ip_tunnel_rcv() в модуле net/ipv4/ip_tunnel.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-05
BDU:2024-03751
Уязвимость функции hugetlbfs_parse_param() в модуле fs/hugetlbfs/inode.c системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-01
BDU:2024-03753
Уязвимость функции taprio_parse_tc_entry() в модуле net/sched/sch_taprio.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-03754
Уязвимость функции print_absolute_relocs() ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-05-06
BDU:2024-03763
Уязвимость функции sr9800_bind() в модуле drivers/net/usb/sr9800.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03773
Уязвимость функции edp_setup_replay() в модуле drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c драйвера amdgpu видеокарт AMD Radeon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03941
Уязвимость функции io_uring_get_file() подсистемы io_uring ядра Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-04137
Уязвимость функции tomoyo_write_control() подсистемы безопасности TOMOYO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-04234
Уязвимость функции pep_ioctl() реализации протокола PhoNet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-04539
Уязвимость функции ath12k_htt_pull_ppdu_stats() драйвера ath12k (Qualcomm Technologies Wi-Fi 7) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-04577
Уязвимость функции gfs2_put_super() файловой системы gfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-06349
Уязвимость функции dm_table_create() в модуле drivers/md/dm-table.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-06
BDU:2024-06493
Уязвимость функции synchronize_rcu() в компоненте ipset ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06494
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06495
Уязвимость компонента rfcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06496
Уязвимость функции do_sys_name_to_handle() в компоненте kernel-infoleak ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06895
Уязвимость компонента drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c ядра операционной системы Linux, связанная с недостаточной обработкой форматной строки, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06899
Уязвимость компонента drivers/usb/gadget/function/f_ncm.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06900
Уязвимость драйвера AoE ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06901
Уязвимость ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06929
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06991
Уязвимость функции mi_enum_attr() компонента fs/ntfs3 ядра операционной системы Linux, связанная с копированием буфера без проверки входных данных, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07484
Уязвимость функции criu_restore_memory_of_gpu() драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-18
BDU:2024-07630
Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-07642
Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07750
Уязвимость функции tcpm_register_source_caps() драйвера контроллера USB Type-C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-08626
Уязвимость компонента cxl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08630
Уязвимость компонента target ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08633
Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08636
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08637
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08642
Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08646
Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08649
Уязвимость компонента nvmet-fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08661
Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии
Modified: 2026-01-20
BDU:2024-08664
Уязвимость компонента dm-crypt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08665
Уязвимость компонента l2tp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2024-08666
Уязвимость компонента ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08667
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08668
Уязвимость компонента srpt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08669
Уязвимость компонента qedr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08670
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08671
Уязвимость компонента afs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-08672
Уязвимость компонента arp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08673
Уязвимость компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08674
Уязвимость компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08676
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-02
BDU:2024-08677
Уязвимость компонента rt5645 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08681
Уязвимость компонентов fs/aio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09016
Уязвимость функции ext4_mb_find_by_goal() ядра операционной системы Linux, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09031
Уязвимость компонента fs/ntfs3 ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09130
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09132
Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09134
Уязвимость компонентов dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09149
Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09152
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09153
Уязвимость компонента savage ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09154
Уязвимость компонента sis ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09155
Уязвимость компонента hisi-sfc-v3xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09156
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09158
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09159
Уязвимость компонента edma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-09-05
BDU:2024-09160
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-05-06
BDU:2024-09162
Уязвимость компонента b43 ядра операционной системы Linux, связанная с циклом с недостижимым условием выхода, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09163
Уязвимость компонента nvme-fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09164
Уязвимость компонента target ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09165
Уязвимость компонента efi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09166
Уязвимость компонента hfi1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09167
Уязвимость компонента irdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09168
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09172
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09173
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09175
Уязвимость компонента hv_netvsc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09176
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09179
Уязвимость компонента zswap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09184
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09186
Уязвимость компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09187
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09189
Уязвимость компонента rc ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-03-21
BDU:2024-09190
Уязвимость компонентов powerpc/pseries/iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09194
Уязвимость компонентов fbcon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09196
Уязвимость компонента stmmac ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09198
Уязвимость компонента veth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09199
Уязвимость компонента ip_tunnel ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-03-21
BDU:2024-09201
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09207
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09208
Уязвимость компонента stm32 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-09356
Уязвимость компонентов powerpc/pseries ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09358
Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09450
Уязвимость функции rm3100_common_probe() компонента drivers/iio/magnetometer/rm3100-core.c ядра операционной системы Linux, связанная с чтением за допустимыми границами буфера данных, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09723
Уязвимость компонента flower ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09725
Уязвимость компонента dsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09726
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09728
Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09729
Уязвимость компонента zynq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09731
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09755
Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09756
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09757
Уязвимость компонента octeontx2-af ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09758
Уязвимость компонента nbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09759
Уязвимость компонента NTB ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-09767
Уязвимость компонента usb-audio ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2024-09769
Уязвимость компонента ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09802
Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09804
Уязвимость компонента nft_flow_offload ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2024-09835
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09837
Уязвимость компонента rgb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09839
Уязвимость компонентов efi/capsule-loader ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09841
Уязвимость компонента supply ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09842
Уязвимость компонента rtl8xxxu ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-02-09
BDU:2024-09845
Уязвимость функции tpg_alloc() в модуле drivers/media/common/v4l2-tpg/v4l2-tpg-core.c компонента v4l2-tpg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09846
Уязвимость компонента v4l2-mem2mem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09847
Уязвимость компонента imx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09848
Уязвимость компонента cpufreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09849
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09850
Уязвимость компонента dvb-frontends ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09851
Уязвимость компонента go7007 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09852
Уязвимость компонента ttpci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09853
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09854
Уязвимость компонента hi3559a ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09856
Уязвимость компонента wilc1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09857
Уязвимость компонентов s390/dasd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09858
Уязвимость компонента rtnetlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09945
Уязвимость компонентов drm/lima ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09985
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю манипулировать данными
Modified: 2026-01-20
BDU:2024-09990
Уязвимость компонента cpumap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09991
Уязвимость компонента netrom ядра операционной системы Linux, позволяющая нарушителю манипулировать данными
Modified: 2026-01-20
BDU:2024-09992
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-01-20
BDU:2024-09993
Уязвимость компонента hci_event ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-03-21
BDU:2024-09994
Уязвимость компонента bridge ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09999
Уязвимость компонента wilc1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10008
Уязвимость компонента mcast ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10009
Уязвимость компонента SUNRPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10034
Уязвимость компонента tc358743 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-10365
Уязвимость компонента compress ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10658
Уязвимость компонента n_gsm ядра операционной системы Linux, позволяющая нарушителю обойти существующие ограничения безопасности
Modified: 2025-05-06
BDU:2024-10739
Уязвимость компонента libertas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-11575
Уязвимость функции io_recvmsg_mshot_prep() модуля io_uring/net.c компонентов io_uring/net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2024-11616
Уязвимость функции wakeup_kswapd() компонента vmscan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-11617
Уязвимость функции __lpass_get_dmactl_handle компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-00023
Уязвимость функции stream_enc_regs() подсистемы Direct Rendering Manager (DRM) ядра операционной системы Linux ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01230
Уязвимость модуля nf_tables компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01922
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-02904
Уязвимость функции axg_clk_regmaps{} модуля drivers/clk/meson/axg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02907
Уязвимость функции hci_get_dev_info() модуля net/bluetooth/hci_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-02909
Уязвимость функции fcoe_ctlr_announce() модуля drivers/scsi/fcoe/fcoe_ctlr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02910
Уязвимость функции cik_ih_get_wptr() модуля drivers/gpu/drm/amd/amdgpu/cik_ih.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02911
Уязвимость функции pmu_sbi_set_scounteren() модуля drivers/perf/riscv_pmu_sbi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-02925
Уязвимость функции amdgpu_dm_fini() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03085
Уязвимость функции bq27xxx_battery_i2c_remove() модуля drivers/power/supply/bq27xxx_battery_i2c.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03088
Уязвимость функции nvme_alloc_admin_tag_set() модуля drivers/nvme/host/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03587
Уязвимость функции acpi_has_cpu_in_madt() модуля arch/loongarch/include/asm/acpi.h поддержки архитектуры LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03606
Уязвимость функции ff_layout_cancel_io() модуля fs/nfs/flexfilelayout/flexfilelayout.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03608
Уязвимость функции ice_bridge_setlink() модуля drivers/net/ethernet/intel/ice/ice_main.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03609
Уязвимость функции thunderstrike_led_create() модуля drivers/hid/hid-nvidia-shield.c - драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03612
Уязвимость функции nouveau_fence_context_kill() модуля drivers/gpu/drm/nouveau/nouveau_fence.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03613
Уязвимость функции acpi_processor_power_exit() модуля drivers/acpi/processor_idle.c - драйвера поддержки ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03615
Уязвимость функции pvr2_context_exit() модуля drivers/media/usb/pvrusb2/pvrusb2-context.c - драйвера поддержки мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-10-23
BDU:2025-03616
Уязвимость функции amdgpu_dm_atomic_check() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03617
Уязвимость функции unix_gc() модуля net/unix/garbage.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03618
Уязвимость функции nilfs_segctor_prepare_write() модуля fs/nilfs2/segment.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-03909
Уязвимость компонента iommu/vt-d ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-03911
Уязвимость компонента fs/quota/dquot.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03912
Уязвимость компонента crypto/xilinx/zynqmp-aes-gcm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03927
Уязвимость компонента x86/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03928
Уязвимость компонента drm/mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03929
Уязвимость компонента mm/usercopy.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03930
Уязвимость компонента net/core/dev.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2026-01-20
BDU:2025-03931
Уязвимость компонента wireguard/receive.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03932
Уязвимость компонента events_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04258
Уязвимость функции geneve_rx() модуля drivers/net/geneve.c - драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-06-09
BDU:2025-04260
Уязвимость функции hsr_get_node() модуля net/hsr/hsr_framereg.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-23
BDU:2025-04395
Уязвимость функции aoeblk_gdalloc() модуля drivers/block/aoe/aoeblk.c - драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-04396
Уязвимость функции get_firmware_info_v3_2() модуля drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-04401
Уязвимость функции __dm_internal_suspend() модуля drivers/md/dm.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-06-09
BDU:2025-04402
Уязвимость определения структуры f2fs_fault_info{} модуля fs/f2fs/f2fs.h поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04404
Уязвимость функции bt_sock_recvmsg() модуля net/bluetooth/af_bluetooth.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-23
BDU:2025-04405
Уязвимость функции parse_server_interfaces() модуля fs/smb/client/smb2ops.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04408
Уязвимость функции kvm_hyp_reserve() модуля arch/arm64/kvm/pkvm.c подсистемы виртуализации на платформе ARM 64-бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04547
Уязвимость функции smu_v13_0_update_pcie_parameters() модуля drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-02-17
BDU:2025-06318
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06335
Уязвимость функции __thermal_cooling_device_register() и thermal_cooling_device_destroy_sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06397
Уязвимость функции check_session_id(), smb2_check_user_session(), smb2_sess_setup(), smb2_session_logoff(), smb3_decrypt_req(), ksmbd_session_lookup(), ksmbd_session_lookup_slowpath() и ksmbd_get_encryption_key() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06409
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07473
Уязвимость функции reiserfs_rename() модуля fs/reiserfs/namei.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07479
Уязвимость функции j1939_sk_match_dst() модуля net/can/j1939/socket.c поддержки сокетов j1939 шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07482
Уязвимость функции find_or_create_cached_dir() модуля fs/smb/client/cached_dir.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-07485
Уязвимость функции tcf_mirred_to_dev() модуля net/sched/act_mirred.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07831
Уязвимость компонента tracing/trigger ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-10240
Уязвимость ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2026-02-16
BDU:2025-10570
Уязвимость функции mtk_drm_gem_dumb_create() модуля drivers/gpu/drm/mediatek/mtk_drm_gem.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-11958
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-12481
Уязвимость компонента switchdev ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-02-17
BDU:2025-12899
Уязвимость функции ufshcd_queuecommand() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-12936
Уязвимость компонента VMM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12978
Уязвимость функции f2fs_remount() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-12996
Уязвимость функции recv() компонента tls ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13304
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13305
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13306
Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-13309
Уязвимость компонента sc8180x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13310
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13311
Уязвимость компонентов mm/swap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13312
Уязвимость компонента LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13313
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13346
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13347
Уязвимость компонента igc ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2025-13348
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13355
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13358
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2025-13359
Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13360
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14284
Уязвимость функции insert_header() модуля fs/proc/proc_sysctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14286
Уязвимость функции mpi_ec_init() модуля lib/mpi/ec.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14290
Уязвимость функции j1939_netdev_start() модуля net/can/j1939/main.c поддержки сокетов j1939 шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-14292
Уязвимость функции gss_import_v2_context() модуля net/sunrpc/auth_gss/gss_krb5_mech.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14293
Уязвимость функции esw_inline_mode_to_devlink() модуля drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14295
Уязвимость функции create_core_data() модуля drivers/hwmon/coretemp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-14300
Уязвимость функции check_ptr_to_map_access() модуля kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14593
Уязвимость функции grandparent() модуля drivers/cxl/core/port.c драйвера поддержки устройств CXL (Compute Express Link) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15041
Уязвимость функции dcn21_set_backlight_level() модуля drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15043
Уязвимость функции process_isoc_td() модуля drivers/usb/host/xhci-ring.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15048
Уязвимость функции tcf_block_playback_offloads() модуля net/sched/cls_api.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-15058
Уязвимость функции tipc_nl_bearer_add() модуля net/tipc/bearer.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15060
Уязвимость функции dcn21_set_abm_immediate_disable() модуля drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15086
Уязвимость функции dpu_encoder_helper_phys_cleanup() модуля drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-15231
Уязвимость функции tls_do_decryption() (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
BDU:2025-15382
Уязвимость функции smb2_find_context_vals модуля fs/smb/server/oplock.c подсистемы SMB ядра операционной системы Linux, позволяющая удаленному нарушителю получить доступ к защищаемой информации
BDU:2025-15385
Уязвимость функции __set_extent_info() модуля fs/f2fs/extent_cache.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15386
Уязвимость функции handle_kernel_stack_overflow() модуля arch/riscv/include/asm/asm-prototypes.h на процессорах с архитектурой RISC-V ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15392
Уязвимость функции pmu_sbi_ovf_handler() модуля drivers/perf/riscv_pmu_sbi.c - драйвера поддержки мониторинга производительности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15395
Уязвимость функции aspeed_video_get_resolution() модуля drivers/media/platform/aspeed/aspeed-video.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-16228
Уязвимость функции __extent_writepage() компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16230
Уязвимость функции gs_usb_disconnect() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16235
Уязвимость функции rtw88_usb() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16262
Уязвимость функции __stack_chk_fail() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-16315
Уязвимость функции run_unpack() компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2026-01440
Уязвимость команды WMI_TXSTATUS_EVENTID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01452
Уязвимость функции show_ipi_list() модуля arch/loongarch/kernel/smp.c поддержки архитектуры LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01455
Уязвимость функции nilfs_prepare_segment_for_recovery() модуля fs/nilfs2/recovery.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02262
Уязвимость функции ufshcd_cmd_inflight() модуля drivers/ufs/core/ufshcd.c поддержки хост-контроллеров UFS (Universal Flash Storage). ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03278
Уязвимость функции mlx5e_rq_to_ready() модуля drivers/net/ethernet/mellanox/mlx5/core/en_main.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03500
Уязвимость функции sof_ipc4_trigger_pipelines() модуля sound/soc/sof/ipc4-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03536
Уязвимость функции dw_edma_v0_core_write_chunk() модуля drivers/dma/dw-edma/dw-edma-v0-core.c драйвера поддержки движка DMA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03943
Уязвимость функции ipu_bridge_connect_sensor() модуля drivers/media/pci/intel/ipu-bridge.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04308
Уязвимость функции pstore_put_backend_records() модуля fs/pstore/inode.c поддержки постоянного хранилища ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04419
Уязвимость функции rtw_core_deinit() модуля drivers/net/wireless/realtek/rtw88/main.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05736
Уязвимость функции ext4_writepages() модуля fs/ext4/ext4.h файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05737
Уязвимость модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05874
Уязвимость функции sendmsg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05887
Уязвимость функции acpi_get_dsd_graph() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05902
Уязвимость функции blkcg_reset_stats() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06007
Уязвимость функции blk_mq_elv_switch_none() модуля block/blk-mq.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06095
Уязвимость функции rtw_usb_probe() в модуле drivers/net/wireless/realtek/rtw88/usb.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2022-3533
A vulnerability was found in Linux Kernel. It has been rated as problematic. This issue affects the function parse_usdt_arg of the file tools/lib/bpf/usdt.c of the component BPF. The manipulation of the argument reg_name leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211031.
Modified: 2025-11-03
CVE-2022-3606
A vulnerability was found in Linux Kernel. It has been classified as problematic. This affects the function find_prog_by_sec_insn of the file tools/lib/bpf/libbpf.c of the component BPF. The manipulation leads to null pointer dereference. It is recommended to apply a patch to fix this issue. The identifier VDB-211749 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2
- https://vuldb.com/?id.211749
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2
- https://lists.debian.org/debian-lts-announce/2025/04/msg00033.html
- https://vuldb.com/?id.211749
Modified: 2025-04-08
CVE-2022-48669
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix potential memleak in papr_get_attr() `buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure.
- https://git.kernel.org/stable/c/1699fb915b9f61794d559b55114c09a390aaf234
- https://git.kernel.org/stable/c/7f7d39fe3d80d6143404940b2413010cf6527029
- https://git.kernel.org/stable/c/a3f22feb2220a945d1c3282e34199e8bcdc5afc4
- https://git.kernel.org/stable/c/cda9c0d556283e2d4adaa9960b2dc19b16156bae
- https://git.kernel.org/stable/c/d0647c3e81eff62b66d46fd4e475318cb8cb3610
- https://git.kernel.org/stable/c/1699fb915b9f61794d559b55114c09a390aaf234
- https://git.kernel.org/stable/c/7f7d39fe3d80d6143404940b2413010cf6527029
- https://git.kernel.org/stable/c/a3f22feb2220a945d1c3282e34199e8bcdc5afc4
- https://git.kernel.org/stable/c/cda9c0d556283e2d4adaa9960b2dc19b16156bae
- https://git.kernel.org/stable/c/d0647c3e81eff62b66d46fd4e475318cb8cb3610
Modified: 2024-09-06
CVE-2022-48872
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall
- https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907
- https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4
- https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1
- https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb
- https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39
Modified: 2024-11-21
CVE-2023-0160
A deadlock flaw was found in the Linux kernel’s BPF subsystem. This flaw allows a local user to potentially crash the system.
- https://access.redhat.com/security/cve/CVE-2023-0160
- https://bugzilla.redhat.com/show_bug.cgi?id=2159764
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56
- https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/
- https://access.redhat.com/security/cve/CVE-2023-0160
- https://bugzilla.redhat.com/show_bug.cgi?id=2159764
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56
- https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/
Modified: 2025-03-31
CVE-2023-0394
A NULL pointer dereference flaw was found in rawv6_push_pending_frames in net/ipv6/raw.c in the network subcomponent in the Linux kernel. This flaw causes the system to crash.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230302-0005/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230302-0005/
Modified: 2025-03-25
CVE-2023-0615
A memory leak flaw and potential divide by zero and Integer overflow was found in the Linux kernel V4L2 and vivid test code functionality. This issue occurs when a user triggers ioctls, such as VIDIOC_S_DV_TIMINGS ioctl. This could allow a local user to crash the system if vivid test code enabled.
Modified: 2024-11-21
CVE-2023-1032
The Linux kernel io_uring IORING_OP_SOCKET operation contained a double free in function __sys_socket_file() in file net/socket.c. This issue was introduced in da214a475f8bd1d3e9e7a19ddfeb4d1617551bab and fixed in 649c15c7691e9b13cbe9bf6c65c365350e056067.
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1032
- https://ubuntu.com/security/notices/USN-5977-1
- https://ubuntu.com/security/notices/USN-6024-1
- https://ubuntu.com/security/notices/USN-6033-1
- https://www.openwall.com/lists/oss-security/2023/03/13/2
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1032
- https://ubuntu.com/security/notices/USN-5977-1
- https://ubuntu.com/security/notices/USN-6024-1
- https://ubuntu.com/security/notices/USN-6033-1
- https://www.openwall.com/lists/oss-security/2023/03/13/2
Modified: 2025-02-19
CVE-2023-1079
A flaw was found in the Linux kernel. A use-after-free may be triggered in asus_kbd_backlight_set when plugging/disconnecting in a malicious USB device, which advertises itself as an Asus device. Similarly to the previous known CVE-2023-25012, but in asus devices, the work_struct may be scheduled by the LED controller while the device is disconnecting, triggering a use-after-free on the struct asus_kbd_leds *led structure. A malicious USB device may exploit the issue to cause memory corruption with controlled data.
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ab3a086d10eeec1424f2e8a968827a6336203df
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ab3a086d10eeec1424f2e8a968827a6336203df
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
Modified: 2024-11-21
CVE-2023-1192
A use-after-free flaw was found in smb2_is_status_io_timeout() in CIFS in the Linux Kernel. After CIFS transfers response data to a system call, there are still local variable points to the memory region, and if the system call frees it faster than CIFS uses it, CIFS will access a free memory region, leading to a denial of service.
- https://access.redhat.com/security/cve/CVE-2023-1192
- https://bugzilla.redhat.com/show_bug.cgi?id=2154178
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d527f51331cace562393a8038d870b3e9916686f
- https://access.redhat.com/security/cve/CVE-2023-1192
- https://bugzilla.redhat.com/show_bug.cgi?id=2154178
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d527f51331cace562393a8038d870b3e9916686f
Modified: 2024-11-21
CVE-2023-1193
A use-after-free flaw was found in setup_async_work in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. This issue could allow an attacker to crash the system by accessing freed work.
- https://access.redhat.com/security/cve/CVE-2023-1193
- https://bugzilla.redhat.com/show_bug.cgi?id=2154177
- https://lkml.kernel.org/linux-cifs/20230401084951.6085-2-linkinjeon@kernel.org/T/
- https://access.redhat.com/security/cve/CVE-2023-1193
- https://bugzilla.redhat.com/show_bug.cgi?id=2154177
- https://lkml.kernel.org/linux-cifs/20230401084951.6085-2-linkinjeon@kernel.org/T/
Modified: 2024-11-21
CVE-2023-1206
A hash collision flaw was found in the IPv6 connection lookup table in the Linux kernel’s IPv6 functionality when a user makes a new kind of SYN flood attack. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%.
- https://bugzilla.redhat.com/show_bug.cgi?id=2175903
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230929-0006/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
- https://bugzilla.redhat.com/show_bug.cgi?id=2175903
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230929-0006/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-02-25
CVE-2023-1513
A flaw was found in KVM. When calling the KVM_GET_DEBUGREGS ioctl, on 32-bit systems, there might be some uninitialized portions of the kvm_debugregs structure that could be copied to userspace, causing an information leak.
- https://bugzilla.redhat.com/show_bug.cgi?id=2179892
- https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/
- https://bugzilla.redhat.com/show_bug.cgi?id=2179892
- https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/
Modified: 2025-02-12
CVE-2023-1855
A use-after-free flaw was found in xgene_hwmon_remove in drivers/hwmon/xgene-hwmon.c in the Hardware Monitoring Linux Kernel Driver (xgene-hwmon). This flaw could allow a local attacker to crash the system due to a race problem. This vulnerability could even lead to a kernel information leak problem.
- https://github.com/torvalds/linux/commit/cb090e64cf25602b9adaf32d5dfc9c8bec493cd1
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20230318122758.2140868-1-linux%40roeck-us.net/
- https://github.com/torvalds/linux/commit/cb090e64cf25602b9adaf32d5dfc9c8bec493cd1
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20230318122758.2140868-1-linux%40roeck-us.net/
Modified: 2025-03-18
CVE-2023-1859
A use-after-free flaw was found in xen_9pfs_front_removet in net/9p/trans_xen.c in Xen transport for 9pfs in the Linux Kernel. This flaw could allow a local attacker to crash the system due to a race problem, possibly leading to a kernel information leak.
Modified: 2025-03-19
CVE-2023-1990
A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem.
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20230312160837.2040857-1-zyytlz.wz%40163.com/
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20230312160837.2040857-1-zyytlz.wz%40163.com/
Modified: 2025-02-13
CVE-2023-1998
The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line. This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects.
- https://github.com/google/security-research/security/advisories/GHSA-mj4w-6495-6crx
- https://github.com/torvalds/linux/commit/6921ed9049bc7457f66c1596c5b78aec0dae4a9d
- https://kernel.dance/#6921ed9049bc7457f66c1596c5b78aec0dae4a9d
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://github.com/google/security-research/security/advisories/GHSA-mj4w-6495-6crx
- https://github.com/torvalds/linux/commit/6921ed9049bc7457f66c1596c5b78aec0dae4a9d
- https://kernel.dance/#6921ed9049bc7457f66c1596c5b78aec0dae4a9d
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
Modified: 2024-11-21
CVE-2023-2002
A vulnerability was found in the HCI sockets implementation due to a missing capability check in net/bluetooth/hci_sock.c in the Linux Kernel. This flaw allows an attacker to unauthorized execution of management commands, compromising the confidentiality, integrity, and availability of Bluetooth communication.
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20240202-0004/
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/04/16/3
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20240202-0004/
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/04/16/3
Modified: 2024-11-21
CVE-2023-2124
An out-of-bounds memory access flaw was found in the Linux kernel’s XFS file system in how a user restores an XFS image after failure (with a dirty log journal). This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/xfs_buf_item_recover.c?h=v6.4-rc1&id=22ed903eee23a5b174e240f1cdfa9acf393a5210
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230622-0010/
- https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994e
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/xfs_buf_item_recover.c?h=v6.4-rc1&id=22ed903eee23a5b174e240f1cdfa9acf393a5210
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230622-0010/
- https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994e
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
Modified: 2025-03-19
CVE-2023-2162
A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information.
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.spinics.net/lists/linux-scsi/msg181542.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.spinics.net/lists/linux-scsi/msg181542.html
Modified: 2025-05-05
CVE-2023-2176
A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.
Modified: 2025-04-23
CVE-2023-2194
An out-of-bounds write vulnerability was found in the Linux kernel's SLIMpro I2C device driver. The userspace "data->block[0]" variable was not capped to a number between 0-255 and was used as the size of a memcpy, possibly writing beyond the end of dma_buffer. This flaw could allow a local privileged user to crash the system or potentially achieve code execution.
- https://bugzilla.redhat.com/show_bug.cgi?id=2188396
- https://github.com/torvalds/linux/commit/92fbb6d1296f
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2188396
- https://github.com/torvalds/linux/commit/92fbb6d1296f
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
Modified: 2025-03-19
CVE-2023-23005
In the Linux kernel before 6.2, mm/memory-tiers.c misinterprets the alloc_memory_type return value (expects it to be NULL in the error case, whereas it is actually an error pointer). NOTE: this is disputed by third parties because there are no realistic cases in which a user can cause the alloc_memory_type error case to be reached.
- https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee
- https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee
Modified: 2025-03-20
CVE-2023-23039
An issue was discovered in the Linux kernel through 6.2.0-rc2. drivers/tty/vcc.c has a race condition and resultant use-after-free if a physically proximate attacker removes a VCC device while calling open(), aka a race condition between vcc_open() and vcc_remove().
Modified: 2025-03-06
CVE-2023-2430
A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-03-19
CVE-2023-28328
A NULL pointer dereference flaw was found in the az6027 driver in drivers/media/usb/dev-usb/az6027.c in the Linux Kernel. The message from user space is not checked properly before transferring into the device. This flaw allows a local user to crash the system or potentially cause a denial of service.
- https://bugzilla.redhat.com/show_bug.cgi?id=2177389
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2177389
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
Modified: 2025-05-05
CVE-2023-28866
In the Linux kernel through 6.2.8, net/bluetooth/hci_sync.c allows out-of-bounds access because amp_init1[] and amp_init2[] are supposed to have an intentionally invalid element, but do not.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=95084403f8c070ccf5d7cbe72352519c1798a40a
- https://lore.kernel.org/lkml/20230321015018.1759683-1-iam%40sung-woo.kim/
- https://patchwork.kernel.org/project/bluetooth/patch/20230322232543.3079578-1-luiz.dentz%40gmail.com
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=95084403f8c070ccf5d7cbe72352519c1798a40a
- https://lore.kernel.org/lkml/20230321015018.1759683-1-iam%40sung-woo.kim/
- https://patchwork.kernel.org/project/bluetooth/patch/20230322232543.3079578-1-luiz.dentz%40gmail.com
Modified: 2025-03-11
CVE-2023-2985
A use after free flaw was found in hfsplus_put_super in fs/hfsplus/super.c in the Linux Kernel. This flaw could allow a local user to cause a denial of service problem.
Modified: 2025-03-19
CVE-2023-30456
An issue was discovered in arch/x86/kvm/vmx/nested.c in the Linux kernel before 6.2.8. nVMX on x86_64 lacks consistency checks for CR0 and CR4.
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8
- https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230511-0007/
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8
- https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230511-0007/
Modified: 2025-05-05
CVE-2023-30772
The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/power/supply/da9150-charger.c if a physically proximate attacker unplugs a device.
- https://bugzilla.suse.com/show_bug.cgi?id=1210329
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06615d11cc78162dfd5116efb71f29eb29502d37
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://bugzilla.suse.com/show_bug.cgi?id=1210329
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06615d11cc78162dfd5116efb71f29eb29502d37
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
Modified: 2025-03-11
CVE-2023-3161
A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing font->width and font->height greater than 32 to fbcon_set_font, since there are no checks in place, a shift-out-of-bounds occurs leading to undefined behavior and possible denial of service.
Modified: 2024-11-21
CVE-2023-3212
A NULL pointer dereference issue was found in the gfs2 file system in the Linux kernel. It occurs on corrupt gfs2 file systems when the evict code tries to reference the journal descriptor structure after it has been freed and set to NULL. A privileged local user could use this flaw to cause a kernel panic.
- https://bugzilla.redhat.com/show_bug.cgi?id=2214348
- https://github.com/torvalds/linux/commit/504a10d9e46bc37b23d0a1ae2f28973c8516e636
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230929-0005/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- https://bugzilla.redhat.com/show_bug.cgi?id=2214348
- https://github.com/torvalds/linux/commit/504a10d9e46bc37b23d0a1ae2f28973c8516e636
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230929-0005/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
Modified: 2025-03-11
CVE-2023-3220
An issue was discovered in the Linux kernel through 6.1-rc8. dpu_crtc_atomic_check in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c lacks check of the return value of kzalloc() and will cause the NULL Pointer Dereference.
Modified: 2025-03-11
CVE-2023-3268
An out of bounds (OOB) memory access flaw was found in the Linux kernel in relay_file_read_start_pos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ec16f1450f4936025a9bdf1a273affdb9732c1
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/lkml/1682238502-1892-1-git-send-email-yangpc%40wangsu.com/T/
- https://security.netapp.com/advisory/ntap-20230824-0006/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ec16f1450f4936025a9bdf1a273affdb9732c1
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/lkml/1682238502-1892-1-git-send-email-yangpc%40wangsu.com/T/
- https://security.netapp.com/advisory/ntap-20230824-0006/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
Modified: 2025-05-05
CVE-2023-33203
The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/net/ethernet/qualcomm/emac/emac.c if a physically proximate attacker unplugs an emac based device.
- https://bugzilla.redhat.com/show_bug.cgi?id=2192667
- https://bugzilla.suse.com/show_bug.cgi?id=1210685
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75
- https://bugzilla.redhat.com/show_bug.cgi?id=2192667
- https://bugzilla.suse.com/show_bug.cgi?id=1210685
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75
Modified: 2025-03-18
CVE-2023-33288
An issue was discovered in the Linux kernel before 6.2.9. A use-after-free was found in bq24190_remove in drivers/power/supply/bq24190_charger.c. It could allow a local attacker to crash the system due to a race condition.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47c29d69212911f50bdcdd0564b5999a559010d4
- https://github.com/torvalds/linux/commit/47c29d69212911f50bdcdd0564b5999a559010d4
- https://lore.kernel.org/all/CAHk-=whcaHLNpb7Mu_QX7ABwPgyRyfW-V8=v4Mv0S22fpjY4JQ%40mail.gmail.com/
- https://lore.kernel.org/lkml/20230309174728.233732-1-zyytlz.wz%40163.com/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47c29d69212911f50bdcdd0564b5999a559010d4
- https://github.com/torvalds/linux/commit/47c29d69212911f50bdcdd0564b5999a559010d4
- https://lore.kernel.org/all/CAHk-=whcaHLNpb7Mu_QX7ABwPgyRyfW-V8=v4Mv0S22fpjY4JQ%40mail.gmail.com/
- https://lore.kernel.org/lkml/20230309174728.233732-1-zyytlz.wz%40163.com/
Modified: 2024-11-21
CVE-2023-3338
A null pointer dereference flaw was found in the Linux kernel's DECnet networking protocol. This issue could allow a remote user to crash the system.
- https://access.redhat.com/security/cve/CVE-2023-3338
- https://bugzilla.redhat.com/show_bug.cgi?id=2218618
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://seclists.org/oss-sec/2023/q2/276
- https://security.netapp.com/advisory/ntap-20230824-0005/
- https://www.debian.org/security/2023/dsa-5480
- https://access.redhat.com/security/cve/CVE-2023-3338
- https://bugzilla.redhat.com/show_bug.cgi?id=2218618
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://seclists.org/oss-sec/2023/q2/276
- https://security.netapp.com/advisory/ntap-20230824-0005/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2025-03-10
CVE-2023-3358
A null pointer dereference was found in the Linux kernel's Integrated Sensor Hub (ISH) driver. This issue could allow a local user to crash the system.
Modified: 2025-03-07
CVE-2023-3359
An issue was discovered in the Linux kernel brcm_nvram_parse in drivers/nvmem/brcm_nvram.c. Lacks for the check of the return value of kzalloc() can cause the NULL Pointer Dereference.
Modified: 2025-02-13
CVE-2023-3389
A use-after-free vulnerability in the Linux Kernel io_uring subsystem can be exploited to achieve local privilege escalation. Racing a io_uring cancel poll request with a linked timeout can cause a UAF in a hrtimer. We recommend upgrading past commit ef7dfac51d8ed961b742218f526bd589f3900a59 (4716c73b188566865bdd79c3a6709696a224ac04 for 5.10 stable and 0e388fce7aec40992eadee654193cad345d62663 for 5.15 stable).
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=4716c73b188566865bdd79c3a6709696a224ac04
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=0e388fce7aec40992eadee654193cad345d62663
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef7dfac51d8ed961b742218f526bd589f3900a59
- https://kernel.dance/0e388fce7aec40992eadee654193cad345d62663
- https://kernel.dance/4716c73b188566865bdd79c3a6709696a224ac04
- https://kernel.dance/ef7dfac51d8ed961b742218f526bd589f3900a59
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230731-0001/
- https://www.debian.org/security/2023/dsa-5480
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=4716c73b188566865bdd79c3a6709696a224ac04
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=0e388fce7aec40992eadee654193cad345d62663
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef7dfac51d8ed961b742218f526bd589f3900a59
- https://kernel.dance/0e388fce7aec40992eadee654193cad345d62663
- https://kernel.dance/4716c73b188566865bdd79c3a6709696a224ac04
- https://kernel.dance/ef7dfac51d8ed961b742218f526bd589f3900a59
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230731-0001/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2026-02-18
CVE-2023-33951
A race condition vulnerability was found in the vmwgfx driver in the Linux kernel. The flaw exists within the handling of GEM objects. The issue results from improper locking when performing operations on an object. This flaw allows a local privileged user to disclose information in the context of the kernel.
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/errata/RHSA-2023:6901
- https://access.redhat.com/errata/RHSA-2023:7077
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-33951
- https://bugzilla.redhat.com/show_bug.cgi?id=2218195
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20110/
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/errata/RHSA-2023:6901
- https://access.redhat.com/errata/RHSA-2023:7077
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-33951
- https://bugzilla.redhat.com/show_bug.cgi?id=2218195
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20110/
Modified: 2024-11-21
CVE-2023-33952
A double-free vulnerability was found in handling vmw_buffer_object objects in the vmwgfx driver in the Linux kernel. This issue occurs due to the lack of validating the existence of an object prior to performing further free operations on the object, which may allow a local privileged user to escalate privileges and execute code in the context of the kernel.
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/errata/RHSA-2023:6901
- https://access.redhat.com/errata/RHSA-2023:7077
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-33952
- https://bugzilla.redhat.com/show_bug.cgi?id=2218212
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20292
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/errata/RHSA-2023:6901
- https://access.redhat.com/errata/RHSA-2023:7077
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-33952
- https://bugzilla.redhat.com/show_bug.cgi?id=2218212
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20292
Modified: 2025-03-11
CVE-2023-34256
An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4_group_desc_csum does not properly check an offset. NOTE: this is disputed by third parties because the kernel is not intended to defend against attackers with the stated "When modifying the block device while it is mounted by the filesystem" access.
- https://bugzilla.suse.com/show_bug.cgi?id=1211895
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f04351888a83e595571de672e0a4a8b74f4fb31
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://syzkaller.appspot.com/bug?extid=8785e41224a3afd04321
- https://bugzilla.suse.com/show_bug.cgi?id=1211895
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f04351888a83e595571de672e0a4a8b74f4fb31
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://syzkaller.appspot.com/bug?extid=8785e41224a3afd04321
Modified: 2024-11-21
CVE-2023-3567
A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information.
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0431
- https://access.redhat.com/errata/RHSA-2024:0432
- https://access.redhat.com/errata/RHSA-2024:0439
- https://access.redhat.com/errata/RHSA-2024:0448
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-3567
- https://bugzilla.redhat.com/show_bug.cgi?id=2221463
- https://www.spinics.net/lists/stable-commits/msg285184.html
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0431
- https://access.redhat.com/errata/RHSA-2024:0432
- https://access.redhat.com/errata/RHSA-2024:0439
- https://access.redhat.com/errata/RHSA-2024:0448
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-3567
- https://bugzilla.redhat.com/show_bug.cgi?id=2221463
- https://www.spinics.net/lists/stable-commits/msg285184.html
Modified: 2025-05-05
CVE-2023-35823
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134_finidev in drivers/media/pci/saa7134/saa7134-core.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30cf57da176cca80f11df0d9b7f71581fe601389
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/
- https://lore.kernel.org/lkml/20230318085023.832510-1-zyytlz.wz%40163.com/t/
- https://security.netapp.com/advisory/ntap-20230803-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30cf57da176cca80f11df0d9b7f71581fe601389
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/
- https://lore.kernel.org/lkml/20230318085023.832510-1-zyytlz.wz%40163.com/t/
- https://security.netapp.com/advisory/ntap-20230803-0002/
Modified: 2025-05-05
CVE-2023-35824
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in dm1105_remove in drivers/media/pci/dm1105/dm1105.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5abda7a16698d4d1f47af1168d8fa2c640116b4a
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/
- https://lore.kernel.org/lkml/20230318081506.795147-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230803-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5abda7a16698d4d1f47af1168d8fa2c640116b4a
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/
- https://lore.kernel.org/lkml/20230318081506.795147-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230803-0002/
Modified: 2024-11-21
CVE-2023-35827
An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://lore.kernel.org/lkml/cca0b40b-d6f8-54c7-1e46-83cb62d0a2f1%40huawei.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0003/
- https://www.spinics.net/lists/netdev/msg886947.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://lore.kernel.org/lkml/cca0b40b-d6f8-54c7-1e46-83cb62d0a2f1%40huawei.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0003/
- https://www.spinics.net/lists/netdev/msg886947.html
Modified: 2025-02-13
CVE-2023-3609
A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation. If tcf_change_indev() fails, u32_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability. We recommend upgrading past commit 04c55383fa5689357bcdd2c8036725a55ed632bc.
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc
- https://kernel.dance/04c55383fa5689357bcdd2c8036725a55ed632bc
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230818-0005/
- https://www.debian.org/security/2023/dsa-5480
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc
- https://kernel.dance/04c55383fa5689357bcdd2c8036725a55ed632bc
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230818-0005/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2025-05-05
CVE-2023-37453
An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds and crash in read_descriptors in drivers/usb/core/sysfs.c.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1e4c574225cc5a0553115e5eb5787d1474db5b0f
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=85d07c55621676d47d873d2749b88f783cd4d5a1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de28e469da75359a2bb8cd8778b78aa64b1be1f4
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b
- https://lore.kernel.org/all/000000000000c0ffe505fe86c9ca%40google.com/T/
- https://lore.kernel.org/all/000000000000e56434059580f86e%40google.com/T/
- https://syzkaller.appspot.com/bug?extid=18996170f8096c6174d0
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1e4c574225cc5a0553115e5eb5787d1474db5b0f
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=85d07c55621676d47d873d2749b88f783cd4d5a1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de28e469da75359a2bb8cd8778b78aa64b1be1f4
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b
- https://lore.kernel.org/all/000000000000c0ffe505fe86c9ca%40google.com/T/
- https://lore.kernel.org/all/000000000000e56434059580f86e%40google.com/T/
- https://syzkaller.appspot.com/bug?extid=18996170f8096c6174d0
Modified: 2024-11-21
CVE-2023-37454
An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. NOTE: the suse.com reference has a different perspective about this.
- https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-37454
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f861765464f43a71462d52026fbddfc858239a5
- https://lore.kernel.org/all/00000000000056e02f05dfb6e11a%40google.com/T/
- https://syzkaller.appspot.com/bug?extid=26873a72980f8fa8bc55
- https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57
- https://syzkaller.appspot.com/bug?extid=61564e5023b7229ec85d
- https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-37454
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f861765464f43a71462d52026fbddfc858239a5
- https://lore.kernel.org/all/00000000000056e02f05dfb6e11a%40google.com/T/
- https://syzkaller.appspot.com/bug?extid=26873a72980f8fa8bc55
- https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57
- https://syzkaller.appspot.com/bug?extid=61564e5023b7229ec85d
Modified: 2024-11-21
CVE-2023-38409
An issue was discovered in set_con2fb_map in drivers/video/fbdev/core/fbcon.c in the Linux kernel before 6.2.12. Because an assignment occurs only for the first vc, the fbcon_registered_fb and fbcon_display arrays can be desynchronized in fbcon_mode_deleted (the con2fb_map points at the old fb_info).
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.12
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=fffb0b52d5258554c645c966c6cbef7de50b851d
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.12
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=fffb0b52d5258554c645c966c6cbef7de50b851d
Modified: 2024-11-21
CVE-2023-3863
A use-after-free flaw was found in nfc_llcp_find_local in net/nfc/llcp_core.c in NFC in the Linux kernel. This flaw allows a local user with special privileges to impact a kernel information leak issue.
- https://access.redhat.com/security/cve/CVE-2023-3863
- https://bugzilla.redhat.com/show_bug.cgi?id=2225126
- https://github.com/torvalds/linux/commit/6709d4b7bc2e079241fdef15d1160581c5261c10
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20240202-0002/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
- https://access.redhat.com/security/cve/CVE-2023-3863
- https://bugzilla.redhat.com/show_bug.cgi?id=2225126
- https://github.com/torvalds/linux/commit/6709d4b7bc2e079241fdef15d1160581c5261c10
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20240202-0002/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-11-21
CVE-2023-39189
A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39189
- https://bugzilla.redhat.com/show_bug.cgi?id=2226777
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39189
- https://bugzilla.redhat.com/show_bug.cgi?id=2226777
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
Modified: 2024-11-21
CVE-2023-39191
An improper input validation flaw was found in the eBPF subsystem in the Linux kernel. The issue occurs due to a lack of proper validation of dynamic pointers within user-supplied eBPF programs prior to executing them. This may allow an attacker with CAP_BPF privileges to escalate privileges and execute arbitrary code in the context of the kernel.
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/errata/RHSA-2024:0381
- https://access.redhat.com/errata/RHSA-2024:0439
- https://access.redhat.com/errata/RHSA-2024:0448
- https://access.redhat.com/security/cve/CVE-2023-39191
- https://bugzilla.redhat.com/show_bug.cgi?id=2226783
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-19399/
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/errata/RHSA-2024:0381
- https://access.redhat.com/errata/RHSA-2024:0439
- https://access.redhat.com/errata/RHSA-2024:0448
- https://access.redhat.com/security/cve/CVE-2023-39191
- https://bugzilla.redhat.com/show_bug.cgi?id=2226783
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-19399/
Modified: 2024-11-21
CVE-2023-39192
A flaw was found in the Netfilter subsystem in the Linux kernel. The xt_u32 module did not validate the fields in the xt_u32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure.
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39192
- https://bugzilla.redhat.com/show_bug.cgi?id=2226784
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18408/
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39192
- https://bugzilla.redhat.com/show_bug.cgi?id=2226784
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18408/
Modified: 2024-11-21
CVE-2023-39193
A flaw was found in the Netfilter subsystem in the Linux kernel. The sctp_mt_check did not validate the flag_count field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39193
- https://bugzilla.redhat.com/show_bug.cgi?id=2226787
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18866/
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39193
- https://bugzilla.redhat.com/show_bug.cgi?id=2226787
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18866/
Modified: 2024-11-21
CVE-2023-39194
A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39194
- https://bugzilla.redhat.com/show_bug.cgi?id=2226788
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18111/
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39194
- https://bugzilla.redhat.com/show_bug.cgi?id=2226788
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18111/
Modified: 2026-03-24
CVE-2023-39198
A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39198
- https://bugzilla.redhat.com/show_bug.cgi?id=2218332
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-39198
- https://bugzilla.redhat.com/show_bug.cgi?id=2218332
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-40791
extract_user_to_sg in lib/scatterlist.c in the Linux kernel before 6.4.12 fails to unpin pages in a certain situation, as demonstrated by a WARNING for try_grab_page.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f443fd5af5dbd531f880d3645d5dd36976cf087f
- https://lkml.org/lkml/2023/8/3/323
- https://lore.kernel.org/linux-crypto/20571.1690369076%40warthog.procyon.org.uk/
- https://security.netapp.com/advisory/ntap-20231110-0009/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f443fd5af5dbd531f880d3645d5dd36976cf087f
- https://lkml.org/lkml/2023/8/3/323
- https://lore.kernel.org/linux-crypto/20571.1690369076%40warthog.procyon.org.uk/
- https://security.netapp.com/advisory/ntap-20231110-0009/
Modified: 2024-11-21
CVE-2023-4132
A use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition.
- https://access.redhat.com/errata/RHSA-2023:6901
- https://access.redhat.com/errata/RHSA-2023:7077
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/security/cve/CVE-2023-4132
- https://bugzilla.redhat.com/show_bug.cgi?id=2221707
- https://access.redhat.com/errata/RHSA-2023:6901
- https://access.redhat.com/errata/RHSA-2023:7077
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/security/cve/CVE-2023-4132
- https://bugzilla.redhat.com/show_bug.cgi?id=2221707
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20231020-0005/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-11-21
CVE-2023-4133
A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flower_stats_timer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-4133
- https://bugzilla.redhat.com/show_bug.cgi?id=2221702
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-4133
- https://bugzilla.redhat.com/show_bug.cgi?id=2221702
Modified: 2024-11-18
CVE-2023-4134
A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service.
Modified: 2026-03-24
CVE-2023-4194
A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate.
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/security/cve/CVE-2023-4194
- https://bugzilla.redhat.com/show_bug.cgi?id=2229498
- https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/
- https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/
- https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/security/cve/CVE-2023-4194
- https://bugzilla.redhat.com/show_bug.cgi?id=2229498
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q/
- https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/
- https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/
- https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/
- https://security.netapp.com/advisory/ntap-20231027-0002/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-02-13
CVE-2023-4244
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability. We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e91b0ebd994635df2346353322ac51ce84ce6d8
- https://kernel.dance/3e91b0ebd994635df2346353322ac51ce84ce6d8
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e91b0ebd994635df2346353322ac51ce84ce6d8
- https://kernel.dance/3e91b0ebd994635df2346353322ac51ce84ce6d8
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
Modified: 2024-11-21
CVE-2023-4273
A flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack.
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/security/cve/CVE-2023-4273
- https://bugzilla.redhat.com/show_bug.cgi?id=2221609
- https://dfir.ru/2023/08/23/cve-2023-4273-a-vulnerability-in-the-linux-exfat-driver/
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/security/cve/CVE-2023-4273
- https://bugzilla.redhat.com/show_bug.cgi?id=2221609
- https://dfir.ru/2023/08/23/cve-2023-4273-a-vulnerability-in-the-linux-exfat-driver/
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q/
- https://security.netapp.com/advisory/ntap-20231027-0002/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-11-21
CVE-2023-42752
An integer overflow flaw was found in the Linux kernel. This issue leads to the kernel allocating `skb_shared_info` in the userspace, which is exploitable in systems without SMAP protection since `skb_shared_info` contains references to function pointers.
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://access.redhat.com/security/cve/CVE-2023-42752
- https://bugzilla.redhat.com/show_bug.cgi?id=2239828
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=915d975b2ffa
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c3b704d4a4a2
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://access.redhat.com/security/cve/CVE-2023-42752
- https://bugzilla.redhat.com/show_bug.cgi?id=2239828
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=915d975b2ffa
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c3b704d4a4a2
Modified: 2024-11-21
CVE-2023-42754
A NULL pointer dereference flaw was found in the Linux kernel ipv4 stack. The socket buffer (skb) was assumed to be associated with a device before calling __ip_options_compile, which is not always the case if the skb is re-routed by ipvs. This issue may allow a local user with CAP_NET_ADMIN privileges to crash the system.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-42754
- https://bugzilla.redhat.com/show_bug.cgi?id=2239845
- https://seclists.org/oss-sec/2023/q4/14
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-42754
- https://bugzilla.redhat.com/show_bug.cgi?id=2239845
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/
- https://seclists.org/oss-sec/2023/q4/14
Modified: 2024-11-21
CVE-2023-42755
A flaw was found in the IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service.
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-42755
- https://bugzilla.redhat.com/show_bug.cgi?id=2239847
- https://seclists.org/oss-sec/2023/q3/229
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-42755
- https://bugzilla.redhat.com/show_bug.cgi?id=2239847
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://seclists.org/oss-sec/2023/q3/229
Modified: 2024-11-21
CVE-2023-42756
A flaw was found in the Netfilter subsystem of the Linux kernel. A race condition between IPSET_CMD_ADD and IPSET_CMD_SWAP can lead to a kernel panic due to the invocation of `__ip_set_put` on a wrong `set`. This issue may allow a local user to crash the system.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/security/cve/CVE-2023-42756
- https://bugzilla.redhat.com/show_bug.cgi?id=2239848
- https://seclists.org/oss-sec/2023/q3/242
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/security/cve/CVE-2023-42756
- https://bugzilla.redhat.com/show_bug.cgi?id=2239848
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/
- https://seclists.org/oss-sec/2023/q3/242
Modified: 2025-08-19
CVE-2023-4458
A flaw was found within the parsing of extended attributes in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.
Modified: 2024-11-21
CVE-2023-4569
A memory leak flaw was found in nft_set_catchall_flush in net/netfilter/nf_tables_api.c in the Linux Kernel. This issue may allow a local attacker to cause double-deactivations of catchall elements, which can result in a memory leak.
- https://access.redhat.com/security/cve/CVE-2023-4569
- https://bugzilla.redhat.com/show_bug.cgi?id=2235470
- https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de/
- https://www.debian.org/security/2023/dsa-5492
- https://access.redhat.com/security/cve/CVE-2023-4569
- https://bugzilla.redhat.com/show_bug.cgi?id=2235470
- https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de/
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-11-21
CVE-2023-45862
An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef
- https://security.netapp.com/advisory/ntap-20231116-0004/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef
- https://security.netapp.com/advisory/ntap-20231116-0004/
Modified: 2024-11-21
CVE-2023-45863
An issue was discovered in lib/kobject.c in the Linux kernel before 6.2.3. With root access, an attacker can trigger a race condition that results in a fill_kobj_path out-of-bounds write.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2024-11-21
CVE-2023-4611
A use-after-free flaw was found in mm/mempolicy.c in the memory management subsystem in the Linux Kernel. This issue is caused by a race between mbind() and VMA-locked page fault, and may allow a local attacker to crash the system or lead to a kernel information leak.
- https://access.redhat.com/security/cve/CVE-2023-4611
- https://bugzilla.redhat.com/show_bug.cgi?id=2227244
- https://www.spinics.net/lists/stable-commits/msg310136.html
- https://access.redhat.com/security/cve/CVE-2023-4611
- https://bugzilla.redhat.com/show_bug.cgi?id=2227244
- https://www.spinics.net/lists/stable-commits/msg310136.html
Modified: 2025-06-17
CVE-2023-46343
In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7937609cd387246aed994e81aa4fa951358fba41
- https://github.com/torvalds/linux/commit/7937609cd387246aed994e81aa4fa951358fba41
- https://lore.kernel.org/netdev/20231013184129.18738-1-krzysztof.kozlowski%40linaro.org/T/#r38bdbaf8ae15305b77f6c5bc8e15d38f405623c7
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7937609cd387246aed994e81aa4fa951358fba41
- https://github.com/torvalds/linux/commit/7937609cd387246aed994e81aa4fa951358fba41
- https://lore.kernel.org/netdev/20231013184129.18738-1-krzysztof.kozlowski%40linaro.org/T/#r38bdbaf8ae15305b77f6c5bc8e15d38f405623c7
Modified: 2026-02-25
CVE-2023-46813
An issue was discovered in the Linux kernel before 6.5.9, exploitable by local users with userspace access to MMIO registers. Incorrect access checking in the #VC handler and instruction emulation of the SEV-ES emulation of MMIO accesses could lead to arbitrary write access to kernel memory (and thus privilege escalation). This depends on a race condition through which userspace can replace an instruction before the #VC handler reads it.
- https://bugzilla.suse.com/show_bug.cgi?id=1212649
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63e44bc52047f182601e7817da969a105aa1f721
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a37cd2a59d0cb270b1bba568fd3a3b8668b9d3ba
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9cb9c45583b911e0db71d09caa6b56469eb2bdf
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://bugzilla.suse.com/show_bug.cgi?id=1212649
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63e44bc52047f182601e7817da969a105aa1f721
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a37cd2a59d0cb270b1bba568fd3a3b8668b9d3ba
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9cb9c45583b911e0db71d09caa6b56469eb2bdf
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2024-11-21
CVE-2023-46862
An issue was discovered in the Linux kernel through 6.5.9. During a race with SQ thread exit, an io_uring/fdinfo.c io_uring_show_fdinfo NULL pointer dereference can occur.
- https://bugzilla.kernel.org/show_bug.cgi?id=218032#c4
- https://github.com/torvalds/linux/commit/7644b1a1c9a7ae8ab99175989bfc8676055edb46
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://bugzilla.kernel.org/show_bug.cgi?id=218032#c4
- https://github.com/torvalds/linux/commit/7644b1a1c9a7ae8ab99175989bfc8676055edb46
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2025-03-06
CVE-2023-47233
The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.
- https://bugzilla.suse.com/show_bug.cgi?id=1216702
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f7352557a35ab7888bc7831411ec8a3cbe20d78
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lore.kernel.org/all/20231104054709.716585-1-zyytlz.wz%40163.com/
- https://marc.info/?l=linux-kernel&m=169907678011243&w=2
- https://bugzilla.suse.com/show_bug.cgi?id=1216702
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f7352557a35ab7888bc7831411ec8a3cbe20d78
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lore.kernel.org/all/20231104054709.716585-1-zyytlz.wz%40163.com/
- https://marc.info/?l=linux-kernel&m=169907678011243&w=2
Modified: 2024-11-21
CVE-2023-5090
A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.
- https://access.redhat.com/errata/RHSA-2024:2758
- https://access.redhat.com/errata/RHSA-2024:3854
- https://access.redhat.com/errata/RHSA-2024:3855
- https://access.redhat.com/errata/RHSA-2024:4211
- https://access.redhat.com/errata/RHSA-2024:4352
- https://access.redhat.com/security/cve/CVE-2023-5090
- https://bugzilla.redhat.com/show_bug.cgi?id=2248122
- https://access.redhat.com/errata/RHSA-2024:3854
- https://access.redhat.com/errata/RHSA-2024:3855
- https://access.redhat.com/errata/RHSA-2024:4211
- https://access.redhat.com/errata/RHSA-2024:4352
- https://access.redhat.com/security/cve/CVE-2023-5090
- https://bugzilla.redhat.com/show_bug.cgi?id=2248122
Modified: 2024-11-21
CVE-2023-51042
In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.
Modified: 2024-11-21
CVE-2023-51043
In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.
Modified: 2024-11-21
CVE-2023-51780
An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8
- https://github.com/torvalds/linux/commit/24e90b9e34f9e039f56b5f25f6e6eb92cdd8f4b3
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://security.netapp.com/advisory/ntap-20240419-0001/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8
- https://github.com/torvalds/linux/commit/24e90b9e34f9e039f56b5f25f6e6eb92cdd8f4b3
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://security.netapp.com/advisory/ntap-20240419-0001/
Modified: 2024-11-21
CVE-2023-51781
An issue was discovered in the Linux kernel before 6.6.8. atalk_ioctl in net/appletalk/ddp.c has a use-after-free because of an atalk_recvmsg race condition.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8
- https://github.com/torvalds/linux/commit/189ff16722ee36ced4d2a2469d4ab65a8fee4198
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8
- https://github.com/torvalds/linux/commit/189ff16722ee36ced4d2a2469d4ab65a8fee4198
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2024-11-21
CVE-2023-51782
An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8
- https://github.com/torvalds/linux/commit/810c38a369a0a0ce625b5c12169abce1dd9ccd53
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8
- https://github.com/torvalds/linux/commit/810c38a369a0a0ce625b5c12169abce1dd9ccd53
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2025-11-04
CVE-2023-52340
The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20240816-0005/
Modified: 2025-11-04
CVE-2023-52429
dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/
- https://www.spinics.net/lists/dm-devel/msg56625.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/
- https://www.spinics.net/lists/dm-devel/msg56625.html
Modified: 2025-01-17
CVE-2023-52434
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2_parse_contexts()
Validate offsets and lengths before dereferencing create contexts in
smb2_parse_contexts().
This fixes following oops when accessing invalid create contexts from
server:
BUG: unable to handle page fault for address: ffff8881178d8cc3
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 4a01067 P4D 4a01067 PUD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]
Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00
00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7
7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00
RSP: 0018:ffffc900007939e0 EFLAGS: 00010216
RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90
RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000
RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000
R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000
R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22
FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5
- https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa
- https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29
- https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb
- https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48
- https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144
- https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5
- https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa
- https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29
- https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb
- https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48
- https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20250117-0009/
Modified: 2024-11-21
CVE-2023-52435
In the Linux kernel, the following vulnerability has been resolved:
net: prevent mss overflow in skb_segment()
Once again syzbot is able to crash the kernel in skb_segment() [1]
GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :
mss = mss * partial_segs;
65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.
Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.
[1]
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0d3ffbbf8631d6db0552f46250015648991c856f
- https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7
- https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a
- https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3
- https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77
- https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137
- https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083
- https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7
- https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a
- https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3
- https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77
- https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137
- https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2023-52452
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead. This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
- https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19
- https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529
- https://git.kernel.org/stable/c/fbcf372c8eda2290470268e0afb5ab5d5f5d5fde
- https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19
- https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529
- https://git.kernel.org/stable/c/fbcf372c8eda2290470268e0afb5ab5d5f5d5fde
Modified: 2025-03-14
CVE-2023-52591
In the Linux kernel, the following vulnerability has been resolved: reiserfs: Avoid touching renamed directory if parent does not change The VFS will not be locking moved directory if its parent does not change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem.
- https://git.kernel.org/stable/c/17e1361cb91dc1325834da95d2ab532959d2debc
- https://git.kernel.org/stable/c/49db9b1b86a82448dfaf3fcfefcf678dee56c8ed
- https://git.kernel.org/stable/c/c04c162f82ac403917780eb6d1654694455d4e7c
- https://git.kernel.org/stable/c/17e1361cb91dc1325834da95d2ab532959d2debc
- https://git.kernel.org/stable/c/49db9b1b86a82448dfaf3fcfefcf678dee56c8ed
- https://git.kernel.org/stable/c/c04c162f82ac403917780eb6d1654694455d4e7c
Modified: 2025-02-14
CVE-2023-52596
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix out of bounds access for empty sysctl registers When registering tables to the sysctl subsystem there is a check to see if header is a permanently empty directory (used for mounts). This check evaluates the first element of the ctl_table. This results in an out of bounds evaluation when registering empty directories. The function register_sysctl_mount_point now passes a ctl_table of size 1 instead of size 0. It now relies solely on the type to identify a permanently empty register. Make sure that the ctl_table has at least one element before testing for permanent emptiness.
- https://git.kernel.org/stable/c/15893975e9e382f8294ea8d926f08dc2d8d39ede
- https://git.kernel.org/stable/c/2ae7081bc10123b187e36a4f3a8e53768de31489
- https://git.kernel.org/stable/c/315552310c7de92baea4e570967066569937a843
- https://git.kernel.org/stable/c/15893975e9e382f8294ea8d926f08dc2d8d39ede
- https://git.kernel.org/stable/c/2ae7081bc10123b187e36a4f3a8e53768de31489
- https://git.kernel.org/stable/c/315552310c7de92baea4e570967066569937a843
Modified: 2025-03-10
CVE-2023-52616
In the Linux kernel, the following vulnerability has been resolved: crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately.
- https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165
- https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6
- https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49
- https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a
- https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a
- https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598
- https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165
- https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6
- https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49
- https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a
- https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a
- https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-16
CVE-2023-52620
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow timeout for anonymous sets Never used from userspace, disallow these parameters.
- https://git.kernel.org/stable/c/00b19ee0dcc1aef06294471ab489bae26d94524e
- https://git.kernel.org/stable/c/116b0e8e4673a5faa8a739a19b467010c4d3058c
- https://git.kernel.org/stable/c/49ce99ae43314d887153e07cec8bb6a647a19268
- https://git.kernel.org/stable/c/6f3ae02bbb62f151b19162d5fdc9fe3d48450323
- https://git.kernel.org/stable/c/b7be6c737a179a76901c872f6b4c1d00552d9a1b
- https://git.kernel.org/stable/c/e26d3009efda338f19016df4175f354a9bd0a4ab
- https://git.kernel.org/stable/c/00b19ee0dcc1aef06294471ab489bae26d94524e
- https://git.kernel.org/stable/c/116b0e8e4673a5faa8a739a19b467010c4d3058c
- https://git.kernel.org/stable/c/49ce99ae43314d887153e07cec8bb6a647a19268
- https://git.kernel.org/stable/c/6f3ae02bbb62f151b19162d5fdc9fe3d48450323
- https://git.kernel.org/stable/c/b7be6c737a179a76901c872f6b4c1d00552d9a1b
- https://git.kernel.org/stable/c/e26d3009efda338f19016df4175f354a9bd0a4ab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-08
CVE-2023-52629
In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.
Modified: 2025-04-08
CVE-2023-52631
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix an NULL dereference bug The issue here is when this is called from ntfs_load_attr_list(). The "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line.
- https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2
- https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b
- https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c
- https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6
- https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7
- https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2
- https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b
- https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c
- https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6
- https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7
Modified: 2025-01-07
CVE-2023-52637
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
modifies jsk->filters while receiving packets.
Following trace was seen on affected system:
==================================================================
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
Read of size 4 at addr ffff888012144014 by task j1939/350
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
print_report+0xd3/0x620
? kasan_complete_mode_report_info+0x7d/0x200
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
kasan_report+0xc2/0x100
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
__asan_load4+0x84/0xb0
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
j1939_sk_recv+0x20b/0x320 [can_j1939]
? __kasan_check_write+0x18/0x20
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
? j1939_simple_recv+0x69/0x280 [can_j1939]
? j1939_ac_recv+0x5e/0x310 [can_j1939]
j1939_can_recv+0x43f/0x580 [can_j1939]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
? raw_rcv+0x42/0x3c0 [can_raw]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
can_rcv_filter+0x11f/0x350 [can]
can_receive+0x12f/0x190 [can]
? __pfx_can_rcv+0x10/0x10 [can]
can_rcv+0xdd/0x130 [can]
? __pfx_can_rcv+0x10/0x10 [can]
__netif_receive_skb_one_core+0x13d/0x150
? __pfx___netif_receive_skb_one_core+0x10/0x10
? __kasan_check_write+0x18/0x20
? _raw_spin_lock_irq+0x8c/0xe0
__netif_receive_skb+0x23/0xb0
process_backlog+0x107/0x260
__napi_poll+0x69/0x310
net_rx_action+0x2a1/0x580
? __pfx_net_rx_action+0x10/0x10
? __pfx__raw_spin_lock+0x10/0x10
? handle_irq_event+0x7d/0xa0
__do_softirq+0xf3/0x3f8
do_softirq+0x53/0x80
- https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532
- https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8
- https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed
- https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba
- https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc
- https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50
- https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d
- https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532
- https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8
- https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed
- https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba
- https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc
- https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50
- https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-03
CVE-2023-52638
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change]
- https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170
- https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e
- https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284
- https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d
- https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf
- https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170
- https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e
- https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284
- https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d
- https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf
Modified: 2025-03-17
CVE-2023-52639
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm; Let children inherit the private field of the parent.
- https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082
- https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc
- https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380
- https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32
- https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082
- https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc
- https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380
- https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32
Modified: 2025-02-27
CVE-2023-52640
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea.
- https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c
- https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23
- https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb
- https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15
- https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd
- https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c
- https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23
- https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb
- https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15
- https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd
Modified: 2025-01-07
CVE-2023-52641
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there.
- https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc
- https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd
- https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c
- https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a
- https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b
- https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc
- https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd
- https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c
- https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a
- https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b
Modified: 2025-03-27
CVE-2023-52642
In the Linux kernel, the following vulnerability has been resolved: media: rc: bpf attach/detach requires write permission Note that bpf attach/detach also requires CAP_NET_ADMIN.
- https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f
- https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8
- https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f
- https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e
- https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be
- https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0
- https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f
- https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8
- https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f
- https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e
- https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be
- https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2023-52643
In the Linux kernel, the following vulnerability has been resolved: iio: core: fix memleak in iio_device_register_sysfs When iio_device_register_sysfs_group() fails, we should free iio_dev_opaque->chan_attr_group.attrs to prevent potential memleak.
- https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363
- https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2
- https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93
- https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81
- https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728
- https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363
- https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2
- https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93
- https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81
- https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728
Modified: 2025-04-02
CVE-2023-52644
In the Linux kernel, the following vulnerability has been resolved: wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated---
- https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455
- https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010
- https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240
- https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436
- https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08
- https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc
- https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83
- https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d
- https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610
- https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455
- https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010
- https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240
- https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436
- https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08
- https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc
- https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83
- https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d
- https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52645
In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd.
- https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff
- https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b
- https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438
- https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5
- https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25
- https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff
- https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b
- https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438
- https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5
- https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25
Modified: 2024-12-23
CVE-2023-52650
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: dsi: Add missing check for of_find_device_by_node Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc
- https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80
- https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6
- https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976
- https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129
- https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d
- https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d
- https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9
- https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5
- https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc
- https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80
- https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6
- https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976
- https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129
- https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d
- https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d
- https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9
- https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-18
CVE-2023-52652
In the Linux kernel, the following vulnerability has been resolved: NTB: fix possible name leak in ntb_register_device() If device_register() fails in ntb_register_device(), the device name allocated by dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device() to give up the reference in the error path. So fix this by calling put_device() in the error path so that the name can be freed in kobject_cleanup(). As a result of this, put_device() in the error path of ntb_register_device() is removed and the actual error is returned. [mani: reworded commit message]
- https://git.kernel.org/stable/c/6632a54ac8057cc0b0d789c6f73883e871bcd25c
- https://git.kernel.org/stable/c/913421f9f7fd8324dcc41753d0f28b52e177ef04
- https://git.kernel.org/stable/c/a039690d323221eb5865f1f31db3ec264e7a14b6
- https://git.kernel.org/stable/c/a62b9f3d7bbfac874cc0c638bc1776dcf1f8ec06
- https://git.kernel.org/stable/c/aebfdfe39b9327a3077d0df8db3beb3160c9bdd0
- https://git.kernel.org/stable/c/e8025439ef8e16029dc313d78a351ef192469b7b
- https://git.kernel.org/stable/c/6632a54ac8057cc0b0d789c6f73883e871bcd25c
- https://git.kernel.org/stable/c/913421f9f7fd8324dcc41753d0f28b52e177ef04
- https://git.kernel.org/stable/c/a039690d323221eb5865f1f31db3ec264e7a14b6
- https://git.kernel.org/stable/c/a62b9f3d7bbfac874cc0c638bc1776dcf1f8ec06
- https://git.kernel.org/stable/c/aebfdfe39b9327a3077d0df8db3beb3160c9bdd0
- https://git.kernel.org/stable/c/e8025439ef8e16029dc313d78a351ef192469b7b
Modified: 2025-04-08
CVE-2023-52653
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix a memleak in gss_import_v2_context The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error. Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation.
- https://git.kernel.org/stable/c/47ac11db93e74ac49cd6c3fc69bcbc5964c4a8b4
- https://git.kernel.org/stable/c/99044c01ed5329e73651c054d8a4baacdbb1a27c
- https://git.kernel.org/stable/c/d111e30d9cd846bb368faf3637dc0f71fcbcf822
- https://git.kernel.org/stable/c/e67b652d8e8591d3b1e569dbcdfcee15993e91fa
- https://git.kernel.org/stable/c/47ac11db93e74ac49cd6c3fc69bcbc5964c4a8b4
- https://git.kernel.org/stable/c/99044c01ed5329e73651c054d8a4baacdbb1a27c
- https://git.kernel.org/stable/c/d111e30d9cd846bb368faf3637dc0f71fcbcf822
- https://git.kernel.org/stable/c/e67b652d8e8591d3b1e569dbcdfcee15993e91fa
Modified: 2025-12-23
CVE-2023-52656
In the Linux kernel, the following vulnerability has been resolved: io_uring: drop any code related to SCM_RIGHTS This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it.
- https://git.kernel.org/stable/c/6e5e6d274956305f1fc0340522b38f5f5be74bdb
- https://git.kernel.org/stable/c/6fc19b3d8a45ff0e5d50ec8184cee1d5eac1a8ba
- https://git.kernel.org/stable/c/88c49d9c896143cdc0f77197c4dcf24140375e89
- https://git.kernel.org/stable/c/a3812a47a32022ca76bf46ddacdd823dc2aabf8b
- https://git.kernel.org/stable/c/a6771f343af90a25f3a14911634562bb5621df02
- https://git.kernel.org/stable/c/cfb24022bb2c31f1f555dc6bc3cc5e2547446fb3
- https://git.kernel.org/stable/c/d909d381c3152393421403be4b6435f17a2378b4
- https://git.kernel.org/stable/c/6e5e6d274956305f1fc0340522b38f5f5be74bdb
- https://git.kernel.org/stable/c/88c49d9c896143cdc0f77197c4dcf24140375e89
- https://git.kernel.org/stable/c/a3812a47a32022ca76bf46ddacdd823dc2aabf8b
- https://git.kernel.org/stable/c/a6771f343af90a25f3a14911634562bb5621df02
- https://git.kernel.org/stable/c/cfb24022bb2c31f1f555dc6bc3cc5e2547446fb3
- https://git.kernel.org/stable/c/d909d381c3152393421403be4b6435f17a2378b4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2023-52657
In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amd/pm: resolve reboot exception for si oland" This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86. This causes hangs on SI when DC is enabled and errors on driver reboot and power off cycles.
- https://git.kernel.org/stable/c/2e443ed55fe3ffb08327b331a9f45e9382413c94
- https://git.kernel.org/stable/c/955558030954b9637b41c97b730f9b38c92ac488
- https://git.kernel.org/stable/c/baac292852c0e347626fb5436916947188e5838f
- https://git.kernel.org/stable/c/c51468ac328d3922747be55507c117e47da813e6
- https://git.kernel.org/stable/c/2e443ed55fe3ffb08327b331a9f45e9382413c94
- https://git.kernel.org/stable/c/955558030954b9637b41c97b730f9b38c92ac488
- https://git.kernel.org/stable/c/baac292852c0e347626fb5436916947188e5838f
- https://git.kernel.org/stable/c/c51468ac328d3922747be55507c117e47da813e6
Modified: 2026-03-17
CVE-2023-52658
In the Linux kernel, the following vulnerability has been resolved: Revert "net/mlx5: Block entering switchdev mode with ns inconsistency" This reverts commit 662404b24a4c4d839839ed25e3097571f5938b9b. The revert is required due to the suspicion it is not good for anything and cause crash.
- https://git.kernel.org/stable/c/136ccb2041a5d1a475f845d3bc138550be6f5daa
- https://git.kernel.org/stable/c/1bcdd66d33edb446903132456c948f0b764ef2f9
- https://git.kernel.org/stable/c/3fba8eab2cfc7334e0f132d29dfd2552f2f2a579
- https://git.kernel.org/stable/c/8deeefb24786ea7950b37bde4516b286c877db00
- https://git.kernel.org/stable/c/1bcdd66d33edb446903132456c948f0b764ef2f9
- https://git.kernel.org/stable/c/3fba8eab2cfc7334e0f132d29dfd2552f2f2a579
- https://git.kernel.org/stable/c/8deeefb24786ea7950b37bde4516b286c877db00
Modified: 2025-09-25
CVE-2023-52660
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ handling due to shared interrupts The driver requests the interrupts as IRQF_SHARED, so the interrupt handlers can be called at any time. If such a call happens while the ISP is powered down, the SoC will hang as the driver tries to access the ISP registers. This can be reproduced even without the platform sharing the IRQ line: Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will hang. Fix this by adding a new field, 'irqs_enabled', which is used to bail out from the interrupt handler when the ISP is not operational.
- https://git.kernel.org/stable/c/abd34206f396d3ae50cddbd5aa840b8cd7f68c63
- https://git.kernel.org/stable/c/b39b4d207d4f236a74e20d291f6356f2231fd9ee
- https://git.kernel.org/stable/c/edcf92bc66d8361c51dff953a55210e5cfd95587
- https://git.kernel.org/stable/c/ffb635bb398fc07cb38f8a7b4a82cbe5f412f08e
- https://git.kernel.org/stable/c/abd34206f396d3ae50cddbd5aa840b8cd7f68c63
- https://git.kernel.org/stable/c/b39b4d207d4f236a74e20d291f6356f2231fd9ee
- https://git.kernel.org/stable/c/edcf92bc66d8361c51dff953a55210e5cfd95587
- https://git.kernel.org/stable/c/ffb635bb398fc07cb38f8a7b4a82cbe5f412f08e
Modified: 2025-09-19
CVE-2023-52661
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be undone. Add the missing clk_put and a new 'put_pll_d_out0' label in the error handling path, and use it.
- https://git.kernel.org/stable/c/2388c36e028fff7f8ffd515681a14c6c2c07fea7
- https://git.kernel.org/stable/c/45c8034db47842b25a3ab6139d71e13b4e67b9b3
- https://git.kernel.org/stable/c/5c8dc26e31b8b410ad1895e0d314def50c76eed0
- https://git.kernel.org/stable/c/845322a9c06dd1dcf35b6c4e3af89684297c23cc
- https://git.kernel.org/stable/c/f3f407ccbe84a34de9be3195d22cdd5969f3fd9f
- https://git.kernel.org/stable/c/fa74e4f5d0821829545b9f7034a0e577c205c101
- https://git.kernel.org/stable/c/2388c36e028fff7f8ffd515681a14c6c2c07fea7
- https://git.kernel.org/stable/c/45c8034db47842b25a3ab6139d71e13b4e67b9b3
- https://git.kernel.org/stable/c/5c8dc26e31b8b410ad1895e0d314def50c76eed0
- https://git.kernel.org/stable/c/845322a9c06dd1dcf35b6c4e3af89684297c23cc
- https://git.kernel.org/stable/c/f3f407ccbe84a34de9be3195d22cdd5969f3fd9f
- https://git.kernel.org/stable/c/fa74e4f5d0821829545b9f7034a0e577c205c101
Modified: 2025-01-14
CVE-2023-52662
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init.
- https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf
- https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a
- https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6
- https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5
- https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce
- https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876
- https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf
- https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a
- https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6
- https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5
- https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce
- https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876
Modified: 2025-09-25
CVE-2023-52676
In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904
- https://git.kernel.org/stable/c/1d38a9ee81570c4bd61f557832dead4d6f816760
- https://git.kernel.org/stable/c/ad140fc856f0b1d5e2215bcb6d0cc247a86805a2
- https://git.kernel.org/stable/c/e5ad9ecb84405637df82732ee02ad741a5f782a6
- https://git.kernel.org/stable/c/1d38a9ee81570c4bd61f557832dead4d6f816760
- https://git.kernel.org/stable/c/ad140fc856f0b1d5e2215bcb6d0cc247a86805a2
- https://git.kernel.org/stable/c/e5ad9ecb84405637df82732ee02ad741a5f782a6
Modified: 2025-01-06
CVE-2023-52751
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in smb2_query_info_compound() The following UAF was triggered when running fstests generic/072 with KASAN enabled against Windows Server 2022 and mount options 'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __stack_depot_save+0x39/0x480 ? kasan_save_stack+0x33/0x60 ? kasan_set_track+0x25/0x30 ? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs] ? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __lock_acquire+0x480/0x26c0 ? lock_release+0x1ed/0x640 ? srso_alias_return_thunk+0x5/0x7f ? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f ? lockdep_hardirqs_on_prepare+0x136/0x200 ? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] This is a race between open_cached_dir() and cached_dir_lease_break() where the cache entry for the open directory handle receives a lease break while creating it. And before returning from open_cached_dir(), we put the last reference of the new @cfid because of !@cfid->has_lease. Besides the UAF, while running xfstests a lot of missed lease breaks have been noticed in tests that run several concurrent statfs(2) calls on those cached fids CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ... To fix both, in open_cached_dir() ensure that @cfid->has_lease is set right before sending out compounded request so that any potential lease break will be get processed by demultiplex thread while we're still caching @cfid. And, if open failed for some reason, re-check @cfid->has_lease to decide whether or not put lease reference.
- https://git.kernel.org/stable/c/5c86919455c1edec99ebd3338ad213b59271a71b
- https://git.kernel.org/stable/c/6db94d08359c43f2c8fe372811cdee04564a41b9
- https://git.kernel.org/stable/c/93877b9afc2994c89362007aac480a7b150f386f
- https://git.kernel.org/stable/c/5c86919455c1edec99ebd3338ad213b59271a71b
- https://git.kernel.org/stable/c/6db94d08359c43f2c8fe372811cdee04564a41b9
- https://git.kernel.org/stable/c/93877b9afc2994c89362007aac480a7b150f386f
Modified: 2025-11-03
CVE-2023-52760
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.
- https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81
- https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37
- https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81
- https://git.kernel.org/stable/c/7ad4e0a4f61c57c3ca291ee010a9d677d0199fba
- https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-09-23
CVE-2023-52761
In the Linux kernel, the following vulnerability has been resolved:
riscv: VMAP_STACK overflow detection thread-safe
commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added
support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to
`shadow_stack` temporarily before switching finally to per-cpu
`overflow_stack`.
If two CPUs/harts are racing and end up in over flowing kernel stack, one
or both will end up corrupting each other state because `shadow_stack` is
not per-cpu. This patch optimizes per-cpu overflow stack switch by
directly picking per-cpu `overflow_stack` and gets rid of `shadow_stack`.
Following are the changes in this patch
- Defines an asm macro to obtain per-cpu symbols in destination
register.
- In entry.S, when overflow is detected, per-cpu overflow stack is
located using per-cpu asm macro. Computing per-cpu symbol requires
a temporary register. x31 is saved away into CSR_SCRATCH
(CSR_SCRATCH is anyways zero since we're in kernel).
Please see Links for additional relevant disccussion and alternative
solution.
Tested by `echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT`
Kernel crash log below
Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT
Task stack: [0xff20000010a98000..0xff20000010a9c000]
Overflow stack: [0xff600001f7d98370..0xff600001f7d99370]
CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34
Hardware name: riscv-virtio,qemu (DT)
epc : __memset+0x60/0xfc
ra : recursive_loop+0x48/0xc6 [lkdtm]
epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80
gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88
t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0
s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000
a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000
a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff
s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90
s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684
s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10
s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4
t5 : ffffffff815dbab8 t6 : ff20000010a9bb48
status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f
Kernel panic - not syncing: Kernel stack overflow
CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[
- https://git.kernel.org/stable/c/1493baaf09e3c1899959c8a107cd1207e16d1788
- https://git.kernel.org/stable/c/be97d0db5f44c0674480cb79ac6f5b0529b84c76
- https://git.kernel.org/stable/c/eff53aea3855f71992c043cebb1c00988c17ee20
- https://git.kernel.org/stable/c/1493baaf09e3c1899959c8a107cd1207e16d1788
- https://git.kernel.org/stable/c/be97d0db5f44c0674480cb79ac6f5b0529b84c76
- https://git.kernel.org/stable/c/eff53aea3855f71992c043cebb1c00988c17ee20
Modified: 2025-01-06
CVE-2023-52770
In the Linux kernel, the following vulnerability has been resolved: f2fs: split initial and dynamic conditions for extent_cache Let's allocate the extent_cache tree without dynamic conditions to avoid a missing condition causing a panic as below. # create a file w/ a compressed flag # disable the compression # panic while updating extent_cache F2FS-fs (dm-64): Swapfile: last extent is not aligned to section F2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N) Adding 124996k swap on ./swap-file. Priority:0 extents:2 across:17179494468k ================================================================== BUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] BUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] BUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] BUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] BUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 Write of size 4 at addr 0000000000000030 by task syz-executor154/3327 CPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G O 5.10.185 #1 Hardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023 Call Trace: __dump_stack out/common/lib/dump_stack.c:77 [inline] dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118 __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415 kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428 kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186 __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37 instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155 f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172 f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline] f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764 vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310 ksys_fallocate out/common/fs/open.c:333 [inline] __do_sys_fallocate out/common/fs/open.c:341 [inline] __se_sys_fallocate out/common/fs/open.c:339 [inline] __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339 do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46
- https://git.kernel.org/stable/c/9de787139b0258a5dd1f498780c26d76b61d2958
- https://git.kernel.org/stable/c/d83309e7e006cee8afca83523559017c824fbf7a
- https://git.kernel.org/stable/c/f803982190f0265fd36cf84670aa6daefc2b0768
- https://git.kernel.org/stable/c/9de787139b0258a5dd1f498780c26d76b61d2958
- https://git.kernel.org/stable/c/d83309e7e006cee8afca83523559017c824fbf7a
- https://git.kernel.org/stable/c/f803982190f0265fd36cf84670aa6daefc2b0768
Modified: 2025-09-23
CVE-2023-52771
In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix delete_endpoint() vs parent unregistration race The CXL subsystem, at cxl_mem ->probe() time, establishes a lineage of ports (struct cxl_port objects) between an endpoint and the root of a CXL topology. Each port including the endpoint port is attached to the cxl_port driver. Given that setup, it follows that when either any port in that lineage goes through a cxl_port ->remove() event, or the memdev goes through a cxl_mem ->remove() event. The hierarchy below the removed port, or the entire hierarchy if the memdev is removed needs to come down. The delete_endpoint() callback is careful to check whether it is being called to tear down the hierarchy, or if it is only being called to teardown the memdev because an ancestor port is going through ->remove(). That care needs to take the device_lock() of the endpoint's parent. Which requires 2 bugs to be fixed: 1/ A reference on the parent is needed to prevent use-after-free scenarios like this signature: BUG: spinlock bad magic on CPU#0, kworker/u56:0/11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023 Workqueue: cxl_port detach_memdev [cxl_core] RIP: 0010:spin_bug+0x65/0xa0 Call Trace: do_raw_spin_lock+0x69/0xa0 __mutex_lock+0x695/0xb80 delete_endpoint+0xad/0x150 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 detach_memdev+0x15/0x20 [cxl_core] process_one_work+0x1e3/0x4c0 worker_thread+0x1dd/0x3d0 2/ In the case of RCH topologies, the parent device that needs to be locked is not always @port->dev as returned by cxl_mem_find_port(), use endpoint->dev.parent instead.
- https://git.kernel.org/stable/c/37179fcc916bce8c3cc7b36d67ef814cce55142b
- https://git.kernel.org/stable/c/6b2e428e673b3f55965674a426c40922e91388aa
- https://git.kernel.org/stable/c/8d2ad999ca3c64cb08cf6a58d227b9d9e746d708
- https://git.kernel.org/stable/c/37179fcc916bce8c3cc7b36d67ef814cce55142b
- https://git.kernel.org/stable/c/6b2e428e673b3f55965674a426c40922e91388aa
- https://git.kernel.org/stable/c/8d2ad999ca3c64cb08cf6a58d227b9d9e746d708
Modified: 2025-09-26
CVE-2023-52797
In the Linux kernel, the following vulnerability has been resolved:
drivers: perf: Check find_first_bit() return value
We must check the return value of find_first_bit() before using the
return value as an index array since it happens to overflow the array
and then panic:
[ 107.318430] Kernel BUG [#1]
[ 107.319434] CPU: 3 PID: 1238 Comm: kill Tainted: G E 6.6.0-rc6ubuntu-defconfig #2
[ 107.319465] Hardware name: riscv-virtio,qemu (DT)
[ 107.319551] epc : pmu_sbi_ovf_handler+0x3a4/0x3ae
[ 107.319840] ra : pmu_sbi_ovf_handler+0x52/0x3ae
[ 107.319868] epc : ffffffff80a0a77c ra : ffffffff80a0a42a sp : ffffaf83fecda350
[ 107.319884] gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480
[ 107.319899] t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520
[ 107.319921] s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff
[ 107.319936] a2 : 0000000001073734 a3 : 0000000000000004 a4 : 0000000000000000
[ 107.319951] a5 : 0000000000000040 a6 : 000000001d1c8774 a7 : 0000000000504d55
[ 107.319965] s2 : ffffffff82451f10 s3 : ffffffff82724e70 s4 : 000000000000003f
[ 107.319980] s5 : 0000000000000011 s6 : ffffaf8083db27c0 s7 : 0000000000000000
[ 107.319995] s8 : 0000000000000001 s9 : 00007fffb45d6558 s10: 00007fffb45d81a0
[ 107.320009] s11: ffffaf7ffff60000 t3 : 0000000000000004 t4 : 0000000000000000
[ 107.320023] t5 : ffffaf7f80000000 t6 : ffffaf8000000000
[ 107.320037] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
[ 107.320081] [
- https://git.kernel.org/stable/c/2c86b24095fcf72cf51bc72d12e4350163b4e11d
- https://git.kernel.org/stable/c/45a0de41ec383c8b7c6d442734ba3852dd2fc4a7
- https://git.kernel.org/stable/c/c6e316ac05532febb0c966fa9b55f5258ed037be
- https://git.kernel.org/stable/c/2c86b24095fcf72cf51bc72d12e4350163b4e11d
- https://git.kernel.org/stable/c/45a0de41ec383c8b7c6d442734ba3852dd2fc4a7
- https://git.kernel.org/stable/c/c6e316ac05532febb0c966fa9b55f5258ed037be
Modified: 2025-11-25
CVE-2023-52812
In the Linux kernel, the following vulnerability has been resolved: drm/amd: check num of link levels when update pcie param In SR-IOV environment, the value of pcie_table->num_of_link_levels will be 0, and num_of_levels - 1 will cause array index out of bounds
- https://git.kernel.org/stable/c/09f617219fe9ccd8d7b65dc3e879b5889f663b5a
- https://git.kernel.org/stable/c/2f2d48b6247ae3001f83c98730b3cce475cb2927
- https://git.kernel.org/stable/c/406e8845356d18bdf3d3a23b347faf67706472ec
- https://git.kernel.org/stable/c/5b4574b663d0a1a0a62d5232429b7db9ae6d0670
- https://git.kernel.org/stable/c/09f617219fe9ccd8d7b65dc3e879b5889f663b5a
- https://git.kernel.org/stable/c/406e8845356d18bdf3d3a23b347faf67706472ec
- https://git.kernel.org/stable/c/5b4574b663d0a1a0a62d5232429b7db9ae6d0670
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2023-52827
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats() len is extracted from HTT message and could be an unexpected value in case errors happen, so add validation before using to avoid possible out-of-bound read in the following message iteration and parsing. The same issue also applies to ppdu_info->ppdu_stats.common.num_users, so validate it before using too. These are found during code review. Compile test only.
- https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e
- https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57
- https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c
- https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e
- https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57
- https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c
Modified: 2025-11-03
CVE-2023-52857
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix coverity issue with unintentional integer overflow 1. Instead of multiplying 2 variable of different types. Change to assign a value of one variable and then multiply the other variable. 2. Add a int variable for multiplier calculation instead of calculating different types multiplier with dma_addr_t variable directly.
- https://git.kernel.org/stable/c/0d8a1df39d3fc34560e2cc663b5c340d06a25396
- https://git.kernel.org/stable/c/96312a251d4dcee5d36e32edba3002bfde0ddd9c
- https://git.kernel.org/stable/c/a12bd675100531f9fb4508fd4430dd1632325a0e
- https://git.kernel.org/stable/c/b0b0d811eac6b4c52cb9ad632fa6384cf48869e7
- https://git.kernel.org/stable/c/0d8a1df39d3fc34560e2cc663b5c340d06a25396
- https://git.kernel.org/stable/c/96312a251d4dcee5d36e32edba3002bfde0ddd9c
- https://git.kernel.org/stable/c/b0b0d811eac6b4c52cb9ad632fa6384cf48869e7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-12-17
CVE-2023-52880
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that.
- https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167
- https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a
- https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88
- https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58
- https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed
- https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa
- https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167
- https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a
- https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88
- https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58
- https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed
- https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2023-52916
In the Linux kernel, the following vulnerability has been resolved: media: aspeed: Fix memory overwrite if timing is 1600x900 When capturing 1600x900, system could crash when system memory usage is tight. The way to reproduce this issue: 1. Use 1600x900 to display on host 2. Mount ISO through 'Virtual media' on OpenBMC's web 3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done 4. Open KVM on OpenBMC's web The size of macro block captured is 8x8. Therefore, we should make sure the height of src-buf is 8 aligned to fix this issue.
Modified: 2025-12-31
CVE-2023-52927
In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.
Modified: 2025-04-01
CVE-2023-52999
In the Linux kernel, the following vulnerability has been resolved:
net: fix UaF in netns ops registration error path
If net_assign_generic() fails, the current error path in ops_init() tries
to clear the gen pointer slot. Anyway, in such error path, the gen pointer
itself has not been modified yet, and the existing and accessed one is
smaller than the accessed index, causing an out-of-bounds error:
BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320
Write of size 8 at addr ffff888109124978 by task modprobe/1018
CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/12075708f2e77ee6a9f8bb2cf512c38be3099794
- https://git.kernel.org/stable/c/66689a72ba73575e76d4f6a8748d3fa2690ec1c4
- https://git.kernel.org/stable/c/71ab9c3e2253619136c31c89dbb2c69305cc89b1
- https://git.kernel.org/stable/c/ad0dfe9bcf0d78e699c7efb64c90ed062dc48bea
- https://git.kernel.org/stable/c/d4c008f3b7f7d4ffd311eb2dae5e75b3cbddacd0
- https://git.kernel.org/stable/c/ddd49cbbd4c1ceb38032018b589b44208e54f55e
Modified: 2025-10-30
CVE-2023-53012
In the Linux kernel, the following vulnerability has been resolved: thermal: core: call put_device() only after device_register() fails put_device() shouldn't be called before a prior call to device_register(). __thermal_cooling_device_register() doesn't follow that properly and needs fixing. Also thermal_cooling_device_destroy_sysfs() is getting called unnecessarily on few error paths. Fix all this by placing the calls at the right place. Based on initial work done by Caleb Connolly.
Modified: 2025-11-12
CVE-2023-53071
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: do not run mt76_unregister_device() on unregistered hw Trying to probe a mt7921e pci card without firmware results in a successful probe where ieee80211_register_hw hasn't been called. When removing the driver, ieee802111_unregister_hw is called unconditionally leading to a kernel NULL pointer dereference. Fix the issue running mt76_unregister_device routine just for registered hw.
Modified: 2025-11-25
CVE-2023-53149
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.
Modified: 2025-11-24
CVE-2023-53151
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing
writes, raid1 has cond_resched() while raid10 doesn't, and too many
writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for
raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
Call Trace:
- https://git.kernel.org/stable/c/00ecb6fa67c0f772290c5ea5ae8b46eefd503b83
- https://git.kernel.org/stable/c/010444623e7f4da6b4a4dd603a7da7469981e293
- https://git.kernel.org/stable/c/1d467e10507167eb6dc2c281a87675b731955d86
- https://git.kernel.org/stable/c/634daf6b2c81015cc5e28bf694a6a94a50c641cd
- https://git.kernel.org/stable/c/84a578961b2566e475bfa8740beaf0abcc781a6f
- https://git.kernel.org/stable/c/d0345f7c7dbc5d42e4e6f1db99c1c1879d7b0eb5
- https://git.kernel.org/stable/c/f45b2fa7678ab385299de345f7e85d05caea386b
- https://git.kernel.org/stable/c/fbf50184190d55f8717bd29aa9530c399be96f30
Modified: 2025-12-02
CVE-2023-53194
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add length check in indx_get_root
This adds a length check to guarantee the retrieved index root is legit.
[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320
[ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243
[ 162.460851]
[ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42
[ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 162.462609] Call Trace:
[ 162.462954]
Modified: 2026-01-14
CVE-2023-53218
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Make it so that a waiting process can be aborted When sendmsg() creates an rxrpc call, it queues it to wait for a connection and channel to be assigned and then waits before it can start shovelling data as the encrypted DATA packet content includes a summary of the connection parameters. However, sendmsg() may get interrupted before a connection gets assigned and further sendmsg() calls will fail with EBUSY until an assignment is made. Fix this so that the call can at least be aborted without failing on EBUSY. We have to be careful here as sendmsg() mustn't be allowed to start the call timer if the call doesn't yet have a connection assigned as an oops may follow shortly thereafter.
Modified: 2026-01-14
CVE-2023-53231
In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/
Modified: 2026-01-14
CVE-2023-53261
In the Linux kernel, the following vulnerability has been resolved: coresight: Fix memory leak in acpi_buffer->pointer There are memory leaks reported by kmemleak: ... unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] ... The ACPI buffer memory (buf.pointer) should be freed. But the buffer is also used after returning from acpi_get_dsd_graph(). Move the temporary variables buf to acpi_coresight_parse_graph(), and free it before the function return to prevent memory leak.
Modified: 2026-01-14
CVE-2023-53292
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NULL dereference on q->elevator by checking it with lock.
Modified: 2026-01-14
CVE-2023-53336
In the Linux kernel, the following vulnerability has been resolved: media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run sensor->adev is not set yet. So if either of the dev_warn() calls about unknown values are hit this will lead to a NULL pointer deref. Set sensor->adev earlier, with a borrowed ref to avoid making unrolling on errors harder, to fix this.
Modified: 2026-01-14
CVE-2023-53353
In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release() The memory manager IDR is currently destroyed when user releases the file descriptor. However, at this point the user context might be still held, and memory buffers might be still in use. Later on, calls to release those buffers will fail due to not finding their handles in the IDR, leading to a memory leak. To avoid this leak, split the IDR destruction from the memory manager fini, and postpone it to hpriv_release() when there is no user context and no buffers are used.
Modified: 2026-01-14
CVE-2023-53367
In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: fix mem leak in capture user mappings This commit fixes a memory leak caused when clearing the user_mappings info when a new context is opened immediately after user_mapping is captured and a hard reset is performed.
Modified: 2026-01-14
CVE-2023-53394
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix crash on regular rq reactivation When the regular rq is reactivated after the XSK socket is closed it could be reading stale cqes which eventually corrupts the rq. This leads to no more traffic being received on the regular rq and a crash on the next close or deactivation of the rq. Kal Cuttler Conely reported this issue as a crash on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is running. This patch flushes all cqes when during the rq flush. The cqe flushing is done in the reset state of the rq. mlx5e_rq_to_ready code is moved into the flush function to allow for this.
Modified: 2026-04-06
CVE-2023-53421
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") while the later one was introduced by commit f73316482977 ("blk-cgroup: reimplement basic IO stats using cgroup rstat"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.
- https://git.kernel.org/stable/c/0561aa6033dd181594116d705c41fc16e97161a2
- https://git.kernel.org/stable/c/3d2af77e31ade05ff7ccc3658c3635ec1bea0979
- https://git.kernel.org/stable/c/892faa76be894d324bf48b12a55c7af7be2bad83
- https://git.kernel.org/stable/c/abbce7f82613ea5eeefd0fc3c1c8e449b9cef2a2
- https://git.kernel.org/stable/c/b0d26283af612b9e0cc3188b0b88ad7fdea447e8
Modified: 2026-04-06
CVE-2023-53424
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: fix of_iomap memory leak Smatch reports: drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn: 'base' from of_iomap() not released on lines: 496. This problem was also found in linux-next. In mtk_clk_simple_probe(), base is not released when handling errors if clk_data is not existed, which may cause a leak. So free_base should be added here to release base.
Modified: 2026-01-14
CVE-2023-53429
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't check PageError in __extent_writepage __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.
Modified: 2026-01-14
CVE-2023-53447
In the Linux kernel, the following vulnerability has been resolved: f2fs: don't reset unchangable mount option in f2fs_remount() syzbot reports a bug as below: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942 Call Trace: lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691 __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline] _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300 __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100 f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116 f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664 f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838 vfs_fallocate+0x54b/0x6b0 fs/open.c:324 ksys_fallocate fs/open.c:347 [inline] __do_sys_fallocate fs/open.c:355 [inline] __se_sys_fallocate fs/open.c:353 [inline] __x64_sys_fallocate+0xbd/0x100 fs/open.c:353 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is race condition as below: - since it tries to remount rw filesystem, so that do_remount won't call sb_prepare_remount_readonly to block fallocate, there may be race condition in between remount and fallocate. - in f2fs_remount(), default_options() will reset mount option to default one, and then update it based on result of parse_options(), so there is a hole which race condition can happen. Thread A Thread B - f2fs_fill_super - parse_options - clear_opt(READ_EXTENT_CACHE) - f2fs_remount - default_options - set_opt(READ_EXTENT_CACHE) - f2fs_fallocate - f2fs_insert_range - f2fs_drop_extent_tree - __drop_extent_tree - __may_extent_tree - test_opt(READ_EXTENT_CACHE) return true - write_lock(&et->lock) access NULL pointer - parse_options - clear_opt(READ_EXTENT_CACHE)
Modified: 2026-01-16
CVE-2023-53460
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix memory leak in rtw_usb_probe() drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811 Fix this by modifying return to a goto statement.
Modified: 2026-01-20
CVE-2023-53486
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Enhance the attribute size check
This combines the overflow and boundary check so that all attribute size
will be properly examined while enumerating them.
[ 169.181521] BUG: KASAN: slab-out-of-bounds in run_unpack+0x2e3/0x570
[ 169.183161] Read of size 1 at addr ffff8880094b6240 by task mount/247
[ 169.184046]
[ 169.184925] CPU: 0 PID: 247 Comm: mount Not tainted 6.0.0-rc7+ #3
[ 169.185908] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 169.187066] Call Trace:
[ 169.187492]
Modified: 2026-01-23
CVE-2023-53491
In the Linux kernel, the following vulnerability has been resolved: start_kernel: Add __no_stack_protector function attribute Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it. Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.
Modified: 2026-04-06
CVE-2023-53510
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix handling of lrbp->cmd ufshcd_queuecommand() may be called two times in a row for a SCSI command before it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd. See also scsi_send_eh_cmnd(). This commit prevents that the following appears if a command times out: WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0
Modified: 2026-04-06
CVE-2023-53523
In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: fix time stamp counter initialization If the gs_usb device driver is unloaded (or unbound) before the interface is shut down, the USB stack first calls the struct usb_driver::disconnect and then the struct net_device_ops::ndo_stop callback. In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more RX'ed CAN frames are send from the USB device to the host. Later in gs_can_close() a reset control message is send to each CAN channel to remove the controller from the CAN bus. In this race window the USB device can still receive CAN frames from the bus and internally queue them to be send to the host. At least in the current version of the candlelight firmware, the queue of received CAN frames is not emptied during the reset command. After loading (or binding) the gs_usb driver, new URBs are submitted during the struct net_device_ops::ndo_open callback and the candlelight firmware starts sending its already queued CAN frames to the host. However, this scenario was not considered when implementing the hardware timestamp function. The cycle counter/time counter infrastructure is set up (gs_usb_timestamp_init()) after the USBs are submitted, resulting in a NULL pointer dereference if timecounter_cyc2time() (via the call chain: gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()) is called too early. Move the gs_usb_timestamp_init() function before the URBs are submitted to fix this problem. For a comprehensive solution, we need to consider gs_usb devices with more than 1 channel. The cycle counter/time counter infrastructure is setup per channel, but the RX URBs are per device. Once gs_can_open() of _a_ channel has been called, and URBs have been submitted, the gs_usb_receive_bulk_callback() can be called for _all_ available channels, even for channels that are not running, yet. As cycle counter/time counter has not set up, this will again lead to a NULL pointer dereference. Convert the cycle counter/time counter from a "per channel" to a "per device" functionality. Also set it up, before submitting any URBs to the device. Further in gs_usb_receive_bulk_callback(), don't process any URBs for not started CAN channels, only resubmit the URB.
Modified: 2026-01-23
CVE-2023-53529
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: Fix memory leak in rtw88_usb
Kmemleak shows the following leak arising from routine in the usb
probe routine:
unreferenced object 0xffff895cb29bba00 (size 512):
comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s)
hex dump (first 32 bytes):
77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0...
02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U......
backtrace:
[
Modified: 2026-03-25
CVE-2023-53538
In the Linux kernel, the following vulnerability has been resolved: btrfs: insert tree mod log move in push_node_left There is a fairly unlikely race condition in tree mod log rewind that can result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0 This occurs when logical inode resolution takes a tree mod log sequence number, and then while backref walking hits a rewind on a busy node which has the following sequence of tree mod log operations (numbers filled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 When this sequence gets applied via btrfs_tree_mod_log_rewind, it allocates a fresh rewind eb, and first inserts the correct key info for the 533 elements, then overwrites the first 456 of them, then decrements the count by 456 via the add ops, then rewinds the move by doing a memmove from 456:988->0:532. We have never written anything past 532, ---truncated---
Modified: 2026-03-25
CVE-2023-53545
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: unmap and remove csa_va properly
Root PD BO should be reserved before unmap and remove
a bo_va from VM otherwise lockdep will complain.
v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)
[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu]
[14616.937096] Call Trace:
[14616.937097]
Modified: 2026-03-21
CVE-2023-53574
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: delete timer and free skb queue when unloading Fix possible crash and memory leak on driver unload by deleting TX purge timer and freeing C2H queue in 'rtw_core_deinit()', shrink critical section in the latter by freeing COEX queue out of TX report lock scope.
Modified: 2026-02-03
CVE-2023-53627
In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list When freeing slots in function slot_complete_v3_hw(), it is possible that sas_dev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows: ==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task() ==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe() [ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5 [ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored [ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [ 7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [ 7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [ 7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [ 7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw] [ 7165.485247] sp : ffff00001d623bc0 [ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16: 0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [ 7165.567872] Call trace: [ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main] [ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas] [ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas] [ 7165.592082] scsi_error_handler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] ret_from_fork+0x10/0x18 [ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception To fix the issue, grab sas_dev lock when traversing the members of sas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoid concurrency of adding and deleting member. When ---truncated---
Modified: 2024-11-21
CVE-2023-6039
A use-after-free flaw was found in lan78xx_disconnect in drivers/net/usb/lan78xx.c in the network sub-component, net/usb/lan78xx in the Linux Kernel. This flaw allows a local attacker to crash the system when the LAN78XX USB device detaches.
- https://access.redhat.com/security/cve/CVE-2023-6039
- https://bugzilla.redhat.com/show_bug.cgi?id=2248755
- https://github.com/torvalds/linux/commit/1e7417c188d0a83fb385ba2dbe35fd2563f2b6f3
- https://access.redhat.com/security/cve/CVE-2023-6039
- https://bugzilla.redhat.com/show_bug.cgi?id=2248755
- https://github.com/torvalds/linux/commit/1e7417c188d0a83fb385ba2dbe35fd2563f2b6f3
Modified: 2026-02-18
CVE-2023-6546
A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2024:0930
- https://access.redhat.com/errata/RHSA-2024:0937
- https://access.redhat.com/errata/RHSA-2024:1018
- https://access.redhat.com/errata/RHSA-2024:1019
- https://access.redhat.com/errata/RHSA-2024:1055
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1253
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1607
- https://access.redhat.com/errata/RHSA-2024:1612
- https://access.redhat.com/errata/RHSA-2024:1614
- https://access.redhat.com/errata/RHSA-2024:2093
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2621
- https://access.redhat.com/errata/RHSA-2024:2697
- https://access.redhat.com/errata/RHSA-2024:4577
- https://access.redhat.com/errata/RHSA-2024:4729
- https://access.redhat.com/errata/RHSA-2024:4731
- https://access.redhat.com/errata/RHSA-2024:4970
- https://access.redhat.com/security/cve/CVE-2023-6546
- https://bugzilla.redhat.com/show_bug.cgi?id=2255498
- https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527
- http://www.openwall.com/lists/oss-security/2024/04/10/18
- http://www.openwall.com/lists/oss-security/2024/04/10/21
- http://www.openwall.com/lists/oss-security/2024/04/11/7
- http://www.openwall.com/lists/oss-security/2024/04/11/9
- http://www.openwall.com/lists/oss-security/2024/04/12/1
- http://www.openwall.com/lists/oss-security/2024/04/12/2
- http://www.openwall.com/lists/oss-security/2024/04/16/2
- http://www.openwall.com/lists/oss-security/2024/04/17/1
- https://access.redhat.com/errata/RHSA-2024:0930
- https://access.redhat.com/errata/RHSA-2024:0937
- https://access.redhat.com/errata/RHSA-2024:1018
- https://access.redhat.com/errata/RHSA-2024:1019
- https://access.redhat.com/errata/RHSA-2024:1055
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1253
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1607
- https://access.redhat.com/errata/RHSA-2024:1612
- https://access.redhat.com/errata/RHSA-2024:1614
- https://access.redhat.com/errata/RHSA-2024:2093
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2621
- https://access.redhat.com/errata/RHSA-2024:2697
- https://access.redhat.com/errata/RHSA-2024:4577
- https://access.redhat.com/errata/RHSA-2024:4729
- https://access.redhat.com/errata/RHSA-2024:4731
- https://access.redhat.com/security/cve/CVE-2023-6546
- https://bugzilla.redhat.com/show_bug.cgi?id=2255498
- https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527
Modified: 2024-11-21
CVE-2023-6560
An out-of-bounds memory access flaw was found in the io_uring SQ/CQ rings functionality in the Linux kernel. This issue could allow a local user to crash the system.
- http://packetstormsecurity.com/files/176405/io_uring-__io_uaddr_map-Dangerous-Multi-Page-Handling.html
- https://access.redhat.com/security/cve/CVE-2023-6560
- https://bugzilla.redhat.com/show_bug.cgi?id=2253249
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AU4NHBDEDLRW33O76Y6LFECEYNQET5GZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UCQIPFUQXKXRCH5Y4RP3C5NK4IHNBNVK/
- https://patchwork.kernel.org/project/io-uring/patch/20231130194633.649319-2-axboe@kernel.dk/
- http://packetstormsecurity.com/files/176405/io_uring-__io_uaddr_map-Dangerous-Multi-Page-Handling.html
- https://access.redhat.com/security/cve/CVE-2023-6560
- https://bugzilla.redhat.com/show_bug.cgi?id=2253249
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AU4NHBDEDLRW33O76Y6LFECEYNQET5GZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UCQIPFUQXKXRCH5Y4RP3C5NK4IHNBNVK/
- https://patchwork.kernel.org/project/io-uring/patch/20231130194633.649319-2-axboe@kernel.dk/
Modified: 2025-06-25
CVE-2023-6622
A null pointer dereference vulnerability was found in nft_dynset_init() in net/netfilter/nft_dynset.c in nf_tables in the Linux kernel. This issue may allow a local attacker with CAP_NET_ADMIN user privilege to trigger a denial of service.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-6622
- https://bugzilla.redhat.com/show_bug.cgi?id=2253632
- https://github.com/torvalds/linux/commit/3701cd390fd731ee7ae8b8006246c8db82c72bea
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-6622
- https://bugzilla.redhat.com/show_bug.cgi?id=2253632
- https://github.com/torvalds/linux/commit/3701cd390fd731ee7ae8b8006246c8db82c72bea
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AAOVK2F3ALGKYIQ5IOMAYEC2DGI7BWAW/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/G3AGDVE3KBLOOYBPISFDS74R4YAZEDAY/
Modified: 2024-11-21
CVE-2023-7192
A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:1188
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1367
- https://access.redhat.com/errata/RHSA-2024:1382
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-7192
- https://bugzilla.redhat.com/show_bug.cgi?id=2256279
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ac4893980bbe79ce383daf9a0885666a30fe4c83
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:1188
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1367
- https://access.redhat.com/errata/RHSA-2024:1382
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-7192
- https://bugzilla.redhat.com/show_bug.cgi?id=2256279
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ac4893980bbe79ce383daf9a0885666a30fe4c83
Modified: 2025-05-14
CVE-2024-0340
A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.
- https://access.redhat.com/errata/RHSA-2024:3618
- https://access.redhat.com/errata/RHSA-2024:3627
- https://access.redhat.com/errata/RHSA-2024:9315
- https://access.redhat.com/errata/RHSA-2025:7526
- https://access.redhat.com/security/cve/CVE-2024-0340
- https://bugzilla.redhat.com/show_bug.cgi?id=2257406
- https://lore.kernel.org/lkml/5kn47peabxjrptkqa6dwtyus35ahf4pcj4qm4pumse33kxqpjw@mec4se5relrc/T/
- https://access.redhat.com/errata/RHSA-2024:3618
- https://access.redhat.com/errata/RHSA-2024:3627
- https://access.redhat.com/security/cve/CVE-2024-0340
- https://bugzilla.redhat.com/show_bug.cgi?id=2257406
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lore.kernel.org/lkml/5kn47peabxjrptkqa6dwtyus35ahf4pcj4qm4pumse33kxqpjw@mec4se5relrc/T/
Modified: 2024-11-21
CVE-2024-0639
A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
- https://access.redhat.com/security/cve/CVE-2024-0639
- https://bugzilla.redhat.com/show_bug.cgi?id=2258754
- https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a
- https://access.redhat.com/security/cve/CVE-2024-0639
- https://bugzilla.redhat.com/show_bug.cgi?id=2258754
- https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a
Modified: 2024-11-21
CVE-2024-0641
A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
- https://access.redhat.com/security/cve/CVE-2024-0641
- https://bugzilla.redhat.com/show_bug.cgi?id=2258757
- https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5
- https://access.redhat.com/security/cve/CVE-2024-0641
- https://bugzilla.redhat.com/show_bug.cgi?id=2258757
- https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5
Modified: 2024-11-21
CVE-2024-0775
A use-after-free flaw was found in the __ext4_remount in fs/ext4/super.c in ext4 in the Linux kernel. This flaw allows a local user to cause an information leak problem while freeing the old quota file names before a potential failure, leading to a use-after-free.
- https://access.redhat.com/security/cve/CVE-2024-0775
- https://bugzilla.redhat.com/show_bug.cgi?id=2259414
- https://scm.linefinity.com/common/linux-stable/commit/4c0b4818b1f636bc96359f7817a2d8bab6370162
- https://access.redhat.com/security/cve/CVE-2024-0775
- https://bugzilla.redhat.com/show_bug.cgi?id=2259414
- https://scm.linefinity.com/common/linux-stable/commit/4c0b4818b1f636bc96359f7817a2d8bab6370162
Modified: 2024-11-21
CVE-2024-0841
A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2024-0841
- https://bugzilla.redhat.com/show_bug.cgi?id=2256490
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2024-0841
- https://bugzilla.redhat.com/show_bug.cgi?id=2256490
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-1312
A use-after-free flaw was found in the Linux kernel's Memory Management subsystem when a user wins two races at the same time with a fail in the mas_prev_slot function. This issue could allow a local user to crash the system.
- https://access.redhat.com/security/cve/CVE-2024-1312
- https://bugzilla.redhat.com/show_bug.cgi?id=2225569
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/memory.c?h=v6.8-rc3&id=657b5146955eba331e01b9a6ae89ce2e716ba306
- https://access.redhat.com/security/cve/CVE-2024-1312
- https://bugzilla.redhat.com/show_bug.cgi?id=2225569
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/memory.c?h=v6.8-rc3&id=657b5146955eba331e01b9a6ae89ce2e716ba306
Modified: 2025-08-15
CVE-2024-21803
Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows Local Execution of Code. This vulnerability is associated with program files https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects Linux kernel: from v2.6.12-rc2 before v6.8-rc1.
Modified: 2024-11-21
CVE-2024-22386
A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
Modified: 2025-06-05
CVE-2024-22705
An issue was discovered in ksmbd in the Linux kernel before 6.6.10. smb2_get_data_area_len in fs/smb/server/smb2misc.c can cause an smb_strndup_from_utf16 out-of-bounds access because the relationship between Name data and CreateContexts data is mishandled.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.10
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d10c77873ba1e9e6b91905018e29e196fd5f863d
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.10
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d10c77873ba1e9e6b91905018e29e196fd5f863d
Modified: 2024-11-21
CVE-2024-23196
A race condition was found in the Linux kernel's sound/hda device driver in snd_hdac_regmap_sync() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
Modified: 2025-11-03
CVE-2024-24855
A race condition was found in the Linux kernel's scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
Modified: 2025-05-07
CVE-2024-25744
In the Linux kernel before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point. This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/mem_encrypt_amd.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.7
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b82a8dbd3d2f4563156f7150c6f2ecab6e960b30
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.7
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b82a8dbd3d2f4563156f7150c6f2ecab6e960b30
- https://security.netapp.com/advisory/ntap-20241115-0006/
Modified: 2025-10-01
CVE-2024-26581
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just added in this transactions, skip end interval elements that are not yet active.
- https://git.kernel.org/stable/c/10e9cb39313627f2eae4cd70c4b742074e998fd8
- https://git.kernel.org/stable/c/1296c110c5a0b45a8fcf58e7d18bc5da61a565cb
- https://git.kernel.org/stable/c/2bab493a5624444ec6e648ad0d55a362bcb4c003
- https://git.kernel.org/stable/c/4cee42fcf54fec46b344681e7cc4f234bb22f85a
- https://git.kernel.org/stable/c/60c0c230c6f046da536d3df8b39a20b9a9fd6af0
- https://git.kernel.org/stable/c/6eb14441f10602fa1cf691da9d685718b68b78a9
- https://git.kernel.org/stable/c/b734f7a47aeb32a5ba298e4ccc16bb0c52b6dbf7
- https://git.kernel.org/stable/c/c60d252949caf9aba537525195edae6bbabc35eb
- https://git.kernel.org/stable/c/10e9cb39313627f2eae4cd70c4b742074e998fd8
- https://git.kernel.org/stable/c/1296c110c5a0b45a8fcf58e7d18bc5da61a565cb
- https://git.kernel.org/stable/c/2bab493a5624444ec6e648ad0d55a362bcb4c003
- https://git.kernel.org/stable/c/4cee42fcf54fec46b344681e7cc4f234bb22f85a
- https://git.kernel.org/stable/c/60c0c230c6f046da536d3df8b39a20b9a9fd6af0
- https://git.kernel.org/stable/c/6eb14441f10602fa1cf691da9d685718b68b78a9
- https://git.kernel.org/stable/c/b734f7a47aeb32a5ba298e4ccc16bb0c52b6dbf7
- https://git.kernel.org/stable/c/c60d252949caf9aba537525195edae6bbabc35eb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2024-26582
In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when we try to read from the partially-read skb.
- https://git.kernel.org/stable/c/20b4ed034872b4d024b26e2bc1092c3f80e5db96
- https://git.kernel.org/stable/c/32b55c5ff9103b8508c1e04bfa5a08c64e7a925f
- https://git.kernel.org/stable/c/754c9bab77a1b895b97bd99d754403c505bc79df
- https://git.kernel.org/stable/c/d684763534b969cca1022e2a28645c7cc91f7fa5
- https://git.kernel.org/stable/c/20b4ed034872b4d024b26e2bc1092c3f80e5db96
- https://git.kernel.org/stable/c/32b55c5ff9103b8508c1e04bfa5a08c64e7a925f
- https://git.kernel.org/stable/c/754c9bab77a1b895b97bd99d754403c505bc79df
- https://git.kernel.org/stable/c/d684763534b969cca1022e2a28645c7cc91f7fa5
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-11-04
CVE-2024-26583
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.
- https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33
- https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01
- https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a
- https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d
- https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7
- https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33
- https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01
- https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a
- https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d
- https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-11-04
CVE-2024-26584
In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.
- https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754
- https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368
- https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3
- https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694
- https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72
- https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754
- https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368
- https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3
- https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694
- https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-11-04
CVE-2024-26585
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.
- https://git.kernel.org/stable/c/196f198ca6fce04ba6ce262f5a0e4d567d7d219d
- https://git.kernel.org/stable/c/6db22d6c7a6dc914b12c0469b94eb639b6a8a146
- https://git.kernel.org/stable/c/dd32621f19243f89ce830919496a5dcc2158aa33
- https://git.kernel.org/stable/c/e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb
- https://git.kernel.org/stable/c/e327ed60bff4a991cd7a709c47c4f0c5b4a4fd57
- https://git.kernel.org/stable/c/196f198ca6fce04ba6ce262f5a0e4d567d7d219d
- https://git.kernel.org/stable/c/6db22d6c7a6dc914b12c0469b94eb639b6a8a146
- https://git.kernel.org/stable/c/e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb
- https://git.kernel.org/stable/c/e327ed60bff4a991cd7a709c47c4f0c5b4a4fd57
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2024-11-21
CVE-2024-26586
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b
- https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62
- https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15
- https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706
- https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182
- https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819
- https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383
- https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62
- https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15
- https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706
- https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182
- https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819
- https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2024-26587
In the Linux kernel, the following vulnerability has been resolved:
net: netdevsim: don't try to destroy PHC on VFs
PHC gets initialized in nsim_init_netdevsim(), which
is only called if (nsim_dev_port_is_pf()).
Create a counterpart of nsim_init_netdevsim() and
move the mock_phc_destroy() there.
This fixes a crash trying to destroy netdevsim with
VFs instantiated, as caught by running the devlink.sh test:
BUG: kernel NULL pointer dereference, address: 00000000000000b8
RIP: 0010:mock_phc_destroy+0xd/0x30
Call Trace:
- https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca
- https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588
- https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda
- https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca
- https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588
- https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda
Modified: 2025-04-22
CVE-2024-26590
In the Linux kernel, the following vulnerability has been resolved: erofs: fix inconsistent per-file compression format EROFS can select compression algorithms on a per-file basis, and each per-file compression algorithm needs to be marked in the on-disk superblock for initialization. However, syzkaller can generate inconsistent crafted images that use an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA algorithmtype even it's not set in `sbi->available_compr_algs`. This can lead to an unexpected "BUG: kernel NULL pointer dereference" if the corresponding decompressor isn't built-in. Fix this by checking against `sbi->available_compr_algs` for each m_algorithmformat request. Incorrect !erofs_sb_has_compr_cfgs preset bitmap is now fixed together since it was harmless previously.
- https://git.kernel.org/stable/c/118a8cf504d7dfa519562d000f423ee3ca75d2c4
- https://git.kernel.org/stable/c/47467e04816cb297905c0f09bc2d11ef865942d9
- https://git.kernel.org/stable/c/823ba1d2106019ddf195287ba53057aee33cf724
- https://git.kernel.org/stable/c/eed24b816e50c6cd18cbee0ff0d7218c8fced199
- https://git.kernel.org/stable/c/118a8cf504d7dfa519562d000f423ee3ca75d2c4
- https://git.kernel.org/stable/c/47467e04816cb297905c0f09bc2d11ef865942d9
- https://git.kernel.org/stable/c/823ba1d2106019ddf195287ba53057aee33cf724
- https://git.kernel.org/stable/c/eed24b816e50c6cd18cbee0ff0d7218c8fced199
Modified: 2025-11-04
CVE-2024-26593
In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read.
- https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a
- https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c
- https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2
- https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9
- https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f
- https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21
- https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7
- https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a
- https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c
- https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2
- https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9
- https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f
- https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21
- https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-11-03
CVE-2024-26595
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b
- https://git.kernel.org/stable/c/75fa2d8b3c0175b519c99ace54ab8474cfd0077e
- https://git.kernel.org/stable/c/817840d125a370626895df269c50c923b79b0a39
- https://git.kernel.org/stable/c/d0a1efe417c97a1e9b914056ee6b86f1ef75fe1f
- https://git.kernel.org/stable/c/efeb7dfea8ee10cdec11b6b6ba4e405edbe75809
- https://git.kernel.org/stable/c/817840d125a370626895df269c50c923b79b0a39
- https://git.kernel.org/stable/c/d0a1efe417c97a1e9b914056ee6b86f1ef75fe1f
- https://git.kernel.org/stable/c/efeb7dfea8ee10cdec11b6b6ba4e405edbe75809
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2024-11-21
CVE-2024-26600
In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let's fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL.
- https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4
- https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4
- https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1
- https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b
- https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d
- https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5
- https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462
- https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3
- https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4
- https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4
- https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1
- https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b
- https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d
- https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5
- https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462
- https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26601
In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case.
- https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581
- https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4
- https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a
- https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326
- https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e
- https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb
- https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581
- https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4
- https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a
- https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326
- https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e
- https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-26602
In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.
- https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265
- https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a
- https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3
- https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee
- https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23
- https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71
- https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea
- https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6
- https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265
- https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a
- https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3
- https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee
- https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23
- https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71
- https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea
- https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-26603
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ]
- https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996
- https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda
- https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a
- https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2
- https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835
- https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996
- https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda
- https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a
- https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2
- https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-11-04
CVE-2024-26606
In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work.
- https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61
- https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc
- https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769
- https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69
- https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7
- https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc
- https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68
- https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac
- https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61
- https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc
- https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769
- https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69
- https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7
- https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc
- https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68
- https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/
Modified: 2025-11-04
CVE-2024-26622
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems.
- https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f
- https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815
- https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824
- https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711
- https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc
- https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee
- https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f
- https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815
- https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824
- https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711
- https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc
- https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IVVYSTEVMPYGF6GDSOD44MUXZXAZHOHB/
Modified: 2025-12-23
CVE-2024-26629
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids. If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded). When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe. For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'.
- https://git.kernel.org/stable/c/10d75984495f7fe62152c3b0dbfa3f0a6b739c9b
- https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098
- https://git.kernel.org/stable/c/99fb654d01dc3f08b5905c663ad6c89a9d83302f
- https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b
- https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
- https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
- https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd
- https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098
- https://git.kernel.org/stable/c/99fb654d01dc3f08b5905c663ad6c89a9d83302f
- https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b
- https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
- https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
- https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd
Modified: 2025-01-07
CVE-2024-26647
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix late derefrence 'dsc' check in 'link_set_dsc_pps_packet()' In link_set_dsc_pps_packet(), 'struct display_stream_compressor *dsc' was dereferenced in a DC_LOGGER_INIT(dsc->ctx->logger); before the 'dsc' NULL pointer check. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:905 link_set_dsc_pps_packet() warn: variable dereferenced before check 'dsc' (see line 903)
- https://git.kernel.org/stable/c/3bb9b1f958c3d986ed90a3ff009f1e77e9553207
- https://git.kernel.org/stable/c/6aa5ede6665122f4c8abce3c6eba06b49e54d25c
- https://git.kernel.org/stable/c/cf656fc7276e5b3709a81bc9d9639459be2b2647
- https://git.kernel.org/stable/c/3bb9b1f958c3d986ed90a3ff009f1e77e9553207
- https://git.kernel.org/stable/c/6aa5ede6665122f4c8abce3c6eba06b49e54d25c
- https://git.kernel.org/stable/c/cf656fc7276e5b3709a81bc9d9639459be2b2647
Modified: 2025-04-08
CVE-2024-26648
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix variable deferencing before NULL check in edp_setup_replay() In edp_setup_replay(), 'struct dc *dc' & 'struct dmub_replay *replay' was dereferenced before the pointer 'link' & 'replay' NULL check. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:947 edp_setup_replay() warn: variable dereferenced before check 'link' (see line 933)
- https://git.kernel.org/stable/c/22ae604aea14756954e1c00ae653e34d2afd2935
- https://git.kernel.org/stable/c/7073934f5d73f8b53308963cee36f0d389ea857c
- https://git.kernel.org/stable/c/c02d257c654191ecda1dc1af6875d527e85310e7
- https://git.kernel.org/stable/c/22ae604aea14756954e1c00ae653e34d2afd2935
- https://git.kernel.org/stable/c/7073934f5d73f8b53308963cee36f0d389ea857c
- https://git.kernel.org/stable/c/c02d257c654191ecda1dc1af6875d527e85310e7
Modified: 2025-11-04
CVE-2024-26651
In the Linux kernel, the following vulnerability has been resolved: sr9800: Add check for usbnet_get_endpoints Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error.
- https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61
- https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581
- https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7
- https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009
- https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a
- https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384
- https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028
- https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f
- https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774
- https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61
- https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581
- https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7
- https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009
- https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a
- https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384
- https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028
- https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f
- https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AXURWFKAKFEIUBN7RTCXI7GZYAHXNBX5/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SI2D7K2T6QCWALKLYEWZ22P4UXMEBCGB/
Modified: 2025-03-17
CVE-2024-26659
In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.
- https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c
- https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3
- https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134
- https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e
- https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811
- https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97
- https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c
- https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3
- https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134
- https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e
- https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811
- https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-03
CVE-2024-26660
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN301 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn301_stream_encoder_create reported by Smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5
- https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054
- https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2
- https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738
- https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d
- https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a
- https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054
- https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2
- https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738
- https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d
- https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a
Modified: 2025-04-08
CVE-2024-26661
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()' In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;" pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to ensure the tg is not NULL.
- https://git.kernel.org/stable/c/39f24c08363af1cd945abad84e3c87fd3e3c845a
- https://git.kernel.org/stable/c/3f3c237a706580326d3b7a1b97697e5031ca4667
- https://git.kernel.org/stable/c/66951d98d9bf45ba25acf37fe0747253fafdf298
- https://git.kernel.org/stable/c/39f24c08363af1cd945abad84e3c87fd3e3c845a
- https://git.kernel.org/stable/c/3f3c237a706580326d3b7a1b97697e5031ca4667
- https://git.kernel.org/stable/c/66951d98d9bf45ba25acf37fe0747253fafdf298
Modified: 2025-04-08
CVE-2024-26662
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()' 'panel_cntl' structure used to control the display panel could be null, dereferencing it could lead to a null pointer access. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)
- https://git.kernel.org/stable/c/0c863cab0e9173f8b6c7bc328bee3b8625f131b5
- https://git.kernel.org/stable/c/2e150ccea13129eb048679114808eb9770443e4d
- https://git.kernel.org/stable/c/e96fddb32931d007db12b1fce9b5e8e4c080401b
- https://git.kernel.org/stable/c/0c863cab0e9173f8b6c7bc328bee3b8625f131b5
- https://git.kernel.org/stable/c/2e150ccea13129eb048679114808eb9770443e4d
- https://git.kernel.org/stable/c/e96fddb32931d007db12b1fce9b5e8e4c080401b
Modified: 2025-01-07
CVE-2024-26663
In the Linux kernel, the following vulnerability has been resolved:
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
syzbot reported the following general protection fault [1]:
general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
- https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87
- https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95
- https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1
- https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87
- https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6
- https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f
- https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59
- https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12
- https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87
- https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95
- https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1
- https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87
- https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6
- https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f
- https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59
- https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26664
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.
- https://git.kernel.org/stable/c/1eb74c00c9c3b13cb65e508c5d5a2f11afb96b8b
- https://git.kernel.org/stable/c/3a7753bda55985dc26fae17795cb10d825453ad1
- https://git.kernel.org/stable/c/4e440abc894585a34c2904a32cd54af1742311b3
- https://git.kernel.org/stable/c/853a6503c586a71abf27e60a7f8c4fb28092976d
- https://git.kernel.org/stable/c/93f0f4e846fcb682c3ec436e3b2e30e5a3a8ee6a
- https://git.kernel.org/stable/c/9bce69419271eb8b2b3ab467387cb59c99d80deb
- https://git.kernel.org/stable/c/a16afec8e83c56b14a4a73d2e3fb8eec3a8a057e
- https://git.kernel.org/stable/c/f0da068c75c20ffc5ba28243ff577531dc2af1fd
- https://git.kernel.org/stable/c/1eb74c00c9c3b13cb65e508c5d5a2f11afb96b8b
- https://git.kernel.org/stable/c/3a7753bda55985dc26fae17795cb10d825453ad1
- https://git.kernel.org/stable/c/4e440abc894585a34c2904a32cd54af1742311b3
- https://git.kernel.org/stable/c/853a6503c586a71abf27e60a7f8c4fb28092976d
- https://git.kernel.org/stable/c/93f0f4e846fcb682c3ec436e3b2e30e5a3a8ee6a
- https://git.kernel.org/stable/c/9bce69419271eb8b2b3ab467387cb59c99d80deb
- https://git.kernel.org/stable/c/a16afec8e83c56b14a4a73d2e3fb8eec3a8a057e
- https://git.kernel.org/stable/c/f0da068c75c20ffc5ba28243ff577531dc2af1fd
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-03
CVE-2024-26665
In the Linux kernel, the following vulnerability has been resolved: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs.
- https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1
- https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab
- https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06
- https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a
- https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732
- https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d
- https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1
- https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab
- https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06
- https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a
- https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732
- https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26667
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output") introduced a smatch warning about another conditional block in dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it. Patchwork: https://patchwork.freedesktop.org/patch/574878/
- https://git.kernel.org/stable/c/79592a6e7bdc1d05460c95f891f5e5263a107af8
- https://git.kernel.org/stable/c/7f3d03c48b1eb6bc45ab20ca98b8b11be25f9f52
- https://git.kernel.org/stable/c/eb4f56f3ff5799ca754ae6d811803a63fe25a4a2
- https://git.kernel.org/stable/c/fb8bfc6ea3cd8c5ac3d35711d064e2f6646aec17
- https://git.kernel.org/stable/c/79592a6e7bdc1d05460c95f891f5e5263a107af8
- https://git.kernel.org/stable/c/7f3d03c48b1eb6bc45ab20ca98b8b11be25f9f52
- https://git.kernel.org/stable/c/eb4f56f3ff5799ca754ae6d811803a63fe25a4a2
- https://git.kernel.org/stable/c/fb8bfc6ea3cd8c5ac3d35711d064e2f6646aec17
Modified: 2025-03-17
CVE-2024-26669
In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: Fix chain template offload
When a qdisc is deleted from a net device the stack instructs the
underlying driver to remove its flow offload callback from the
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
then continues to replay the removal of the filters in the block for
this driver by iterating over the chains in the block and invoking the
'reoffload' operation of the classifier being used. In turn, the
classifier in its 'reoffload' operation prepares and emits a
'FLOW_CLS_DESTROY' command for each filter.
However, the stack does not do the same for chain templates and the
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
a qdisc is deleted. This results in a memory leak [1] which can be
reproduced using [2].
Fix by introducing a 'tmplt_reoffload' operation and have the stack
invoke it with the appropriate arguments as part of the replay.
Implement the operation in the sole classifier that supports chain
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
command based on whether a flow offload callback is being bound to a
filter block or being unbound from one.
As far as I can tell, the issue happens since cited commit which
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
in __tcf_block_put(). The order cannot be reversed as the filter block
is expected to be freed after flushing all the chains.
[1]
unreferenced object 0xffff888107e28800 (size 2048):
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
hex dump (first 32 bytes):
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
backtrace:
[
- https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8
- https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97
- https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01
- https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8
- https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97
- https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01
Modified: 2025-03-17
CVE-2024-26675
In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
- https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8
- https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16
- https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed
- https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982
- https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3
- https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719
- https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b
- https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8
- https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8
- https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16
- https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed
- https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982
- https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3
- https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719
- https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b
- https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-05-07
CVE-2024-26676
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
syzbot reported a warning [0] in __unix_gc() with a repro, which
creates a socketpair and sends one socket's fd to itself using the
peer.
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}],
msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, cmsg_data=[3]}],
msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1
This forms a self-cyclic reference that GC should finally untangle
but does not due to lack of MSG_OOB handling, resulting in memory
leak.
Recently, commit 11498715f266 ("af_unix: Remove io_uring code for
GC.") removed io_uring's dead code in GC and revealed the problem.
The code was executed at the final stage of GC and unconditionally
moved all GC candidates from gc_candidates to gc_inflight_list.
That papered over the reported problem by always making the following
WARN_ON_ONCE(!list_empty(&gc_candidates)) false.
The problem has been there since commit 2aab4b969002 ("af_unix: fix
struct pid leaks in OOB support") added full scm support for MSG_OOB
while fixing another bug.
To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb
if the socket still exists in gc_candidates after purging collected skb.
Then, we need to set NULL to oob_skb before calling kfree_skb() because
it calls last fput() and triggers unix_release_sock(), where we call
duplicate kfree_skb(u->oob_skb) if not NULL.
Note that the leaked socket remained being linked to a global list, so
kmemleak also could not detect it. We need to check /proc/net/protocol
to notice the unfreed socket.
[0]:
WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345
Modules linked in:
CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: events_unbound __unix_gc
RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345
Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8
RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e
RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30
RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66
R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000
R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d
- https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668
- https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140
- https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276
- https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b
- https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d
- https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668
- https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140
- https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276
- https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b
Modified: 2025-03-17
CVE-2024-26677
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.
- https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2
- https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae
- https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef
- https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2
- https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae
- https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef
Modified: 2025-03-17
CVE-2024-26679
In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning.
- https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830
- https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41
- https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2
- https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299
- https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd
- https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b
- https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40
- https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd
- https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830
- https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41
- https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2
- https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299
- https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd
- https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b
- https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40
- https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26680
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: Fix DMA mapping for PTP hwts ring
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
for PTP HWTS ring but then generic aq_ring_free() does not take this
into account.
Create and use a specific function to free HWTS ring to fix this
issue.
Trace:
[ 215.351607] ------------[ cut here ]------------
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
...
[ 215.581176] Call Trace:
[ 215.583632]
- https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56
- https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887
- https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12
- https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1
- https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56
- https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887
- https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12
- https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1
Modified: 2025-03-17
CVE-2024-26681
In the Linux kernel, the following vulnerability has been resolved:
netdevsim: avoid potential loop in nsim_dev_trap_report_work()
Many syzbot reports include the following trace [1]
If nsim_dev_trap_report_work() can not grab the mutex,
it should rearm itself at least one jiffie later.
[1]
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Workqueue: events nsim_dev_trap_report_work
RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline]
RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline]
RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline]
RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline]
RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]
RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189
Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00
RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046
RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3
RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0
RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e
R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002
R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0193e0660cc6689c794794b471492923cfd7bfbc
- https://git.kernel.org/stable/c/6eecddd9c3c8d6e3a097531cdc6d500335b35e46
- https://git.kernel.org/stable/c/ba5e1272142d051dcc57ca1d3225ad8a089f9858
- https://git.kernel.org/stable/c/d91964cdada76740811b7c621239f9c407820dbc
- https://git.kernel.org/stable/c/0193e0660cc6689c794794b471492923cfd7bfbc
- https://git.kernel.org/stable/c/6eecddd9c3c8d6e3a097531cdc6d500335b35e46
- https://git.kernel.org/stable/c/ba5e1272142d051dcc57ca1d3225ad8a089f9858
- https://git.kernel.org/stable/c/d91964cdada76740811b7c621239f9c407820dbc
Modified: 2025-03-17
CVE-2024-26684
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
- https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37
- https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2
- https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3
- https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89
- https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf
- https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591
- https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00
- https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37
- https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2
- https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3
- https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89
- https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf
- https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591
- https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26685
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential bug in end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel. The use of async_write for segment summary buffers has already been removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer.
- https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803
- https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b
- https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff
- https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab
- https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8
- https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928
- https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd
- https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596
- https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803
- https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b
- https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff
- https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab
- https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8
- https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928
- https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd
- https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26687
In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated---
- https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd
- https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4
- https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5
- https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44
- https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b
- https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3
- https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9
- https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd
- https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4
- https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5
- https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44
- https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b
- https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3
- https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-07
CVE-2024-26688
In the Linux kernel, the following vulnerability has been resolved:
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
When configuring a hugetlb filesystem via the fsconfig() syscall, there is
a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
is non valid.
E.g: Taking the following steps:
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
with NULL, losing its previous value, and we will print an error:
...
...
case Opt_pagesize:
ps = memparse(param->string, &rest);
ctx->hstate = h;
if (!ctx->hstate) {
pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
return -EINVAL;
}
return 0;
...
...
This is a problem because later on, we will dereference ctxt->hstate in
hugetlbfs_fill_super()
...
...
sb->s_blocksize = huge_page_size(ctx->hstate);
...
...
Causing below Oops.
Fix this by replacing cxt->hstate value only when then pagesize is known
to be valid.
kernel: hugetlbfs: Unsupported page size 0 MB
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x0000) - not-present page
kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
kernel: Oops: 0000 [#1] PREEMPT SMP PTI
kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
kernel: Call Trace:
kernel:
- https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274
- https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557
- https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff
- https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9
- https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498
- https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773
- https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39
- https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274
- https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557
- https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff
- https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9
- https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498
- https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773
- https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26689
In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed. In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.
- https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77
- https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc
- https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214
- https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7
- https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef
- https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139
- https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77
- https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc
- https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214
- https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7
- https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef
- https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26691
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data.
- https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc
- https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc
- https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228
- https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc
- https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc
- https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228
Modified: 2025-01-07
CVE-2024-26695
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked
The SEV platform device can be shutdown with a null psp_master,
e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN:
[ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)
[ 137.162647] ccp 0000:23:00.1: no command queues available
[ 137.170598] ccp 0000:23:00.1: sev enabled
[ 137.174645] ccp 0000:23:00.1: psp enabled
[ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI
[ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]
[ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311
[ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180
[ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c
[ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216
[ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e
[ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0
[ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66
[ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28
[ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8
[ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000
[ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0
[ 137.182693] Call Trace:
[ 137.182693]
- https://git.kernel.org/stable/c/58054faf3bd29cd0b949b77efcb6157f66f401ed
- https://git.kernel.org/stable/c/7535ec350a5f09b5756a7607f5582913f21200f4
- https://git.kernel.org/stable/c/8731fe001a60581794ed9cf65da8cd304846a6fb
- https://git.kernel.org/stable/c/88aa493f393d2ee38ac140e1f6ac1881346e85d4
- https://git.kernel.org/stable/c/b5909f197f3b26aebedca7d8ac7b688fd993a266
- https://git.kernel.org/stable/c/ccb88e9549e7cfd8bcd511c538f437e20026e983
- https://git.kernel.org/stable/c/58054faf3bd29cd0b949b77efcb6157f66f401ed
- https://git.kernel.org/stable/c/7535ec350a5f09b5756a7607f5582913f21200f4
- https://git.kernel.org/stable/c/8731fe001a60581794ed9cf65da8cd304846a6fb
- https://git.kernel.org/stable/c/88aa493f393d2ee38ac140e1f6ac1881346e85d4
- https://git.kernel.org/stable/c/b5909f197f3b26aebedca7d8ac7b688fd993a266
- https://git.kernel.org/stable/c/ccb88e9549e7cfd8bcd511c538f437e20026e983
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26696
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.
- https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e
- https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534
- https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f
- https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32
- https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46
- https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6
- https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d
- https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28
- https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e
- https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534
- https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f
- https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32
- https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46
- https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6
- https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d
- https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26697
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page.
- https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5
- https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9
- https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d
- https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa
- https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65
- https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1
- https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3
- https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba
- https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5
- https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9
- https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d
- https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa
- https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65
- https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1
- https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3
- https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26698
In the Linux kernel, the following vulnerability has been resolved:
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
VMBus channel"), napi_disable was getting called for all channels,
including all subchannels without confirming if they are enabled or not.
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
has finished running but nvdev->subchan_work has not started yet.
netvsc_subchan_work() -> rndis_set_subchannel() has not created the
sub-channels and because of that netvsc_sc_open() is not running.
netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
netvsc_subchan_work did not run.
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
opposite.
Now during netvsc_device_remove(), when napi_disable is called for those
subchannels, napi_disable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napi_disable() is not
getting called for non-enabled NAPI struct.
But netif_napi_del() is still necessary for these non-enabled NAPI struct
for cleanup purpose.
Call trace:
[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
[ 654.568030] Call Trace:
[ 654.571221]
- https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd
- https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b
- https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518
- https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a
- https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f
- https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11
- https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd
- https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b
- https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518
- https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a
- https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f
- https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-07
CVE-2024-26700
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix MST Null Ptr for RV
The change try to fix below error specific to RV platform:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
Call Trace:
- https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238
- https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f
- https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5
- https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57
- https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238
- https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f
- https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5
- https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57
Modified: 2025-04-08
CVE-2024-26702
In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC Recently, we encounter kernel crash in function rm3100_common_probe caused by out of bound access of array rm3100_samp_rates (because of underlying hardware failures). Add boundary check to prevent out of bound access.
- https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513
- https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01
- https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56
- https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1
- https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481
- https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e
- https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60
- https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513
- https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01
- https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56
- https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1
- https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481
- https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e
- https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26704
In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue.
- https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1
- https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f
- https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4
- https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6
- https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1
- https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1
- https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71
- https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537
- https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1
- https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f
- https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4
- https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6
- https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1
- https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1
- https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71
- https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26706
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer.
- https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592
- https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831
- https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003
- https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2
- https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592
- https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831
- https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003
- https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2
Modified: 2025-03-17
CVE-2024-26707
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
Syzkaller reported [1] hitting a warning after failing to allocate
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
not help much in this case, it might be prudent to switch to
netdev_warn_once(). At the very least it will suppress syzkaller
reports such as [1].
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
for similar reasons.
[1]
HSR: Could not send supervision frame
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
...
Call Trace:
- https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb
- https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e
- https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51
- https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a
- https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8
- https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0
- https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb
- https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e
- https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51
- https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a
- https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8
- https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2024-26710
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Limit KASAN thread size increase to 32KB KASAN is seen to increase stack usage, to the point that it was reported to lead to stack overflow on some 32-bit machines (see link). To avoid overflows the stack size was doubled for KASAN builds in commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with KASAN"). However with a 32KB stack size to begin with, the doubling leads to a 64KB stack, which causes build errors: arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff) Although the asm could be reworked, in practice a 32KB stack seems sufficient even for KASAN builds - the additional usage seems to be in the 2-3KB range for a 64-bit KASAN build. So only increase the stack for KASAN if the stack size is < 32KB.
- https://git.kernel.org/stable/c/4cc31fa07445879a13750cb061bb8c2654975fcb
- https://git.kernel.org/stable/c/b29b16bd836a838b7690f80e37f8376414c74cbe
- https://git.kernel.org/stable/c/f1acb109505d983779bbb7e20a1ee6244d2b5736
- https://git.kernel.org/stable/c/f9a4c401bf4c5af3437ad221c0a5880a518068d4
- https://git.kernel.org/stable/c/4297217bcf1f0948a19c2bacc6b68d92e7778ad9
- https://git.kernel.org/stable/c/4cc31fa07445879a13750cb061bb8c2654975fcb
- https://git.kernel.org/stable/c/b29b16bd836a838b7690f80e37f8376414c74cbe
- https://git.kernel.org/stable/c/f1acb109505d983779bbb7e20a1ee6244d2b5736
Modified: 2025-04-08
CVE-2024-26712
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address.
- https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe
- https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058
- https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882
- https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6
- https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0
- https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25
- https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe
- https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058
- https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882
- https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6
- https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0
- https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26714
In the Linux kernel, the following vulnerability has been resolved: interconnect: qcom: sc8180x: Mark CO0 BCM keepalive The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases.
- https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7
- https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0
- https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0
- https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43
- https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7
- https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0
- https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0
- https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43
Modified: 2025-01-07
CVE-2024-26715
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur.
- https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182
- https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751
- https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316
- https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7
- https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b
- https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182
- https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751
- https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316
- https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7
- https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b
Modified: 2025-01-07
CVE-2024-26717
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures.
- https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f
- https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776
- https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783
- https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c
- https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3
- https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f
- https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776
- https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783
- https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c
- https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3
Modified: 2025-03-17
CVE-2024-26718
In the Linux kernel, the following vulnerability has been resolved: dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet callback frees the structure that contains the tasklet or if it calls some code that may free it, tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer from the memory corruption problem. But we need something that stops the memory corruption now and that can be backported to the stable kernels. So, I'm proposing this commit that disables tasklets in both dm-crypt and dm-verity. This commit doesn't remove the tasklet support, because the tasklet code will be reused when atomic workqueues will be implemented. [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/ [2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/
- https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189
- https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257
- https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94
- https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc
- https://git.kernel.org/stable/c/b825e0f9d68c178072bffd32dd34c39e3d2d597a
- https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189
- https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257
- https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94
- https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc
Modified: 2025-02-03
CVE-2024-26719
In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue.
- https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0
- https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9
- https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906
- https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0
- https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9
- https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906
Modified: 2025-01-07
CVE-2024-26722
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/050ad2ca0ac169dd9e552075d2c6af1bbb46534c
- https://git.kernel.org/stable/c/1f0d7792e9023e8658e901b7b76a555f6aa052ec
- https://git.kernel.org/stable/c/3dd2d99e2352903d0e0b8769e6c9b8293c7454b2
- https://git.kernel.org/stable/c/422d5243b9f780abd3d39da2b746e3915677b07d
- https://git.kernel.org/stable/c/4a98bc739d0753a5810ce5630943cd7614c7717e
- https://git.kernel.org/stable/c/6ef5d5b92f7117b324efaac72b3db27ae8bb3082
- https://git.kernel.org/stable/c/d14b8e2005f36319df9412d42037416d64827f6b
- https://git.kernel.org/stable/c/ed5b8b735369b40d6c1f8ef3e62d369f74b4c491
- https://git.kernel.org/stable/c/050ad2ca0ac169dd9e552075d2c6af1bbb46534c
- https://git.kernel.org/stable/c/1f0d7792e9023e8658e901b7b76a555f6aa052ec
- https://git.kernel.org/stable/c/3dd2d99e2352903d0e0b8769e6c9b8293c7454b2
- https://git.kernel.org/stable/c/422d5243b9f780abd3d39da2b746e3915677b07d
- https://git.kernel.org/stable/c/4a98bc739d0753a5810ce5630943cd7614c7717e
- https://git.kernel.org/stable/c/6ef5d5b92f7117b324efaac72b3db27ae8bb3082
- https://git.kernel.org/stable/c/d14b8e2005f36319df9412d42037416d64827f6b
- https://git.kernel.org/stable/c/ed5b8b735369b40d6c1f8ef3e62d369f74b4c491
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-26723
In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix crash when adding interface under a lag There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0 The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places.
- https://git.kernel.org/stable/c/15faa1f67ab405d47789d4702f587ec7df7ef03e
- https://git.kernel.org/stable/c/2a492f01228b7d091dfe38974ef40dccf8f9f2f1
- https://git.kernel.org/stable/c/48fae67d837488c87379f0c9f27df7391718477c
- https://git.kernel.org/stable/c/b9357489c46c7a43999964628db8b47d3a1f8672
- https://git.kernel.org/stable/c/15faa1f67ab405d47789d4702f587ec7df7ef03e
- https://git.kernel.org/stable/c/2a492f01228b7d091dfe38974ef40dccf8f9f2f1
- https://git.kernel.org/stable/c/48fae67d837488c87379f0c9f27df7391718477c
- https://git.kernel.org/stable/c/b9357489c46c7a43999964628db8b47d3a1f8672
Modified: 2025-07-10
CVE-2024-26726
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't drop extent_map for free space inode on write error
While running the CI for an unrelated change I hit the following panic
with generic/648 on btrfs_holes_spacecache.
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
Call Trace:
- https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555
- https://git.kernel.org/stable/c/143842584c1237ebc248b2547c29d16bbe400a92
- https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade
- https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7
- https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e
- https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555
- https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade
- https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7
- https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e
Modified: 2025-03-17
CVE-2024-26727
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not ASSERT() if the newly created subvolume already got read
[BUG]
There is a syzbot crash, triggered by the ASSERT() during subvolume
creation:
assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319
------------[ cut here ]------------
kernel BUG at fs/btrfs/disk-io.c:1319!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60
- https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f
- https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468
- https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d
- https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430
- https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb
- https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f
- https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f
- https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468
- https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d
- https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430
- https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb
- https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-03
CVE-2024-26731
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()
syzbot reported the following NULL pointer dereference issue [1]:
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:0x0
[...]
Call Trace:
- https://git.kernel.org/stable/c/4588b13abcbd561ec67f5b3c1cb2eff690990a54
- https://git.kernel.org/stable/c/4cd12c6065dfcdeba10f49949bffcf383b3952d8
- https://git.kernel.org/stable/c/9b099ed46dcaf1403c531ff02c3d7400fa37fa26
- https://git.kernel.org/stable/c/d61608a4e394f23e0dca099df9eb8e555453d949
- https://git.kernel.org/stable/c/4588b13abcbd561ec67f5b3c1cb2eff690990a54
- https://git.kernel.org/stable/c/4cd12c6065dfcdeba10f49949bffcf383b3952d8
- https://git.kernel.org/stable/c/9b099ed46dcaf1403c531ff02c3d7400fa37fa26
- https://git.kernel.org/stable/c/d61608a4e394f23e0dca099df9eb8e555453d949
Modified: 2025-03-17
CVE-2024-26733
In the Linux kernel, the following vulnerability has been resolved:
arp: Prevent overflow in arp_req_get().
syzkaller reported an overflown write in arp_req_get(). [0]
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
the sa_data buffer is just 14 bytes.
In the splat below, 2 bytes are overflown to the next int field,
arp_flags. We initialise the field just after the memcpy(), so it's
not a problem.
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
in arp_ioctl() before calling arp_req_get().
To avoid the overflow, let's limit the max length of memcpy().
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
array in struct sockaddr") just silenced syzkaller.
[0]:
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Modules linked in:
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a
- https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50
- https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91
- https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667
- https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587
- https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0
- https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a
- https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50
- https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91
- https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667
- https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587
- https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20241101-0013/
Modified: 2025-03-17
CVE-2024-26735
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix possible use-after-free and null-ptr-deref The pernet operations structure for the subsystem must be registered before registering the generic netlink family.
- https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b
- https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b
- https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6
- https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d
- https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197
- https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee
- https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa
- https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44
- https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b
- https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b
- https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6
- https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d
- https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197
- https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee
- https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa
- https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241101-0012/
Modified: 2025-03-17
CVE-2024-26736
In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
- https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5
- https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e
- https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d
- https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa
- https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637
- https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e
- https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1
- https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5
- https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e
- https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d
- https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa
- https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637
- https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e
- https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-26737
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period.
- https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f
- https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c
- https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33
- https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6
- https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5
- https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f
- https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c
- https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33
- https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6
- https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5
Modified: 2025-11-25
CVE-2024-26739
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: don't override retval if we already lost the skb If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it.
- https://git.kernel.org/stable/c/0117fe0a4615a7c8d30d6ebcbf87332fbe63e6fd
- https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210
- https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d
- https://git.kernel.org/stable/c/9d3ef89b6a5e9f2e940de2cef3d543be0be8dec5
- https://git.kernel.org/stable/c/e873e8f7d03a2ee5b77fb1a305c782fed98e2754
- https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7
- https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210
- https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d
- https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-03-17
CVE-2024-26740
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue.
- https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17
- https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be
- https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4
- https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17
- https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be
- https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4
Modified: 2025-03-17
CVE-2024-26741
In the Linux kernel, the following vulnerability has been resolved:
dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().
syzkaller reported a warning [0] in inet_csk_destroy_sock() with no
repro.
WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash);
However, the syzkaller's log hinted that connect() failed just before
the warning due to FAULT_INJECTION. [1]
When connect() is called for an unbound socket, we search for an
available ephemeral port. If a bhash bucket exists for the port, we
call __inet_check_established() or __inet6_check_established() to check
if the bucket is reusable.
If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num.
Later, we look up the corresponding bhash2 bucket and try to allocate
it if it does not exist.
Although it rarely occurs in real use, if the allocation fails, we must
revert the changes by check_established(). Otherwise, an unconnected
socket could illegally occupy an ehash entry.
Note that we do not put tw back into ehash because sk might have
already responded to a packet for tw and it would be better to free
tw earlier under such memory presure.
[0]:
WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
Modules linked in:
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05
RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40
RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8
RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0
R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000
FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/334a8348b2df26526f3298848ad6864285592caf
- https://git.kernel.org/stable/c/66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f
- https://git.kernel.org/stable/c/729bc77af438a6e67914c97f6f3d3af8f72c0131
- https://git.kernel.org/stable/c/f8c4a6b850882bc47aaa864b720c7a2ee3102f39
- https://git.kernel.org/stable/c/334a8348b2df26526f3298848ad6864285592caf
- https://git.kernel.org/stable/c/66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f
- https://git.kernel.org/stable/c/729bc77af438a6e67914c97f6f3d3af8f72c0131
- https://git.kernel.org/stable/c/f8c4a6b850882bc47aaa864b720c7a2ee3102f39
Modified: 2025-03-17
CVE-2024-26742
In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix disable_managed_interrupts Correct blk-mq registration issue with module parameter disable_managed_interrupts enabled. When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to register with blk-mq using blk_mq_map_queues(). The driver is currently calling blk_mq_pci_map_queues() which results in a stack trace and possibly undefined behavior. Stack Trace: [ 7.860089] scsi host2: smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.351193] process_one_work+0x1a7/0x360 [ 8.364462] ? create_worker+0x1a0/0x1a0 [ 8.379252] worker_thread+0x1ce/0x390 [ 8.392623] ? create_worker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? set_kthread_struct+0x50/0x50 [ 8.431532] ret_from_fork+0x1f/0x40 [ 8.444137] ---[ end trace 1bf0173d39354506 ]---
- https://git.kernel.org/stable/c/3c31b18a8dd8b7bf36af1cd723d455853b8f94fe
- https://git.kernel.org/stable/c/4f5b15c15e6016efb3e14582d02cc4ddf57227df
- https://git.kernel.org/stable/c/5761eb9761d2d5fe8248a9b719efc4d8baf1f24a
- https://git.kernel.org/stable/c/b9433b25cb06c415c9cb24782599649a406c8d6d
- https://git.kernel.org/stable/c/3c31b18a8dd8b7bf36af1cd723d455853b8f94fe
- https://git.kernel.org/stable/c/4f5b15c15e6016efb3e14582d02cc4ddf57227df
- https://git.kernel.org/stable/c/5761eb9761d2d5fe8248a9b719efc4d8baf1f24a
- https://git.kernel.org/stable/c/b9433b25cb06c415c9cb24782599649a406c8d6d
Modified: 2025-03-17
CVE-2024-26743
In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix qedr_create_user_qp error flow
Avoid the following warning by making sure to free the allocated
resources in case that qedr_init_user_queue() fail.
-----------[ cut here ]-----------
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
Call Trace:
- https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a
- https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a
- https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928
- https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc
- https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298
- https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6
- https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a
- https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a
- https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928
- https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc
- https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298
- https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-05-02
CVE-2024-26744
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Support specifying the srpt_service_guid parameter
Make loading ib_srpt with this parameter set work. The current behavior is
that setting that parameter while loading the ib_srpt kernel module
triggers the following kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
- https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82
- https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b
- https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4
- https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8
- https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d
- https://git.kernel.org/stable/c/e0055d6461b36bfc25a9d2ab974eef78d36a6738
- https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0
- https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f
- https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82
- https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b
- https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4
- https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8
- https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d
- https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0
- https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-26745
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due
to NULL pointer exception:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc000000020847ad4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop
CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12
Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c
REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)
MSR: 800000000280b033
- https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051
- https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28
- https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3
- https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf
- https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051
- https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28
- https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3
- https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf
Modified: 2025-04-04
CVE-2024-26747
In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations.
- https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa
- https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db
- https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e
- https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734
- https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1
- https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913
- https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa
- https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db
- https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e
- https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734
- https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1
- https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26748
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request); Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.
- https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48
- https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8
- https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3
- https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019
- https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3
- https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c
- https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7
- https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48
- https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8
- https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3
- https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019
- https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3
- https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c
- https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26749
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem.
- https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9
- https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16
- https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3
- https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d
- https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643
- https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6
- https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824
- https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9
- https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16
- https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3
- https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d
- https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643
- https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6
- https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26751
In the Linux kernel, the following vulnerability has been resolved: ARM: ep93xx: Add terminator to gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops.
- https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8
- https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482
- https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8
- https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997
- https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa
- https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e
- https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48
- https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557
- https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8
- https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482
- https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8
- https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997
- https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa
- https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e
- https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48
- https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26752
In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent.
- https://git.kernel.org/stable/c/0da15a70395182ee8cb75716baf00dddc0bea38d
- https://git.kernel.org/stable/c/13cd1daeea848614e585b2c6ecc11ca9c8ab2500
- https://git.kernel.org/stable/c/359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79
- https://git.kernel.org/stable/c/4c3ce64bc9d36ca9164dd6c77ff144c121011aae
- https://git.kernel.org/stable/c/804bd8650a3a2bf3432375f8c97d5049d845ce56
- https://git.kernel.org/stable/c/83340c66b498e49353530e41542500fc8a4782d6
- https://git.kernel.org/stable/c/c1d3a84a67db910ce28a871273c992c3d7f9efb5
- https://git.kernel.org/stable/c/dcb4d14268595065c85dc5528056713928e17243
- https://git.kernel.org/stable/c/0da15a70395182ee8cb75716baf00dddc0bea38d
- https://git.kernel.org/stable/c/13cd1daeea848614e585b2c6ecc11ca9c8ab2500
- https://git.kernel.org/stable/c/359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79
- https://git.kernel.org/stable/c/4c3ce64bc9d36ca9164dd6c77ff144c121011aae
- https://git.kernel.org/stable/c/804bd8650a3a2bf3432375f8c97d5049d845ce56
- https://git.kernel.org/stable/c/83340c66b498e49353530e41542500fc8a4782d6
- https://git.kernel.org/stable/c/c1d3a84a67db910ce28a871273c992c3d7f9efb5
- https://git.kernel.org/stable/c/dcb4d14268595065c85dc5528056713928e17243
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-27
CVE-2024-26753
In the Linux kernel, the following vulnerability has been resolved: crypto: virtio/akcipher - Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o
- https://git.kernel.org/stable/c/37077ed16c7793e21b005979d33f8a61565b7e86
- https://git.kernel.org/stable/c/62f361bfea60c6afc3df09c1ad4152e6507f6f47
- https://git.kernel.org/stable/c/b0365460e945e1117b47cf7329d86de752daff63
- https://git.kernel.org/stable/c/c0ec2a712daf133d9996a8a1b7ee2d4996080363
- https://git.kernel.org/stable/c/ef1e47d50324e232d2da484fe55a54274eeb9bc1
- https://git.kernel.org/stable/c/37077ed16c7793e21b005979d33f8a61565b7e86
- https://git.kernel.org/stable/c/62f361bfea60c6afc3df09c1ad4152e6507f6f47
- https://git.kernel.org/stable/c/b0365460e945e1117b47cf7329d86de752daff63
- https://git.kernel.org/stable/c/c0ec2a712daf133d9996a8a1b7ee2d4996080363
- https://git.kernel.org/stable/c/ef1e47d50324e232d2da484fe55a54274eeb9bc1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-07
CVE-2024-26754
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
The gtp_net_ops pernet operations structure for the subsystem must be
registered before registering the generic netlink family.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
RSP: 0018:ffff888014107220 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec
- https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca
- https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a
- https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576
- https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77
- https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e
- https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861
- https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7
- https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec
- https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca
- https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a
- https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576
- https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77
- https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e
- https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861
- https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-16
CVE-2024-26759
In the Linux kernel, the following vulnerability has been resolved:
mm/swap: fix race when skipping swapcache
When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
swapin the same entry at the same time, they get different pages (A, B).
Before one thread (T0) finishes the swapin and installs page (A) to the
PTE, another thread (T1) could finish swapin of page (B), swap_free the
entry, then swap out the possibly modified page reusing the same entry.
It breaks the pte_same check in (T0) because PTE value is unchanged,
causing ABA problem. Thread (T0) will install a stalled page (A) into the
PTE and cause data corruption.
One possible callstack is like this:
CPU0 CPU1
---- ----
do_swap_page() do_swap_page() with same entry
- https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458
- https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95
- https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a
- https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d
- https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458
- https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95
- https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a
- https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d
Modified: 2025-03-03
CVE-2024-26760
In the Linux kernel, the following vulnerability has been resolved: scsi: target: pscsi: Fix bio_put() for error case As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in bio_free().
- https://git.kernel.org/stable/c/1cfe9489fb563e9a0c9cdc5ca68257a44428c2ec
- https://git.kernel.org/stable/c/4ebc079f0c7dcda1270843ab0f38ab4edb8f7921
- https://git.kernel.org/stable/c/de959094eb2197636f7c803af0943cb9d3b35804
- https://git.kernel.org/stable/c/f49b20fd0134da84a6bd8108f9e73c077b7d6231
- https://git.kernel.org/stable/c/1cfe9489fb563e9a0c9cdc5ca68257a44428c2ec
- https://git.kernel.org/stable/c/4ebc079f0c7dcda1270843ab0f38ab4edb8f7921
- https://git.kernel.org/stable/c/de959094eb2197636f7c803af0943cb9d3b35804
- https://git.kernel.org/stable/c/f49b20fd0134da84a6bd8108f9e73c077b7d6231
Modified: 2025-03-17
CVE-2024-26761
In the Linux kernel, the following vulnerability has been resolved: cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window The Linux CXL subsystem is built on the assumption that HPA == SPA. That is, the host physical address (HPA) the HDM decoder registers are programmed with are system physical addresses (SPA). During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1, 8.1.3.8) are checked if the memory is enabled and the CXL range is in a HPA window that is described in a CFMWS structure of the CXL host bridge (cxl-3.1, 9.18.1.3). Now, if the HPA is not an SPA, the CXL range does not match a CFMWS window and the CXL memory range will be disabled then. The HDM decoder stops working which causes system memory being disabled and further a system hang during HDM decoder initialization, typically when a CXL enabled kernel boots. Prevent a system hang and do not disable the HDM decoder if the decoder's CXL range is not found in a CFMWS window. Note the change only fixes a hardware hang, but does not implement HPA/SPA translation. Support for this can be added in a follow on patch series.
- https://git.kernel.org/stable/c/031217128990d7f0ab8c46db1afb3cf1e075fd29
- https://git.kernel.org/stable/c/0cab687205986491302cd2e440ef1d253031c221
- https://git.kernel.org/stable/c/2cc1a530ab31c65b52daf3cb5d0883c8b614ea69
- https://git.kernel.org/stable/c/3a3181a71935774bda2398451256d7441426420b
- https://git.kernel.org/stable/c/031217128990d7f0ab8c46db1afb3cf1e075fd29
- https://git.kernel.org/stable/c/0cab687205986491302cd2e440ef1d253031c221
- https://git.kernel.org/stable/c/2cc1a530ab31c65b52daf3cb5d0883c8b614ea69
- https://git.kernel.org/stable/c/3a3181a71935774bda2398451256d7441426420b
Modified: 2025-03-18
CVE-2024-26763
In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/
- https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa
- https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529
- https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90
- https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e
- https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7
- https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75
- https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857
- https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6
- https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa
- https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529
- https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90
- https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e
- https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7
- https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75
- https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857
- https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-18
CVE-2024-26764
In the Linux kernel, the following vulnerability has been resolved: fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio.
- https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487
- https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6
- https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f
- https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942
- https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760
- https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353
- https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7
- https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f
- https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487
- https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6
- https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f
- https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942
- https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760
- https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353
- https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7
- https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-18
CVE-2024-26765
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 ... Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58
- https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a
- https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f
- https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53
- https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464
- https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a
- https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f
- https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53
- https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464
Modified: 2025-02-27
CVE-2024-26766
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
Unfortunately the commit `fd8958efe877` introduced another error
causing the `descs` array to overflow. This reults in further crashes
easily reproducible by `sendmsg` system call.
[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
--
[ 1080.974535] Call Trace:
[ 1080.976990]
- https://git.kernel.org/stable/c/115b7f3bc1dce590a6851a2dcf23dc1100c49790
- https://git.kernel.org/stable/c/3f38d22e645e2e994979426ea5a35186102ff3c2
- https://git.kernel.org/stable/c/47ae64df23ed1318e27bd9844e135a5e1c0e6e39
- https://git.kernel.org/stable/c/52dc9a7a573dbf778625a0efca0fca55489f084b
- https://git.kernel.org/stable/c/5833024a9856f454a964a198c63a57e59e07baf5
- https://git.kernel.org/stable/c/9034a1bec35e9f725315a3bb6002ef39666114d9
- https://git.kernel.org/stable/c/a2fef1d81becf4ff60e1a249477464eae3c3bc2a
- https://git.kernel.org/stable/c/e6f57c6881916df39db7d95981a8ad2b9c3458d6
- https://git.kernel.org/stable/c/115b7f3bc1dce590a6851a2dcf23dc1100c49790
- https://git.kernel.org/stable/c/3f38d22e645e2e994979426ea5a35186102ff3c2
- https://git.kernel.org/stable/c/47ae64df23ed1318e27bd9844e135a5e1c0e6e39
- https://git.kernel.org/stable/c/52dc9a7a573dbf778625a0efca0fca55489f084b
- https://git.kernel.org/stable/c/5833024a9856f454a964a198c63a57e59e07baf5
- https://git.kernel.org/stable/c/9034a1bec35e9f725315a3bb6002ef39666114d9
- https://git.kernel.org/stable/c/a2fef1d81becf4ff60e1a249477464eae3c3bc2a
- https://git.kernel.org/stable/c/e6f57c6881916df39db7d95981a8ad2b9c3458d6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-26767
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check
- https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738
- https://git.kernel.org/stable/c/070fda699dfdce560755379bc428d9edada7a54e
- https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375
- https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7
- https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738
- https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375
- https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
Modified: 2025-04-04
CVE-2024-26768
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With default config, the value of NR_CPUS is 64. When HW platform has more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC is the maximum cpu number in MADT table (max physical number) which can exceed the supported maximum cpu number (NR_CPUS, max logical number), but kernel should not crash. Kernel should boot cpus with NR_CPUS, let the remainder cpus stay in BIOS. The potential crash reason is that the array acpi_core_pic[NR_CPUS] can be overflowed when parsing MADT table, and it is obvious that CORE_PIC should be corresponding to physical core rather than logical core, so it is better to define the array as acpi_core_pic[MAX_CORE_PIC]. With the patch, system can boot up 64 vcpus with qemu parameter -smp 128, otherwise system will crash with the following message. [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192 [ 0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60 [ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8 [ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005 [ 0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001 [ 0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063 [ 0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98 [ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90 [ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330 [ 0.000000] ra: 90000000037a46ec platform_init+0x214/0x250 [ 0.000000] ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94 [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 0.000000] BADV: 0000420000004259 [ 0.000000] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec [ 0.000000] 000000000a7fd000 0000000008290000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 00000000019d8000 000000000f556b60 [ 0.000000] 000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000 [ 0.000000] 9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c [ 0.000000] 000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08 [ 0.000000] 9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018 [ 0.000000] 000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000 [ 0.000000] 0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000 [ 0.000000] 000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<90000000037a5f0c>] efi_runtime_init+0x30/0x94 [ 0.000000] [<90000000037a46ec>] platform_init+0x214/0x250 [ 0.000000] [<90000000037a484c>] setup_arch+0x124/0x45c [ 0.000000] [<90000000037a0790>] start_kernel+0x90/0x670 [ 0.000000] [<900000000378b0d8>] kernel_entry+0xd8/0xdc
- https://git.kernel.org/stable/c/0f6810e39898af2d2cabd9313e4dbc945fb5dfdd
- https://git.kernel.org/stable/c/4551b30525cf3d2f026b92401ffe241eb04dfebe
- https://git.kernel.org/stable/c/88e189bd16e5889e44a41b3309558ebab78b9280
- https://git.kernel.org/stable/c/0f6810e39898af2d2cabd9313e4dbc945fb5dfdd
- https://git.kernel.org/stable/c/4551b30525cf3d2f026b92401ffe241eb04dfebe
- https://git.kernel.org/stable/c/88e189bd16e5889e44a41b3309558ebab78b9280
Modified: 2025-04-04
CVE-2024-26769
In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item.
- https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd
- https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4
- https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397
- https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8
- https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30
- https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd
- https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4
- https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397
- https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8
- https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30
Modified: 2025-01-27
CVE-2024-26770
In the Linux kernel, the following vulnerability has been resolved: HID: nvidia-shield: Add missing null pointer checks to LED initialization 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. [jkosina@suse.com: tweak changelog a bit]
- https://git.kernel.org/stable/c/83527a13740f57b45f162e3af4c7db4b88521100
- https://git.kernel.org/stable/c/b6eda11c44dc89a681e1c105f0f4660e69b1e183
- https://git.kernel.org/stable/c/e71cc4a1e584293deafff1a7dea614b0210d0443
- https://git.kernel.org/stable/c/83527a13740f57b45f162e3af4c7db4b88521100
- https://git.kernel.org/stable/c/b6eda11c44dc89a681e1c105f0f4660e69b1e183
- https://git.kernel.org/stable/c/e71cc4a1e584293deafff1a7dea614b0210d0443
Modified: 2025-01-27
CVE-2024-26771
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Add some null pointer checks to the edma_probe devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
- https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d
- https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369
- https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27
- https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49
- https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce
- https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e
- https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d
- https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369
- https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27
- https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49
- https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce
- https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-26772
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap.
- https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a
- https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43
- https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d
- https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513
- https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff
- https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916
- https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586
- https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7
- https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a
- https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43
- https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d
- https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513
- https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff
- https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916
- https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586
- https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-18
CVE-2024-26773
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group
- https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1
- https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea
- https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d
- https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53
- https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5
- https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03
- https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe
- https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36
- https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1
- https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea
- https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d
- https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53
- https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5
- https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03
- https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe
- https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-06-19
CVE-2024-26774
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Determine if bb_fragments is 0 instead of determining bb_free to eliminate the risk of dividing by zero when the block bitmap is corrupted.
- https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150
- https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3
- https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b
- https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a
- https://git.kernel.org/stable/c/687061cfaa2ac3095170e136dd9c29a4974f41d4
- https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150
- https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3
- https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b
- https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a
Modified: 2025-07-17
CVE-2024-26775
In the Linux kernel, the following vulnerability has been resolved:
aoe: avoid potential deadlock at set_capacity
Move set_capacity() outside of the section procected by (&d->lock).
To avoid possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
[1] lock(&bdev->bd_size_lock);
local_irq_disable();
[2] lock(&d->lock);
[3] lock(&bdev->bd_size_lock);
- https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77
- https://git.kernel.org/stable/c/2499fa286fb010ceb289950050199f33c26667b9
- https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26
- https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c
- https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86
- https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77
- https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26
- https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c
- https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86
Modified: 2025-02-27
CVE-2024-26776
In the Linux kernel, the following vulnerability has been resolved: spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc
- https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d
- https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4
- https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9
- https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd
- https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5
- https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8
- https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d
- https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4
- https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9
- https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd
- https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5
- https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26777
In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.
- https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b
- https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207
- https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e
- https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb
- https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313
- https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1
- https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52
- https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99
- https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b
- https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207
- https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e
- https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb
- https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313
- https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1
- https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52
- https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-27
CVE-2024-26778
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.
- https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288
- https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4
- https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1
- https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24
- https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff
- https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1
- https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01
- https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13
- https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288
- https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4
- https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1
- https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24
- https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff
- https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1
- https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01
- https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-04
CVE-2024-26779
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.
- https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9
- https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954
- https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd
- https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587
- https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5
- https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d
- https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f
- https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696
- https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9
- https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954
- https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd
- https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587
- https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5
- https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d
- https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f
- https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-10
CVE-2024-26782
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix double-free on socket dismantle
when MPTCP server accepts an incoming connection, it clones its listener
socket. However, the pointer to 'inet_opt' for the new socket has the same
value as the original one: as a consequence, on program exit it's possible
to observe the following splat:
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
Free of addr ffff888485950880 by task swapper/25/0
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
Call Trace:
- https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c
- https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e
- https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc
- https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582
- https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85
- https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e
- https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c
- https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e
- https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc
- https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582
- https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85
- https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-03
CVE-2024-26783
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index
With numa balancing on, when a numa system is running where a numa node
doesn't have its local memory so it has no managed zones, the following
oops has been observed. It's because wakeup_kswapd() is called with a
wrong zone index, -1. Fixed it by checking the index before calling
wakeup_kswapd().
> BUG: unable to handle page fault for address: 00000000000033f3
> #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: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
> RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812)
> Code: (omitted)
> RSP: 0000:ffffc90004257d58 EFLAGS: 00010286
> RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480
> RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff
> R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003
> R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940
> FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> PKRU: 55555554
> Call Trace:
>
- https://git.kernel.org/stable/c/2774f256e7c0219e2b0a0894af1c76bdabc4f974
- https://git.kernel.org/stable/c/bdd21eed8b72f9e28d6c279f6db258e090c79080
- https://git.kernel.org/stable/c/d6159bd4c00594249e305bfe02304c67c506264e
- https://git.kernel.org/stable/c/e5ec1c24e71dbf144677a975d6ba91043c2193db
- https://git.kernel.org/stable/c/2774f256e7c0219e2b0a0894af1c76bdabc4f974
- https://git.kernel.org/stable/c/bdd21eed8b72f9e28d6c279f6db258e090c79080
- https://git.kernel.org/stable/c/d6159bd4c00594249e305bfe02304c67c506264e
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-03-20
CVE-2024-26787
In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.
- https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53
- https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4
- https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c
- https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be
- https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef
- https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85
- https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53
- https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4
- https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c
- https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be
- https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef
- https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-01
CVE-2024-26788
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18
- https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478
- https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b
- https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99
- https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8
- https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd
- https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1
- https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d
- https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478
- https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b
- https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99
- https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8
- https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd
- https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1
- https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26790
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ). Implement this workaround.
- https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce
- https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa
- https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da
- https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367
- https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e
- https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471
- https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580
- https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce
- https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa
- https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da
- https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367
- https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e
- https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471
- https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-20
CVE-2024-26791
In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).
- https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84
- https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d
- https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
- https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4
- https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9
- https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1
- https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311
- https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8
- https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84
- https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d
- https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
- https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4
- https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9
- https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1
- https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311
- https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-20
CVE-2024-26793
In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated---
- https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb
- https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8
- https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e
- https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16
- https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e
- https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627
- https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69
- https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6
- https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb
- https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8
- https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e
- https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16
- https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e
- https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627
- https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69
- https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-19
CVE-2024-26795
In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments
- https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe
- https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef
- https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af
- https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd
- https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9
- https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e
- https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe
- https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef
- https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af
- https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd
- https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9
- https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-03-17
CVE-2024-26798
In the Linux kernel, the following vulnerability has been resolved:
fbcon: always restore the old font data in fbcon_do_set_font()
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().
This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
BUG: unable to handle page fault for address: fffffffffffffff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
Call Trace:
- https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f
- https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d
- https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b
- https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520
- https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8
- https://git.kernel.org/stable/c/ae68f57df3335679653868fafccd8c88ef84ae98
- https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f
- https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d
- https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b
- https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520
- https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8
Modified: 2025-04-04
CVE-2024-26799
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix uninitialized pointer dmactl In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params. Cleans up clang scan build warning: sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]
- https://git.kernel.org/stable/c/1382d8b55129875b2e07c4d2a7ebc790183769ee
- https://git.kernel.org/stable/c/99adc8b4d2f38bf0d06483ec845bc48f60c3f8cf
- https://git.kernel.org/stable/c/d5a7726e6ea62d447b79ab5baeb537ea6bdb225b
- https://git.kernel.org/stable/c/1382d8b55129875b2e07c4d2a7ebc790183769ee
- https://git.kernel.org/stable/c/99adc8b4d2f38bf0d06483ec845bc48f60c3f8cf
- https://git.kernel.org/stable/c/d5a7726e6ea62d447b79ab5baeb537ea6bdb225b
Modified: 2024-12-20
CVE-2024-26801
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth
- https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592
- https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b
- https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1
- https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2
- https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090
- https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14
- https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1
- https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03
- https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592
- https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b
- https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1
- https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2
- https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090
- https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14
- https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1
- https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-04
CVE-2024-26802
In the Linux kernel, the following vulnerability has been resolved:
stmmac: Clear variable when destroying workqueue
Currently when suspending driver and stopping workqueue it is checked whether
workqueue is not NULL and if so, it is destroyed.
Function destroy_workqueue() does drain queue and does clear variable, but
it does not set workqueue variable to NULL. This can cause kernel/module
panic if code attempts to clear workqueue that was not initialized.
This scenario is possible when resuming suspended driver in stmmac_resume(),
because there is no handling for failed stmmac_hw_setup(),
which can fail and return if DMA engine has failed to initialize,
and workqueue is initialized after DMA engine.
Should DMA engine fail to initialize, resume will proceed normally,
but interface won't work and TX queue will eventually timeout,
causing 'Reset adapter' error.
This then does destroy workqueue during reset process.
And since workqueue is initialized after DMA engine and can be skipped,
it will cause kernel/module panic.
To secure against this possible crash, set workqueue variable to NULL when
destroying workqueue.
Log/backtrace from crash goes as follows:
[88.031977]------------[ cut here ]------------
[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out
[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398
- https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6
- https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3
- https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f
- https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462
- https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8
- https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6
- https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3
- https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f
- https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462
- https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8
Modified: 2025-04-01
CVE-2024-26803
In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths.
- https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664
- https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325
- https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941
- https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c
- https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736
- https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664
- https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325
- https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941
- https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c
- https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736
Modified: 2025-03-21
CVE-2024-26804
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.
- https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b
- https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee
- https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
- https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9
- https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96
- https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282
- https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383
- https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b
- https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee
- https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
- https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9
- https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96
- https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282
- https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26805
In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated---
- https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44
- https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d
- https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd
- https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777
- https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285
- https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736
- https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65
- https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77
- https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44
- https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d
- https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd
- https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777
- https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285
- https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736
- https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65
- https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-19
CVE-2024-26809
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: release elements in clone only from destroy path Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice. This fix requires: 212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol") which came after: 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").
- https://git.kernel.org/stable/c/362508506bf545e9ce18c72a2c48dcbfb891ab9c
- https://git.kernel.org/stable/c/5ad233dc731ab64cdc47b84a5c1f78fff6c024af
- https://git.kernel.org/stable/c/821e28d5b506e6a73ccc367ff792bd894050d48b
- https://git.kernel.org/stable/c/9384b4d85c46ce839f51af01374062ce6318b2f2
- https://git.kernel.org/stable/c/b0e256f3dd2ba6532f37c5c22e07cb07a36031ee
- https://git.kernel.org/stable/c/b36b83297ff4910dfc8705402c8abffd4bbf8144
- https://git.kernel.org/stable/c/ff90050771412b91e928093ccd8736ae680063c2
- https://git.kernel.org/stable/c/362508506bf545e9ce18c72a2c48dcbfb891ab9c
- https://git.kernel.org/stable/c/5ad233dc731ab64cdc47b84a5c1f78fff6c024af
- https://git.kernel.org/stable/c/821e28d5b506e6a73ccc367ff792bd894050d48b
- https://git.kernel.org/stable/c/9384b4d85c46ce839f51af01374062ce6318b2f2
- https://git.kernel.org/stable/c/b0e256f3dd2ba6532f37c5c22e07cb07a36031ee
- https://git.kernel.org/stable/c/b36b83297ff4910dfc8705402c8abffd4bbf8144
- https://git.kernel.org/stable/c/ff90050771412b91e928093ccd8736ae680063c2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-27
CVE-2024-26815
In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check
taprio_parse_tc_entry() is not correctly checking
TCA_TAPRIO_TC_ENTRY_INDEX attribute:
int tc; // Signed value
tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]);
if (tc >= TC_QOPT_MAX_QUEUE) {
NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range");
return -ERANGE;
}
syzbot reported that it could fed arbitary negative values:
UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18
shift exponent -2147418108 is negative
CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Call Trace:
- https://git.kernel.org/stable/c/343041b59b7810f9cdca371f445dd43b35c740b1
- https://git.kernel.org/stable/c/6915b1b28fe57e92c78e664366dc61c4f15ff03b
- https://git.kernel.org/stable/c/860e838fb089d652a446ced52cbdf051285b68e7
- https://git.kernel.org/stable/c/9b720bb1a69a9f12a4a5c86b6f89386fe05ed0f2
- https://git.kernel.org/stable/c/bd2474a45df7c11412c2587de3d4e43760531418
- https://git.kernel.org/stable/c/343041b59b7810f9cdca371f445dd43b35c740b1
- https://git.kernel.org/stable/c/6915b1b28fe57e92c78e664366dc61c4f15ff03b
- https://git.kernel.org/stable/c/860e838fb089d652a446ced52cbdf051285b68e7
- https://git.kernel.org/stable/c/9b720bb1a69a9f12a4a5c86b6f89386fe05ed0f2
- https://git.kernel.org/stable/c/bd2474a45df7c11412c2587de3d4e43760531418
Modified: 2025-03-27
CVE-2024-26816
In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map.
- https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03
- https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723
- https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088
- https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40
- https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a
- https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b
- https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa
- https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c
- https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af
- https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03
- https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723
- https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088
- https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40
- https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a
- https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b
- https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa
- https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c
- https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-27
CVE-2024-26820
In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER handler cannot perform VF register successfully as the register call is received before netvsc_probe is finished. This is because we register register_netdevice_notifier() very early( even before vmbus_driver_register()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe.
- https://git.kernel.org/stable/c/309ef7de5d840e17607e7d65cbf297c0564433ef
- https://git.kernel.org/stable/c/4d29a58d96a78728cb01ee29ed70dc4bd642f135
- https://git.kernel.org/stable/c/5b10a88f64c0315cfdef45de0aaaa4eef57de0b7
- https://git.kernel.org/stable/c/9cae43da9867412f8bd09aee5c8a8dc5e8dc3dc2
- https://git.kernel.org/stable/c/a71302c8638939c45e4ba5a99ea438185fd3f418
- https://git.kernel.org/stable/c/b6d46f306b3964d05055ddaa96b58cd8bd3a472c
- https://git.kernel.org/stable/c/bcb7164258d0a9a8aa2e73ddccc2d78f67d2519d
- https://git.kernel.org/stable/c/c7441c77c91e47f653104be8353b44a3366a5366
- https://git.kernel.org/stable/c/309ef7de5d840e17607e7d65cbf297c0564433ef
- https://git.kernel.org/stable/c/4d29a58d96a78728cb01ee29ed70dc4bd642f135
- https://git.kernel.org/stable/c/5b10a88f64c0315cfdef45de0aaaa4eef57de0b7
- https://git.kernel.org/stable/c/9cae43da9867412f8bd09aee5c8a8dc5e8dc3dc2
- https://git.kernel.org/stable/c/a71302c8638939c45e4ba5a99ea438185fd3f418
- https://git.kernel.org/stable/c/b6d46f306b3964d05055ddaa96b58cd8bd3a472c
- https://git.kernel.org/stable/c/bcb7164258d0a9a8aa2e73ddccc2d78f67d2519d
- https://git.kernel.org/stable/c/c7441c77c91e47f653104be8353b44a3366a5366
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-27
CVE-2024-26825
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free rx_data_reassembly skb on NCI device cleanup rx_data_reassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak. As by design the rx_data_reassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1
- https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d
- https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23
- https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895
- https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf
- https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81
- https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9
- https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c
- https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1
- https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d
- https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23
- https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895
- https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf
- https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81
- https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9
- https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-27
CVE-2024-26826
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data re-injection from stale subflow When the MPTCP PM detects that a subflow is stale, all the packet scheduler must re-inject all the mptcp-level unacked data. To avoid acquiring unneeded locks, it first try to check if any unacked data is present at all in the RTX queue, but such check is currently broken, as it uses TCP-specific helper on an MPTCP socket. Funnily enough fuzzers and static checkers are happy, as the accessed memory still belongs to the mptcp_sock struct, and even from a functional perspective the recovery completed successfully, as the short-cut test always failed. A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize tcp_sock fast path variables") - exposed the issue, as the tcp field reorganization makes the mptcp code always skip the re-inection. Fix the issue dropping the bogus call: we are on a slow path, the early optimization proved once again to be evil.
- https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8
- https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8
- https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2
- https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5
- https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598
- https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8
- https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8
- https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2
- https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5
- https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598
Modified: 2025-04-08
CVE-2024-26828
In the Linux kernel, the following vulnerability has been resolved: cifs: fix underflow in parse_server_interfaces() In this loop, we step through the buffer and after each item we check if the size_left is greater than the minimum size we need. However, the problem is that "bytes_left" is type ssize_t while sizeof() is type size_t. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.
- https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512
- https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204
- https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301
- https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308
- https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512
- https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204
- https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301
- https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308
Modified: 2025-06-19
CVE-2024-26829
In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: fix a memleak in irtoy_tx When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak.
- https://git.kernel.org/stable/c/207557e393a135c1b6fe1df7cc0741d2c1789fff
- https://git.kernel.org/stable/c/7219a692ffc00089015ada33b85b334d1a4b6e8e
- https://git.kernel.org/stable/c/b37259448bbc70af1d0e52a9dd5559a9c29c9621
- https://git.kernel.org/stable/c/be76ad74a43f90f340f9f479e6b04f02125f6aef
- https://git.kernel.org/stable/c/dc9ceb90c4b42c6e5c6757df1d6257110433788e
- https://git.kernel.org/stable/c/207557e393a135c1b6fe1df7cc0741d2c1789fff
- https://git.kernel.org/stable/c/486a4176bc783df798bce2903824801af8d2c3ae
- https://git.kernel.org/stable/c/7219a692ffc00089015ada33b85b334d1a4b6e8e
- https://git.kernel.org/stable/c/b37259448bbc70af1d0e52a9dd5559a9c29c9621
- https://git.kernel.org/stable/c/be76ad74a43f90f340f9f479e6b04f02125f6aef
- https://git.kernel.org/stable/c/dc9ceb90c4b42c6e5c6757df1d6257110433788e
Modified: 2025-04-02
CVE-2024-26830
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0:
- https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893
- https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc
- https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404
- https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d
- https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893
- https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc
- https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404
- https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d
Modified: 2025-04-02
CVE-2024-26832
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.
- https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffea
- https://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644
- https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abe
- https://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1d
- https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffea
- https://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644
- https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abe
- https://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1d
Modified: 2025-01-07
CVE-2024-26833
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:
unreferenced object 0xffff896302b45800 (size 1024):
comm "(udev-worker)", pid 222, jiffies 4294894636
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 6265fd77):
[
- https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2
- https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e
- https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b
- https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30
- https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857
- https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3
- https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2
- https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e
- https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b
- https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30
- https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857
- https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-02
CVE-2024-26835
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: set dormant flag on hook register failure We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core.
- https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376
- https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af
- https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be
- https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95
- https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7
- https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3
- https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec
- https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069
- https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376
- https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af
- https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be
- https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95
- https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7
- https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3
- https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec
- https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-02
CVE-2024-26837
In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.
- https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f
- https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db
- https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b
- https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8
- https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f
- https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db
- https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b
- https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8
Modified: 2025-04-02
CVE-2024-26838
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix KASAN issue with tasklet
KASAN testing revealed the following issue assocated with freeing an IRQ.
[50006.466686] Call Trace:
[50006.466691]
- https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc
- https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824
- https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa
- https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb
- https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848
- https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc
- https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824
- https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa
- https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb
- https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848
Modified: 2025-01-14
CVE-2024-26839
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.
- https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3
- https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7
- https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25
- https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2
- https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a
- https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896
- https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8
- https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b
- https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3
- https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7
- https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25
- https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2
- https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a
- https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896
- https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8
- https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-07
CVE-2024-26840
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix memory leak in cachefiles_add_cache()
The following memory leak was reported after unbinding /dev/cachefiles:
==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
comm "cachefilesd2", pid 680, jiffies 4294881224
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc ea38a44b):
[
- https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285
- https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3
- https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8
- https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58
- https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579
- https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a
- https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083
- https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444
- https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285
- https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3
- https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8
- https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58
- https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579
- https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a
- https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083
- https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-02
CVE-2024-26841
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Update cpu_sibling_map when disabling nonboot CPUs Update cpu_sibling_map when disabling nonboot CPUs by defining & calling clear_cpu_sibling_map(), otherwise we get such errors on SMT systems: jump label: negative count! WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100 CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20 a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280 a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001 t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000 t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964 t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8 s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040 s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006 ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000 90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0 900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001 0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0 0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f 6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000 900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000 0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4 0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c ... Call Trace: [<9000000000224528>] show_stack+0x48/0x1a0 [<900000000179afc8>] dump_stack_lvl+0x78/0xa0 [<9000000000263ed0>] __warn+0x90/0x1a0 [<90000000017419b8>] report_bug+0x1b8/0x280 [<900000000179c564>] do_bp+0x264/0x420 [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100 [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300 [<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0 [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240 [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0 [<900000000029a720>] kthread+0x140/0x160 [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4
- https://git.kernel.org/stable/c/0d862db64d26c2905ba1a6a8561466b215b664c2
- https://git.kernel.org/stable/c/752cd08da320a667a833803a8fd6bb266114cce5
- https://git.kernel.org/stable/c/b1ec3d6b86fdd057559a5908e6668279bf770e0e
- https://git.kernel.org/stable/c/0d862db64d26c2905ba1a6a8561466b215b664c2
- https://git.kernel.org/stable/c/752cd08da320a667a833803a8fd6bb266114cce5
- https://git.kernel.org/stable/c/b1ec3d6b86fdd057559a5908e6668279bf770e0e
Modified: 2025-03-04
CVE-2024-26842
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd()
When task_tag >= 32 (in MCQ mode) and sizeof(unsigned int) == 4, 1U <<
task_tag will out of bounds for a u32 mask. Fix this up to prevent
SHIFT_ISSUE (bitwise shifts that are out of bounds for their data type).
[name:debug_monitors&]Unexpected kernel BRK exception at EL1
[name:traps&]Internal error: BRK handler: 00000000f2005514 [#1] PREEMPT SMP
[name:mediatek_cpufreq_hw&]cpufreq stop DVFS log done
[name:mrdump&]Kernel Offset: 0x1ba5800000 from 0xffffffc008000000
[name:mrdump&]PHYS_OFFSET: 0x80000000
[name:mrdump&]pstate: 22400005 (nzCv daif +PAN -UAO)
[name:mrdump&]pc : [0xffffffdbaf52bb2c] ufshcd_clear_cmd+0x280/0x288
[name:mrdump&]lr : [0xffffffdbaf52a774] ufshcd_wait_for_dev_cmd+0x3e4/0x82c
[name:mrdump&]sp : ffffffc0081471b0
- https://git.kernel.org/stable/c/7ac9e18f5d66087cd22751c5c5bf0090eb0038fe
- https://git.kernel.org/stable/c/a992425d18e5f7c48931121993c6c69426f2a8fb
- https://git.kernel.org/stable/c/b513d30d59bb383a6a5d6b533afcab2cee99a8f8
- https://git.kernel.org/stable/c/7ac9e18f5d66087cd22751c5c5bf0090eb0038fe
- https://git.kernel.org/stable/c/a992425d18e5f7c48931121993c6c69426f2a8fb
- https://git.kernel.org/stable/c/b513d30d59bb383a6a5d6b533afcab2cee99a8f8
Modified: 2025-04-29
CVE-2024-26843
In the Linux kernel, the following vulnerability has been resolved: efi: runtime: Fix potential overflow of soft-reserved region size md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region.
- https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0
- https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9
- https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426
- https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be
- https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70
- https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4
- https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0
- https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9
- https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426
- https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be
- https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70
- https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-02
CVE-2024-26844
In the Linux kernel, the following vulnerability has been resolved: block: Fix WARNING in _copy_from_iter Syzkaller reports a warning in _copy_from_iter because an iov_iter is supposedly used in the wrong direction. The reason is that syzcaller managed to generate a request with a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs the kernel to copy user buffers into the kernel, read into the copied buffers and then copy the data back to user space. Thus the iovec is used in both directions. Detect this situation in the block layer and construct a new iterator with the correct direction for the copy-in.
- https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956
- https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6
- https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b
- https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b
- https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956
- https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6
- https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b
- https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b
Modified: 2026-01-05
CVE-2024-26845
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Add TMF to tmr_list handling An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core.
- https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d
- https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf
- https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb
- https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25
- https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d
- https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f
- https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a
- https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d
- https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf
- https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb
- https://git.kernel.org/stable/c/425a571a7e6fc389954cf2564e1edbba3740e171
- https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25
- https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d
- https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f
- https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-21
CVE-2024-26846
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue. While at it, remove the unused nvme_fc_wq workqueue too.
- https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17
- https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c
- https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2
- https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982
- https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9
- https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67
- https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17
- https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c
- https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2
- https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982
- https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9
- https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2026-04-18
CVE-2024-26849
In the Linux kernel, the following vulnerability has been resolved: netlink: add nla be16/32 types to minlen array BUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline] BUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline] BUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline] BUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [inline] nla_validate_int_range lib/nlattr.c:336 [inline] validate_nla lib/nlattr.c:575 [inline] ... The message in question matches this policy: [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255), but because NLA_BE32 size in minlen array is 0, the validation code will read past the malformed (too small) attribute. Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing: those likely should be added too.
- https://git.kernel.org/stable/c/000a68159c0326b46c42ec712ab98793e7e625a7
- https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32
- https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d
- https://git.kernel.org/stable/c/80b40f9cb87f3bf5877dfb852765cf92bc03ca77
- https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a
- https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d
- https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32
- https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d
- https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a
- https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d
Modified: 2025-04-02
CVE-2024-26851
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
that are out of bounds for their data type.
vmlinux get_bitmap(b=75) + 712
- https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c
- https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591
- https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a
- https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362
- https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416
- https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb
- https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13
- https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc
- https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c
- https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591
- https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a
- https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362
- https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416
- https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb
- https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13
- https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-21
CVE-2024-26852
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
Commit f7225172f25a ("net/ipv6: prevent use after free in
ip6_route_mpath_notify") was not able to fix the root cause.
We need to defer the fib6_info_release() calls after
ip6_route_mpath_notify(), in the cleanup phase.
[1]
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
- https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136
- https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18
- https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda
- https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e
- https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab
- https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe
- https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24
- https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a
- https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136
- https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18
- https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda
- https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e
- https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab
- https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe
- https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24
- https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-02
CVE-2024-26853
In the Linux kernel, the following vulnerability has been resolved: igc: avoid returning frame twice in XDP_REDIRECT When a frame can not be transmitted in XDP_REDIRECT (e.g. due to a full queue), it is necessary to free it by calling xdp_return_frame_rx_napi. However, this is the responsibility of the caller of the ndo_xdp_xmit (see for example bq_xmit_all in kernel/bpf/devmap.c) and thus calling it inside igc_xdp_xmit (which is the ndo_xdp_xmit of the igc driver) as well will lead to memory corruption. In fact, bq_xmit_all expects that it can return all frames after the last successfully transmitted one. Therefore, break for the first not transmitted frame, but do not call xdp_return_frame_rx_napi in igc_xdp_xmit. This is equally implemented in other Intel drivers such as the igb. There are two alternatives to this that were rejected: 1. Return num_frames as all the frames would have been transmitted and release them inside igc_xdp_xmit. While it might work technically, it is not what the return value is meant to represent (i.e. the number of SUCCESSFULLY transmitted packets). 2. Rework kernel/bpf/devmap.c and all drivers to support non-consecutively dropped packets. Besides being complex, it likely has a negative performance impact without a significant gain since it is anyway unlikely that the next frame can be transmitted if the previous one was dropped. The memory corruption can be reproduced with the following script which leads to a kernel panic after a few seconds. It basically generates more traffic than a i225 NIC can transmit and pushes it via XDP_REDIRECT from a virtual interface to the physical interface where frames get dropped. #!/bin/bash INTERFACE=enp4s0 INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex` sudo ip link add dev veth1 type veth peer name veth2 sudo ip link set up $INTERFACE sudo ip link set up veth1 sudo ip link set up veth2 cat << EOF > redirect.bpf.c SEC("prog") int redirect(struct xdp_md *ctx) { return bpf_redirect($INTERFACE_IDX, 0); } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o sudo ip link set veth2 xdp obj redirect.bpf.o cat << EOF > pass.bpf.c SEC("prog") int pass(struct xdp_md *ctx) { return XDP_PASS; } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o sudo ip link set $INTERFACE xdp obj pass.bpf.o cat << EOF > trafgen.cfg { /* Ethernet Header */ 0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, const16(ETH_P_IP), /* IPv4 Header */ 0b01000101, 0, # IPv4 version, IHL, TOS const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header)) const16(2), # IPv4 ident 0b01000000, 0, # IPv4 flags, fragmentation off 64, # IPv4 TTL 17, # Protocol UDP csumip(14, 33), # IPv4 checksum /* UDP Header */ 10, 0, 1, 1, # IP Src - adapt as needed 10, 0, 1, 2, # IP Dest - adapt as needed const16(6666), # UDP Src Port const16(6666), # UDP Dest Port const16(1008), # UDP length (UDP header 8 bytes + payload length) csumudp(14, 34), # UDP checksum /* Payload */ fill('W', 1000), } EOF sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp
- https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f
- https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2
- https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a
- https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b
- https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f
- https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2
- https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a
- https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b
Modified: 2025-01-07
CVE-2024-26855
In the Linux kernel, the following vulnerability has been resolved: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() The function ice_bridge_setlink() may encounter a NULL pointer dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration.
- https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c
- https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f
- https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3
- https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309
- https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19
- https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596
- https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb
- https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c
- https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f
- https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3
- https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309
- https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19
- https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596
- https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26856
In the Linux kernel, the following vulnerability has been resolved: net: sparx5: Fix use after free inside sparx5_del_mact_entry Based on the static analyzis of the code it looks like when an entry from the MAC table was removed, the entry was still used after being freed. More precise the vid of the mac_entry was used after calling devm_kfree on the mac_entry. The fix consists in first using the vid of the mac_entry to delete the entry from the HW and after that to free it.
- https://git.kernel.org/stable/c/0de693d68b0a18d5e256556c7c62d92cca35ad52
- https://git.kernel.org/stable/c/71809805b95052ff551922f11660008fb3666025
- https://git.kernel.org/stable/c/89d72d4125e94aa3c2140fedd97ce07ba9e37674
- https://git.kernel.org/stable/c/e46274df1100fb0c06704195bfff5bfbd418bf64
- https://git.kernel.org/stable/c/e83bebb718fd1f42549358730e1206164e0861d6
- https://git.kernel.org/stable/c/0de693d68b0a18d5e256556c7c62d92cca35ad52
- https://git.kernel.org/stable/c/71809805b95052ff551922f11660008fb3666025
- https://git.kernel.org/stable/c/89d72d4125e94aa3c2140fedd97ce07ba9e37674
- https://git.kernel.org/stable/c/e46274df1100fb0c06704195bfff5bfbd418bf64
- https://git.kernel.org/stable/c/e83bebb718fd1f42549358730e1206164e0861d6
Modified: 2025-03-21
CVE-2024-26857
In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
- https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca
- https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5
- https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74
- https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29
- https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5
- https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c
- https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914
- https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a
- https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca
- https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5
- https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74
- https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29
- https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5
- https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c
- https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914
- https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-04
CVE-2024-26859
In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge() 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp, 800 struct bnx2x_fastpath *fp, u16 index) 801 { 802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index]; 803 struct page *page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 To solve this issue, we need to verify page pool allocations before freeing.
- https://git.kernel.org/stable/c/3a9f78b297e08ca8e88ae3ecff1f6fe2766dc5eb
- https://git.kernel.org/stable/c/44f9f1abb0ecc43023225ab9539167facbabf0ec
- https://git.kernel.org/stable/c/4f37d3a7e004bbf560c21441ca9c022168017ec4
- https://git.kernel.org/stable/c/7bcc090c81116c66936a7415f2c6b1483a4bcfd9
- https://git.kernel.org/stable/c/8eebff95ce9558be66a36aa7cfb43223f3ab4699
- https://git.kernel.org/stable/c/8ffcd3ccdbda0c918c4a0f922ef1c17010f1b598
- https://git.kernel.org/stable/c/c51f8b6930db3f259b8820b589f2459d2df3fc68
- https://git.kernel.org/stable/c/cf7d8cba639ae792a42c2a137b495eac262ac36c
- https://git.kernel.org/stable/c/d27e2da94a42655861ca4baea30c8cd65546f25d
- https://git.kernel.org/stable/c/3a9f78b297e08ca8e88ae3ecff1f6fe2766dc5eb
- https://git.kernel.org/stable/c/44f9f1abb0ecc43023225ab9539167facbabf0ec
- https://git.kernel.org/stable/c/4f37d3a7e004bbf560c21441ca9c022168017ec4
- https://git.kernel.org/stable/c/7bcc090c81116c66936a7415f2c6b1483a4bcfd9
- https://git.kernel.org/stable/c/8eebff95ce9558be66a36aa7cfb43223f3ab4699
- https://git.kernel.org/stable/c/8ffcd3ccdbda0c918c4a0f922ef1c17010f1b598
- https://git.kernel.org/stable/c/c51f8b6930db3f259b8820b589f2459d2df3fc68
- https://git.kernel.org/stable/c/cf7d8cba639ae792a42c2a137b495eac262ac36c
- https://git.kernel.org/stable/c/d27e2da94a42655861ca4baea30c8cd65546f25d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-02
CVE-2024-26861
In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...
- https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6
- https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce
- https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b
- https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3
- https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0
- https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc
- https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed
- https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6
- https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce
- https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b
- https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3
- https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0
- https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc
- https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26862
In the Linux kernel, the following vulnerability has been resolved: packet: annotate data-races around ignore_outgoing ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt() Add appropriate READ_ONCE()/WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 [inline] dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 worker_thread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
- https://git.kernel.org/stable/c/2c02c5059c78a52d170bdee4a369b470de6deb37
- https://git.kernel.org/stable/c/68e84120319d4fc298fcdb14cf0bea6a0f64ffbd
- https://git.kernel.org/stable/c/6ebfad33161afacb3e1e59ed1c2feefef70f9f97
- https://git.kernel.org/stable/c/84c510411e321caff3c07e6cd0f917f06633cfc0
- https://git.kernel.org/stable/c/8b1e273c6afcf00d3c40a54ada7d6aac1b503b97
- https://git.kernel.org/stable/c/d35b62c224e70797f8a1c37fe9bc4b3e294b7560
- https://git.kernel.org/stable/c/ee413f30ec4fe94a0bdf32c8f042cb06fa913234
- https://git.kernel.org/stable/c/ef7eed7e11d23337310ecc2c014ecaeea52719c5
- https://git.kernel.org/stable/c/2c02c5059c78a52d170bdee4a369b470de6deb37
- https://git.kernel.org/stable/c/68e84120319d4fc298fcdb14cf0bea6a0f64ffbd
- https://git.kernel.org/stable/c/6ebfad33161afacb3e1e59ed1c2feefef70f9f97
- https://git.kernel.org/stable/c/84c510411e321caff3c07e6cd0f917f06633cfc0
- https://git.kernel.org/stable/c/8b1e273c6afcf00d3c40a54ada7d6aac1b503b97
- https://git.kernel.org/stable/c/d35b62c224e70797f8a1c37fe9bc4b3e294b7560
- https://git.kernel.org/stable/c/ee413f30ec4fe94a0bdf32c8f042cb06fa913234
- https://git.kernel.org/stable/c/ef7eed7e11d23337310ecc2c014ecaeea52719c5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-27
CVE-2024-26863
In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in hsr_get_node() KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.
- https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209
- https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122
- https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862
- https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a
- https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428
- https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e
- https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949
- https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6
- https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c
- https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209
- https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122
- https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862
- https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a
- https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428
- https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e
- https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949
- https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6
- https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-07
CVE-2024-26865
In the Linux kernel, the following vulnerability has been resolved:
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
syzkaller reported a warning of netns tracker [0] followed by KASAN
splat [1] and another ref tracker warning [1].
syzkaller could not find a repro, but in the log, the only suspicious
sequence was as follows:
18:26:22 executing program 1:
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
...
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
So, the scenario would be:
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
rds_tcp_listen_init().
2. syz-executor connect()s to it and creates a reqsk.
3. syz-executor exit()s immediately.
4. netns is dismantled. [0]
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
6. listener is freed after RCU grace period. [2]
Basically, reqsk assumes that the listener guarantees netns safety
until all reqsk timers are expired by holding the listener's refcount.
However, this was not the case for kernel sockets.
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
inet_twsk_purge()") fixed this issue only for per-netns ehash.
Let's apply the same fix for the global ehash.
[0]:
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
__sock_create (net/socket.c:1572)
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
rds_tcp_init_net (net/rds/tcp.c:577)
ops_init (net/core/net_namespace.c:137)
setup_net (net/core/net_namespace.c:340)
copy_net_ns (net/core/net_namespace.c:497)
create_new_namespaces (kernel/nsproxy.c:110)
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
ksys_unshare (kernel/fork.c:3429)
__x64_sys_unshare (kernel/fork.c:3496)
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
...
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
[1]:
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3
- https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24
- https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6
- https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500
- https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279
- https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3
- https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24
- https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6
- https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500
- https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279
Modified: 2025-01-27
CVE-2024-26866
In the Linux kernel, the following vulnerability has been resolved: spi: lpspi: Avoid potential use-after-free in probe() fsl_lpspi_probe() is allocating/disposing memory manually with spi_alloc_host()/spi_alloc_target(), but uses devm_spi_register_controller(). In case of error after the latter call the memory will be explicitly freed in the probe function by spi_controller_put() call, but used afterwards by "devm" management outside probe() (spi_unregister_controller() <- devm_spi_unregister() below). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 ... Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork
- https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f
- https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861
- https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68
- https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea
- https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f
- https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861
- https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68
- https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea
Modified: 2025-01-14
CVE-2024-26868
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix panic when nfs4_ff_layout_prepare_ds() fails
We've been seeing the following panic in production
BUG: kernel NULL pointer dereference, address: 0000000000000065
PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0
RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]
Call Trace:
- https://git.kernel.org/stable/c/31db25e3141b20e2a76a9f219eeca52e3cab126c
- https://git.kernel.org/stable/c/5ada9016b1217498fad876a3d5b07645cc955608
- https://git.kernel.org/stable/c/719fcafe07c12646691bd62d7f8d94d657fa0766
- https://git.kernel.org/stable/c/7ca651b4ec4a049f5a46a0e5ff921b86b91c47c5
- https://git.kernel.org/stable/c/dac068f164ad05b35e7c0be13f138c3f6adca58f
- https://git.kernel.org/stable/c/31db25e3141b20e2a76a9f219eeca52e3cab126c
- https://git.kernel.org/stable/c/5ada9016b1217498fad876a3d5b07645cc955608
- https://git.kernel.org/stable/c/719fcafe07c12646691bd62d7f8d94d657fa0766
- https://git.kernel.org/stable/c/7ca651b4ec4a049f5a46a0e5ff921b86b91c47c5
- https://git.kernel.org/stable/c/dac068f164ad05b35e7c0be13f138c3f6adca58f
Modified: 2025-05-07
CVE-2024-26869
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate meta inode pages forcely Below race case can cause data corruption: Thread A GC thread - gc_data_segment - ra_data_block - locked meta_inode page - f2fs_inplace_write_data - invalidate_mapping_pages : fail to invalidate meta_inode page due to lock failure or dirty|writeback status - f2fs_submit_page_bio : write last dirty data to old blkaddr - move_data_block - load old data from meta_inode page - f2fs_submit_page_write : write old data to new blkaddr Because invalidate_mapping_pages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncate_inode_pages_range() instead of invalidate_mapping_pages() to make sure meta_inode page will be dropped.
- https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253
- https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189
- https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65
- https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694
- https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253
- https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189
- https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65
- https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694
Modified: 2025-04-30
CVE-2024-26870
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size.
- https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb
- https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf
- https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65
- https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b
- https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768
- https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf
- https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a
- https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb
- https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf
- https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65
- https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b
- https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768
- https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf
- https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26872
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete.
- https://git.kernel.org/stable/c/6413e78086caf7bf15639923740da0d91fdfd090
- https://git.kernel.org/stable/c/7104a00fa37ae898a827381f1161fa3286c8b346
- https://git.kernel.org/stable/c/85570b91e4820a0db9d9432098778cafafa7d217
- https://git.kernel.org/stable/c/bdd895e0190c464f54f84579e7535d80276f0fc5
- https://git.kernel.org/stable/c/c21a8870c98611e8f892511825c9607f1e2cd456
- https://git.kernel.org/stable/c/e362d007294955a4fb929e1c8978154a64efdcb6
- https://git.kernel.org/stable/c/ec77fa12da41260c6bf9e060b89234b980c5130f
- https://git.kernel.org/stable/c/6413e78086caf7bf15639923740da0d91fdfd090
- https://git.kernel.org/stable/c/7104a00fa37ae898a827381f1161fa3286c8b346
- https://git.kernel.org/stable/c/85570b91e4820a0db9d9432098778cafafa7d217
- https://git.kernel.org/stable/c/bdd895e0190c464f54f84579e7535d80276f0fc5
- https://git.kernel.org/stable/c/c21a8870c98611e8f892511825c9607f1e2cd456
- https://git.kernel.org/stable/c/e362d007294955a4fb929e1c8978154a64efdcb6
- https://git.kernel.org/stable/c/ec77fa12da41260c6bf9e060b89234b980c5130f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-04
CVE-2024-26874
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use.
- https://git.kernel.org/stable/c/3fc88b246a2fc16014e374040fc15af1d3752535
- https://git.kernel.org/stable/c/4688be96d20ffa49d2186523ee84f475f316fd49
- https://git.kernel.org/stable/c/9acee29a38b4d4b70f1f583e5ef9a245db4db710
- https://git.kernel.org/stable/c/9beec711a17245b853d64488fd5b739031612340
- https://git.kernel.org/stable/c/a3dd12b64ae8373a41a216a0b621df224210860a
- https://git.kernel.org/stable/c/accdac6b71d5a2b84040c3d2234f53a60edc398e
- https://git.kernel.org/stable/c/c958e86e9cc1b48cac004a6e245154dfba8e163b
- https://git.kernel.org/stable/c/d2bd30c710475b2e29288827d2c91f9e6e2b91d7
- https://git.kernel.org/stable/c/dfde84cc6c589f2a9f820f12426d97365670b731
- https://git.kernel.org/stable/c/3fc88b246a2fc16014e374040fc15af1d3752535
- https://git.kernel.org/stable/c/4688be96d20ffa49d2186523ee84f475f316fd49
- https://git.kernel.org/stable/c/9acee29a38b4d4b70f1f583e5ef9a245db4db710
- https://git.kernel.org/stable/c/9beec711a17245b853d64488fd5b739031612340
- https://git.kernel.org/stable/c/a3dd12b64ae8373a41a216a0b621df224210860a
- https://git.kernel.org/stable/c/accdac6b71d5a2b84040c3d2234f53a60edc398e
- https://git.kernel.org/stable/c/c958e86e9cc1b48cac004a6e245154dfba8e163b
- https://git.kernel.org/stable/c/d2bd30c710475b2e29288827d2c91f9e6e2b91d7
- https://git.kernel.org/stable/c/dfde84cc6c589f2a9f820f12426d97365670b731
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-21
CVE-2024-26875
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix uaf in pvr2_context_set_notify
[Syzbot reported]
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: usb_hub_wq hub_event
Call Trace:
- https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee
- https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475
- https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a
- https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592
- https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f
- https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb
- https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16
- https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7
- https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c
- https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee
- https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475
- https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a
- https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592
- https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f
- https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb
- https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16
- https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7
- https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-26877
In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling crypto_finalize_request, BH should be disabled to avoid
triggering the following calltrace:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
Modules linked in: cryptodev(O)
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : crypto_finalize_request+0xa0/0x118
lr : crypto_finalize_request+0x104/0x118
sp : ffffffc085353ce0
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
Call trace:
crypto_finalize_request+0xa0/0x118
crypto_finalize_aead_request+0x18/0x30
zynqmp_handle_aes_req+0xcc/0x388
crypto_pump_work+0x168/0x2d8
kthread_worker_fn+0xfc/0x3a0
kthread+0x118/0x138
ret_from_fork+0x10/0x20
irq event stamp: 40
hardirqs last enabled at (39): [
- https://git.kernel.org/stable/c/03e6d4e948432a61b35783323b6ab2be071d2619
- https://git.kernel.org/stable/c/23bc89fdce71124cd2126fc919c7076e7cb489cf
- https://git.kernel.org/stable/c/8a01335aedc50a66d04dd39203c89f4bc8042596
- https://git.kernel.org/stable/c/9db89b1fb85557892e6681724b367287de5f9f20
- https://git.kernel.org/stable/c/a71f66bd5f7b9b35a8aaa49e29565eca66299399
- https://git.kernel.org/stable/c/a853450bf4c752e664abab0b2fad395b7ad7701c
- https://git.kernel.org/stable/c/dbf291d8ffffb70f48286176a15c6c54f0bb0743
- https://git.kernel.org/stable/c/03e6d4e948432a61b35783323b6ab2be071d2619
- https://git.kernel.org/stable/c/23bc89fdce71124cd2126fc919c7076e7cb489cf
- https://git.kernel.org/stable/c/8a01335aedc50a66d04dd39203c89f4bc8042596
- https://git.kernel.org/stable/c/9db89b1fb85557892e6681724b367287de5f9f20
- https://git.kernel.org/stable/c/a71f66bd5f7b9b35a8aaa49e29565eca66299399
- https://git.kernel.org/stable/c/a853450bf4c752e664abab0b2fad395b7ad7701c
- https://git.kernel.org/stable/c/dbf291d8ffffb70f48286176a15c6c54f0bb0743
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-14
CVE-2024-26878
In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue.
- https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25
- https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5
- https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0
- https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0
- https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877
- https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754
- https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1
- https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f
- https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7
- https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25
- https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5
- https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0
- https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0
- https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877
- https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754
- https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1
- https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f
- https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-27
CVE-2024-26879
In the Linux kernel, the following vulnerability has been resolved: clk: meson: Add missing clocks to axg_clk_regmaps Some clocks were missing from axg_clk_regmaps, which caused kernel panic during cat /sys/kernel/debug/clk/clk_summary [ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc ... [ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.436900] pc : regmap_read+0x1c/0x88 [ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.445611] sp : ffff800082f1b690 [ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70 [ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000 [ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000 [ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff [ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000 [ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100 [ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24 [ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710 [ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000 [ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000 [ 57.519615] Call trace: [ 57.522030] regmap_read+0x1c/0x88 [ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.530050] clk_core_is_enabled+0x44/0x120 [ 57.534190] clk_summary_show_subtree+0x154/0x2f0 [ 57.538847] clk_summary_show_subtree+0x220/0x2f0 [ 57.543505] clk_summary_show_subtree+0x220/0x2f0 [ 57.548162] clk_summary_show_subtree+0x220/0x2f0 [ 57.552820] clk_summary_show_subtree+0x220/0x2f0 [ 57.557477] clk_summary_show_subtree+0x220/0x2f0 [ 57.562135] clk_summary_show_subtree+0x220/0x2f0 [ 57.566792] clk_summary_show_subtree+0x220/0x2f0 [ 57.571450] clk_summary_show+0x84/0xb8 [ 57.575245] seq_read_iter+0x1bc/0x4b8 [ 57.578954] seq_read+0x8c/0xd0 [ 57.582059] full_proxy_read+0x68/0xc8 [ 57.585767] vfs_read+0xb0/0x268 [ 57.588959] ksys_read+0x70/0x108 [ 57.592236] __arm64_sys_read+0x24/0x38 [ 57.596031] invoke_syscall+0x50/0x128 [ 57.599740] el0_svc_common.constprop.0+0x48/0xf8 [ 57.604397] do_el0_svc+0x28/0x40 [ 57.607675] el0_svc+0x34/0xb8 [ 57.610694] el0t_64_sync_handler+0x13c/0x158 [ 57.615006] el0t_64_sync+0x190/0x198 [ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00) [ 57.624668] ---[ end trace 0000000000000000 ]--- [jbrunet: add missing Fixes tag]
- https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7
- https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202
- https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8
- https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84
- https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10
- https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418
- https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7
- https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202
- https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8
- https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84
- https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10
- https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418
Modified: 2025-12-23
CVE-2024-26880
In the Linux kernel, the following vulnerability has been resolved:
dm: call the resume method on internal suspend
There is this reported crash when experimenting with the lvm2 testsuite.
The list corruption is caused by the fact that the postsuspend and resume
methods were not paired correctly; there were two consecutive calls to the
origin_postsuspend function. The second call attempts to remove the
"hash_list" entry from a list, while it was already removed by the first
call.
Fix __dm_internal_resume so that it calls the preresume and resume
methods of the table's targets.
If a preresume method of some target fails, we are in a tricky situation.
We can't return an error because dm_internal_resume isn't supposed to
return errors. We can't return success, because then the "resume" and
"postsuspend" methods would not be paired correctly. So, we set the
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
tools, but it won't cause a kernel crash.
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:56!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
- https://git.kernel.org/stable/c/03ad5ad53e51abf3a4c7538c1bc67a5982b41dc5
- https://git.kernel.org/stable/c/15a3fc5c8774c17589dabfe1d642d40685c985af
- https://git.kernel.org/stable/c/360a7d1be8112654f1fb328ed3862be630bca3f4
- https://git.kernel.org/stable/c/65e8fbde64520001abf1c8d0e573561b4746ef38
- https://git.kernel.org/stable/c/69836d9329f0b4c58faaf3d886a7748ddb5bf718
- https://git.kernel.org/stable/c/ad10289f68f45649816cc68eb93f45fd5ec48a15
- https://git.kernel.org/stable/c/da7ece2197101b1469853e6b5e915be1e3896d52
- https://git.kernel.org/stable/c/ef02d8edf738557af2865c5bfb66a03c4e071be7
- https://git.kernel.org/stable/c/f89bd27709376d37ff883067193320c58a8c1d5a
- https://git.kernel.org/stable/c/03ad5ad53e51abf3a4c7538c1bc67a5982b41dc5
- https://git.kernel.org/stable/c/15a3fc5c8774c17589dabfe1d642d40685c985af
- https://git.kernel.org/stable/c/360a7d1be8112654f1fb328ed3862be630bca3f4
- https://git.kernel.org/stable/c/65e8fbde64520001abf1c8d0e573561b4746ef38
- https://git.kernel.org/stable/c/69836d9329f0b4c58faaf3d886a7748ddb5bf718
- https://git.kernel.org/stable/c/ad10289f68f45649816cc68eb93f45fd5ec48a15
- https://git.kernel.org/stable/c/da7ece2197101b1469853e6b5e915be1e3896d52
- https://git.kernel.org/stable/c/ef02d8edf738557af2865c5bfb66a03c4e071be7
- https://git.kernel.org/stable/c/f89bd27709376d37ff883067193320c58a8c1d5a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26881
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is received on HIP08 devices The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash: [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] __handle_domain_irq+0x88/0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.460717] cpu_startup_entry+0x30/0xfc [ 5889.465523] secondary_start_kernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel...
- https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3
- https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4
- https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265
- https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70
- https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6
- https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108
- https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3
- https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4
- https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265
- https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70
- https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6
- https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108
Modified: 2024-12-20
CVE-2024-26882
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
- https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a
- https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a
- https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80
- https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3
- https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0
- https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1
- https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b
- https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5
- https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a
- https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a
- https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80
- https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3
- https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0
- https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1
- https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b
- https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20241220-0002/
Modified: 2025-03-07
CVE-2024-26883
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check on 32-bit arches The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem.
- https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a
- https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895
- https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d
- https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0
- https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a
- https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b
- https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae
- https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3
- https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d
- https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a
- https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895
- https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d
- https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0
- https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a
- https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b
- https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae
- https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3
- https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26884
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup.
- https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5
- https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d
- https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6
- https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1
- https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868
- https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace
- https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016
- https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93
- https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e
- https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5
- https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d
- https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6
- https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1
- https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868
- https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace
- https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016
- https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93
- https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-24
CVE-2024-26885
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation.
- https://git.kernel.org/stable/c/1f5e352b9088211fa5eb4e1639cd365f4f7d2f65
- https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c
- https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691
- https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3
- https://git.kernel.org/stable/c/4b81a9f92b3676cb74b907a7a209b3d15bd9a7f9
- https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3
- https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c
- https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737
- https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c
- https://git.kernel.org/stable/c/225da02acdc97af01b6bc6ce1a3e5362bf01d3fb
- https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691
- https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3
- https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3
- https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c
- https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-21
CVE-2024-26886
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: af_bluetooth: Fix deadlock
Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
bellow, so instead of using sock_sock this uses sk_receive_queue.lock
on bt_sock_ioctl to avoid the UAF:
INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
Not tainted 6.7.6-lemon #183
Workqueue: hci0 hci_rx_work
Call Trace:
- https://git.kernel.org/stable/c/2c9e2df022ef8b9d7fac58a04a2ef4ed25288955
- https://git.kernel.org/stable/c/64be3c6154886200708da0dfe259705fb992416c
- https://git.kernel.org/stable/c/817e8138ce86001b2fa5c63d6ede756e205a01f7
- https://git.kernel.org/stable/c/f7b94bdc1ec107c92262716b073b3e816d4784fb
- https://git.kernel.org/stable/c/2c9e2df022ef8b9d7fac58a04a2ef4ed25288955
- https://git.kernel.org/stable/c/64be3c6154886200708da0dfe259705fb992416c
- https://git.kernel.org/stable/c/817e8138ce86001b2fa5c63d6ede756e205a01f7
- https://git.kernel.org/stable/c/cb8adca52f306563d958a863bb0cbae9c184d1ae
- https://git.kernel.org/stable/c/f7b94bdc1ec107c92262716b073b3e816d4784fb
Modified: 2025-03-21
CVE-2024-26889
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix possible buffer overflow struct hci_dev_info has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy.
- https://git.kernel.org/stable/c/2e845867b4e279eff0a19ade253390470e07e8a1
- https://git.kernel.org/stable/c/2edce8e9a99dd5e4404259d52e754fdc97fb42c2
- https://git.kernel.org/stable/c/54a03e4ac1a41edf8a5087bd59f8241b0de96d3d
- https://git.kernel.org/stable/c/6d5a9d4a7bcbb7534ce45a18a52e7bd23e69d8ac
- https://git.kernel.org/stable/c/81137162bfaa7278785b24c1fd2e9e74f082e8e4
- https://git.kernel.org/stable/c/8c28598a2c29201d2ba7fc37539a7d41c264fb10
- https://git.kernel.org/stable/c/a41c8efe659caed0e21422876bbb6b73c15b5244
- https://git.kernel.org/stable/c/d47e6c1932cee02954ea588c9f09fd5ecefeadfc
- https://git.kernel.org/stable/c/2e845867b4e279eff0a19ade253390470e07e8a1
- https://git.kernel.org/stable/c/2edce8e9a99dd5e4404259d52e754fdc97fb42c2
- https://git.kernel.org/stable/c/54a03e4ac1a41edf8a5087bd59f8241b0de96d3d
- https://git.kernel.org/stable/c/68644bf5ec6baaff40fc39b3529c874bfda709bd
- https://git.kernel.org/stable/c/6d5a9d4a7bcbb7534ce45a18a52e7bd23e69d8ac
- https://git.kernel.org/stable/c/81137162bfaa7278785b24c1fd2e9e74f082e8e4
- https://git.kernel.org/stable/c/8c28598a2c29201d2ba7fc37539a7d41c264fb10
- https://git.kernel.org/stable/c/a41c8efe659caed0e21422876bbb6b73c15b5244
- https://git.kernel.org/stable/c/d47e6c1932cee02954ea588c9f09fd5ecefeadfc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-05-07
CVE-2024-26891
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected
For those endpoint devices connect to system via hotplug capable ports,
users could request a hot reset to the device by flapping device's link
through setting the slot's link control register, as pciehp_ist() DLLSC
interrupt sequence response, pciehp will unload the device driver and
then power it off. thus cause an IOMMU device-TLB invalidation (Intel
VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence
target device to be sent and deadly loop to retry that request after ITE
fault triggered in interrupt context.
That would cause following continuous hard lockup warning and system hang
[ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down
[ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present
[ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144
[ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
OE kernel version xxxx
[ 4223.822623] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490
[ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b
57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1
0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39
[ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093
[ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005
[ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340
[ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000
[ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200
[ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004
[ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000)
knlGS:0000000000000000
[ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0
[ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 4223.822628] PKRU: 55555554
[ 4223.822628] Call Trace:
[ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0
[ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250
[ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50
[ 4223.822629] intel_iommu_release_device+0x1f/0x30
[ 4223.822629] iommu_release_device+0x33/0x60
[ 4223.822629] iommu_bus_notifier+0x7f/0x90
[ 4223.822630] blocking_notifier_call_chain+0x60/0x90
[ 4223.822630] device_del+0x2e5/0x420
[ 4223.822630] pci_remove_bus_device+0x70/0x110
[ 4223.822630] pciehp_unconfigure_device+0x7c/0x130
[ 4223.822631] pciehp_disable_slot+0x6b/0x100
[ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320
[ 4223.822631] pciehp_ist+0x176/0x180
[ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110
[ 4223.822632] irq_thread_fn+0x19/0x50
[ 4223.822632] irq_thread+0x104/0x190
[ 4223.822632] ? irq_forced_thread_fn+0x90/0x90
[ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0
[ 4223.822633] kthread+0x114/0x130
[ 4223.822633] ? __kthread_cancel_work+0x40/0x40
[ 4223.822633] ret_from_fork+0x1f/0x30
[ 4223.822633] Kernel panic - not syncing: Hard LOCKUP
[ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
OE kernel version xxxx
[ 4223.822634] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822634] Call Trace:
[ 4223.822634]
- https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05
- https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062
- https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf
- https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b
- https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868
- https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554
- https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85
- https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05
- https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062
- https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf
- https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b
- https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868
- https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554
- https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-27
CVE-2024-26893
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in SMC transport cleanup path When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash.
- https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4
- https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c
- https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773
- https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d
- https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd
- https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4
- https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c
- https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773
- https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d
- https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd
Modified: 2025-03-21
CVE-2024-26894
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[
- https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2
- https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc
- https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e
- https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5
- https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9
- https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa
- https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51
- https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d
- https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8
- https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2
- https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc
- https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e
- https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5
- https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9
- https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa
- https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51
- https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d
- https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-26895
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver: echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind ================================================================== BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86 CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c [...] Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28 Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...] David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list. Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev) Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe. [1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/
- https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9
- https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447
- https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208
- https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb
- https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f
- https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c
- https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1
- https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9
- https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447
- https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208
- https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb
- https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f
- https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c
- https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-21
CVE-2024-26896
In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix memory leak when starting AP
Kmemleak reported this error:
unreferenced object 0xd73d1180 (size 184):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
backtrace:
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
[<127bdd74>] __alloc_skb+0x144/0x170
[
- https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3
- https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b
- https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3
- https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc
- https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487
- https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3
- https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b
- https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3
- https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc
- https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487
Modified: 2025-12-23
CVE-2024-26897
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data structures have been fully initialised by the time it runs. However, because of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k driver initialisation is completed. We already committed a partial fix for this in commit: 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()") However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event tasklet, pairing it with an "initialisation complete" bit in the TX struct. It seems syzbot managed to trigger the race for one of the other commands as well, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside ath9k_tx_init()).
- https://git.kernel.org/stable/c/1bc5461a21c56a36e2a7d81e152b90ce019a3905
- https://git.kernel.org/stable/c/24355fcb0d4cbcb6ddda262596558e8cfba70f11
- https://git.kernel.org/stable/c/4afa0246656d5680c8a4c3fb37ba6570c4ab819b
- https://git.kernel.org/stable/c/74d0639261dd795dce958d1b14815bdcbb48a715
- https://git.kernel.org/stable/c/a015fbf698c8957aa5fbeefc5c59dd2cf3107298
- https://git.kernel.org/stable/c/ac90e22e735bac44f74b5161fb096fbeb0ff8bc2
- https://git.kernel.org/stable/c/f8ff4b4df71e87f609be0cc37d92e918107f9b90
- https://git.kernel.org/stable/c/1bc5461a21c56a36e2a7d81e152b90ce019a3905
- https://git.kernel.org/stable/c/24355fcb0d4cbcb6ddda262596558e8cfba70f11
- https://git.kernel.org/stable/c/4afa0246656d5680c8a4c3fb37ba6570c4ab819b
- https://git.kernel.org/stable/c/74d0639261dd795dce958d1b14815bdcbb48a715
- https://git.kernel.org/stable/c/a015fbf698c8957aa5fbeefc5c59dd2cf3107298
- https://git.kernel.org/stable/c/ac90e22e735bac44f74b5161fb096fbeb0ff8bc2
- https://git.kernel.org/stable/c/f8ff4b4df71e87f609be0cc37d92e918107f9b90
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-26898
In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts This patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in kthread. Which means that the dev_put(ifp) should NOT be called in the success path of skb initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into use-after-free because the net_device is freed. This patch removed the dev_put(ifp) in the success path in aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().
- https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c
- https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881
- https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa
- https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4
- https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e
- https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99
- https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62
- https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662
- https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65
- https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c
- https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881
- https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa
- https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4
- https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e
- https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99
- https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62
- https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662
- https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26901
In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem.
- https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43
- https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71
- https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1
- https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b
- https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b
- https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b
- https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730
- https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126
- https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6
- https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43
- https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71
- https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1
- https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b
- https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b
- https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b
- https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730
- https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126
- https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26902
In the Linux kernel, the following vulnerability has been resolved:
perf: RISCV: Fix panic on pmu overflow handler
(1 << idx) of int is not desired when setting bits in unsigned long
overflowed_ctrs, use BIT() instead. This panic happens when running
'perf record -e branches' on sophgo sg2042.
[ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[ 273.320851] Oops [#1]
[ 273.323179] Modules linked in:
[ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9
[ 273.332521] Hardware name: Sophgo Mango (DT)
[ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62
[ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e
[ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0
[ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978
[ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70
[ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000
[ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015
[ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a
[ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0
[ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210
[ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098
[ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca
[ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8
[ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d
[ 273.434512] [
- https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c
- https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9
- https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6
- https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c
- https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9
- https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6
Modified: 2024-11-21
CVE-2024-26903
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx.
- https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26
- https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b
- https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5
- https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73
- https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85
- https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd
- https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96
- https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0
- https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26
- https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b
- https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5
- https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73
- https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85
- https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd
- https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96
- https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-16
CVE-2024-26906
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault()
When trying to use copy_from_kernel_nofault() to read vsyscall page
through a bpf program, the following oops was reported:
BUG: unable to handle page fault for address: ffffffffff600000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
RIP: 0010:copy_from_kernel_nofault+0x6f/0x110
......
Call Trace:
- https://git.kernel.org/stable/c/29bd6f86904682adafe9affbc7f79b14defcaff8
- https://git.kernel.org/stable/c/32019c659ecfe1d92e3bf9fcdfbb11a7c70acd58
- https://git.kernel.org/stable/c/57f78c46f08198e1be08ffe99c4c1ccc12855bf5
- https://git.kernel.org/stable/c/6e4694e65b6db4c3de125115dd4f55848cc48381
- https://git.kernel.org/stable/c/e8a67fe34b76a49320b33032228a794f40b0316b
- https://git.kernel.org/stable/c/f175de546a3eb77614d94d4c02550181c0a8493e
- https://git.kernel.org/stable/c/29bd6f86904682adafe9affbc7f79b14defcaff8
- https://git.kernel.org/stable/c/32019c659ecfe1d92e3bf9fcdfbb11a7c70acd58
- https://git.kernel.org/stable/c/57f78c46f08198e1be08ffe99c4c1ccc12855bf5
- https://git.kernel.org/stable/c/6e4694e65b6db4c3de125115dd4f55848cc48381
- https://git.kernel.org/stable/c/e8a67fe34b76a49320b33032228a794f40b0316b
- https://git.kernel.org/stable/c/f175de546a3eb77614d94d4c02550181c0a8493e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-26907
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
------------[ cut here ]------------
memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
[last unloaded: mlx_compat(OE)]
CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c
- https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350
- https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d
- https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd
- https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21
- https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa
- https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c
- https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350
- https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d
- https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd
- https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21
- https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-26910
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback.
- https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c
- https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb
- https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001
- https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05
- https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397
- https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49
- https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225
- https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c
- https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb
- https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001
- https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05
- https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397
- https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49
- https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-26915
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reset IH OVERFLOW_CLEAR bit Allows us to detect subsequent IH ring buffer overflows as well.
- https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d
- https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd
- https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70
- https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1
- https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2
- https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d
- https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd
- https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70
- https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1
- https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2
Modified: 2025-09-16
CVE-2024-26916
In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amd: flush any delayed gfxoff on suspend entry" commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks") caused GFXOFF control to be used more heavily and the codepath that was removed from commit 0dee72639533 ("drm/amd: flush any delayed gfxoff on suspend entry") now can be exercised at suspend again. Users report that by using GNOME to suspend the lockscreen trigger will cause SDMA traffic and the system can deadlock. This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.
- https://git.kernel.org/stable/c/65158edb0a3a8df23197d52cd24287e39eaf95d6
- https://git.kernel.org/stable/c/916361685319098f696b798ef1560f69ed96e934
- https://git.kernel.org/stable/c/caa2565a2e13899be31f7b1e069e6465d3e2adb0
- https://git.kernel.org/stable/c/d855ceb6a5fde668c5431156bc60fae0cc52b764
- https://git.kernel.org/stable/c/ff70e6ff6fc2413caf33410af7462d1f584d927e
- https://git.kernel.org/stable/c/65158edb0a3a8df23197d52cd24287e39eaf95d6
- https://git.kernel.org/stable/c/916361685319098f696b798ef1560f69ed96e934
- https://git.kernel.org/stable/c/caa2565a2e13899be31f7b1e069e6465d3e2adb0
- https://git.kernel.org/stable/c/d855ceb6a5fde668c5431156bc60fae0cc52b764
- https://git.kernel.org/stable/c/ff70e6ff6fc2413caf33410af7462d1f584d927e
Modified: 2025-02-03
CVE-2024-26917
In the Linux kernel, the following vulnerability has been resolved: scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock" This reverts commit 1a1975551943f681772720f639ff42fbaa746212. This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave". Instead, a work queue should be used, and will be addressed in a separate commit.
- https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b
- https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21
- https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783
- https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5
- https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0
- https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b
- https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6
- https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb
- https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b
- https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21
- https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783
- https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5
- https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0
- https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b
- https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6
- https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-16
CVE-2024-26919
In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: Fix debugfs directory leak The ULPI per-device debugfs root is named after the ulpi device's parent, but ulpi_unregister_interface tries to remove a debugfs directory named after the ulpi device itself. This results in the directory sticking around and preventing subsequent (deferred) probes from succeeding. Change the directory name to match the ulpi device.
- https://git.kernel.org/stable/c/330d22aba17a4d30a56f007d0f51291d7e00862b
- https://git.kernel.org/stable/c/33713945cc92ea9c4a1a9479d5c1b7acb7fc4df3
- https://git.kernel.org/stable/c/3caf2b2ad7334ef35f55b95f3e1b138c6f77b368
- https://git.kernel.org/stable/c/d31b886ed6a5095214062ee4fb55037eb930adb6
- https://git.kernel.org/stable/c/330d22aba17a4d30a56f007d0f51291d7e00862b
- https://git.kernel.org/stable/c/33713945cc92ea9c4a1a9479d5c1b7acb7fc4df3
- https://git.kernel.org/stable/c/3caf2b2ad7334ef35f55b95f3e1b138c6f77b368
- https://git.kernel.org/stable/c/d31b886ed6a5095214062ee4fb55037eb930adb6
Modified: 2025-09-16
CVE-2024-26920
In the Linux kernel, the following vulnerability has been resolved: tracing/trigger: Fix to return error if failed to alloc snapshot Fix register_snapshot_trigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error.
- https://git.kernel.org/stable/c/0958b33ef5a04ed91f61cef4760ac412080c4e08
- https://git.kernel.org/stable/c/36be97e9eb535fe3008a5cb040b1e56f29f2e398
- https://git.kernel.org/stable/c/4b001ef14baab16b553a002cb9979e31b8fc0c6b
- https://git.kernel.org/stable/c/6022c065c9ec465d84cebff8f480db083e4ee06b
- https://git.kernel.org/stable/c/0958b33ef5a04ed91f61cef4760ac412080c4e08
- https://git.kernel.org/stable/c/2450a69d2ee75d1f0112d509ac82ef98f5ad6b5f
- https://git.kernel.org/stable/c/26ebeffff238488466fa578be3b35b8a46e69906
- https://git.kernel.org/stable/c/2a3073d58382157ab396734ed4e421ba9e969db1
- https://git.kernel.org/stable/c/34925d01baf3ee62ab21c21efd9e2c44c24c004a
- https://git.kernel.org/stable/c/36be97e9eb535fe3008a5cb040b1e56f29f2e398
- https://git.kernel.org/stable/c/4b001ef14baab16b553a002cb9979e31b8fc0c6b
- https://git.kernel.org/stable/c/56cfbe60710772916a5ba092c99542332b48e870
- https://git.kernel.org/stable/c/6022c065c9ec465d84cebff8f480db083e4ee06b
- https://git.kernel.org/stable/c/8ffd5590f4d6ef5460acbeac7fbdff7025f9b419
- https://git.kernel.org/stable/c/b5085b5ac1d96ea2a8a6240f869655176ce44197
- https://git.kernel.org/stable/c/bcf4a115a5068f3331fafb8c176c1af0da3d8b19
Modified: 2025-03-21
CVE-2024-26927
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Add some bounds checking to firmware data Smatch complains about "head->full_size - head->header_size" can underflow. To some extent, we're always going to have to trust the firmware a bit. However, it's easy enough to add a check for negatives, and let's add a upper bounds check as well.
- https://git.kernel.org/stable/c/044e220667157fb9d59320341badec59cf45ba48
- https://git.kernel.org/stable/c/98f681b0f84cfc3a1d83287b77697679e0398306
- https://git.kernel.org/stable/c/9eeb8e1231f6450c574c1db979122e171a1813ab
- https://git.kernel.org/stable/c/ced7df8b3c5c4751244cad79011e86cf1f809153
- https://git.kernel.org/stable/c/d133d67e7e724102d1e53009c4f88afaaf3e167c
- https://git.kernel.org/stable/c/044e220667157fb9d59320341badec59cf45ba48
- https://git.kernel.org/stable/c/98f681b0f84cfc3a1d83287b77697679e0398306
- https://git.kernel.org/stable/c/9eeb8e1231f6450c574c1db979122e171a1813ab
- https://git.kernel.org/stable/c/ced7df8b3c5c4751244cad79011e86cf1f809153
- https://git.kernel.org/stable/c/d133d67e7e724102d1e53009c4f88afaaf3e167c
Modified: 2025-09-18
CVE-2024-27023
In the Linux kernel, the following vulnerability has been resolved: md: Fix missing release of 'active_io' for flush submit_flushes atomic_set(&mddev->flush_pending, 1); rdev_for_each_rcu(rdev, mddev) atomic_inc(&mddev->flush_pending); bi->bi_end_io = md_end_flush submit_bio(bi); /* flush io is done first */ md_end_flush if (atomic_dec_and_test(&mddev->flush_pending)) percpu_ref_put(&mddev->active_io) -> active_io is not released if (atomic_dec_and_test(&mddev->flush_pending)) -> missing release of active_io For consequence, mddev_suspend() will wait for 'active_io' to be zero forever. Fix this problem by releasing 'active_io' in submit_flushes() if 'flush_pending' is decreased to zero.
- https://git.kernel.org/stable/c/02dad157ba11064d073f5499dc33552b227d5d3a
- https://git.kernel.org/stable/c/11f81438927f84edfaaeb5d5f10856c3a1c1fc82
- https://git.kernel.org/stable/c/6b2ff10390b19a2364af622b6666b690443f9f3f
- https://git.kernel.org/stable/c/855678ed8534518e2b428bcbcec695de9ba248e8
- https://git.kernel.org/stable/c/02dad157ba11064d073f5499dc33552b227d5d3a
- https://git.kernel.org/stable/c/11f81438927f84edfaaeb5d5f10856c3a1c1fc82
- https://git.kernel.org/stable/c/6b2ff10390b19a2364af622b6666b690443f9f3f
- https://git.kernel.org/stable/c/855678ed8534518e2b428bcbcec695de9ba248e8
Modified: 2024-12-23
CVE-2024-27024
In the Linux kernel, the following vulnerability has been resolved: net/rds: fix WARNING in rds_conn_connect_if_down If connection isn't established yet, get_mr() will fail, trigger connection after get_mr().
- https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85
- https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4
- https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1
- https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b
- https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80
- https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2
- https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0
- https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38
- https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85
- https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4
- https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1
- https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b
- https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80
- https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2
- https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0
- https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27025
In the Linux kernel, the following vulnerability has been resolved: nbd: null check for nla_nest_start nla_nest_start() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code.
- https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d
- https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e
- https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced
- https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8
- https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797
- https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983
- https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a
- https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf
- https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d
- https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e
- https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced
- https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8
- https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797
- https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983
- https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a
- https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27028
In the Linux kernel, the following vulnerability has been resolved: spi: spi-mt65xx: Fix NULL pointer access in interrupt handler The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes. Add a check to trans->tx_buf before using it.
- https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713
- https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38
- https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6
- https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753
- https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4
- https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55
- https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11
- https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4
- https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62
- https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713
- https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38
- https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6
- https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753
- https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4
- https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55
- https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11
- https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4
- https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27030
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Use separate handlers for interrupts For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data.
- https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44
- https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701
- https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c
- https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a
- https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70
- https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2
- https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c
- https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d
- https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44
- https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701
- https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c
- https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a
- https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70
- https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2
- https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c
- https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27032
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential panic during recovery During recovery, if FAULT_BLOCK is on, it is possible that f2fs_reserve_new_block() will return -ENOSPC during recovery, then it may trigger panic. Also, if fault injection rate is 1 and only FAULT_BLOCK fault type is on, it may encounter deadloop in loop of block reservation. Let's change as below to fix these issues: - remove bug_on() to avoid panic. - limit the loop count of block reservation to avoid potential deadloop.
- https://git.kernel.org/stable/c/21ec68234826b1b54ab980a8df6e33c74cfbee58
- https://git.kernel.org/stable/c/8844b2f8a3f0c428b74672f9726f9950b1a7764c
- https://git.kernel.org/stable/c/d034810d02a5af8eb74debe29877dcaf5f00fdd1
- https://git.kernel.org/stable/c/f26091a981318b5b7451d61f99bc073a6af8db67
- https://git.kernel.org/stable/c/fe4de493572a4263554903bf9c3afc5c196e15f0
- https://git.kernel.org/stable/c/21ec68234826b1b54ab980a8df6e33c74cfbee58
- https://git.kernel.org/stable/c/8844b2f8a3f0c428b74672f9726f9950b1a7764c
- https://git.kernel.org/stable/c/d034810d02a5af8eb74debe29877dcaf5f00fdd1
- https://git.kernel.org/stable/c/f26091a981318b5b7451d61f99bc073a6af8db67
- https://git.kernel.org/stable/c/fe4de493572a4263554903bf9c3afc5c196e15f0
Modified: 2025-09-18
CVE-2024-27034
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover normal cluster write with cp_rwsem When we overwrite compressed cluster w/ normal cluster, we should not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data will be corrupted if partial blocks were persisted before CP & SPOR, due to cluster metadata wasn't updated atomically.
- https://git.kernel.org/stable/c/2b1b14d9fc94b8feae20808684c8af28ec80f45b
- https://git.kernel.org/stable/c/52982edfcefd475cc34af663d5c47c0cddaa5739
- https://git.kernel.org/stable/c/542c8b3c774a480bfd0804291a12f6f2391b0cd1
- https://git.kernel.org/stable/c/75abfd61392b1db391bde6d738a30d685b843286
- https://git.kernel.org/stable/c/7d420eaaa18ec8e2bb4eeab8c65c00492ef6f416
- https://git.kernel.org/stable/c/fd244524c2cf07b5f4c3fe8abd6a99225c76544b
- https://git.kernel.org/stable/c/2b1b14d9fc94b8feae20808684c8af28ec80f45b
- https://git.kernel.org/stable/c/52982edfcefd475cc34af663d5c47c0cddaa5739
- https://git.kernel.org/stable/c/542c8b3c774a480bfd0804291a12f6f2391b0cd1
- https://git.kernel.org/stable/c/75abfd61392b1db391bde6d738a30d685b843286
- https://git.kernel.org/stable/c/7d420eaaa18ec8e2bb4eeab8c65c00492ef6f416
- https://git.kernel.org/stable/c/fd244524c2cf07b5f4c3fe8abd6a99225c76544b
Modified: 2025-09-18
CVE-2024-27035
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to guarantee persisting compressed blocks by CP If data block in compressed cluster is not persisted with metadata during checkpoint, after SPOR, the data may be corrupted, let's guarantee to write compressed page by checkpoint.
- https://git.kernel.org/stable/c/57e8b17d0522c8f4daf0c4d9969b4d7358033532
- https://git.kernel.org/stable/c/82704e598d7b33c7e45526e34d3c585426319bed
- https://git.kernel.org/stable/c/8a430dd49e9cb021372b0ad91e60aeef9c6ced00
- https://git.kernel.org/stable/c/c3311694b9bcced233548574d414c91d39214684
- https://git.kernel.org/stable/c/e54cce8137258a550b49cae45d09e024821fb28d
- https://git.kernel.org/stable/c/57e8b17d0522c8f4daf0c4d9969b4d7358033532
- https://git.kernel.org/stable/c/82704e598d7b33c7e45526e34d3c585426319bed
- https://git.kernel.org/stable/c/8a430dd49e9cb021372b0ad91e60aeef9c6ced00
- https://git.kernel.org/stable/c/c3311694b9bcced233548574d414c91d39214684
- https://git.kernel.org/stable/c/e54cce8137258a550b49cae45d09e024821fb28d
Modified: 2025-04-08
CVE-2024-27037
In the Linux kernel, the following vulnerability has been resolved: clk: zynq: Prevent null pointer dereference caused by kmalloc failure The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen. This patch uses a stack variable to replace the kmalloc().
- https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db
- https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85
- https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b
- https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6
- https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d
- https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8
- https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db
- https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85
- https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b
- https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6
- https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d
- https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8
Modified: 2024-12-23
CVE-2024-27038
In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_core_get NULL dereference It is possible for clk_core_get to dereference a NULL in the following sequence: clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw() __clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core. Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL. Reading the description of this function it talks about returning NULL but that cannot be so at the moment. Update the function to check for hw before dereferencing it and return NULL if hw is NULL.
- https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2
- https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185
- https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51
- https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed
- https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959
- https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6
- https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07
- https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428
- https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2
- https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185
- https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51
- https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed
- https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959
- https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6
- https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07
- https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-27039
In the Linux kernel, the following vulnerability has been resolved: clk: hisilicon: hi3559a: Fix an erroneous devm_kfree() 'p_clk' is an array allocated just before the for loop for all clk that need to be registered. It is incremented at each loop iteration. If a clk_register() call fails, 'p_clk' may point to something different from what should be freed. The best we can do, is to avoid this wrong release of memory.
- https://git.kernel.org/stable/c/2cc572e0085ebd4b662b74a0f43222bc00df9a00
- https://git.kernel.org/stable/c/3f8445f1c746fda180a7f75372ed06b24e9cefe2
- https://git.kernel.org/stable/c/64c6a38136b74a2f18c42199830975edd9fbc379
- https://git.kernel.org/stable/c/95d1f1228c1bb54803ae57525b76db60e99b37e4
- https://git.kernel.org/stable/c/d575765b1b62e8bdb00af11caa1aabeb01763d9f
- https://git.kernel.org/stable/c/e0b0d1c46a2ce1e46b79d004a7270fdef872e097
- https://git.kernel.org/stable/c/2cc572e0085ebd4b662b74a0f43222bc00df9a00
- https://git.kernel.org/stable/c/3f8445f1c746fda180a7f75372ed06b24e9cefe2
- https://git.kernel.org/stable/c/64c6a38136b74a2f18c42199830975edd9fbc379
- https://git.kernel.org/stable/c/95d1f1228c1bb54803ae57525b76db60e99b37e4
- https://git.kernel.org/stable/c/d575765b1b62e8bdb00af11caa1aabeb01763d9f
- https://git.kernel.org/stable/c/e0b0d1c46a2ce1e46b79d004a7270fdef872e097
Modified: 2025-04-08
CVE-2024-27041
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini() Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL before the call to dc_enable_dmub_notifications(), check beforehand to ensure there will not be a possible NULL-ptr-deref there. Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in 'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy(). Clean up by combining them all under one 'if'. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
- https://git.kernel.org/stable/c/1c62697e4086de988b31124fb8c79c244ea05f2b
- https://git.kernel.org/stable/c/2a3cfb9a24a28da9cc13d2c525a76548865e182c
- https://git.kernel.org/stable/c/ca2eb375db76fd50f31afdd67d6ca4f833254957
- https://git.kernel.org/stable/c/e040f1fbe9abae91b12b074cfc3bbb5367b79811
- https://git.kernel.org/stable/c/1c62697e4086de988b31124fb8c79c244ea05f2b
- https://git.kernel.org/stable/c/2a3cfb9a24a28da9cc13d2c525a76548865e182c
- https://git.kernel.org/stable/c/ca2eb375db76fd50f31afdd67d6ca4f833254957
- https://git.kernel.org/stable/c/e040f1fbe9abae91b12b074cfc3bbb5367b79811
Modified: 2024-12-23
CVE-2024-27043
In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free.
- https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644
- https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e
- https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d
- https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712
- https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62
- https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5
- https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b
- https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856
- https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086
- https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644
- https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e
- https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d
- https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712
- https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62
- https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5
- https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b
- https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856
- https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27044
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()' The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)
- https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7
- https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0
- https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7
- https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08
- https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb
- https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484
- https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656
- https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a
- https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7
- https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0
- https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7
- https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08
- https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb
- https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484
- https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656
- https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27045
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()' Tell snprintf() to store at most 10 bytes in the output buffer instead of 30. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10
- https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877
- https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141
- https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7
- https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4
- https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab
- https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65
- https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515
- https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877
- https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141
- https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7
- https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4
- https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab
- https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65
- https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27046
In the Linux kernel, the following vulnerability has been resolved: nfp: flower: handle acti_netdevs allocation failure The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen. This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again.
- https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5
- https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d
- https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642
- https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002
- https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f
- https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2
- https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d
- https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3
- https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e
- https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5
- https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d
- https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642
- https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002
- https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f
- https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2
- https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d
- https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3
- https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27047
In the Linux kernel, the following vulnerability has been resolved: net: phy: fix phy_get_internal_delay accessing an empty array The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0.
- https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad
- https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b
- https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a
- https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8
- https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79
- https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563
- https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b
- https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad
- https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b
- https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a
- https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8
- https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79
- https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563
- https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27051
In the Linux kernel, the following vulnerability has been resolved: cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5
- https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db
- https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035
- https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567
- https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6
- https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095
- https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6
- https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5
- https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db
- https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035
- https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567
- https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6
- https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095
- https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27052
In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().
- https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361
- https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e
- https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e
- https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a
- https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707
- https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59
- https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4
- https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361
- https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e
- https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e
- https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a
- https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707
- https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59
- https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27053
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix RCU usage in connect path With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning: ============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcu_dereference_check() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4 wilc_parse_join_bss_param from connect+0x2c4/0x648 connect from cfg80211_connect+0x30c/0xb74 cfg80211_connect from nl80211_connect+0x860/0xa94 nl80211_connect from genl_rcv_msg+0x3fc/0x59c genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb from genl_rcv+0x2c/0x3c genl_rcv from netlink_unicast+0x3b0/0x550 netlink_unicast from netlink_sendmsg+0x368/0x688 netlink_sendmsg from ____sys_sendmsg+0x190/0x430 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158 ___sys_sendmsg from sys_sendmsg+0xe8/0x150 sys_sendmsg from ret_fast_syscall+0x0/0x1c This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilc_parse_join_bss_param under the critical section, just use the critical section to copy ies data
- https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f
- https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce
- https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de
- https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2
- https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38
- https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2
- https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7
- https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2
- https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f
- https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce
- https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de
- https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2
- https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38
- https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2
- https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7
- https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-05-02
CVE-2024-27054
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix double module refcount decrement Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same.
- https://git.kernel.org/stable/c/9fe0562179d8fa960afca0eaed6d4ba4122a3cc6
- https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a
- https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06
- https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5
- https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e
- https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19
- https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650
- https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a
- https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06
- https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5
- https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e
- https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19
- https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650
Modified: 2025-09-18
CVE-2024-27057
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume. If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic. If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case. Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot.
- https://git.kernel.org/stable/c/3cac6eebea9b4bc5f041e157e45c76e212ad6759
- https://git.kernel.org/stable/c/c40aad7c81e5fba34b70123ed7ce3397fa62a4d2
- https://git.kernel.org/stable/c/d153e8b154f9746ac969c85a4e6474760453647c
- https://git.kernel.org/stable/c/3cac6eebea9b4bc5f041e157e45c76e212ad6759
- https://git.kernel.org/stable/c/c40aad7c81e5fba34b70123ed7ce3397fa62a4d2
- https://git.kernel.org/stable/c/d153e8b154f9746ac969c85a4e6474760453647c
Modified: 2025-12-23
CVE-2024-27065
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not compare internal table flags on updates Restore skipping transaction if table update does not modify flags.
- https://git.kernel.org/stable/c/2531f907d3e40a6173090f10670ae76d117ab27b
- https://git.kernel.org/stable/c/3443e57654f90c9a843ab6a6040c10709fd033aa
- https://git.kernel.org/stable/c/4a0e7f2decbf9bd72461226f1f5f7dcc4b08f139
- https://git.kernel.org/stable/c/4d37f12707ee965d338028732575f0b85f6d9e4f
- https://git.kernel.org/stable/c/640dbf688ba955e83e03de84fbdda8e570b7cce4
- https://git.kernel.org/stable/c/845083249d6a392f3a88804e1669bdb936ee129f
- https://git.kernel.org/stable/c/9683cb6c2c6c0f45537bf0b8868b5d38fcb63fc7
- https://git.kernel.org/stable/c/df257c435e51651c43b86326d112ddadda76350e
- https://git.kernel.org/stable/c/fcf32a5bfcb8a57ac0ce717fcfa4d688c91f1005
- https://git.kernel.org/stable/c/2531f907d3e40a6173090f10670ae76d117ab27b
- https://git.kernel.org/stable/c/3443e57654f90c9a843ab6a6040c10709fd033aa
- https://git.kernel.org/stable/c/4a0e7f2decbf9bd72461226f1f5f7dcc4b08f139
- https://git.kernel.org/stable/c/4d37f12707ee965d338028732575f0b85f6d9e4f
- https://git.kernel.org/stable/c/640dbf688ba955e83e03de84fbdda8e570b7cce4
- https://git.kernel.org/stable/c/845083249d6a392f3a88804e1669bdb936ee129f
- https://git.kernel.org/stable/c/9683cb6c2c6c0f45537bf0b8868b5d38fcb63fc7
- https://git.kernel.org/stable/c/df257c435e51651c43b86326d112ddadda76350e
- https://git.kernel.org/stable/c/fcf32a5bfcb8a57ac0ce717fcfa4d688c91f1005
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-08
CVE-2024-27073
In the Linux kernel, the following vulnerability has been resolved: media: ttpci: fix two memleaks in budget_av_attach When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations.
- https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63
- https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb
- https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0
- https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c
- https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06
- https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b
- https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016
- https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837
- https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63
- https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb
- https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0
- https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c
- https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06
- https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b
- https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016
- https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27074
In the Linux kernel, the following vulnerability has been resolved: media: go7007: fix a memleak in go7007_load_encoder In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked.
- https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159
- https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4
- https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3
- https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5
- https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073
- https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12
- https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661
- https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3
- https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975
- https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159
- https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4
- https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3
- https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5
- https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073
- https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12
- https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661
- https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3
- https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27075
In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: avoid stack overflow warnings with clang A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang: drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe) Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled.
- https://git.kernel.org/stable/c/107052a8cfeff3a97326277192b4f052e4860a8a
- https://git.kernel.org/stable/c/7a4cf27d1f0538f779bf31b8c99eda394e277119
- https://git.kernel.org/stable/c/8fad9c5bb00d3a9508d18bbfe832e33a47377730
- https://git.kernel.org/stable/c/c073c8cede5abd3836e83d70d72606d11d0759d4
- https://git.kernel.org/stable/c/d20b64f156de5d10410963fe238d82a4e7e97a2f
- https://git.kernel.org/stable/c/d6b4895197ab5a47cb81c6852d49320b05052960
- https://git.kernel.org/stable/c/ed514ecf4f29c80a2f09ae3c877059b401efe893
- https://git.kernel.org/stable/c/fa8b472952ef46eb632825051078c21ce0cafe55
- https://git.kernel.org/stable/c/fb07104a02e87c06c39914d13ed67fd8f839ca82
- https://git.kernel.org/stable/c/107052a8cfeff3a97326277192b4f052e4860a8a
- https://git.kernel.org/stable/c/7a4cf27d1f0538f779bf31b8c99eda394e277119
- https://git.kernel.org/stable/c/8fad9c5bb00d3a9508d18bbfe832e33a47377730
- https://git.kernel.org/stable/c/c073c8cede5abd3836e83d70d72606d11d0759d4
- https://git.kernel.org/stable/c/d20b64f156de5d10410963fe238d82a4e7e97a2f
- https://git.kernel.org/stable/c/d6b4895197ab5a47cb81c6852d49320b05052960
- https://git.kernel.org/stable/c/ed514ecf4f29c80a2f09ae3c877059b401efe893
- https://git.kernel.org/stable/c/fa8b472952ef46eb632825051078c21ce0cafe55
- https://git.kernel.org/stable/c/fb07104a02e87c06c39914d13ed67fd8f839ca82
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27076
In the Linux kernel, the following vulnerability has been resolved: media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak Free the memory allocated in v4l2_ctrl_handler_init on release.
- https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce
- https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01
- https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684
- https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e
- https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282
- https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328
- https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b
- https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f
- https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce
- https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01
- https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684
- https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e
- https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282
- https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328
- https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b
- https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-23
CVE-2024-27077
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.
- https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4
- https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d
- https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333
- https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458
- https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211
- https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d
- https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f
- https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2
- https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef
- https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4
- https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d
- https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333
- https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458
- https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211
- https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d
- https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f
- https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2
- https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-23
CVE-2024-27078
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0.
- https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77
- https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09
- https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941
- https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7
- https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d
- https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511
- https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79
- https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c
- https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28
- https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77
- https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09
- https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941
- https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7
- https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d
- https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511
- https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79
- https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c
- https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-27388
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.
- https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d
- https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3
- https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c
- https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4
- https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69
- https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364
- https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8
- https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8
- https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044
- https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d
- https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3
- https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c
- https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4
- https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69
- https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364
- https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8
- https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8
- https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-18
CVE-2024-27389
In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---
- https://git.kernel.org/stable/c/340682ed1932b8e3bd0bfc6c31a0c6354eb57cc6
- https://git.kernel.org/stable/c/4cdf9006fc095af71da80e9b5f48a32e991b9ed3
- https://git.kernel.org/stable/c/a43e0fc5e9134a46515de2f2f8d4100b74e50de3
- https://git.kernel.org/stable/c/cb9e802e49c24eeb3af35e9e8c04d526f35f112a
- https://git.kernel.org/stable/c/db6e5e16f1ee9e3b01d2f71c7f0ba945f4bf0f4e
- https://git.kernel.org/stable/c/340682ed1932b8e3bd0bfc6c31a0c6354eb57cc6
- https://git.kernel.org/stable/c/4cdf9006fc095af71da80e9b5f48a32e991b9ed3
- https://git.kernel.org/stable/c/a43e0fc5e9134a46515de2f2f8d4100b74e50de3
- https://git.kernel.org/stable/c/cb9e802e49c24eeb3af35e9e8c04d526f35f112a
- https://git.kernel.org/stable/c/db6e5e16f1ee9e3b01d2f71c7f0ba945f4bf0f4e
Modified: 2025-09-18
CVE-2024-27390
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well.
- https://git.kernel.org/stable/c/17ef8efc00b34918b966388b2af0993811895a8c
- https://git.kernel.org/stable/c/26d4bac55750d535f1f0b8790dc26daf6089e373
- https://git.kernel.org/stable/c/5da9a218340a2bc804dc4327e5804392e24a0b88
- https://git.kernel.org/stable/c/7eb06ee5921189812e6b4bfe7b0f1e878be16df7
- https://git.kernel.org/stable/c/9d159d6637ccce25f879d662a480541ef4ba3a50
- https://git.kernel.org/stable/c/a03ede2282ebbd181bd6f5c38cbfcb5765afcd04
- https://git.kernel.org/stable/c/17ef8efc00b34918b966388b2af0993811895a8c
- https://git.kernel.org/stable/c/26d4bac55750d535f1f0b8790dc26daf6089e373
- https://git.kernel.org/stable/c/5da9a218340a2bc804dc4327e5804392e24a0b88
- https://git.kernel.org/stable/c/7eb06ee5921189812e6b4bfe7b0f1e878be16df7
- https://git.kernel.org/stable/c/9d159d6637ccce25f879d662a480541ef4ba3a50
- https://git.kernel.org/stable/c/a03ede2282ebbd181bd6f5c38cbfcb5765afcd04
Modified: 2025-09-18
CVE-2024-27391
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: do not realloc workqueue everytime an interface is added Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands: for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue.
- https://git.kernel.org/stable/c/328efda22af81130c2ad981c110518cb29ff2f1d
- https://git.kernel.org/stable/c/4041c60a9d543b3ad50225385b072ba68e96166e
- https://git.kernel.org/stable/c/515cc676dfbce40d93c92b1ff3c1070e917f4e52
- https://git.kernel.org/stable/c/90ae293d1d255f622318fce6eeea2e18f9fde5c1
- https://git.kernel.org/stable/c/9ab0c303ccabfd6bdce14432792d41090070008c
- https://git.kernel.org/stable/c/328efda22af81130c2ad981c110518cb29ff2f1d
- https://git.kernel.org/stable/c/4041c60a9d543b3ad50225385b072ba68e96166e
- https://git.kernel.org/stable/c/515cc676dfbce40d93c92b1ff3c1070e917f4e52
- https://git.kernel.org/stable/c/90ae293d1d255f622318fce6eeea2e18f9fde5c1
- https://git.kernel.org/stable/c/9ab0c303ccabfd6bdce14432792d41090070008c
Modified: 2025-09-18
CVE-2024-27402
In the Linux kernel, the following vulnerability has been resolved: phonet/pep: fix racy skb_queue_empty() use The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.
- https://git.kernel.org/stable/c/0a9f558c72c47472c38c05fcb72c70abb9104277
- https://git.kernel.org/stable/c/7d2a894d7f487dcb894df023e9d3014cf5b93fe5
- https://git.kernel.org/stable/c/7d3914a477eed92b48c493a8631cc4554ab4fd4f
- https://git.kernel.org/stable/c/8ef4fcc7014b9f93619851d6b78d6cc2789a4c88
- https://git.kernel.org/stable/c/9d5523e065b568e79dfaa2ea1085a5bcf74baf78
- https://git.kernel.org/stable/c/0a9f558c72c47472c38c05fcb72c70abb9104277
- https://git.kernel.org/stable/c/7d2a894d7f487dcb894df023e9d3014cf5b93fe5
- https://git.kernel.org/stable/c/8ef4fcc7014b9f93619851d6b78d6cc2789a4c88
- https://git.kernel.org/stable/c/9d5523e065b568e79dfaa2ea1085a5bcf74baf78
Modified: 2025-09-18
CVE-2024-27403
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_flow_offload: reset dst in route object after setting up flow dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow.
- https://git.kernel.org/stable/c/012df10717da02367aaf92c65f9c89db206c15f4
- https://git.kernel.org/stable/c/4c167af9f6b5ae4a5dbc243d5983c295ccc2e43c
- https://git.kernel.org/stable/c/558b00a30e05753a62ecc7e05e939ca8f0241148
- https://git.kernel.org/stable/c/670548c8db44d76e40e1dfc06812bca36a61e9ae
- https://git.kernel.org/stable/c/9e0f0430389be7696396c62f037be4bf72cf93e3
- https://git.kernel.org/stable/c/012df10717da02367aaf92c65f9c89db206c15f4
- https://git.kernel.org/stable/c/4c167af9f6b5ae4a5dbc243d5983c295ccc2e43c
- https://git.kernel.org/stable/c/558b00a30e05753a62ecc7e05e939ca8f0241148
- https://git.kernel.org/stable/c/670548c8db44d76e40e1dfc06812bca36a61e9ae
- https://git.kernel.org/stable/c/9e0f0430389be7696396c62f037be4bf72cf93e3
Modified: 2025-09-18
CVE-2024-27404
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data races on remote_id Similar to the previous patch, address the data race on remote_id, adding the suitable ONCE annotations.
- https://git.kernel.org/stable/c/2dba5774e8ed326a78ad4339d921a4291281ea6e
- https://git.kernel.org/stable/c/967d3c27127e71a10ff5c083583a038606431b61
- https://git.kernel.org/stable/c/987c3ed7297e5661bc7f448f06fc366e497ac9b2
- https://git.kernel.org/stable/c/e64148635509bf13eea851986f5a0b150e5bd066
- https://git.kernel.org/stable/c/2dba5774e8ed326a78ad4339d921a4291281ea6e
- https://git.kernel.org/stable/c/967d3c27127e71a10ff5c083583a038606431b61
- https://git.kernel.org/stable/c/987c3ed7297e5661bc7f448f06fc366e497ac9b2
- https://git.kernel.org/stable/c/e64148635509bf13eea851986f5a0b150e5bd066
Modified: 2025-04-08
CVE-2024-27405
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.
- https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48
- https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e
- https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5
- https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca
- https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd
- https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd
- https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151
- https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e
- https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48
- https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e
- https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5
- https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca
- https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd
- https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd
- https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151
- https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-27407
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()
- https://git.kernel.org/stable/c/1c0a95d99b1b2b5d842e5abc7ef7eed1193b60d7
- https://git.kernel.org/stable/c/652cfeb43d6b9aba5c7c4902bed7a7340df131fb
- https://git.kernel.org/stable/c/8c77398c72618101d66480b94b34fe9087ee3d08
- https://git.kernel.org/stable/c/e99faa97359654b6e4e769246c72cf50a57e05b2
- https://git.kernel.org/stable/c/1c0a95d99b1b2b5d842e5abc7ef7eed1193b60d7
- https://git.kernel.org/stable/c/652cfeb43d6b9aba5c7c4902bed7a7340df131fb
- https://git.kernel.org/stable/c/8c77398c72618101d66480b94b34fe9087ee3d08
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2025-09-18
CVE-2024-27408
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup The Linked list element and pointer are not stored in the same memory as the eDMA controller register. If the doorbell register is toggled before the full write of the linked list a race condition error will occur. In remote setup we can only use a readl to the memory to assure the full write has occurred.
- https://git.kernel.org/stable/c/bbcc1c83f343e580c3aa1f2a8593343bf7b55bba
- https://git.kernel.org/stable/c/d24fe6d5a1cfdddb7a9ef56736ec501c4d0a5fd3
- https://git.kernel.org/stable/c/f396b4df27cfe01a99f4b41f584c49e56477be3a
- https://git.kernel.org/stable/c/bbcc1c83f343e580c3aa1f2a8593343bf7b55bba
- https://git.kernel.org/stable/c/d24fe6d5a1cfdddb7a9ef56736ec501c4d0a5fd3
- https://git.kernel.org/stable/c/f396b4df27cfe01a99f4b41f584c49e56477be3a
Modified: 2025-12-17
CVE-2024-27410
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject iftype change with mesh ID change It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID.
- https://git.kernel.org/stable/c/177d574be4b58f832354ab1ef5a297aa0c9aa2df
- https://git.kernel.org/stable/c/930e826962d9f01dcd2220176134427358d112f2
- https://git.kernel.org/stable/c/a2add961a5ed25cfd6a74f9ffb9e7ab6d6ded838
- https://git.kernel.org/stable/c/f78c1375339a291cba492a70eaf12ec501d28a8e
- https://git.kernel.org/stable/c/063715c33b4c37587aeca2c83cf08ead0c542995
- https://git.kernel.org/stable/c/0cfbb26ee5e7b3d6483a73883f9f6157bca22ec9
- https://git.kernel.org/stable/c/177d574be4b58f832354ab1ef5a297aa0c9aa2df
- https://git.kernel.org/stable/c/930e826962d9f01dcd2220176134427358d112f2
- https://git.kernel.org/stable/c/99eb2159680af8786104dac80528acd5acd45980
- https://git.kernel.org/stable/c/a2add961a5ed25cfd6a74f9ffb9e7ab6d6ded838
- https://git.kernel.org/stable/c/d38d31bbbb9dc0d4d71a45431eafba03d0bc150d
- https://git.kernel.org/stable/c/f78c1375339a291cba492a70eaf12ec501d28a8e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27412
In the Linux kernel, the following vulnerability has been resolved: power: supply: bq27xxx-i2c: Do not free non existing IRQ The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq(). But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to: [ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring probe() to fix this.
- https://git.kernel.org/stable/c/083686474e7c97b0f8b66df37fcb64e432e8b771
- https://git.kernel.org/stable/c/2df70149e73e79783bcbc7db4fa51ecef0e2022c
- https://git.kernel.org/stable/c/7394abc8926adee6a817bab10797e0adc898af77
- https://git.kernel.org/stable/c/cefe18e9ec84f8fe3e198ccebb815cc996eb9797
- https://git.kernel.org/stable/c/d4d813c0a14d6bf52d810a55db06a2e7e3d98eaa
- https://git.kernel.org/stable/c/d7acc4a569f5f4513120c85ea2b9f04909b7490f
- https://git.kernel.org/stable/c/e601ae81910ce6a3797876e190a2d8ef6cf828bc
- https://git.kernel.org/stable/c/fbca8bae1ba79d443a58781b45e92a73a24ac8f8
- https://git.kernel.org/stable/c/083686474e7c97b0f8b66df37fcb64e432e8b771
- https://git.kernel.org/stable/c/2df70149e73e79783bcbc7db4fa51ecef0e2022c
- https://git.kernel.org/stable/c/7394abc8926adee6a817bab10797e0adc898af77
- https://git.kernel.org/stable/c/cefe18e9ec84f8fe3e198ccebb815cc996eb9797
- https://git.kernel.org/stable/c/d4d813c0a14d6bf52d810a55db06a2e7e3d98eaa
- https://git.kernel.org/stable/c/d7acc4a569f5f4513120c85ea2b9f04909b7490f
- https://git.kernel.org/stable/c/e601ae81910ce6a3797876e190a2d8ef6cf828bc
- https://git.kernel.org/stable/c/fbca8bae1ba79d443a58781b45e92a73a24ac8f8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27413
In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect allocation size gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here.
- https://git.kernel.org/stable/c/00cf21ac526011a29fc708f8912da446fac19f7b
- https://git.kernel.org/stable/c/11aabd7487857b8e7d768fefb092f66dfde68492
- https://git.kernel.org/stable/c/4b73473c050a612fb4317831371073eda07c3050
- https://git.kernel.org/stable/c/537e3f49dbe88881a6f0752beaa596942d9efd64
- https://git.kernel.org/stable/c/62a5dcd9bd3097e9813de62fa6f22815e84a0172
- https://git.kernel.org/stable/c/950d4d74d311a18baed6878dbfba8180d7e5dddd
- https://git.kernel.org/stable/c/ddc547dd05a46720866c32022300f7376c40119f
- https://git.kernel.org/stable/c/fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e
- https://git.kernel.org/stable/c/00cf21ac526011a29fc708f8912da446fac19f7b
- https://git.kernel.org/stable/c/11aabd7487857b8e7d768fefb092f66dfde68492
- https://git.kernel.org/stable/c/4b73473c050a612fb4317831371073eda07c3050
- https://git.kernel.org/stable/c/537e3f49dbe88881a6f0752beaa596942d9efd64
- https://git.kernel.org/stable/c/62a5dcd9bd3097e9813de62fa6f22815e84a0172
- https://git.kernel.org/stable/c/950d4d74d311a18baed6878dbfba8180d7e5dddd
- https://git.kernel.org/stable/c/ddc547dd05a46720866c32022300f7376c40119f
- https://git.kernel.org/stable/c/fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27414
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic in the function `rtnl_bridge_setlink` to enable the loop to also check the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment removed the `break` statement and led to an error logic of the flags writing back at the end of this function. if (have_flags) memcpy(nla_data(attr), &flags, sizeof(flags)); // attr should point to IFLA_BRIDGE_FLAGS NLA !!! Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS. However, this is not necessarily true fow now as the updated loop will let the attr point to the last NLA, even an invalid NLA which could cause overflow writes. This patch introduces a new variable `br_flag` to save the NLA pointer that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned error logic.
- https://git.kernel.org/stable/c/167d8642daa6a44b51de17f8ff0f584e1e762db7
- https://git.kernel.org/stable/c/743ad091fb46e622f1b690385bb15e3cd3daf874
- https://git.kernel.org/stable/c/831bc2728fb48a8957a824cba8c264b30dca1425
- https://git.kernel.org/stable/c/882a51a10ecf24ce135d573afa0872aef02c5125
- https://git.kernel.org/stable/c/a1227b27fcccc99dc44f912b479e01a17e2d7d31
- https://git.kernel.org/stable/c/b9fbc44159dfc3e9a7073032752d9e03f5194a6f
- https://git.kernel.org/stable/c/f2261eb994aa5757c1da046b78e3229a3ece0ad9
- https://git.kernel.org/stable/c/167d8642daa6a44b51de17f8ff0f584e1e762db7
- https://git.kernel.org/stable/c/743ad091fb46e622f1b690385bb15e3cd3daf874
- https://git.kernel.org/stable/c/831bc2728fb48a8957a824cba8c264b30dca1425
- https://git.kernel.org/stable/c/882a51a10ecf24ce135d573afa0872aef02c5125
- https://git.kernel.org/stable/c/a1227b27fcccc99dc44f912b479e01a17e2d7d31
- https://git.kernel.org/stable/c/b9fbc44159dfc3e9a7073032752d9e03f5194a6f
- https://git.kernel.org/stable/c/f2261eb994aa5757c1da046b78e3229a3ece0ad9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27415
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: confirm multicast packets before passing them up the stack conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb. The Macvlan broadcast worker and normal confirm path will race. This race will not happen if step 2 already confirmed a clone. In that case later steps perform skb_clone() with skb->_nfct already confirmed (in hash table). This works fine. But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting. Pablo points out that nf_conntrack_bridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again. This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook. Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry. The downside is that this disables NAT and conntrack helpers. Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example: -m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5 For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings. Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.
- https://git.kernel.org/stable/c/2b1414d5e94e477edff1d2c79030f1d742625ea0
- https://git.kernel.org/stable/c/62e7151ae3eb465e0ab52a20c941ff33bb6332e9
- https://git.kernel.org/stable/c/7c3f28599652acf431a2211168de4a583f30b6d5
- https://git.kernel.org/stable/c/80cd0487f630b5382734997c3e5e3003a77db315
- https://git.kernel.org/stable/c/cb734975b0ffa688ff6cc0eed463865bf07b6c01
- https://git.kernel.org/stable/c/2b1414d5e94e477edff1d2c79030f1d742625ea0
- https://git.kernel.org/stable/c/62e7151ae3eb465e0ab52a20c941ff33bb6332e9
- https://git.kernel.org/stable/c/7c3f28599652acf431a2211168de4a583f30b6d5
- https://git.kernel.org/stable/c/80cd0487f630b5382734997c3e5e3003a77db315
- https://git.kernel.org/stable/c/cb734975b0ffa688ff6cc0eed463865bf07b6c01
Modified: 2025-12-17
CVE-2024-27416
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated.
- https://git.kernel.org/stable/c/30a5e812f78e3d1cced90e1ed750bf027599205f
- https://git.kernel.org/stable/c/79820a7e1e057120c49be07cbe10643d0706b259
- https://git.kernel.org/stable/c/7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865
- https://git.kernel.org/stable/c/8e2758cc25891d2b76717aaf89b40ed215de188c
- https://git.kernel.org/stable/c/afec8f772296dd8e5a2a6f83bbf99db1b9ca877f
- https://git.kernel.org/stable/c/c3df637266df29edee85e94cab5fd7041e5753ba
- https://git.kernel.org/stable/c/df193568d61234c81de7ed4d540c01975de60277
- https://git.kernel.org/stable/c/fba268ac36ab19f9763ff90d276cde0ce6cd5f31
- https://git.kernel.org/stable/c/30a5e812f78e3d1cced90e1ed750bf027599205f
- https://git.kernel.org/stable/c/79820a7e1e057120c49be07cbe10643d0706b259
- https://git.kernel.org/stable/c/7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865
- https://git.kernel.org/stable/c/8e2758cc25891d2b76717aaf89b40ed215de188c
- https://git.kernel.org/stable/c/afec8f772296dd8e5a2a6f83bbf99db1b9ca877f
- https://git.kernel.org/stable/c/c3df637266df29edee85e94cab5fd7041e5753ba
- https://git.kernel.org/stable/c/df193568d61234c81de7ed4d540c01975de60277
- https://git.kernel.org/stable/c/fba268ac36ab19f9763ff90d276cde0ce6cd5f31
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27417
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix potential "struct net" leak in inet6_rtm_getaddr() It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount.
- https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c48653cdb
- https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a
- https://git.kernel.org/stable/c/33a1b6bfef6def2068c8703403759024ce17053e
- https://git.kernel.org/stable/c/44112bc5c74e64f28f5a9127dc34066c7a09bd0f
- https://git.kernel.org/stable/c/810fa7d5e5202fcfb22720304b755f1bdfd4c174
- https://git.kernel.org/stable/c/8a54834c03c30e549c33d5da0975f3e1454ec906
- https://git.kernel.org/stable/c/9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132
- https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c48653cdb
- https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a
- https://git.kernel.org/stable/c/33a1b6bfef6def2068c8703403759024ce17053e
- https://git.kernel.org/stable/c/44112bc5c74e64f28f5a9127dc34066c7a09bd0f
- https://git.kernel.org/stable/c/810fa7d5e5202fcfb22720304b755f1bdfd4c174
- https://git.kernel.org/stable/c/8a54834c03c30e549c33d5da0975f3e1454ec906
- https://git.kernel.org/stable/c/9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27418
In the Linux kernel, the following vulnerability has been resolved: net: mctp: take ownership of skb in mctp_local_output Currently, mctp_local_output only takes ownership of skb on success, and we may leak an skb if mctp_local_output fails in specific states; the skb ownership isn't transferred until the actual output routing occurs. Instead, make mctp_local_output free the skb on all error paths up to the route action, so it always consumes the passed skb.
- https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3
- https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd
- https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b
- https://git.kernel.org/stable/c/cbebc55ceacef1fc0651e80e0103cc184552fc68
- https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3
- https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd
- https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b
- https://git.kernel.org/stable/c/cbebc55ceacef1fc0651e80e0103cc184552fc68
Modified: 2025-12-23
CVE-2024-27419
In the Linux kernel, the following vulnerability has been resolved: netrom: Fix data-races around sysctl_net_busy_read We need to protect the reader reading the sysctl value because the value can be changed concurrently.
- https://git.kernel.org/stable/c/0866afaff19d8460308b022345ed116a12b1d0e1
- https://git.kernel.org/stable/c/16d71319e29d5825ab53f263b59fdd8dc2d60ad4
- https://git.kernel.org/stable/c/34cab94f7473e7b09f5205d4583fb5096cb63b5b
- https://git.kernel.org/stable/c/43464808669ba9d23996f0b6d875450191687caf
- https://git.kernel.org/stable/c/bbf950a6e96a91cf8cf0c71117b94ed3fafc9dd3
- https://git.kernel.org/stable/c/d380ce70058a4ccddc3e5f5c2063165dc07672c6
- https://git.kernel.org/stable/c/d623fd5298d95b65d27ef5a618ebf39541074856
- https://git.kernel.org/stable/c/f9055fa2b2931261d5f89948ee5bc315b6a22d4a
- https://git.kernel.org/stable/c/0866afaff19d8460308b022345ed116a12b1d0e1
- https://git.kernel.org/stable/c/16d71319e29d5825ab53f263b59fdd8dc2d60ad4
- https://git.kernel.org/stable/c/34cab94f7473e7b09f5205d4583fb5096cb63b5b
- https://git.kernel.org/stable/c/43464808669ba9d23996f0b6d875450191687caf
- https://git.kernel.org/stable/c/bbf950a6e96a91cf8cf0c71117b94ed3fafc9dd3
- https://git.kernel.org/stable/c/d380ce70058a4ccddc3e5f5c2063165dc07672c6
- https://git.kernel.org/stable/c/d623fd5298d95b65d27ef5a618ebf39541074856
- https://git.kernel.org/stable/c/f9055fa2b2931261d5f89948ee5bc315b6a22d4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27431
In the Linux kernel, the following vulnerability has been resolved: cpumap: Zero-initialise xdp_rxq_info struct before running XDP program When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program.
- https://git.kernel.org/stable/c/2487007aa3b9fafbd2cb14068f49791ce1d7ede5
- https://git.kernel.org/stable/c/3420b3ff1ff489c177ea1cb7bd9fbbc4e9a0be95
- https://git.kernel.org/stable/c/5f4e51abfbe6eb444fa91906a5cd083044278297
- https://git.kernel.org/stable/c/eaa7cb836659ced2d9f814ac32aa3ec193803ed6
- https://git.kernel.org/stable/c/f0363af9619c77730764f10360e36c6445c12f7b
- https://git.kernel.org/stable/c/f562e4c4aab00986dde3093c4be919c3f2b85a4a
- https://git.kernel.org/stable/c/2487007aa3b9fafbd2cb14068f49791ce1d7ede5
- https://git.kernel.org/stable/c/3420b3ff1ff489c177ea1cb7bd9fbbc4e9a0be95
- https://git.kernel.org/stable/c/5f4e51abfbe6eb444fa91906a5cd083044278297
- https://git.kernel.org/stable/c/eaa7cb836659ced2d9f814ac32aa3ec193803ed6
- https://git.kernel.org/stable/c/f0363af9619c77730764f10360e36c6445c12f7b
- https://git.kernel.org/stable/c/f562e4c4aab00986dde3093c4be919c3f2b85a4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27432
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix PPE hanging issue A patch to resolve an issue was found in MediaTek's GPL-licensed SDK: In the mtk_ppe_stop() function, the PPE scan mode is not disabled before disabling the PPE. This can potentially lead to a hang during the process of disabling the PPE. Without this patch, the PPE may experience a hang during the reboot test.
- https://git.kernel.org/stable/c/09a1907433865b7c8ee6777e507f5126bdd38c0f
- https://git.kernel.org/stable/c/49202a8256fc50517ef06fd5e2084c4febde6369
- https://git.kernel.org/stable/c/943c14ece95eb1cf98d477462aebcbfdfd714633
- https://git.kernel.org/stable/c/9fcadd125044007351905d40c405fadc2d3bb6d6
- https://git.kernel.org/stable/c/ea80e3ed09ab2c2b75724faf5484721753e92c31
- https://git.kernel.org/stable/c/f78807362828ad01db2a9ed005bf79501b620f27
- https://git.kernel.org/stable/c/09a1907433865b7c8ee6777e507f5126bdd38c0f
- https://git.kernel.org/stable/c/49202a8256fc50517ef06fd5e2084c4febde6369
- https://git.kernel.org/stable/c/943c14ece95eb1cf98d477462aebcbfdfd714633
- https://git.kernel.org/stable/c/9fcadd125044007351905d40c405fadc2d3bb6d6
- https://git.kernel.org/stable/c/ea80e3ed09ab2c2b75724faf5484721753e92c31
- https://git.kernel.org/stable/c/f78807362828ad01db2a9ed005bf79501b620f27
Modified: 2025-09-26
CVE-2024-27435
In the Linux kernel, the following vulnerability has been resolved: nvme: fix reconnection fail due to reserved tag allocation We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue.
- https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8
- https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818
- https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96
- https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d
- https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a
- https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8
- https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818
- https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96
- https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d
- https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a
Modified: 2025-12-23
CVE-2024-27436
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Stop parsing channels bits when all channels are found. If a usb audio device sets more bits than the amount of channels it could write outside of the map array.
- https://git.kernel.org/stable/c/22cad1b841a63635a38273b799b4791f202ade72
- https://git.kernel.org/stable/c/5cd466673b34bac369334f66cbe14bb77b7d7827
- https://git.kernel.org/stable/c/629af0d5fe94a35f498ba2c3f19bd78bfa591be6
- https://git.kernel.org/stable/c/6d5dc96b154be371df0d62ecb07efe400701ed8a
- https://git.kernel.org/stable/c/6d88b289fb0a8d055cb79d1c46a56aba7809d96d
- https://git.kernel.org/stable/c/7e2c1b0f6dd9abde9e60f0f9730026714468770f
- https://git.kernel.org/stable/c/9af1658ba293458ca6a13f70637b9654fa4be064
- https://git.kernel.org/stable/c/a39d51ff1f52cd0b6fe7d379ac93bd8b4237d1b7
- https://git.kernel.org/stable/c/c8a24fd281dcdf3c926413dafbafcf35cde517a9
- https://git.kernel.org/stable/c/22cad1b841a63635a38273b799b4791f202ade72
- https://git.kernel.org/stable/c/5cd466673b34bac369334f66cbe14bb77b7d7827
- https://git.kernel.org/stable/c/629af0d5fe94a35f498ba2c3f19bd78bfa591be6
- https://git.kernel.org/stable/c/6d5dc96b154be371df0d62ecb07efe400701ed8a
- https://git.kernel.org/stable/c/6d88b289fb0a8d055cb79d1c46a56aba7809d96d
- https://git.kernel.org/stable/c/7e2c1b0f6dd9abde9e60f0f9730026714468770f
- https://git.kernel.org/stable/c/9af1658ba293458ca6a13f70637b9654fa4be064
- https://git.kernel.org/stable/c/a39d51ff1f52cd0b6fe7d379ac93bd8b4237d1b7
- https://git.kernel.org/stable/c/c8a24fd281dcdf3c926413dafbafcf35cde517a9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-03
CVE-2024-35827
In the Linux kernel, the following vulnerability has been resolved: io_uring/net: fix overflow check in io_recvmsg_mshot_prep() The "controllen" variable is type size_t (unsigned long). Casting it to int could lead to an integer underflow. The check_add_overflow() function considers the type of the destination which is type int. If we add two positive values and the result cannot fit in an integer then that's counted as an overflow. However, if we cast "controllen" to an int and it turns negative, then negative values *can* fit into an int type so there is no overflow. Good: 100 + (unsigned long)-4 = 96 <-- overflow Bad: 100 + (int)-4 = 96 <-- no overflow I deleted the cast of the sizeof() as well. That's not a bug but the cast is unnecessary.
- https://git.kernel.org/stable/c/0c8c74bb59e7d77554016efc34c2d10376985e5e
- https://git.kernel.org/stable/c/59a534690ecc3af72c6ab121aeac1237a4adae66
- https://git.kernel.org/stable/c/868ec868616438df487b9e2baa5a99f8662cc47c
- https://git.kernel.org/stable/c/8ede3db5061bb1fe28e2c9683329aafa89d2b1b4
- https://git.kernel.org/stable/c/b6563ad0d599110bd5cf8f56c47d279c3ed796fe
- https://git.kernel.org/stable/c/0c8c74bb59e7d77554016efc34c2d10376985e5e
- https://git.kernel.org/stable/c/59a534690ecc3af72c6ab121aeac1237a4adae66
- https://git.kernel.org/stable/c/868ec868616438df487b9e2baa5a99f8662cc47c
- https://git.kernel.org/stable/c/8ede3db5061bb1fe28e2c9683329aafa89d2b1b4
- https://git.kernel.org/stable/c/b6563ad0d599110bd5cf8f56c47d279c3ed796fe
Modified: 2025-01-14
CVE-2024-35828
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().
- https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9
- https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a
- https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab
- https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186
- https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf
- https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591
- https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3
- https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2
- https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7
- https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9
- https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a
- https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab
- https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186
- https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf
- https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591
- https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3
- https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2
- https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35829
In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix a memleak in lima_heap_alloc When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks.
- https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea
- https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab
- https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f
- https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7
- https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd
- https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed
- https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf
- https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea
- https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab
- https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f
- https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7
- https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd
- https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed
- https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-35830
In the Linux kernel, the following vulnerability has been resolved: media: tc358743: register v4l2 async device only after successful setup Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.
- https://git.kernel.org/stable/c/17c2650de14842c25c569cbb2126c421489a3a24
- https://git.kernel.org/stable/c/4f1490a5d7a0472ee5d9f36547bc4ba46be755c7
- https://git.kernel.org/stable/c/610f20e5cf35ca9c0992693cae0dd8643ce932e7
- https://git.kernel.org/stable/c/87399f1ff92203d65f1febf5919429f4bb613a02
- https://git.kernel.org/stable/c/8ba8db9786b55047df5ad3db3e01dd886687a77d
- https://git.kernel.org/stable/c/b8505a1aee8f1edc9d16d72ae09c93de086e2a1a
- https://git.kernel.org/stable/c/c915c46a25c3efb084c4f5e69a053d7f7a635496
- https://git.kernel.org/stable/c/daf21394f9898fb9f0698c3e50de08132d2164e6
- https://git.kernel.org/stable/c/edbb3226c985469a2f8eb69885055c9f5550f468
- https://git.kernel.org/stable/c/17c2650de14842c25c569cbb2126c421489a3a24
- https://git.kernel.org/stable/c/4f1490a5d7a0472ee5d9f36547bc4ba46be755c7
- https://git.kernel.org/stable/c/610f20e5cf35ca9c0992693cae0dd8643ce932e7
- https://git.kernel.org/stable/c/87399f1ff92203d65f1febf5919429f4bb613a02
- https://git.kernel.org/stable/c/8ba8db9786b55047df5ad3db3e01dd886687a77d
- https://git.kernel.org/stable/c/b8505a1aee8f1edc9d16d72ae09c93de086e2a1a
- https://git.kernel.org/stable/c/c915c46a25c3efb084c4f5e69a053d7f7a635496
- https://git.kernel.org/stable/c/daf21394f9898fb9f0698c3e50de08132d2164e6
- https://git.kernel.org/stable/c/edbb3226c985469a2f8eb69885055c9f5550f468
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-07
CVE-2024-35833
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA This dma_alloc_coherent() is undone neither in the remove function, nor in the error handling path of fsl_qdma_probe(). Switch to the managed version to fix both issues.
- https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3
- https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24
- https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8
- https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59
- https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714
- https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6
- https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802
- https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3
- https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24
- https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8
- https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59
- https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714
- https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6
- https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-35844
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix reserve_cblocks counting error when out of space When a file only needs one direct_node, performing the following operations will cause the file to be unrepairable: unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4.8M 100% /data unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0 This is because the file has only one direct_node. After returning to -ENOSPC, reserved_blocks += ret will not be executed. As a result, the reserved_blocks at this time is still 0, which is not the real number of reserved blocks. Therefore, fsck cannot be set to repair the file. After this patch, the fsck flag will be set to fix this problem. unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device adb reboot then fsck will be executed unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 924
- https://git.kernel.org/stable/c/2f6d721e14b69d6e1251f69fa238b48e8374e25f
- https://git.kernel.org/stable/c/569c198c9e2093fd29cc071856a4e548fda506bc
- https://git.kernel.org/stable/c/889846dfc8ee2cf31148a44bfd2faeb2faadc685
- https://git.kernel.org/stable/c/f0bf89e84c3afb79d7a3a9e4bc853ad6a3245c0a
- https://git.kernel.org/stable/c/fa3ac8b1a227d9b470b87972494293348b5839ee
- https://git.kernel.org/stable/c/fc0aed88afbf6f606205129a7466eebdf528e3f3
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/2f6d721e14b69d6e1251f69fa238b48e8374e25f
- https://git.kernel.org/stable/c/569c198c9e2093fd29cc071856a4e548fda506bc
- https://git.kernel.org/stable/c/889846dfc8ee2cf31148a44bfd2faeb2faadc685
- https://git.kernel.org/stable/c/f0bf89e84c3afb79d7a3a9e4bc853ad6a3245c0a
- https://git.kernel.org/stable/c/fa3ac8b1a227d9b470b87972494293348b5839ee
- https://git.kernel.org/stable/c/fc0aed88afbf6f606205129a7466eebdf528e3f3
Modified: 2025-04-07
CVE-2024-35845
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dbg-tlv: ensure NUL termination The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it.
- https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641
- https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c
- https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7
- https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a
- https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea
- https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209
- https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9
- https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641
- https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c
- https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7
- https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a
- https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea
- https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209
- https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-03
CVE-2024-40903
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps There could be a potential use-after-free case in tcpm_register_source_caps(). This could happen when: * new (say invalid) source caps are advertised * the existing source caps are unregistered * tcpm_register_source_caps() returns with an error as usb_power_delivery_register_capabilities() fails This causes port->partner_source_caps to hold on to the now freed source caps. Reset port->partner_source_caps value to NULL after unregistering existing source caps.
- https://git.kernel.org/stable/c/04c05d50fa79a41582f7bde8a1fd4377ae4a39e5
- https://git.kernel.org/stable/c/4053696594d7235f3638d49a00cf0f289e4b36a3
- https://git.kernel.org/stable/c/6b67b652849faf108a09647c7fde9b179ef24e2b
- https://git.kernel.org/stable/c/e7e921918d905544500ca7a95889f898121ba886
- https://git.kernel.org/stable/c/04c05d50fa79a41582f7bde8a1fd4377ae4a39e5
- https://git.kernel.org/stable/c/4053696594d7235f3638d49a00cf0f289e4b36a3
- https://git.kernel.org/stable/c/6b67b652849faf108a09647c7fde9b179ef24e2b
- https://git.kernel.org/stable/c/e7e921918d905544500ca7a95889f898121ba886
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41011
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space.
- https://git.kernel.org/stable/c/009c4d78bcf07c4ac2e3dd9f275b4eaa72b4f884
- https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
- https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5
- https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28
- https://git.kernel.org/stable/c/8ad4838040e5515939c071a0f511ce2661a0889d
- https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7
- https://git.kernel.org/stable/c/f7276cdc1912325b64c33fcb1361952c06e55f63
- https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
- https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5
- https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28
- https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
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: 2026-04-23
CVE-2024-58087
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix racy issue from session lookup and expire Increment the session reference count within the lock for lookup to avoid racy issue with session expire.
- https://git.kernel.org/stable/c/2107ab40629aeabbec369cf34b8cf0f288c3eb1b
- https://git.kernel.org/stable/c/37a0e2b362b3150317fb6e2139de67b1e29ae5ff
- https://git.kernel.org/stable/c/450a844c045ff0895d41b05a1cbe8febd1acfcfd
- https://git.kernel.org/stable/c/a39e31e22a535d47b14656a7d6a893c7f6cf758c
- https://git.kernel.org/stable/c/b95629435b84b9ecc0c765995204a4d8a913ed52
- https://www.zerodayinitiative.com/advisories/ZDI-25-100/
Modified: 2025-11-26
CVE-2024-58239
In the Linux kernel, the following vulnerability has been resolved: tls: stop recv() if initial process_rx_list gave us non-DATA If we have a non-DATA record on the rx_list and another record of the same type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATA Just check the record type and jump to the end in case process_rx_list did some work.
- https://git.kernel.org/stable/c/31e10d6cb0c9532ff070cf50da1657c3acee9276
- https://git.kernel.org/stable/c/3b952d8fdfcf6fd8ea0b8954bc9277642cf0977f
- https://git.kernel.org/stable/c/4338032aa90bd1d5b33a4274e8fa8347cda5ee09
- https://git.kernel.org/stable/c/6756168add1c6c3ef1c32c335bb843a5d1f99a75
- https://git.kernel.org/stable/c/a4ed943882a8fc057ea5a67643314245e048bbdd
- https://git.kernel.org/stable/c/f310143961e2d9a0479fca117ce869f8aaecc140
- https://git.kernel.org/stable/c/fdfbaec5923d9359698cbb286bc0deadbb717504
Modified: 2026-01-09
CVE-2024-58240
In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption request handling from async If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result. We should preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it. This will make the next fix easier.
- https://git.kernel.org/stable/c/41532b785e9d79636b3815a64ddf6a096647d011
- https://git.kernel.org/stable/c/48905146d11dbf1ddbb2967319016a83976953f5
- https://git.kernel.org/stable/c/999115298017a675d8ddf61414fc7a85c89f1186
- https://git.kernel.org/stable/c/dec5b6e7b211e405d3bcb504562ab21aa7e5a64d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
