HIGH7.8
Уязвимость модуля vmwgfx ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
ALT-PU-2024-2866-5Package update kernel-image-un-def in branch c10f2
Severity:
Closed issues (368)
HIGH7.5
Уязвимость функции __nvmet_req_complete() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CReferences
HIGH7.5
Уязвимость функции nvmet_tcp_build_pdu_iovec() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CReferences
HIGH7.5
Уязвимость функции xenvif_get_requests() кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции hugetlbfs_fill_super системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции nft_setelem_catchall_deactivate() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции nft_verdict_init() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM4.7
Уязвимость функции tls_decrypt_done (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции f2fs_rename() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции ksmbd_tcp_new_connection() модуля fs/smb/server/transport_tcp.c реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции of_syscon_register драйвера MFD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 2.1
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:PReferences
HIGH7.8
Уязвимость функции kv_parse_power_table компонента PM Driver ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.4
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:N/A:PReferences
HIGH7.8
Уязвимость функции tls_decrypt_done() модуля net/tls/tls_sw.c реализации протокола TLS (Transport Layer Security) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции radeon_crtc_init драйвера видеокарт AMD Radeon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 5.6
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:P/A:CReferences
HIGH7.8
Уязвимость функции nft_set_rbtree (net/netfilter/nft_set_rbtree.c) компонента Netfilter операционной системы Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции sys_membarrier компонента membarrier ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции binder_enqueue_thread_work_ilocked() в модуле drivers/android/binder.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость в функции sii902x_init() драйвера Silicon Image sii902x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.1
Уязвимость функции i801_block_transaction_by_block() в модуле drivers/i2c/busses/i2c-i801.c драйвера шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
HIGH7.8
Уязвимость функции omap8250_remove() в модуле drivers/tty/serial/8250/8250_omap.c драйвера последовательного интерфейса 8250 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции vgic_its_check_cache() в модуле arch/arm64/kvm/vgic/vgic-its.c подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции of_pwm_single_xlate() в модуле drivers/pwm/core.c драйвера устройств PWM (ШИМ, широтно-импульсной модуляции) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции thunderx_ocx_com_threaded_isr() в модуле drivers/edac/thunderx_edac.c драйвера EDAC (Error Detection and Correction) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции pvr2_context_disconnect() в модуле drivers/media/usb/pvrusb2/pvrusb2-context.c драйвера Hauppauge WinTV-PVR USB2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM6.7
Уязвимость функции mlxsw_sp_acl_tcam_init() в модуле drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c драйвера сетевых карт Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
CRITICAL9.8
Уязвимость функции rmnet_fill_info() в модуле drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c реализации протокола MAP (Multiplexing and Aggregation Protocol) драйвера сетевых карт Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции imx_uart_stop_tx() в модуле drivers/tty/serial/imx.c драйвера последовательных устройств Motorolla IMX ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:PReferences
MEDIUM5.5
Уязвимость функции bpf_tracing_prog_attach() в модуле kernel/bpf/syscall.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:PReferences
MEDIUM5.5
Уязвимость функции gfs2_rgrp_dump() в модуле fs/gfs2/rgrp.c файловой системы gfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции efivarfs_reconfigure() в модуле fs/efivarfs/super.c файловой системы EFI Variable Filesystem ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции bpf_map_put() в модуле kernel/bpf/syscall.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции dlpar_memory_remove_by_index() драйвера управления памятью powerpc pseries ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции ext4_mb_generate_buddy() в модуле fs/ext4/mballoc.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 6.4
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:P/A:PReferences
MEDIUM5.5
Уязвимость функции restore_fpregs_from_user() в модуле arch/x86/kernel/fpu/signal.c драйвера FPU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость драйвера MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:PReferences
MEDIUM5.5
Уязвимость функции nvmet_tcp_build_pdu_iovec() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.1
Уязвимость реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность данных
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
MEDIUM6.5
Уязвимость функциях map_usb_set_vbus() и omap_usb_start_srp() в модуле drivers/phy/ti/phy-omap-usb2.c драйвера USB устройств TI (Texas Instruments) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции check_stack_write_fixed_off() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:NCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:C/A:NReferences
HIGH7.1
Уязвимость функции adjust_ptr_min_max_vals() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая оказать воздействие на конфиденциальность и доступность защищаемой информации
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции unpack_profile() в модуле security/apparmor/policy_unpack.c модуля безопасности AppArmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции sock_orphan() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции build_insn() модуля arch/loongarch/net/bpf_jit.c компонента BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции skb_segment компонента Net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM6.2
Уязвимость функции __smc_diag_dump() в модуле net/smc/smc_diag.c реализации протокола SMC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 6.2
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость функции i2c_hid_of_probe() драйвера HID устройств шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.9
Уязвимость драйвера Intel Hardware Feedback Interface ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
CVSS 3.xMEDIUM 4.9
CVSS:3.x/AV:P/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:HCVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:CReferences
MEDIUM4.1
Уязвимость функции nci_free_device() реализации NFC Controller Interface (NCI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:LCVSS 2.0LOW 2.7
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:N/A:PReferences
HIGH7.8
Уязвимость функции __prep_cap() файловой системы ceph ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM4.1
Уязвимость функции __sev_platform_shutdown_locked() драйвера крипографического сопроцессора AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции ext4_move_extents() в модуле fs/ext4/move_extent.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость функции dwc3_gadget_suspend() драйвера USB DesignWare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
CRITICAL9.8
Уязвимость функции ipv6_mc_down() в модуле net/ipv6/mcast.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:CReferences
CRITICAL9.1
Уязвимость функции __ip6_tnl_rcv() в модуле net/ipv6/ip6_tunnel.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
CVSS 3.xCRITICAL 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HCVSS 2.0CRITICAL 9.4
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:N/A:CReferences
HIGH8.8
Уязвимость функции ip6_tnl_parse_tlv_enc_lim() в модуле net/ipv6/ip6_tunnel.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0CRITICAL 9.0
CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH8.4
Уязвимость функции __sock_xmit() в модуле drivers/block/nbd.c драйвера nbd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции default_device_exit_net() в модуле net/core/dev.c сетевой подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.5
Уязвимость функции can_map_frag() в модуле net/ipv4/tcp.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CReferences
MEDIUM5.9
Уязвимость функции check_for_locks() в модуле fs/nfsd/nfs4state.c сервера файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.9
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 5.4
CVSS:2.0/AV:N/AC:H/Au:N/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции fscache_put_cache() в модуле fs/netfs/fscache_cache.c файловой системы netfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции bio_first_folio() в модуле include/linux/bio.h подсистемы управления блочными устройствами ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции llc_conn_handler() в модуле net/llc/llc_conn.c реализации протокола LLC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции llc_ui_sendmsg() в модуле net/llc/af_llc.c реализации протокола LLC2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции create_snapshot() в модуле fs/btrfs/ioctl.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции hugetlbfs_parse_param() в модуле fs/hugetlbfs/inode.c системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции blkpg_do_ioctl() в модуле block/ioctl.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.5
Уязвимость функции vfio_ap_mdev_filter_matrix() драйвера криптографического устройства платформы IBM S/390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0CRITICAL 9.0
CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:CReferences
CRITICAL9.8
Уязвимость функции reqsk_queue_alloc() реализации протокола TCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:CReferences
HIGH8.4
Уязвимость функции ksmbd_nl_policy() реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции iwl_dbg_tlv_override_trig_node() драйвера адаптеров беспроводной связи Intel iwlwifi ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции dm_table_create() в модуле drivers/md/dm-table.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции synchronize_rcu() в компоненте ipset ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.5
Уязвимость функции opal_powercap_init() компонента arch/powerpc/platforms/powernv/opal-powercap.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость компонента dtSearch ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции nft_chain_filter компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость компонента erofs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:LCVSS 2.0LOW 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:PReferences
MEDIUM5.5
Уязвимость компонента ipoib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.1
Уязвимость компонента mtk-jpeg ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость компонента mhi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента mhi ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции scsi_host_busy() компонента drivers/scsi/scsi_error.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента fs/ntfs3 ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость функции stdev_release() компонента drivers/pci/switch/switchtec.c ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента hv_netvsc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость компонента rc ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:NCVSS 2.0LOW 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:NReferences
MEDIUM5.5
Уязвимость функции rm3100_common_probe() компонента drivers/iio/magnetometer/rm3100-core.c ядра операционной системы Linux, связанная с чтением за допустимыми границами буфера данных, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции rcu_scheduler_active() компонента net/sunrpc/xprtmultipath.c ядра операционной системы Linux, связанная с переполнением буфера на стеке, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции kasprintf() компонента arch/powerpc/mm/init-common.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента tpd12s015 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента pipe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM6.6
Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 6.6
CVSS:3.x/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
LOW3.3
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:NCVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:NReferences
HIGH7.8
Уязвимость компонента LPIT ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость компонента of ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость в компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонентов powerpc/imc-pmu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента mvpp2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента calipso ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента ACPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента powerpc/powernv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонентов powerpc/powernv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость функции stream_enc_regs() подсистемы Direct Rendering Manager (DRM) ядра операционной системы Linux ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции jfs_mount() в модуле fs/jfs/jfs_mount.c файловой системы jfs ядра операционной системы Linux в , позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции fcoe_ctlr_announce() модуля drivers/scsi/fcoe/fcoe_ctlr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:PReferences
MEDIUM5.5
Уязвимость функции unix_gc() модуля net/unix/garbage.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции nilfs_segctor_prepare_write() модуля fs/nilfs2/segment.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции do_fp_load() модуля arch/powerpc/lib/sstep.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции rt2x00lib_disable_radio() модуля drivers/net/wireless/ralink/rt2x00/rt2x00dev.c - драйвера поддержки адаптеров беспроводной связи Ralink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции rkisp1_csi_disable() модуля drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции section_nr_to_pfn() модуля include/linux/mmzone.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента sc16is7xx.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM6.7
Уязвимость функции parse_server_interfaces() модуля fs/smb/client/smb2ops.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:A/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:HCVSS 2.0HIGH 7.1
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:C/A:CReferences
HIGH7.8
Уязвимость функции trans_stat_show() модуля drivers/devfreq/devfreq.c - драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции dev_pm_skip_resume() модуля drivers/base/power/main.c - драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции ath9k_htc_txstatus() модуля drivers/net/wireless/ath/ath9k/htc_drv_txrx.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции diNewExt() модуля fs/jfs/jfs_imap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции dbAllocBits() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции dtSplitRoot() модуля fs/jfs/jfs_dtree.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции dbAdjTree() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции j1939_sk_match_dst() модуля net/can/j1939/socket.c поддержки сокетов j1939 шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции aq_ptp_ring_alloc() модуля drivers/net/ethernet/aquantia/atlantic/aq_ptp.c - драйвера поддержки сетевых адаптеров Ethernet с чипсетом aQuantia Atlantic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.1
Уязвимость функции set_cluster_dirty() модуля fs/f2fs/compress.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
HIGH7.1
Уязвимость функции __poke_user() модуля arch/s390/kernel/ptrace.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции rng_get_data() модуля drivers/char/hw_random/core.c - драйвера поддержки алфавитно-цифровых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента tracing/trigger ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции wfx_upload_ap_templates() модуля drivers/net/wireless/silabs/wfx/sta.c - драйвера поддержки адаптеров беспроводной связи Silicon Laboratories ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции drm_mode_page_flip_ioctls модуля drivers/gpu/drm/drm_plane.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции shmem_fetch_notification() модуля drivers/firmware/arm_scmi/common.h - драйвера поддержки прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции scomp_acomp_comp_decomp() модуля crypto/scompress.c криптографической подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.1
Уязвимость ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
HIGH7.8
Уязвимость функций rcu_read_lock_held(), BPF_CALL_4() and BPF_CALL_2() (kernel/bpf/helpers.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
LOW3.8
Уязвимость компонента mediatek c ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
CVSS 3.xLOW 3.8
CVSS:3.x/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:NCVSS 2.0MEDIUM 4.7
CVSS:2.0/AV:N/AC:L/Au:M/C:P/I:P/A:NReferences
MEDIUM5.5
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента sc8180x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM6.3
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
HIGH7.1
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции tcf_ct_handle_fragments() модуля net/sched/act_ct.c ядра операционной системы Linux, позволяющая удаленному нарушителю оказать воздействие на доступность защищаемой информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции mpi_ec_init() модуля lib/mpi/ec.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции ramoops_init_przs() модуля fs/pstore/ram.c поддержки постоянного хранилища ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции alloc_flex_gd() модуля fs/ext4/resize.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции j1939_netdev_start() модуля net/can/j1939/main.c поддержки сокетов j1939 шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.1
Уязвимость функции create_core_data() модуля drivers/hwmon/coretemp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции binder_update_page_range() модуля drivers/android/binder_alloc.c драйвера поддержки связи с Android ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции devfreq_monitor() модуля drivers/devfreq/devfreq.c драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.3
Уязвимость функции rnbd_srv_get_full_path() модуля drivers/block/rnbd/rnbd-srv.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NCVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:N/A:NReferences
HIGH7.1
Уязвимость функции nft_limit_eval() модуля net/netfilter/nft_limit.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
MEDIUM4.0
Уязвимость функции kvm_arch_vcpu_ioctl_set_fpu() модуля arch/s390/kvm/kvm-s390.c поддержки платформы S390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
CVSS 3.xMEDIUM 4.0
CVSS:3.x/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:LCVSS 2.0LOW 2.6
CVSS:2.0/AV:L/AC:H/Au:N/C:N/I:P/A:PReferences
MEDIUM4.4
Уязвимость функции __tracing_map_insert() модуля kernel/trace/tracing_map.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции tipc_nl_bearer_add() модуля net/tipc/bearer.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость функции time_travel_update_time() модуля arch/um/kernel/time.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость функции dpu_encoder_helper_phys_cleanup() модуля drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции nilfs_prepare_segment_for_recovery() модуля fs/nilfs2/recovery.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции blk_mq_mark_tag_wait() модуля block/blk-mq.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
HIGH7.5
Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://xenbits.xenproject.org/xsa/advisory-448.html
- http://xenbits.xen.org/xsa/advisory-448.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://xenbits.xenproject.org/xsa/advisory-448.html
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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:
udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
__skb_gso_segment+0x339/0x710 net/core/gso.c:124
skb_gso_segment include/net/gso.h:83 [inline]
validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x257/0x380 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
__sys_sendto+0x255/0x340 net/socket.c:2190
__do_sys_sendto net/socket.c:2202 [inline]
__se_sys_sendto net/socket.c:2198 [inline]
__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f8692032aa9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
Modules linked in:
---[ end trace 0000000000000000 ]---
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 R0
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
apparmor: avoid crash when parsed profile name is empty
When processing a packed profile in unpack_profile() described like
"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().
aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
? strlen+0x1e/0xa0
aa_policy_init+0x1bb/0x230
aa_alloc_profile+0xb1/0x480
unpack_profile+0x3bc/0x4960
aa_unpack+0x309/0x15e0
aa_replace_profiles+0x213/0x33c0
policy_update+0x261/0x370
profile_replace+0x20e/0x2a0
vfs_write+0x2af/0xe00
ksys_write+0x126/0x250
do_syscall_64+0x46/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
---[ end trace 0000000000000000 ]---
RIP: 0010:strlen+0x1e/0xa0
It seems such behaviour of aa_splitn_fqname() is expected and checked in
other places where it is called (e.g. aa_remove_profiles). Well, there
is an explicit comment "a ns name without a following profile is allowed"
inside.
AFAICS, nothing can prevent unpacked "name" to be in form like
":samba-dcerpcd" - it is passed from userspace.
Deny the whole profile set replacement in such case and inform user with
EPROTO and an explaining message.
Found by Linux Verification Center (linuxtesting.org).
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4
- https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf
- https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200
- https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203
- https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87
- https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e
- https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e
- https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45
- https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4
- https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf
- https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200
- https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203
- https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87
- https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e
- https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e
- https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46
- https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862
- https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28
- https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024
- https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310
- https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728
- https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7
- https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77
- https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46
- https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862
- https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28
- https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024
- https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310
- https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728
- https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7
- https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795
- https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e
- https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb
- https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c
- https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d
- https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1
- https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08
- https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab
- https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795
- https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e
- https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb
- https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c
- https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d
- https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1
- https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08
- https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM6.7
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map.
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6
- https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0
- https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368
- https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2
- https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5
- https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee
- https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6
- https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0
- https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368
- https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2
- https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5
- https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05
- https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37
- https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa
- https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a
- https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a
- https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178
- https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde
- https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05
- https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37
- https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa
- https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a
- https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a
- https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178
- https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8
- https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745
- https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5
- https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6
- https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022
- https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc
- https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65
- https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c
- https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8
- https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745
- https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5
- https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6
- https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022
- https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc
- https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65
- https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0
- https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc
- https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d
- https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7
- https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e
- https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c
- https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5
- https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e
- https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0
- https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc
- https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d
- https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7
- https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e
- https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c
- https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5
- https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88
- https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42
- https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d
- https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68
- https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d
- https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be
- https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510
- https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88
- https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42
- https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d
- https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68
- https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d
- https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be
- https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06
- https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda
- https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181
- https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0
- https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b
- https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19
- https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06
- https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda
- https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181
- https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0
- https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b
- https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130b0af690
- https://git.kernel.org/stable/c/887a558d0298d36297daea039954c39940228d9b
- https://git.kernel.org/stable/c/95e4e0031effad9837af557ecbfd4294a4d8aeee
- https://git.kernel.org/stable/c/ad90d0358bd3b4554f243a425168fc7cebe7d04e
- https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93
- https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0
- https://git.kernel.org/stable/c/d74173bda29aba58f822175d983d07c8ed335494
- https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130b0af690
- https://git.kernel.org/stable/c/887a558d0298d36297daea039954c39940228d9b
- https://git.kernel.org/stable/c/95e4e0031effad9837af557ecbfd4294a4d8aeee
- https://git.kernel.org/stable/c/ad90d0358bd3b4554f243a425168fc7cebe7d04e
- https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93
- https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0
- https://git.kernel.org/stable/c/d74173bda29aba58f822175d983d07c8ed335494
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:NReferences
- https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef
- https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036
- https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf
- https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174
- https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae
- https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104
- https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef
- https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036
- https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf
- https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174
- https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae
- https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737
- https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe
- https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826
- https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8
- https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548
- https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b
- https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737
- https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe
- https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826
- https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8
- https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548
- https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5
- https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8
- https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6
- https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
- https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21
- https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601
- https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398
- https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057
- https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5
- https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8
- https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6
- https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
- https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21
- https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601
- https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398
- https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c
- https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1
- https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001
- https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973
- https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875
- https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b
- https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c
- https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1
- https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001
- https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973
- https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875
- https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drivers/amd/pm: fix a use-after-free in kv_parse_power_table When ps allocated by kzalloc equals to NULL, kv_parse_power_table frees adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call chains: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its first free in kv_parse_power_table and causes a use-after-free bug.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743
- https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02
- https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706
- https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3
- https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e
- https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63
- https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3
- https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a
- https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743
- https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02
- https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706
- https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3
- https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e
- https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63
- https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3
- https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() check the alloc_workqueue return value in radeon_crtc_init() to avoid null-ptr-deref.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088
- https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1
- https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41
- https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb
- https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4
- https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310
- https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85
- https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97
- https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088
- https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1
- https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41
- https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb
- https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4
- https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310
- https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85
- https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229
- https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0
- https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7
- https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551
- https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a
- https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c
- https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c
- https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105
- https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229
- https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0
- https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7
- https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551
- https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a
- https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c
- https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c
- https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte. The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_ versions in order to remove the manual cache control which was a workaround when using the _raw_ versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db
- https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573
- https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611
- https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23
- https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b
- https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169
- https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db
- https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573
- https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611
- https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23
- https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b
- https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: mm/sparsemem: fix race in accessing memory_section->usage The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1]. compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL] NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled. The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed. Fix this issue by the below steps: a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. Thanks to David/Pavan for their inputs on this patch. [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/ On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. For this particular issue below is the log. Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing. [ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated---
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7
- https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800
- https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a
- https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97
- https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea
- https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529
- https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7
- https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800
- https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a
- https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97
- https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea
- https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590
- https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e
- https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9
- https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c
- https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7
- https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6
- https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590
- https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e
- https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9
- https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c
- https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7
- https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM4.4
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function.
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79
- https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08
- https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b
- https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0
- https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17
- https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7
- https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79
- https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08
- https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b
- https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0
- https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17
- https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Drop chan lock before queuing buffers Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup. [mani: added fixes tag and cc'ed stable]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b
- https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
- https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690
- https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece
- https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830
- https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e
- https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b
- https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
- https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690
- https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece
- https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830
- https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Add alignment check for event ring read pointer Though we do check the event ring read pointer by "is_valid_ring_ptr" to make sure it is in the buffer range, but there is another risk the pointer may be not aligned. Since we are expecting event ring elements are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer could lead to multiple issues like DoS or ring buffer memory corruption. So add a alignment check for event ring read pointer.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551
- https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08
- https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010
- https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b
- https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f
- https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551
- https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08
- https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010
- https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b
- https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f
MEDIUM6.1
In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order.
CVSS 3.xMEDIUM 6.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:HReferences
- https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847
- https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de
- https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184
- https://git.kernel.org/stable/c/9ff2d260b25df6fe1341a79113d88fecf6bd553e
- https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379
- https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e
- https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae
- https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847
- https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de
- https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184
- https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379
- https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e
- https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557
- https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7
- https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0
- https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34
- https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe
- https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d
- https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557
- https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7
- https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0
- https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34
- https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe
- https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160
- https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980
- https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67
- https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e
- https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca
- https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085
- https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3
- https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6
- https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160
- https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980
- https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67
- https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e
- https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca
- https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085
- https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3
- https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
LOW3.8
In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller.
CVSS 3.xLOW 3.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:NReferences
- https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8
- https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e
- https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9
- https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e
- https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8
- https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e
- https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9
- https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
`priv->multicast_list` and we keep | remove_list, list)
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.
crash> bc 31
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
--
[exception RIP: ipoib_mcast_join_task+0x1b1]
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
work (&priv->mcast_task{,.work})
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
&mcast->list
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
mcast
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
dev priv (&priv->lock) &priv->multicast_list (aka head)
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- ---
#5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]
#6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
crash> rx ff646f199a8c7e68
ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work
crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000
(empty)
crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000
mcast_task.work.func = 0xffffffffc0944910 ,
mcast_mutex.owner.counter = 0xff1c69998efec000
crash> b 8
PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"
--
#3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646
#4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]
#5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]
#6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]
#7 [ff
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18
- https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825
- https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9
- https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a
- https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90
- https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89
- https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
- https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34
- https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18
- https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825
- https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9
- https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a
- https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90
- https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89
- https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
- https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to tag gcing flag on page during block migration It needs to add missing gcing flag on page during block migration, in order to garantee migrated data be persisted during checkpoint, otherwise out-of-order persistency between data and node may cause data corruption after SPOR. Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag gcing flag on page during file defragment").
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde
- https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b
- https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c
- https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136
- https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3
- https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde
- https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b
- https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c
- https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136
- https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ disable race issue In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7
- https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395
- https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe
- https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545
- https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7
- https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395
- https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe
- https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878
- https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03
- https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132
- https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d
- https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878
- https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03
- https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132
- https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus() Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case. Found by a modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234
- https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348
- https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1
- https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9
- https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1
- https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d
- https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225
- https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc
- https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234
- https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348
- https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1
- https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9
- https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1
- https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d
- https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225
- https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83
- https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c
- https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e
- https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957
- https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8
- https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48
- https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb
- https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83
- https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c
- https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e
- https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957
- https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8
- https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48
- https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM4.0
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu. Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c.
CVSS 3.xMEDIUM 4.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:LReferences
- https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3
- https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99
- https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7
- https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18
- https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1
- https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2
- https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55
- https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f
- https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3
- https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99
- https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7
- https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18
- https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1
- https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2
- https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55
- https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc register correctly If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when returning to user space. In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs() before using test_fp_ctl().
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1
- https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25
- https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713
- https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8
- https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3
- https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a
- https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829
- https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4
- https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1
- https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25
- https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713
- https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8
- https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3
- https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a
- https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829
- https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diNewExt
[Syz report]
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
index -878706688 is out of range for type 'struct iagctl[128]'
CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
diAllocExt fs/jfs/jfs_imap.c:1949 [inline]
diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587
ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225
vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106
do_mkdirat+0x264/0x3a0 fs/namei.c:4129
__do_sys_mkdir fs/namei.c:4149 [inline]
__se_sys_mkdir fs/namei.c:4147 [inline]
__x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fcb7e6a0b57
Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57
RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[Analysis]
When the agstart is too large, it can cause agno overflow.
[Fix]
After obtaining agno, if the value is invalid, exit the subsequent process.
Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next
report by kernel test robot (Dan Carpenter).
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641
- https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402
- https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe
- https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b
- https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98
- https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017
- https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e
- https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41
- https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641
- https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402
- https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe
- https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b
- https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98
- https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017
- https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e
- https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e
- https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce
- https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35
- https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61
- https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f
- https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e
- https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8
- https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3
- https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e
- https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce
- https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35
- https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61
- https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f
- https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e
- https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8
- https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbAdjTree Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add the required check added the bool is_ctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317
- https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c
- https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555
- https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e
- https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603
- https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b
- https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e
- https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73
- https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317
- https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c
- https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555
- https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e
- https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603
- https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b
- https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e
- https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds Read in dtSearch Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb
- https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6
- https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd
- https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7
- https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472
- https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612
- https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950
- https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f
- https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb
- https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6
- https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd
- https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7
- https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472
- https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612
- https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950
- https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
UBSAN: array-index-out-of-bounds in dtSplitRoot
Syzkaller reported the following issue:
oop0: detected capacity change from 0 to 32768
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type 'struct dtslot [128]'
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
do_mkdirat+0x279/0x550 fs/namei.c:4038
__do_sys_mkdirat fs/namei.c:4053 [inline]
__se_sys_mkdirat fs/namei.c:4051 [inline]
__x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fcdc0113fd9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
The issue is caused when the value of fsi becomes less than -1.
The check to break the loop when fsi value becomes -1 is present
but syzbot was able to produce value less than -1 which cause the error.
This patch simply add the change for the values less than 0.
The patch is tested via syzbot.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16
- https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2
- https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8
- https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af
- https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60
- https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39
- https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f
- https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07
- https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16
- https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2
- https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8
- https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af
- https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60
- https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39
- https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f
- https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
================================================================================
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
panic+0x30f/0x770 kernel/panic.c:340
check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
ubsan_epilogue lib/ubsan.c:223 [inline]
__ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
Kernel Offset: disabled
Rebooting in 86400 seconds..
The issue is caused when the value of lp becomes greater than
CTLTREESIZE which is the max size of stree. Adding a simple check
solves this issue.
Dave:
As the function returns a void, good error handling
would require a more intrusive code reorganization, so I modified
Osama's patch at use WARN_ON_ONCE for lack of a cleaner option.
The patch is tested via syzbot.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03
- https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9
- https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd
- https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b
- https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68
- https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56
- https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b
- https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15
- https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03
- https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9
- https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd
- https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b
- https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68
- https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56
- https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b
- https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/lib: Validate size for vector operations Some of the fp/vmx code in sstep.c assume a certain maximum size for the instructions being emulated. The size of those operations however is determined separately in analyse_instr(). Add a check to validate the assumption on the maximum size of the operations, so as to prevent any unintended kernel stack corruption.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf
- https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c
- https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414
- https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd
- https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59
- https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e
- https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678
- https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b
- https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf
- https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c
- https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414
- https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd
- https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59
- https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e
- https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678
- https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532
- https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611
- https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b
- https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7
- https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1
- https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071
- https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e
- https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74
- https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532
- https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611
- https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b
- https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7
- https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1
- https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071
- https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e
- https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Check mailbox/SMT channel for consistency On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda
- https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306
- https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d
- https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350
- https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2
- https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda
- https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306
- https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d
- https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350
- https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then. In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097
- https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3
- https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e
- https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01
- https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918
- https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608
- https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9
- https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5
- https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097
- https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3
- https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e
- https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01
- https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918
- https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608
- https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9
- https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix skb leak and crash on ooo frags
act_ct adds skb->users before defragmentation. If frags arrive in order,
the last frag's reference is reset in:
inet_frag_reasm_prepare
skb_morph
which is not straightforward.
However when frags arrive out of order, nobody unref the last frag, and
all frags are leaked. The situation is even worse, as initiating packet
capture can lead to a crash[0] when skb has been cloned and shared at the
same time.
Fix the issue by removing skb_get() before defragmentation. act_ct
returns TC_ACT_CONSUMED when defrag failed or in progress.
[0]:
[ 843.804823] ------------[ cut here ]------------
[ 843.809659] kernel BUG at net/core/skbuff.c:2091!
[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 843.894229] PKRU: 55555554
[ 843.898539] Call Trace:
[ 843.902772]
[ 843.906922] ? __die_body+0x1e/0x60
[ 843.911032] ? die+0x3c/0x60
[ 843.915037] ? do_trap+0xe2/0x110
[ 843.918911] ? pskb_expand_head+0x2ac/0x300
[ 843.922687] ? do_error_trap+0x65/0x80
[ 843.926342] ? pskb_expand_head+0x2ac/0x300
[ 843.929905] ? exc_invalid_op+0x50/0x60
[ 843.933398] ? pskb_expand_head+0x2ac/0x300
[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20
[ 843.940226] ? pskb_expand_head+0x2ac/0x300
[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240
[ 843.946904] ip_defrag+0x5d4/0x870
[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]
[ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct]
[ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred]
[ 843.959657] tcf_action_exec+0xa1/0x160
[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower]
[ 843.966010] ? skb_clone+0x53/0xc0
[ 843.969173] tcf_classify+0x24d/0x420
[ 843.972333] tc_run+0x8f/0xf0
[ 843.975465] __netif_receive_skb_core+0x67a/0x1080
[ 843.978634] ? dev_gro_receive+0x249/0x730
[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260
[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0
[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]
[ 843.991170] napi_complete_done+0x72/0x1a0
[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]
[ 843.997501] __napi_poll+0x25/0x1b0
[ 844.000627] net_rx_action+0x256/0x330
[ 844.003705] __do_softirq+0xb3/0x29b
[ 844.006718] irq_exit_rcu+0x9e/0xc0
[ 844.009672] common_interrupt+0x86/0xa0
[ 844.012537]
[ 844.015285]
[ 844.017937] asm_common_interrupt+0x26/0x40
[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20
[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4
- https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4
- https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6
- https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97
- https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441
- https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4
- https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4
- https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6
- https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97
- https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe
- https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e
- https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5
- https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883
- https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131
- https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759
- https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625
- https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76
- https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe
- https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e
- https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5
- https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883
- https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131
- https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759
- https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625
- https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c
- https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4
- https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f
- https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c
- https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8
- https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87
- https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c
- https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4
- https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f
- https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c
- https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8
- https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM4.4
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.3
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present).
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
These three bpf_map_{lookup,update,delete}_elem() helpers are also
available for sleepable bpf program, so add the corresponding lock
assertion for sleepable bpf program, otherwise the following warning
will be reported when a sleepable bpf program manipulates bpf map under
interpreter mode (aka bpf_jit_enable=0):
WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
RIP: 0010:bpf_map_lookup_elem+0x54/0x60
......
Call Trace:
? __warn+0xa5/0x240
? bpf_map_lookup_elem+0x54/0x60
? report_bug+0x1ba/0x1f0
? handle_bug+0x40/0x80
? exc_invalid_op+0x18/0x50
? asm_exc_invalid_op+0x1b/0x20
? __pfx_bpf_map_lookup_elem+0x10/0x10
? rcu_lockdep_current_cpu_online+0x65/0xb0
? rcu_is_watching+0x23/0x50
? bpf_map_lookup_elem+0x54/0x60
? __pfx_bpf_map_lookup_elem+0x10/0x10
___bpf_prog_run+0x513/0x3b70
__bpf_prog_run32+0x9d/0xd0
? __bpf_prog_enter_sleepable_recur+0xad/0x120
? __bpf_prog_enter_sleepable_recur+0x3e/0x120
bpf_trampoline_6442580665+0x4d/0x1000
__x64_sys_getpgid+0x5/0x30
? do_syscall_64+0x36/0xb0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d
- https://git.kernel.org/stable/c/3516f93cc63d956e1b290ae4b7bf2586074535a0
- https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d
- https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612
- https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304
- https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3
- https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d
- https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d
- https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304
- https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid online resizing failures due to oversized flex bg
When we online resize an ext4 filesystem with a oversized flexbg_size,
mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
mount $dev $dir
resize2fs $dev 16G
the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
__kmalloc_large_node+0xa2/0x200
__kmalloc+0x16e/0x290
ext4_resize_fs+0x481/0xd80
__ext4_ioctl+0x1616/0x1d90
ext4_ioctl+0x12/0x20
__x64_sys_ioctl+0xf0/0x150
do_syscall_64+0x3b/0x90
==================================================================
This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:
(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845
And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0
- https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954
- https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c
- https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07
- https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644
- https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8
- https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90
- https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2
- https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0
- https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954
- https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c
- https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07
- https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644
- https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8
- https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90
- https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a suspicious RCU usage warning
I received the following warning while running cthon against an ontap
server running pNFS:
[ 57.202521] =============================
[ 57.202522] WARNING: suspicious RCU usage
[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
[ 57.202525] -----------------------------
[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
[ 57.202527]
other info that might help us debug this:
[ 57.202528]
rcu_scheduler_active = 2, debug_locks = 1
[ 57.202529] no locks held by test5/3567.
[ 57.202530]
stack backtrace:
[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
[ 57.202536] Call Trace:
[ 57.202537]
[ 57.202540] dump_stack_lvl+0x77/0xb0
[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0
[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202866] write_cache_pages+0x265/0x450
[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202913] do_writepages+0xd2/0x230
[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80
[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80
[ 57.202924] filemap_write_and_wait_range+0xd9/0x170
[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202969] __se_sys_close+0x46/0xd0
[ 57.202972] do_syscall_64+0x68/0x100
[ 57.202975] ? do_syscall_64+0x77/0x100
[ 57.202976] ? do_syscall_64+0x77/0x100
[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 57.202982] RIP: 0033:0x7fe2b12e4a94
[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3
[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94
[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003
[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49
[ 57.202993] R10: 00007f
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/31b62908693c90d4d07db597e685d9f25a120073
- https://git.kernel.org/stable/c/69c7eeb4f622c2a28da965f970f982db171f3dc6
- https://git.kernel.org/stable/c/7a96d85bf196c170dcf1b47a82e9bb97cca69aa6
- https://git.kernel.org/stable/c/8f860c8407470baff2beb9982ad6b172c94f1d0a
- https://git.kernel.org/stable/c/c430e6bb43955c6bf573665fcebf31694925b9f7
- https://git.kernel.org/stable/c/e8ca3e73301e23e8c0ac0ce2e6bac4545cd776e0
- https://git.kernel.org/stable/c/f8cf4dabbdcb8bef85335b0ed7ad5b25fd82ff56
- https://git.kernel.org/stable/c/fece80a2a6718ed58487ce397285bb1b83a3e54e
- https://git.kernel.org/stable/c/31b62908693c90d4d07db597e685d9f25a120073
- https://git.kernel.org/stable/c/69c7eeb4f622c2a28da965f970f982db171f3dc6
- https://git.kernel.org/stable/c/7a96d85bf196c170dcf1b47a82e9bb97cca69aa6
- https://git.kernel.org/stable/c/8f860c8407470baff2beb9982ad6b172c94f1d0a
- https://git.kernel.org/stable/c/c430e6bb43955c6bf573665fcebf31694925b9f7
- https://git.kernel.org/stable/c/e8ca3e73301e23e8c0ac0ce2e6bac4545cd776e0
- https://git.kernel.org/stable/c/f8cf4dabbdcb8bef85335b0ed7ad5b25fd82ff56
- https://git.kernel.org/stable/c/fece80a2a6718ed58487ce397285bb1b83a3e54e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7091r: Allow users to configure device events AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set. Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation. Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f
- https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4
- https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5
- https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091
- https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6
- https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2
- https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f
- https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4
- https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5
- https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091
- https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6
- https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4
- https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340
- https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c
- https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94
- https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4
- https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340
- https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c
- https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94
MEDIUM5.0
In the Linux kernel, the following vulnerability has been resolved: um: time-travel: fix time corruption In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled.
CVSS 3.xMEDIUM 5.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab
- https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025
- https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c
- https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283
- https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c
- https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab
- https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025
- https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c
- https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283
- https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].
while true
do
echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
done
It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.
[1]
...
..
-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428
-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c
-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428
kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227
vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532
vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428
xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428
[2]
9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a
[ 9436.261664][ C4] Mem abort info:
[ 9436.261666][ C4] ESR = 0x96000044
[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits
[ 9436.261671][ C4] SET = 0, FnV = 0
[ 9436.261673][ C4] EA = 0, S1PTW = 0
[ 9436.261675][ C4] Data abort info:
[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044
[ 9436.261680][ C4] CM = 0, WnR = 1
[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges
[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0
...
[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1
[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)
[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438
[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438
[ 9436.262168][ C4] sp : ffffffc010023dd0
[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008
[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280
[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122
[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80
[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038
[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201
[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100
[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff
[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122
[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101
[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675
- https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9
- https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9
- https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475
- https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22
- https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6
- https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675
- https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9
- https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9
- https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475
- https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22
- https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
HIGH7.8
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
__local_bh_enable_ip+0x6e/0x70
netif_rx+0x16b/0x180
can_send+0x32b/0x520 [can]
? __pfx_can_send+0x10/0x10 [can]
? __check_object_size+0x299/0x410
raw_sendmsg+0x572/0x6d0 [can_raw]
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
? apparmor_socket_sendmsg+0x2f/0x40
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
sock_sendmsg+0xef/0x100
sock_write_iter+0x162/0x220
? __pfx_sock_write_iter+0x10/0x10
? __rtnl_unlock+0x47/0x80
? security_file_permission+0x54/0x320
vfs_write+0x6ba/0x750
? __pfx_vfs_write+0x10/0x10
? __fget_light+0x1ca/0x1f0
? __rcu_read_unlock+0x5b/0x280
ksys_write+0x143/0x170
? __pfx_ksys_write+0x10/0x10
? __kasan_check_read+0x15/0x20
? fpregs_assert_state_consistent+0x62/0x70
__x64_sys_write+0x47/0x60
do_syscall_64+0x60/0x90
? do_syscall_64+0x6d/0x90
? irqentry_exit+0x3f/0x50
? exc_page_fault+0x79/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Allocated by task 348:
kasan_save_stack+0x2a/0x50
kasan_set_track+0x29/0x40
kasan_save_alloc_info+0x1f/0x30
__kasan_kmalloc+0xb5/0xc0
__kmalloc_node_track_caller+0x67/0x160
j1939_sk_setsockopt+0x284/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0
__x64_sys_setsockopt+0x6b/0x80
do_syscall_64+0x60/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Freed by task 349:
kasan_save_stack+0x2a/0x50
kasan_set_track+0x29/0x40
kasan_save_free_info+0x2f/0x50
__kasan_slab_free+0x12e/0x1c0
__kmem_cache_free+0x1b9/0x380
kfree+0x7a/0x120
j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0
__x64_sys_setsockopt+0x6b/0x80
do_syscall_64+0x60/0x90
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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
MEDIUM5.5
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]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
HIGH7.8
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.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d
- https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928
- https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf
- https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d
- https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d
- https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928
- https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf
- https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a potential double-free in fs_any_create_groups When kcalloc() for ft->g succeeds but kvzalloc() for in fails, fs_any_create_groups() will free ft->g. However, its caller fs_any_create_table() will free ft->g again through calling mlx5e_destroy_flow_table(), which will lead to a double-free. Fix this by setting ft->g to NULL in fs_any_create_groups().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8
- https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779
- https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1
- https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e
- https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe
- https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8
- https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779
- https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1
- https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e
- https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: crypto: s390/aes - Fix buffer overread in CTR mode When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: rpmsg: virtio: Free driver_override when rpmsg_remove() Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur: unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 ("pipe: Add general notification queue support") a
regression was introduced that would lock up resized pipes under certain
conditions. See the reproducer in [1].
The commit resizing the pipe ring size was moved to a different
function, doing that moved the wakeup for pipe->wr_wait before actually
raising pipe->max_usage. If a pipe was full before the resize occured it
would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a
watch queue.
[Christian Brauner : rewrite to account for watch queues]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put() Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside scarlett2_mixer_values[].
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572
- https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7
- https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2
- https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810
- https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b
- https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572
- https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7
- https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2
- https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810
- https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/imc-pmu: Add a null pointer check in update_events_in_group() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/024352f7928b28f53609660663329d8c0f4ad032
- https://git.kernel.org/stable/c/0a233867a39078ebb0f575e2948593bbff5826b3
- https://git.kernel.org/stable/c/1e80aa25d186a7aa212df5acd8c75f55ac8dae34
- https://git.kernel.org/stable/c/5a669f3511d273c8c1ab1c1d268fbcdf53fc7a05
- https://git.kernel.org/stable/c/75fc599bcdcb1de093c9ced2e3cccc832f3787f3
- https://git.kernel.org/stable/c/a2da3f9b1a1019c887ee1d164475a8fcdb0a3fec
- https://git.kernel.org/stable/c/c7d828e12b326ea50fb80c369d7aa87519ed14c6
- https://git.kernel.org/stable/c/f105c263009839d80fad6998324a4e1b3511cba0
- https://git.kernel.org/stable/c/024352f7928b28f53609660663329d8c0f4ad032
- https://git.kernel.org/stable/c/0a233867a39078ebb0f575e2948593bbff5826b3
- https://git.kernel.org/stable/c/1e80aa25d186a7aa212df5acd8c75f55ac8dae34
- https://git.kernel.org/stable/c/5a669f3511d273c8c1ab1c1d268fbcdf53fc7a05
- https://git.kernel.org/stable/c/75fc599bcdcb1de093c9ced2e3cccc832f3787f3
- https://git.kernel.org/stable/c/a2da3f9b1a1019c887ee1d164475a8fcdb0a3fec
- https://git.kernel.org/stable/c/c7d828e12b326ea50fb80c369d7aa87519ed14c6
- https://git.kernel.org/stable/c/f105c263009839d80fad6998324a4e1b3511cba0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: riscv: Check if the code to patch lies in the exit section Otherwise we fall through to vmalloc_to_page() which panics since the address does not lie in the vmalloc region.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1d7a03052846f34d624d0ab41a879adf5e85c85f
- https://git.kernel.org/stable/c/420370f3ae3d3b883813fd3051a38805160b2b9f
- https://git.kernel.org/stable/c/890cfe5337e0aaf03ece1429db04d23c88da72e7
- https://git.kernel.org/stable/c/8db56df4a954b774bdc68917046a685a9fa2e4bc
- https://git.kernel.org/stable/c/938f70d14618ec72e10d6fcf8a546134136d7c13
- https://git.kernel.org/stable/c/1d7a03052846f34d624d0ab41a879adf5e85c85f
- https://git.kernel.org/stable/c/420370f3ae3d3b883813fd3051a38805160b2b9f
- https://git.kernel.org/stable/c/890cfe5337e0aaf03ece1429db04d23c88da72e7
- https://git.kernel.org/stable/c/8db56df4a954b774bdc68917046a685a9fa2e4bc
- https://git.kernel.org/stable/c/938f70d14618ec72e10d6fcf8a546134136d7c13
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c Before using list_first_entry, make sure to check that list is not empty, if list is empty return -ENODATA. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4525525cb7161d08f95d0e47025323dd10214313
- https://git.kernel.org/stable/c/499839eca34ad62d43025ec0b46b80e77065f6d8
- https://git.kernel.org/stable/c/4ac4e023ed7ab1c7c67d2d12b7b6198fcd099e5c
- https://git.kernel.org/stable/c/5024cce888e11e5688f77df81db9e14828495d64
- https://git.kernel.org/stable/c/4525525cb7161d08f95d0e47025323dd10214313
- https://git.kernel.org/stable/c/499839eca34ad62d43025ec0b46b80e77065f6d8
- https://git.kernel.org/stable/c/4ac4e023ed7ab1c7c67d2d12b7b6198fcd099e5c
- https://git.kernel.org/stable/c/5024cce888e11e5688f77df81db9e14828495d64
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: of: Fix double free in of_parse_phandle_with_args_map In of_parse_phandle_with_args_map() the inner loop that iterates through the map entries calls of_node_put(new) to free the reference acquired by the previous iteration of the inner loop. This assumes that the value of "new" is NULL on the first iteration of the inner loop. Make sure that this is true in all iterations of the outer loop by setting "new" to NULL after its value is assigned to "cur". Extend the unittest to detect the double free and add an additional test case that actually triggers this path.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db
- https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21
- https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b
- https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2
- https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8
- https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd
- https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7
- https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea
- https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db
- https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21
- https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b
- https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2
- https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8
- https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd
- https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7
- https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add missing error checks to *_ctl_get() The *_ctl_get() functions which call scarlett2_update_*() were not checking the return value. Fix to check the return value and pass to the caller.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3a09488f4f67f7ade59b8ac62a6c7fb29439cf51
- https://git.kernel.org/stable/c/50603a67daef161c78c814580d57f7f0be57167e
- https://git.kernel.org/stable/c/773e38f73461ef2134a0d33a08f1668edde9b7c3
- https://git.kernel.org/stable/c/821fbaeaaae23d483d3df799fe91ec8045973ec3
- https://git.kernel.org/stable/c/cda7762bea857e6951315a2f7d0632ea1850ed43
- https://git.kernel.org/stable/c/3a09488f4f67f7ade59b8ac62a6c7fb29439cf51
- https://git.kernel.org/stable/c/50603a67daef161c78c814580d57f7f0be57167e
- https://git.kernel.org/stable/c/773e38f73461ef2134a0d33a08f1668edde9b7c3
- https://git.kernel.org/stable/c/821fbaeaaae23d483d3df799fe91ec8045973ec3
- https://git.kernel.org/stable/c/cda7762bea857e6951315a2f7d0632ea1850ed43
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A GC-Thread - f2fs_gc - do_garbage_collect - gc_data_segment - move_data_block - f2fs_submit_page_write migrate normal cluster's block via meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io IRQ old data overrides new data due to out-of-order GC and common IO. - f2fs_read_end_io
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/4535be48780431753505e74e1b1ad4836a189bc2
- https://git.kernel.org/stable/c/55fdc1c24a1d6229fe0ecf31335fb9a2eceaaa00
- https://git.kernel.org/stable/c/9bfd5ea71521d0e522ba581c6ccc5db93759c0c3
- https://git.kernel.org/stable/c/f904c156d8011d8291ffd5b6b398f3747e294986
- https://git.kernel.org/stable/c/4535be48780431753505e74e1b1ad4836a189bc2
- https://git.kernel.org/stable/c/55fdc1c24a1d6229fe0ecf31335fb9a2eceaaa00
- https://git.kernel.org/stable/c/9bfd5ea71521d0e522ba581c6ccc5db93759c0c3
- https://git.kernel.org/stable/c/f904c156d8011d8291ffd5b6b398f3747e294986
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ACPI: LPIT: Avoid u32 multiplication overflow In lpit_update_residency() there is a possibility of overflow in multiplication, if tsc_khz is large enough (> UINT_MAX/1000). Change multiplication to mul_u32_u32(). Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/56d2eeda87995245300836ee4dbd13b002311782
- https://git.kernel.org/stable/c/647d1d50c31e60ef9ccb9756a8fdf863329f7aee
- https://git.kernel.org/stable/c/6c38e791bde07d6ca2a0a619ff9b6837e0d5f9ad
- https://git.kernel.org/stable/c/72222dfd76a79d9666ab3117fcdd44ca8cd0c4de
- https://git.kernel.org/stable/c/b7aab9d906e2e252a7783f872406033ec49b6dae
- https://git.kernel.org/stable/c/c1814a4ffd016ce5392c6767d22ef3aa2f0d4bd1
- https://git.kernel.org/stable/c/d1ac288b2742aa4af746c5613bac71760fadd1c4
- https://git.kernel.org/stable/c/f39c3d578c7d09a18ceaf56750fc7f20b02ada63
- https://git.kernel.org/stable/c/56d2eeda87995245300836ee4dbd13b002311782
- https://git.kernel.org/stable/c/647d1d50c31e60ef9ccb9756a8fdf863329f7aee
- https://git.kernel.org/stable/c/6c38e791bde07d6ca2a0a619ff9b6837e0d5f9ad
- https://git.kernel.org/stable/c/72222dfd76a79d9666ab3117fcdd44ca8cd0c4de
- https://git.kernel.org/stable/c/b7aab9d906e2e252a7783f872406033ec49b6dae
- https://git.kernel.org/stable/c/c1814a4ffd016ce5392c6767d22ef3aa2f0d4bd1
- https://git.kernel.org/stable/c/d1ac288b2742aa4af746c5613bac71760fadd1c4
- https://git.kernel.org/stable/c/f39c3d578c7d09a18ceaf56750fc7f20b02ada63
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_event_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/8422d179cf46889c15ceff9ede48c5bfa4e7f0b4
- https://git.kernel.org/stable/c/8649829a1dd25199bbf557b2621cedb4bf9b3050
- https://git.kernel.org/stable/c/9a523e1da6d88c2034f946adfa4f74b236c95ca9
- https://git.kernel.org/stable/c/a14c55eb461d630b836f80591d8caf1f74e62877
- https://git.kernel.org/stable/c/c0b111ea786ddcc8be0682612830796ece9436c7
- https://git.kernel.org/stable/c/e08c2e275fa1874de945b87093f925997722ee42
- https://git.kernel.org/stable/c/e6ad05e3ae9c84c5a71d7bb2d44dc845ae7990cf
- https://git.kernel.org/stable/c/e93d7cf4c1ddbcd846739e7ad849f955a4f18031
- https://git.kernel.org/stable/c/8422d179cf46889c15ceff9ede48c5bfa4e7f0b4
- https://git.kernel.org/stable/c/8649829a1dd25199bbf557b2621cedb4bf9b3050
- https://git.kernel.org/stable/c/9a523e1da6d88c2034f946adfa4f74b236c95ca9
- https://git.kernel.org/stable/c/a14c55eb461d630b836f80591d8caf1f74e62877
- https://git.kernel.org/stable/c/c0b111ea786ddcc8be0682612830796ece9436c7
- https://git.kernel.org/stable/c/e08c2e275fa1874de945b87093f925997722ee42
- https://git.kernel.org/stable/c/e6ad05e3ae9c84c5a71d7bb2d44dc845ae7990cf
- https://git.kernel.org/stable/c/e93d7cf4c1ddbcd846739e7ad849f955a4f18031
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: safexcel - Add error handling for dma_map_sg() calls Macro dma_map_sg() may return 0 on error. This patch enables checks in case of the macro failure and ensures unmapping of previously mapped buffers with dma_unmap_sg(). Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4c0ac81a172a69a7733290915276672787e904ec
- https://git.kernel.org/stable/c/8084b788c2fb1260f7d44c032d5124680b20d2b2
- https://git.kernel.org/stable/c/87e02063d07708cac5bfe9fd3a6a242898758ac8
- https://git.kernel.org/stable/c/fc0b785802b856566df3ac943e38a072557001c4
- https://git.kernel.org/stable/c/4c0ac81a172a69a7733290915276672787e904ec
- https://git.kernel.org/stable/c/8084b788c2fb1260f7d44c032d5124680b20d2b2
- https://git.kernel.org/stable/c/87e02063d07708cac5bfe9fd3a6a242898758ac8
- https://git.kernel.org/stable/c/fc0b785802b856566df3ac943e38a072557001c4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check to scom_debug_init_one() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Add a null pointer check, and release 'ent' to avoid memory leaks.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1eefa93faf69188540b08b024794fa90b1d82e8b
- https://git.kernel.org/stable/c/2a82c4439b903639e0a1f21990cd399fb0a49c19
- https://git.kernel.org/stable/c/9a260f2dd827bbc82cc60eb4f4d8c22707d80742
- https://git.kernel.org/stable/c/a9c05cbb6644a2103c75b6906e9dafb9981ebd13
- https://git.kernel.org/stable/c/dd8422ff271c22058560832fc3006324ded895a9
- https://git.kernel.org/stable/c/ed8d023cfa97b559db58c0e1afdd2eec7a83d8f2
- https://git.kernel.org/stable/c/f84c1446daa552e9699da8d1f8375eac0f65edc7
- https://git.kernel.org/stable/c/1eefa93faf69188540b08b024794fa90b1d82e8b
- https://git.kernel.org/stable/c/2a82c4439b903639e0a1f21990cd399fb0a49c19
- https://git.kernel.org/stable/c/9a260f2dd827bbc82cc60eb4f4d8c22707d80742
- https://git.kernel.org/stable/c/a9c05cbb6644a2103c75b6906e9dafb9981ebd13
- https://git.kernel.org/stable/c/dd8422ff271c22058560832fc3006324ded895a9
- https://git.kernel.org/stable/c/ed8d023cfa97b559db58c0e1afdd2eec7a83d8f2
- https://git.kernel.org/stable/c/f84c1446daa552e9699da8d1f8375eac0f65edc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix a double-free in si_dpm_init When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706
- https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334
- https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30
- https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4
- https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0
- https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a
- https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2
- https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9
- https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706
- https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334
- https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30
- https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4
- https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0
- https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a
- https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2
- https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config() scarlett2_usb_set_config() calls scarlett2_usb_get() but was not checking the result. Return the error if it fails rather than continuing with an invalid value.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/145c5aa51486171025ab47f35cff34bff8d0cea3
- https://git.kernel.org/stable/c/51d5697e1c0380d482c3eab002bfc8d0be177e99
- https://git.kernel.org/stable/c/996fde492ad9b9563ee483b363af40d7696a8467
- https://git.kernel.org/stable/c/be96acd3eaa790d10a5b33e65267f52d02f6ad88
- https://git.kernel.org/stable/c/ca459dfa7d4ed9098fcf13e410963be6ae9b6bf3
- https://git.kernel.org/stable/c/145c5aa51486171025ab47f35cff34bff8d0cea3
- https://git.kernel.org/stable/c/51d5697e1c0380d482c3eab002bfc8d0be177e99
- https://git.kernel.org/stable/c/996fde492ad9b9563ee483b363af40d7696a8467
- https://git.kernel.org/stable/c/be96acd3eaa790d10a5b33e65267f52d02f6ad88
- https://git.kernel.org/stable/c/ca459dfa7d4ed9098fcf13e410963be6ae9b6bf3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ACPI: video: check for error while searching for backlight device parent If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device. Check acpi_get_parent() result and set parent device only in case of success. Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3
- https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95
- https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c
- https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af
- https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8
- https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852df0f15f
- https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f
- https://git.kernel.org/stable/c/ccd45faf4973746c4f30ea41eec864e5cf191099
- https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3
- https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95
- https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c
- https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af
- https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8
- https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852df0f15f
- https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f
- https://git.kernel.org/stable/c/ccd45faf4973746c4f30ea41eec864e5cf191099
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function With tpd12s015_remove() marked with __exit this function is discarded when the driver is compiled as a built-in. The result is that when the driver unbinds there is no cleanup done which results in resource leakage or worse.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/08ccff6ece35f08e8107e975903c370d849089e5
- https://git.kernel.org/stable/c/53926e2a39629702f7f809d614b3ca89c2478205
- https://git.kernel.org/stable/c/81f1bd85960b7a089a91e679ff7cd2524390bbf1
- https://git.kernel.org/stable/c/a8657406e12aa10412134622c58977ac657f16d2
- https://git.kernel.org/stable/c/ce3e112e7ae854249d8755906acc5f27e1542114
- https://git.kernel.org/stable/c/e00ec5901954d85b39b5f10f94e60ab9af463eb1
- https://git.kernel.org/stable/c/08ccff6ece35f08e8107e975903c370d849089e5
- https://git.kernel.org/stable/c/53926e2a39629702f7f809d614b3ca89c2478205
- https://git.kernel.org/stable/c/81f1bd85960b7a089a91e679ff7cd2524390bbf1
- https://git.kernel.org/stable/c/a8657406e12aa10412134622c58977ac657f16d2
- https://git.kernel.org/stable/c/ce3e112e7ae854249d8755906acc5f27e1542114
- https://git.kernel.org/stable/c/e00ec5901954d85b39b5f10f94e60ab9af463eb1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_powercap_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664
- https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219
- https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc
- https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1
- https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab
- https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d
- https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0
- https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664
- https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219
- https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc
- https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1
- https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab
- https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d
- https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: calipso: fix memory leak in netlbl_calipso_add_pass() If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free(). BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller [PM: merged via the LSM tree at Jakub Kicinski request]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149
- https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53
- https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031
- https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01
- https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da
- https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded
- https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99
- https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c
- https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149
- https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53
- https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031
- https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01
- https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da
- https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded
- https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99
- https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
The reference count changes made as part of the CVE-2023-33951 and CVE-2023-33952 fixes exposed a use-after-free flaw in the way memory objects were handled when they were being used to store a surface. When running inside a VMware guest with 3D acceleration enabled, a local, unprivileged user could potentially use this flaw to escalate their privileges.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://access.redhat.com/errata/RHSA-2024:0113
- https://access.redhat.com/errata/RHSA-2024:0134
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-5633
- https://bugzilla.redhat.com/show_bug.cgi?id=2245663
- https://access.redhat.com/errata/RHSA-2024:0113
- https://access.redhat.com/errata/RHSA-2024:0134
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:4823
- https://access.redhat.com/errata/RHSA-2024:4831
- https://access.redhat.com/security/cve/CVE-2023-5633
- https://bugzilla.redhat.com/show_bug.cgi?id=2245663
HIGH7.5
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6356
- https://bugzilla.redhat.com/show_bug.cgi?id=2254054
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6356
- https://bugzilla.redhat.com/show_bug.cgi?id=2254054
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://security.netapp.com/advisory/ntap-20240415-0002/
HIGH7.5
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6536
- https://bugzilla.redhat.com/show_bug.cgi?id=2254052
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6536
- https://bugzilla.redhat.com/show_bug.cgi?id=2254052
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://security.netapp.com/advisory/ntap-20240415-0001/
HIGH7.8
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.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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
HIGH7.8
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability. We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
HIGH7.8
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- http://www.openwall.com/lists/oss-security/2024/04/10/22
- http://www.openwall.com/lists/oss-security/2024/04/10/23
- http://www.openwall.com/lists/oss-security/2024/04/14/1
- http://www.openwall.com/lists/oss-security/2024/04/15/2
- http://www.openwall.com/lists/oss-security/2024/04/17/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660
- https://github.com/Notselwyn/CVE-2024-1086
- https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/
- https://news.ycombinator.com/item?id=39828424
- https://pwning.tech/nftables/
- https://security.netapp.com/advisory/ntap-20240614-0009/
- http://www.openwall.com/lists/oss-security/2024/04/10/22
- http://www.openwall.com/lists/oss-security/2024/04/10/23
- http://www.openwall.com/lists/oss-security/2024/04/14/1
- http://www.openwall.com/lists/oss-security/2024/04/15/2
- http://www.openwall.com/lists/oss-security/2024/04/17/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660
- https://github.com/Notselwyn/CVE-2024-1086
- https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/
- https://news.ycombinator.com/item?id=39828424
- https://pwning.tech/nftables/
- https://security.netapp.com/advisory/ntap-20240614-0009/
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-1086
HIGH7.8
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.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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
HIGH7.8
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.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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/
MEDIUM4.7
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.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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/
MEDIUM6.7
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
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:HReferences
- 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
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Prevent out-of-bounds memory access The test_tag test triggers an unhandled page fault: # ./test_tag [ 130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Oops[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 130.642815] Modules linked in: [last unloaded: bpf_testmod(O)] [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd) [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] Call Trace: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ end trace 0000000000000000 ]--- On my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at loading a BPF prog with 2039 instructions: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated---
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/36a87385e31c9343af9a4756598e704741250a67
- https://git.kernel.org/stable/c/4631c2dd69d928bca396f9f58baeddf85e14ced5
- https://git.kernel.org/stable/c/7924ade13a49c0067da6ea13e398102979c0654a
- https://git.kernel.org/stable/c/9aeb09f4d85a87bac46c010d75a2ea299d462f28
- https://git.kernel.org/stable/c/36a87385e31c9343af9a4756598e704741250a67
- https://git.kernel.org/stable/c/4631c2dd69d928bca396f9f58baeddf85e14ced5
- https://git.kernel.org/stable/c/7924ade13a49c0067da6ea13e398102979c0654a
- https://git.kernel.org/stable/c/9aeb09f4d85a87bac46c010d75a2ea299d462f28
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.
The following prog is accepted:
func#0 @0
0: R1=ctx() R10=fp0
0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()
1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()
2: (b7) r8 = 1024 ; R8_w=1024
3: (37) r8 /= 1 ; R8_w=scalar()
4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
5: (0f) r7 += r8
mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024
mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
=(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
var_off=(0x0; 0x400))
6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()
7: (95) exit
This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:
BUG: unable to handle page fault for address: ffffc90014c80038
[...]
Call Trace:
bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
__bpf_prog_run include/linux/filter.h:651 [inline]
bpf_prog_run include/linux/filter.h:658 [inline]
bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
__sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
__do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Fix this by rejecting ptr alu with variable offset on flow_keys.
Applying the patch rejects the program with "R7 pointer arithmetic
on flow_keys prohibited".
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3
- https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
- https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0
- https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8
- https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d
- https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3
- https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
- https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0
- https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8
- https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix re-attachment branch in bpf_tracing_prog_attach
The following case can cause a crash due to missing attach_btf:
1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3
In the end we have:
- prog->aux->dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one
BUG: kernel NULL pointer dereference, address: 0000000000000058
Call Trace:
? __die+0x20/0x70
? page_fault_oops+0x15b/0x430
? fixup_exception+0x22/0x330
? exc_page_fault+0x6f/0x170
? asm_exc_page_fault+0x22/0x30
? bpf_tracing_prog_attach+0x279/0x560
? btf_obj_id+0x5/0x10
bpf_tracing_prog_attach+0x439/0x560
__sys_bpf+0x1cf4/0x2de0
__x64_sys_bpf+0x1c/0x30
do_syscall_64+0x41/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
Return -EINVAL in this situation.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b
- https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0
- https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee
- https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c
- https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653
- https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b
- https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0
- https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee
- https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c
- https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix UAF issue in ksmbd_tcp_new_connection() The race is between the handling of a new TCP connection and its disconnection. It leads to UAF on `struct tcp_transport` in ksmbd_tcp_new_connection() function.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111
- https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1
- https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544
- https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126
- https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6
- https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111
- https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1
- https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544
- https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126
- https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6
HIGH7.1
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.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- 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/
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate mech token in session setup If client send invalid mech token in session setup request, ksmbd validate and make the error if it is invalid.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e
- https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9
- https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d
- https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a
- https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b
- https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e
- https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9
- https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d
- https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a
- https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved:
net: qualcomm: rmnet: fix global oob in rmnet_policy
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
global out-of-bounds read when parsing the netlink attributes. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x172/0x475 mm/kasan/report.c:395
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
validate_nla lib/nlattr.c:386 [inline]
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
__nla_parse+0x3e/0x50 lib/nlattr.c:697
nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
__rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0x154/0x190 net/socket.c:734
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdcf2072359
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
The buggy address belongs to the variable:
rmnet_policy+0x30/0xe0
The buggy address belongs to the physical page:
page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
^
ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
According to the comment of `nla_parse_nested_deprecated`, the maxtype
should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5
- https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590
- https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1
- https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447
- https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468
- https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc
- https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c
- https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534
- https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5
- https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590
- https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1
- https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447
- https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468
- https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc
- https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c
- https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4
- https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1
- https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f
- https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703
- https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88
- https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6
- https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80
- https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4
- https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1
- https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f
- https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703
- https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88
- https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6
- https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: pwm: Fix out-of-bounds access in of_pwm_single_xlate() With args->args_count == 2 args->args[2] is not defined. Actually the flags are contained in args->args[1].
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/7b85554c7c2aee91171e038e4d5442ffa130b282
- https://git.kernel.org/stable/c/a297d07b9a1e4fb8cda25a4a2363a507d294b7c9
- https://git.kernel.org/stable/c/bae45b7ebb31984b63b13c3519fd724b3ce92123
- https://git.kernel.org/stable/c/e5f2b4b62977fb6c2efcbc5779e0c9dce18215f7
- https://git.kernel.org/stable/c/7b85554c7c2aee91171e038e4d5442ffa130b282
- https://git.kernel.org/stable/c/a297d07b9a1e4fb8cda25a4a2363a507d294b7c9
- https://git.kernel.org/stable/c/bae45b7ebb31984b63b13c3519fd724b3ce92123
- https://git.kernel.org/stable/c/e5f2b4b62977fb6c2efcbc5779e0c9dce18215f7
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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 ]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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/
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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/
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: sii902x: Fix probing race issue A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 The issue here is as follows: - tidss probes, but is deferred as sii902x is still missing. - sii902x starts probing and enters sii902x_init(). - sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective. - sii902x calls sii902x_audio_codec_init() and platform_device_register_data() - The registration of the audio platform device causes probing of the deferred devices. - tidss probes, which eventually causes sii902x_bridge_get_edid() to be called. - sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash. Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe().
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9
- https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c
- https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1
- https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076
- https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9
- https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c
- https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1
- https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix global oob in ksmbd_nl_policy
Similar to a reported issue (check the commit b33fb5b801c6 ("net:
qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds
another global out-of-bounds read for policy ksmbd_nl_policy. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x172/0x475 mm/kasan/report.c:395
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
validate_nla lib/nlattr.c:386 [inline]
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
__nla_parse+0x3e/0x50 lib/nlattr.c:697
__nlmsg_parse include/net/netlink.h:748 [inline]
genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565
genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734
genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
genl_rcv+0x24/0x40 net/netlink/genetlink.c:861
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0x154/0x190 net/socket.c:734
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdd66a8f359
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003
RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000
The buggy address belongs to the variable:
ksmbd_nl_policy+0x100/0xa80
The buggy address belongs to the physical page:
page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9
^
ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05
ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9
==================================================================
To fix it, add a placeholder named __KSMBD_EVENT_MAX and let
KSMBD_EVENT_MAX to be its original value - 1 according to what other
netlink families do. Also change two sites that refer the
KSMBD_EVENT_MAX to correct value.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a
- https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95
- https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d
- https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5
- https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa
- https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a
- https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95
- https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d
- https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5
- https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix a memory corruption iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a
- https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b
- https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd
- https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32
- https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d
- https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67
- https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a
- https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b
- https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd
- https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32
- https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d
- https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfs, fscache: Prevent Oops in fscache_put_cache() This function dereferences "cache" and then checks if it's IS_ERR_OR_NULL(). Check first, then dereference.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1c45256e599061021e2c848952e50f406457e448
- https://git.kernel.org/stable/c/3be0b3ed1d76c6703b9ee482b55f7e01c369cc68
- https://git.kernel.org/stable/c/4200ad3e46ce50f410fdda302745489441bc70f0
- https://git.kernel.org/stable/c/82a9bc343ba019665d3ddc1d9a180bf0e0390cf3
- https://git.kernel.org/stable/c/1c45256e599061021e2c848952e50f406457e448
- https://git.kernel.org/stable/c/3be0b3ed1d76c6703b9ee482b55f7e01c369cc68
- https://git.kernel.org/stable/c/4200ad3e46ce50f410fdda302745489441bc70f0
- https://git.kernel.org/stable/c/82a9bc343ba019665d3ddc1d9a180bf0e0390cf3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
tcp: make sure init the accept_queue's spinlocks once
When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
_raw_spin_unlock (kernel/locking/spinlock.c:186)
inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
tcp_check_req (net/ipv4/tcp_minisocks.c:868)
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
ip_local_deliver_finish (net/ipv4/ip_input.c:234)
__netif_receive_skb_one_core (net/core/dev.c:5529)
process_backlog (./include/linux/rcupdate.h:779)
__napi_poll (net/core/dev.c:6533)
net_rx_action (net/core/dev.c:6604)
__do_softirq (./arch/x86/include/asm/jump_label.h:27)
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
__local_bh_enable_ip (kernel/softirq.c:381)
__dev_queue_xmit (net/core/dev.c:4374)
ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
__ip_queue_xmit (net/ipv4/ip_output.c:535)
__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
release_sock (net/core/sock.c:3536)
inet_wait_for_connect (net/ipv4/af_inet.c:609)
__inet_stream_connect (net/ipv4/af_inet.c:702)
inet_stream_connect (net/ipv4/af_inet.c:748)
__sys_connect (./include/linux/file.h:45 net/socket.c:2064)
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
RIP: 0033:0x7fa10ff05a3d
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89
c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
The issue triggering process is analyzed as follows:
Thread A Thread B
tcp_v4_rcv //receive ack TCP packet inet_shutdown
tcp_check_req tcp_disconnect //disconnect sock
... tcp_set_state(sk, TCP_CLOSE)
inet_csk_complete_hashdance ...
inet_csk_reqsk_queue_add
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02
- https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2
- https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a
- https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855
- https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882
- https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3
- https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02
- https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2
- https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a
- https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855
- https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882
- https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close'
- continuously dump SMC-D connections in parallel:
watch -n 1 'smcss -D'
BUG: kernel NULL pointer dereference, address: 0000000000000030
CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55
RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
Call Trace:
? __die+0x24/0x70
? page_fault_oops+0x66/0x150
? exc_page_fault+0x69/0x140
? asm_exc_page_fault+0x26/0x30
? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
? __kmalloc_node_track_caller+0x35d/0x430
? __alloc_skb+0x77/0x170
smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
smc_diag_dump+0x26/0x60 [smc_diag]
netlink_dump+0x19f/0x320
__netlink_dump_start+0x1dc/0x300
smc_diag_handler_dump+0x6a/0x80 [smc_diag]
? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
sock_diag_rcv_msg+0x121/0x140
? __pfx_sock_diag_rcv_msg+0x10/0x10
netlink_rcv_skb+0x5a/0x110
sock_diag_rcv+0x28/0x40
netlink_unicast+0x22a/0x330
netlink_sendmsg+0x1f8/0x420
__sock_sendmsg+0xb0/0xc0
____sys_sendmsg+0x24e/0x300
? copy_msghdr_from_user+0x62/0x80
___sys_sendmsg+0x7c/0xd0
? __do_fault+0x34/0x160
? do_read_fault+0x5f/0x100
? do_fault+0xb0/0x110
? __handle_mm_fault+0x2b0/0x6c0
__sys_sendmsg+0x4d/0x80
do_syscall_64+0x69/0x180
entry_SYSCALL_64_after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn->rmb_desc. So fix it by checking before dump.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be
- https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22
- https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
- https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a
- https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a
- https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6
- https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9
- https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c
- https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be
- https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22
- https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
- https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a
- https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a
- https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6
- https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9
- https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: always filter entire AP matrix The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or domain is assigned to the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not reference a queue device bound to the vfio_ap device driver, then it's APID will be filtered from the mdev's matrix when updating the guest's AP configuration. Inspecting only the APID of the new adapter or APQI of the new domain will result in passing AP queues through to a guest that are not bound to the vfio_ap device driver under certain circumstances. Consider the following: guest's AP configuration (all also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006 unassign domain 4 unbind queue 16.0005 assign domain 4 When domain 4 is re-assigned, since only domain 4 will be inspected, the APQNs that will be examined will be: 14.0004 16.0004 Since both of those APQNs reference queue devices that are bound to the vfio_ap device driver, nothing will get filtered from the mdev's matrix when updating the guest's AP configuration. Consequently, queue 16.0005 will get passed through despite not being bound to the driver. This violates the linux device model requirement that a guest shall only be given access to devices bound to the device driver facilitating their pass-through. To resolve this problem, every adapter and domain assigned to the mdev will be inspected when filtering the mdev's matrix.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11
- https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a
- https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e
- https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6
- https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11
- https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a
- https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e
- https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
llc: call sock_orphan() at release time
syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
pointer in a closed llc socket.
In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
calling proto_ops::release()") Eric Biggers hinted that some protocols
are missing a sock_orphan(), we need to perform a full audit.
In net-next, I plan to clear sock->sk from sock_orphan() and
amend Eric patch to add a warning.
[1]
BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:488
kasan_report+0xda/0x110 mm/kasan/report.c:601
list_empty include/linux/list.h:373 [inline]
waitqueue_active include/linux/wait.h:127 [inline]
sock_def_write_space_wfree net/core/sock.c:3384 [inline]
sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
skb_release_all net/core/skbuff.c:1092 [inline]
napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
__napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
napi_poll net/core/dev.c:6645 [inline]
net_rx_action+0x956/0xe90 net/core/dev.c:6778
__do_softirq+0x21a/0x8de kernel/softirq.c:553
run_ksoftirqd kernel/softirq.c:921 [inline]
run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
kthread+0x2c6/0x3a0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
Allocated by task 5167:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:314 [inline]
__kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3813 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879
alloc_inode_sb include/linux/fs.h:3019 [inline]
sock_alloc_inode+0x25/0x1c0 net/socket.c:308
alloc_inode+0x5d/0x220 fs/inode.c:260
new_inode_pseudo+0x16/0x80 fs/inode.c:1005
sock_alloc+0x40/0x270 net/socket.c:634
__sock_create+0xbc/0x800 net/socket.c:1535
sock_create net/socket.c:1622 [inline]
__sys_socket_create net/socket.c:1659 [inline]
__sys_socket+0x14c/0x260 net/socket.c:1706
__do_sys_socket net/socket.c:1720 [inline]
__se_sys_socket net/socket.c:1718 [inline]
__x64_sys_socket+0x72/0xb0 net/socket.c:1718
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Freed by task 0:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inlin
---truncated---
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812
- https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f
- https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b
- https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4
- https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee
- https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c
- https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7
- https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a
- https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812
- https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f
- https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b
- https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4
- https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee
- https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c
- https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7
- https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb
- https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0
- https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1
- https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059
- https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c
- https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c
- https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb
- https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0
- https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1
- https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059
- https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c
- https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
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'.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155
- https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663
- https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855
- https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900
- https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c
- https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155
- https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663
- https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855
- https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900
- https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: block: Fix iterating over an empty bio with bio_for_each_folio_all If the bio contains no data, bio_first_folio() calls page_folio() on a NULL pointer and oopses. Move the test that we've reached the end of the bio from bio_next_folio() to bio_first_folio(). [axboe: add unlikely() to error case]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7
- https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659
- https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe
- https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde
- https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7
- https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659
- https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe
- https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim() syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken. Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage. [1] BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendms ---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee
- https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c
- https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d
- https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2
- https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183
- https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087
- https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198
- https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd
- https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee
- https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c
- https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d
- https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2
- https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183
- https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087
- https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198
- https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241220-0001/
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: fix removing a namespace with conflicting altnames Mark reports a BUG() when a net namespace is removed. kernel BUG at net/core/dev.c:11520! Physical interfaces moved outside of init_net get "refunded" to init_net when that namespace disappears. The main interface name may get overwritten in the process if it would have conflicted. We need to also discard all conflicting altnames. Recent fixes addressed ensuring that altnames get moved with the main interface, which surfaced this problem.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/8072699aa9e67d1727692cfb3c347263bb627fb9
- https://git.kernel.org/stable/c/a2232f29bf52c24f827865b3c90829c44b6c695b
- https://git.kernel.org/stable/c/d09486a04f5da0a812c26217213b89a3b1acf836
- https://git.kernel.org/stable/c/e855dded4b70d1975ee7b9fed0c700391e3c8ea6
- https://git.kernel.org/stable/c/8072699aa9e67d1727692cfb3c347263bb627fb9
- https://git.kernel.org/stable/c/a2232f29bf52c24f827865b3c90829c44b6c695b
- https://git.kernel.org/stable/c/d09486a04f5da0a812c26217213b89a3b1acf836
- https://git.kernel.org/stable/c/e855dded4b70d1975ee7b9fed0c700391e3c8ea6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring"). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let's remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62
- https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6
- https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd
- https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097
- https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828
- https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc
- https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61
- https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8
- https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62
- https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6
- https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd
- https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097
- https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828
- https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc
- https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61
- https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c
- https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4
- https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b
- https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d
- https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249
- https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb
- https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b
- https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647
- https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c
- https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4
- https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b
- https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d
- https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249
- https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb
- https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b
- https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM4.4
In the Linux kernel, the following vulnerability has been resolved: nbd: always initialize struct msghdr completely syzbot complains that msg->msg_get_inq value can be uninitialized [1] struct msghdr got many new fields recently, we should always make sure their values is zero by default. [1] BUG: KMSAN: uninit-value in tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 inet_recvmsg+0x131/0x580 net/ipv4/af_inet.c:879 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x12b/0x1e0 net/socket.c:1066 __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700 worker_thread+0xf45/0x1490 kernel/workqueue.c:2781 kthread+0x3ed/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Local variable msg created at: __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 CPU: 1 PID: 7465 Comm: kworker/u5:1 Not tainted 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: nbd5-recv recv_work
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1960f2b534da1e6c65fb96f9e98bda773495f406
- https://git.kernel.org/stable/c/78fbb92af27d0982634116c7a31065f24d092826
- https://git.kernel.org/stable/c/b0028f333420a65a53a63978522db680b37379dd
- https://git.kernel.org/stable/c/d9c54763e5cdbbd3f81868597fe8aca3c96e6387
- https://git.kernel.org/stable/c/1960f2b534da1e6c65fb96f9e98bda773495f406
- https://git.kernel.org/stable/c/78fbb92af27d0982634116c7a31065f24d092826
- https://git.kernel.org/stable/c/b0028f333420a65a53a63978522db680b37379dd
- https://git.kernel.org/stable/c/d9c54763e5cdbbd3f81868597fe8aca3c96e6387
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tcp: add sanity checks to rx zerocopy TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs. This patch adds to can_map_frag() these additional checks: - Page must not be a compound one. - page->mapping must be NULL. This fixes the panic reported by ZhangPeng. syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy. r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60
- https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894
- https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e
- https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e
- https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760
- https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f
- https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60
- https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894
- https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e
- https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e
- https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760
- https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() syzbot found __ip6_tnl_rcv() could access unitiliazed data [1]. Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head. [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6
- https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0
- https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080
- https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0
- https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a
- https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8
- https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6
- https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0
- https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080
- https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0
- https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a
- https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20241108-0008/
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
If the source file descriptor to the snapshot ioctl refers to a deleted
subvolume, we get the following abort:
BTRFS: Transaction aborted (error -2)
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
Call Trace:
? create_pending_snapshot+0x1040/0x1190 [btrfs]
? __warn+0x81/0x130
? create_pending_snapshot+0x1040/0x1190 [btrfs]
? report_bug+0x171/0x1a0
? handle_bug+0x3a/0x70
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? create_pending_snapshot+0x1040/0x1190 [btrfs]
? create_pending_snapshot+0x1040/0x1190 [btrfs]
create_pending_snapshots+0x92/0xc0 [btrfs]
btrfs_commit_transaction+0x66b/0xf40 [btrfs]
btrfs_mksubvol+0x301/0x4d0 [btrfs]
btrfs_mksnapshot+0x80/0xb0 [btrfs]
__btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
btrfs_ioctl+0x8a6/0x2650 [btrfs]
? kmem_cache_free+0x22/0x340
? do_sys_openat2+0x97/0xe0
__x64_sys_ioctl+0x97/0xd0
do_syscall_64+0x46/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
RIP: 0033:0x7fe20abe83af
RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
---[ end trace 0000000000000000 ]---
BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
BTRFS info (device vdc: state EA): forced readonly
BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
This happens because create_pending_snapshot() initializes the new root
item as a copy of the source root item. This includes the refs field,
which is 0 for a deleted subvolume. The call to btrfs_insert_root()
therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
finds the root and returns -ENOENT if refs == 0, which causes
create_pending_snapshot() to abort.
Fix it by checking the source root's refs before attempting the
snapshot, but after locking subvol_sem to avoid racing with deletion.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c
- https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464
- https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b
- https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a
- https://git.kernel.org/stable/c/c06941564027bdbc01d2df7f41e333c11cb0482d
- https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff
- https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256
- https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c
- https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464
- https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b
- https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a
- https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff
- https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when inserting an element into tracing_map Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt; The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7
- https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b
- https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7
- https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177
- https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb
- https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c
- https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860
- https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a
- https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7
- https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b
- https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7
- https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177
- https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb
- https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c
- https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860
- https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee
- https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566
- https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9
- https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c
- https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee
- https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566
- https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9
- https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c
MEDIUM5.5
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
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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:
tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
__sys_sendmsg+0x117/0x1e0 net/socket.c:2667
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The cause of this issue is that when tipc_nl_bearer_add() is called with
the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
even if the bearer is not UDP.
tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
the media_ptr field of the tipc_bearer has an udp_bearer type object, so
the function goes crazy for non-UDP bearers.
This patch fixes the issue by checking the bearer type before calling
tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
HIGH7.1
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.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- 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
HIGH7.1
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.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- 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
MEDIUM5.5
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/
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a
- https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1
- https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0
- https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b
- https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa
- https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a
- https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1
- https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0
- https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b
- https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56
- https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed
- https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0
- https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f
- https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b
- https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676
- https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10
- https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2
- https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56
- https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed
- https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0
- https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f
- https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b
- https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676
- https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10
- https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98
- https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8
- https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d
- https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4
- https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f
- https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e
- https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483
- https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98
- https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8
- https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d
- https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4
- https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f
- https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e
- https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
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
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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:
process_one_work+0x889/0x15e0 kernel/workqueue.c:2633
process_scheduled_works kernel/workqueue.c:2706 [inline]
worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787
kthread+0x2c6/0x3b0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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]
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
[ 215.599305] ? check_unmap+0xa6f/0x2360
[ 215.603147] ? __warn+0xca/0x1d0
[ 215.606391] ? check_unmap+0xa6f/0x2360
[ 215.610237] ? report_bug+0x1ef/0x370
[ 215.613921] ? handle_bug+0x3c/0x70
[ 215.617423] ? exc_invalid_op+0x14/0x50
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
[ 215.625480] ? check_unmap+0xa6f/0x2360
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
[ 215.633445] debug_dma_free_coherent+0x196/0x210
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
[ 215.648060] dma_free_attrs+0x6d/0x130
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
...
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
[ 216.132160] DMA-API: Mapped at:
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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:
instrument_atomic_read include/linux/instrumented.h:68 [inline]
atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline]
debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline]
do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141
__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline]
_raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194
debug_object_activate+0x349/0x540 lib/debugobjects.c:726
debug_work_activate kernel/workqueue.c:578 [inline]
insert_work+0x30/0x230 kernel/workqueue.c:1650
__queue_work+0x62e/0x11d0 kernel/workqueue.c:1802
__queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953
queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989
queue_delayed_work include/linux/workqueue.h:563 [inline]
schedule_delayed_work include/linux/workqueue.h:677 [inline]
nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842
process_one_work+0x886/0x15d0 kernel/workqueue.c:2633
process_scheduled_works kernel/workqueue.c:2706 [inline]
worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787
kthread+0x2c6/0x3a0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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:
kernel: ? __die_body+0x1a/0x60
kernel: ? page_fault_oops+0x16f/0x4a0
kernel: ? search_bpf_extables+0x65/0x70
kernel: ? fixup_exception+0x22/0x310
kernel: ? exc_page_fault+0x69/0x150
kernel: ? asm_exc_page_fault+0x22/0x30
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
kernel: ? hugetlbfs_fill_super+0xb4/0x1a0
kernel: ? hugetlbfs_fill_super+0x28/0x1a0
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
kernel: vfs_get_super+0x40/0xa0
kernel: ? __pfx_bpf_lsm_capable+0x10/0x10
kernel: vfs_get_tree+0x25/0xd0
kernel: vfs_cmd_create+0x64/0xe0
kernel: __x64_sys_fsconfig+0x395/0x410
kernel: do_syscall_64+0x80/0x160
kernel: ? syscall_exit_to_user_mode+0x82/0x240
kernel: ? do_syscall_64+0x8d/0x160
kernel: ? syscall_exit_to_user_mode+0x82/0x240
kernel: ? do_syscall_64+0x8d/0x160
kernel: ? exc_page_fault+0x69/0x150
kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76
kernel: RIP: 0033:0x7ffbc0cb87c9
kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48
kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af
kernel: RAX: fffffffffff
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
HIGH7.8
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.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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
MEDIUM5.5
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]
[ 137.182693] ? show_regs+0x6c/0x80
[ 137.182693] ? __die_body+0x24/0x70
[ 137.182693] ? die_addr+0x4b/0x80
[ 137.182693] ? exc_general_protection+0x126/0x230
[ 137.182693] ? asm_exc_general_protection+0x2b/0x30
[ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180
[ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80
[ 137.182693] sev_dev_destroy+0x49/0x100
[ 137.182693] psp_dev_destroy+0x47/0xb0
[ 137.182693] sp_destroy+0xbb/0x240
[ 137.182693] sp_pci_remove+0x45/0x60
[ 137.182693] pci_device_remove+0xaa/0x1d0
[ 137.182693] device_remove+0xc7/0x170
[ 137.182693] really_probe+0x374/0xbe0
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] __driver_probe_device+0x199/0x460
[ 137.182693] driver_probe_device+0x4e/0xd0
[ 137.182693] __driver_attach+0x191/0x3d0
[ 137.182693] ? __pfx___driver_attach+0x10/0x10
[ 137.182693] bus_for_each_dev+0x100/0x190
[ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10
[ 137.182693] ? __kasan_check_read+0x15/0x20
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] ? _raw_spin_unlock+0x27/0x50
[ 137.182693] driver_attach+0x41/0x60
[ 137.182693] bus_add_driver+0x2a8/0x580
[ 137.182693] driver_register+0x141/0x480
[ 137.182693] __pci_register_driver+0x1d6/0x2a0
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0
[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10
[ 137.182693] sp_pci_init+0x22/0x30
[ 137.182693] sp_mod_init+0x14/0x30
[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10
[ 137.182693] do_one_initcall+0xd1/0x470
[ 137.182693] ? __pfx_do_one_initcall+0x10/0x10
[ 137.182693] ? parameq+0x80/0xf0
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] ? __kmalloc+0x3b0/0x4e0
[ 137.182693] ? kernel_init_freeable+0x92d/0x1050
[ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] kernel_init_freeable+0xa64/0x1050
[ 137.182693] ? __pfx_kernel_init+0x10/0x10
[ 137.182693] kernel_init+0x24/0x160
[ 137.182693] ? __switch_to_asm+0x3e/0x70
[ 137.182693] ret_from_fork+0x40/0x80
[ 137.182693] ? __pfx_kernel_init+0x1
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM4.7
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]
[ 654.573790] __schedule+0x2d6/0x960
[ 654.577733] schedule+0x69/0xf0
[ 654.581214] schedule_timeout+0x87/0x140
[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
[ 654.590291] msleep+0x2d/0x40
[ 654.593625] napi_disable+0x2b/0x80
[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
[ 654.611101] ? do_wait_intr+0xb0/0xb0
[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
HIGH7.8
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.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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:
hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
expire_timers kernel/time/timer.c:1751 [inline]
__run_timers+0x764/0xb20 kernel/time/timer.c:2022
run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
__do_softirq+0x21a/0x8de kernel/softirq.c:553
invoke_softirq kernel/softirq.c:427 [inline]
__irq_exit_rcu kernel/softirq.c:632 [inline]
irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
...
This issue is also found in older kernels (at least up to 5.10).
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM4.4
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.
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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/
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
HIGH7.8
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.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- 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
MEDIUM5.5
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:
extent_write_cache_pages+0x2ac/0x8f0
extent_writepages+0x87/0x110
do_writepages+0xd5/0x1f0
filemap_fdatawrite_wbc+0x63/0x90
__filemap_fdatawrite_range+0x5c/0x80
btrfs_fdatawrite_range+0x1f/0x50
btrfs_write_out_cache+0x507/0x560
btrfs_write_dirty_block_groups+0x32a/0x420
commit_cowonly_roots+0x21b/0x290
btrfs_commit_transaction+0x813/0x1360
btrfs_sync_file+0x51a/0x640
__x64_sys_fdatasync+0x52/0x90
do_syscall_64+0x9c/0x190
entry_SYSCALL_64_after_hwframe+0x6e/0x76
This happens because we fail to write out the free space cache in one
instance, come back around and attempt to write it again. However on
the second pass through we go to call btrfs_get_extent() on the inode to
get the extent mapping. Because this is a new block group, and with the
free space inode we always search the commit root to avoid deadlocking
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
requested range.
This happens because the first time we try to write the space cache out
we hit an error, and on an error we drop the extent mapping. This is
normal for normal files, but the free space cache inode is special. We
always expect the extent map to be correct. Thus the second time
through we end up with a bogus extent map.
Since we're deprecating this feature, the most straightforward way to
fix this is to simply skip dropping the extent map range for this failed
range.
I shortened the test by using error injection to stress the area to make
it easier to reproduce. With this patch in place we no longer panic
with my error injection test.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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
btrfs_get_new_fs_root+0xd3/0xf0
create_subvol+0xd02/0x1650
btrfs_mksubvol+0xe95/0x12b0
__btrfs_ioctl_snap_create+0x2f9/0x4f0
btrfs_ioctl_snap_create+0x16b/0x200
btrfs_ioctl+0x35f0/0x5cf0
__x64_sys_ioctl+0x19d/0x210
do_syscall_64+0x3f/0xe0
entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace 0000000000000000 ]---
[CAUSE]
During create_subvol(), after inserting root item for the newly created
subvolume, we would trigger btrfs_get_new_fs_root() to get the
btrfs_root of that subvolume.
The idea here is, we have preallocated an anonymous device number for
the subvolume, thus we can assign it to the new subvolume.
But there is really nothing preventing things like backref walk to read
the new subvolume.
If that happens before we call btrfs_get_new_fs_root(), the subvolume
would be read out, with a new anonymous device number assigned already.
In that case, we would trigger ASSERT(), as we really expect no one to
read out that subvolume (which is not yet accessible from the fs).
But things like backref walk is still possible to trigger the read on
the subvolume.
Thus our assumption on the ASSERT() is not correct in the first place.
[FIX]
Fix it by removing the ASSERT(), and just free the @anon_dev, reset it
to 0, and continue.
If the subvolume tree is read out by something else, it should have
already get a new anon_dev assigned thus we only need to free the
preallocated one.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913
- https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee
- https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58
- https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f
- https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3
- https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4
- https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913
- https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee
- https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58
- https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f
- https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3
- https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM6.7
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.
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM6.3
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: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:HReferences
- 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
MEDIUM4.7
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.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.5
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.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- 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
MEDIUM5.3
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a double-free in arfs_create_groups When `in` allocated by kvzalloc fails, arfs_create_groups will free ft->g and return an error. However, arfs_create_table, the only caller of arfs_create_groups, will hold this error and call to mlx5e_destroy_flow_table, in which the ft->g will be freed again.
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
- https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7
- https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b
- https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb
- https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b
- https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7
- https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056
- https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5
- https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629
- https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7
- https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b
- https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb
- https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b
- https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7
- https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056
- https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5
- https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: clear BM pool before initialization Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f
- https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b
- https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38
- https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa
- https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec
- https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4
- https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f
- https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b
- https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38
- https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa
- https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec
- https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential sta-link leak When a station is allocated, links are added but not set to valid yet (e.g. during connection to an AP MLD), we might remove the station without ever marking links valid, and leak them. Fix that.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/49aaeb8c539b1633b3bd7c2df131ec578aa1eae1
- https://git.kernel.org/stable/c/587c5892976108674bbe61a8ff659de279318034
- https://git.kernel.org/stable/c/b01a74b3ca6fd51b62c67733ba7c3280fa6c5d26
- https://git.kernel.org/stable/c/e04bf59bdba0fa45d52160be676114e16be855a9
- https://git.kernel.org/stable/c/49aaeb8c539b1633b3bd7c2df131ec578aa1eae1
- https://git.kernel.org/stable/c/587c5892976108674bbe61a8ff659de279318034
- https://git.kernel.org/stable/c/b01a74b3ca6fd51b62c67733ba7c3280fa6c5d26
- https://git.kernel.org/stable/c/e04bf59bdba0fa45d52160be676114e16be855a9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge. As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c
- https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b
- https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547
- https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86
- https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c
- https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b
- https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547
- https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect() subflow_finish_connect() uses four fields (backup, join_id, thmac, none) that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set in mptcp_parse_option()
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
- https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
- https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
- https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
- https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb
- https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
- https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
- https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
- https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
- https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: sof-common: Add NULL check for normal_link string It's not granted that all entries of struct sof_conn_stream declare a `normal_link` (a non-SOF, direct link) string, and this is the case for SoCs that support only SOF paths (hence do not support both direct and SOF usecases). For example, in the case of MT8188 there is no normal_link string in any of the sof_conn_stream entries and there will be more drivers doing that in the future. To avoid possible NULL pointer KPs, add a NULL check for `normal_link`.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/b1d3db6740d0997ffc6e5a0d96ef7cbd62b35fdd
- https://git.kernel.org/stable/c/cad471227a37c0c7c080bfc9ed01b53750e82afe
- https://git.kernel.org/stable/c/cde6ca5872bf67744dffa875a7cb521ab007b7ef
- https://git.kernel.org/stable/c/e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed
- https://git.kernel.org/stable/c/b1d3db6740d0997ffc6e5a0d96ef7cbd62b35fdd
- https://git.kernel.org/stable/c/cad471227a37c0c7c080bfc9ed01b53750e82afe
- https://git.kernel.org/stable/c/cde6ca5872bf67744dffa875a7cb521ab007b7ef
- https://git.kernel.org/stable/c/e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed