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
ALT-PU-2022-1714-11Package update kernel-image-std-def in branch c9f1
Severity:
Closed issues (200)
HIGH8.4
Уязвимость системного вызова PTRACE_SEIZE безопасного режима вычислений seccomp ядра операционной системы 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.4
Уязвимость реализации функции get_user_pages_fast() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
CVSS 3.xHIGH 7.4
CVSS:3.x/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:H/Au:N/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость интерфейса асинхронного ввода/вывода io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать повреждение памяти и повысить свои привилегии до уровня root
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.0
Уязвимость компонента netfront гипервизора Xen, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:M/Au:S/C:C/I:C/A:CReferences
HIGH7.0
Уязвимость компонентов blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront и pvcalls гипервизора Xen, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:M/Au:S/C:C/I:C/A:CReferences
HIGH7.0
Уязвимость компонента xenbus гипервизора Xen, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:M/Au:S/C:C/I:C/A:CReferences
HIGH7.0
Уязвимость драйвера gntalloc гипервизора Xen, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:M/Au:S/C:C/I:C/A:CReferences
HIGH7.0
Уязвимость утилиты гипервизора Xen, вызванная ошибками синхронизации при использовании общего ресурса, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:M/Au:S/C:C/I:C/A:CReferences
HIGH7.0
Уязвимость драйвера scsifront команды PV гипервизора Xen, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/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.0
Уязвимость драйвера blkfront команды PV гипервизора Xen, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:M/Au:S/C:C/I:C/A:CReferences
HIGH7.7
Уязвимость функции diFree (fs/jfs/inode.c) журналируемой файловой системы (JFS) ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
CVSS 3.xHIGH 7.7
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:N/A:CReferences
HIGH8.4
Уязвимость реализации прокси-виртуализированных TPM-устройств ядра операционной системы 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
HIGH8.4
Уязвимость функции em28xx_usb_probe драйвера video4linux ядра операционных систем 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
MEDIUM5.5
Уязвимость функции f2fs_write_compressed_pages() в модуле fs/f2fs/compress.c файловой системы f2fs ядра операционной системы 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
Уязвимость функции speed_show() в компоненте net-sysfs ядра операционной системы 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
Уязвимость функции gdm_lte_rx() драйвера GCT GDM724x LTE ядра операционной системы 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
Уязвимость функции port100_send_complete() в компоненте NFC ядра операционной системы 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
Уязвимость функции of_find_compatible_node() в компоненте ethtool ядра операционной системы 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
Уязвимость компонента swiotlb ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:NReferences
MEDIUM5.5
Уязвимость компонента sctp ядра операционной системы 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.0
Уязвимость компонента net/mlx5: ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость компонента ethernet ядра операционной системы 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
Уязвимость компонента int340x ядра операционной системы 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
Уязвимость функции rndis_set_response() в компоненте rndis ядра операционной системы 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
Уязвимость компонента gadget ядра операционной системы 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
Уязвимость компонента net/packet ядра операционной системы 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
Уязвимость компонента usbtmc ядра операционной системы 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
Уязвимость компонента smp ядра операционной системы 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
Уязвимость функции usb_submit_urb() ядра операционной системы 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
HIGH7.8
Уязвимость функции jffs2_do_fill_super() модуля fs/jffs2/fs.c поддержки файловой системы jffs2 ядра операционной системы 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
Уязвимость функции bfq_setup_merge() модуля block/bfq-iosched.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
Уязвимость функции SATA_DWC_QCMD_MAX() модуля drivers/ata/sata_dwc_460ex.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
MEDIUM5.5
Уязвимость функций gic_dist_base() и gic_do_wait_for_rwp() ядра операционной системы 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/btrfs/extent_io.h файловой системы 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
Уязвимость модуля mm/mremap.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
Уязвимость функции qede_build_skb() модуля drivers/net/ethernet/qlogic/qede/qede_fp.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
Уязвимость функций dpaa2_ptp_probe() и fsl_mc_free_irqs() модуля drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.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
Уязвимость функции spin_lock_irqsave() модуля drivers/infiniband/sw/rdmavt/qp.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
Уязвимость функции kmem_cache_alloc() модуля mm/mempolicy.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.8
Уязвимость функции rxrpc_exit_net() модуля net/rxrpc/net_ns.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
Уязвимость функции LZ4_decompress_generic() модуля lib/lz4/lz4_decompress.c поддержки сжатия lz4 ядра операционной системы 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
Уязвимость функции nla_put_notification_header() модуля drivers/block/drbd/drbd_nl.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
Уязвимость ядра операционной системы 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
Уязвимость функции hci_disconn_phylink_complete_evt() модуля net/bluetooth/hci_event.c подсистемы Bluetooth ядра операционной системы 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.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:PReferences
HIGH7.8
Уязвимость функции tpm_dev_release() модуля drivers/char/tpm/tpm-chip.c - драйвера поддержки алфавитно-цифровых устройств с TPM ядра операционной системы 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.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:PReferences
HIGH7.8
Уязвимость функции dev_attribute_show() модуля drivers/mtd/ubi/build.c - драйвера поддержки памяти MTD ядра операционной системы 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
Уязвимость функции bfq_bfqq_move() модуля block/bfq-cgroup.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
Уязвимость функции bfq_dispatch_request() модуля block/bfq-iosched.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
MEDIUM5.5
Уязвимость функций init() и fini() модуля drivers/char/virtio_console.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
Уязвимость функции ill_acc_of_setup() модуля arch/mips/ralink/ill_acc.c поддержки архитектуры MIPS ядра операционной системы 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
Уязвимость функции tpm2_init_space() модуля drivers/char/tpm/tpm2-space.c драйвера поддержки алфавитноцифровых устройств с TPM ядра операционной системы 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
Уязвимость функции lookup_ioctl() модуля drivers/md/dm-ioctl.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы 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
Уязвимость функции fc_exch_abts_resp() ядра операционной системы 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
Уязвимость функции snd_pcm_oss_period_size() ядра операционной системы 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
Уязвимость функции smtcfb_write() модуля drivers/video/fbdev/sm712fb.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
Уязвимость функции ntfs_read_inode_mount() модуля fs/ntfs/inode.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
Уязвимость функций ext4_writepage(), mpage_prepare_extent_to_map() модуля fs/ext4/inode.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
Уязвимость функции qla2xxx_create_qpair() модуля drivers/scsi/qla2xxx/qla_init.c драйвера поддержки устройств SCSI ядра операционной системы 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
Уязвимость функции device_pm_check_callbacks() в модуле 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
HIGH7.1
Уязвимость функции ath5k_eeprom_convert_pcal_info_5111() модуля drivers/net/wireless/ath/ath5k/eeprom.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы 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
Уязвимость функции xdr_stream_decode_uint32_array() модуля include/linux/sunrpc/xdr.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
Уязвимость функции nfsd_proc_write() модуля fs/nfsd/nfsproc.c поддержки сетевой файловой системы NFS ядра операционной системы 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
Уязвимость функции s2250_probe() модуля drivers/media/usb/go7007/s2250-board.c драйвера поддержки мультимедийных устройств USB ядра операционной системы 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
Уязвимость функции netlink_group_mask() модуля net/netlink/af_netlink.c поддержки интерфейса мониторинга сокетов NETLINK ядра операционной системы 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
Уязвимость функции nvidia_setup_i2c_bus() модуля drivers/video/fbdev/nvidia/nv_i2c.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
MEDIUM5.5
Уязвимость функции snd_soc_new_compress() модуля sound/soc/soc-compress.c поддержки звука SoC ядра операционной системы 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
Уязвимость функции imx_pd_connector_get_modes() модуля drivers/gpu/drm/imx/parallel-display.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
MEDIUM5.5
Уязвимость функции zorro7xx_remove_one() модуля drivers/scsi/zorro7xx.c драйвера поддержки устройств SCSI ядра операционной системы 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
Уязвимость функции acpi_cppc_processor_probe() модуля drivers/acpi/cppc_acpi.c драйвера поддержки ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы 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:CMEDIUM5.5
Уязвимость функции pm8001_send_abort_all() модуля drivers/scsi/pm8001/pm8001_hwi.c - драйвера поддержки устройств SCSI ядра операционной системы 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
Уязвимость функции dax_fs_init() модуля drivers/dax/super.c драйвера поддержки устройств DAX (direct access mapping device) ядра операционной системы 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
Уязвимость функции at91sam9g20ek_audio_probe() модуля sound/soc/atmel/sam9g20_wm8731.c поддержки звука SoC ядра операционной системы 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
Уязвимость функции stk1160_disconnect() модуля drivers/media/usb/stk1160/stk1160-core.c драйвера поддержки мультимедийных устройств USB ядра операционной системы 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
Уязвимость функции f2fs_handle_failed_inode() модуля fs/f2fs/inode.c файловой системы F2FS ядра операционной системы 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
Уязвимость функции nft_do_chain() модуля net/netfilter/nf_tables_core.c компонента 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
Уязвимость функции vmbus_exit() модуля drivers/hv/vmbus_drv.c драйвера поддержки гостевого режима Microsoft HyperV ядра операционной системы 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
Уязвимость функции decrypt_internal() модуля net/tls/tls_sw.c реализации протокола TLS ядра операционной системы 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
Уязвимость функции tcp_bpf_sendmsg_redir() модуля net/ipv4/tcp_bpf.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
MEDIUM5.5
Уязвимость функции blk_unregister_queue() модуля block/blk-sysfs.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:CMEDIUM5.5
Уязвимость функции fib_nh_match() модуля net/ipv4/fib_semantics.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
Уязвимость функции udmabuf_create() модуля drivers/dma-buf/udmabuf.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:CMEDIUM5.5
Уязвимость функции cl_stream_prepare() модуля sound/soc/sof/intel/hda-loader.c поддержки звука SoC ядра операционной системы 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
Уязвимость функции fcp_avc_transaction() модуля sound/firewire/fcp.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
Уязвимость функции mxser_activate() модуля drivers/tty/mxser.c драйвера поддержки консоли TTY ядра операционной системы 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
Уязвимость функции btmtksdio_probe() модуля drivers/bluetooth/btmtksdio.c драйвера поддержки устройств Bluetooth ядра операционной системы 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
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadlock Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_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/8e8542437bb4070423c9754d5ba270ffdbae8c8d
- https://git.kernel.org/stable/c/df77fbd8c5b222c680444801ffd20e8bbc90a56e
- https://git.kernel.org/stable/c/0478ccdc8ea016de1ebaf6fe6da0275c2b258c5b
- https://git.kernel.org/stable/c/8e8542437bb4070423c9754d5ba270ffdbae8c8d
- https://git.kernel.org/stable/c/df77fbd8c5b222c680444801ffd20e8bbc90a56e
HIGH7.8
An unprivileged write to the file handler flaw in the Linux kernel's control groups and namespaces subsystem was found in the way users have access to some less privileged process that are controlled by cgroups and have higher privileged parent process. It is actually both for cgroup2 and cgroup1 versions of control groups. A local user could use this flaw to crash the system or escalate their privileges on the system.
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CCVSS 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://bugzilla.redhat.com/show_bug.cgi?id=2035652
- https://lore.kernel.org/lkml/20211209214707.805617-1-tj%40kernel.org/T/
- https://security.netapp.com/advisory/ntap-20220602-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2035652
- https://lore.kernel.org/lkml/20211209214707.805617-1-tj%40kernel.org/T/
- https://security.netapp.com/advisory/ntap-20220602-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111 The bug was found during fuzzing. Stacktrace locates it in ath5k_eeprom_convert_pcal_info_5111. When none of the curve is selected in the loop, idx can go up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound. pd = &chinfo[pier].pd_curves[idx]; There are many OOB writes using pd later in the code. So I added a sanity check for idx. Checks for other loops involving AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not used outside the loops. The patch is NOT tested with real device. The following is the fuzzing report BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Write of size 1 at addr ffff8880174a4d60 by task modprobe/214 CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 really_probe+0x209/0x5d0
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/25efc5d03455c3839249bc77fce5e29ecb54677e
- https://git.kernel.org/stable/c/564d4eceb97eaf381dd6ef6470b06377bb50c95a
- https://git.kernel.org/stable/c/9d7d83d0399e23d66fd431b553842a84ac10398f
- https://git.kernel.org/stable/c/be2f81024e7981565d90a4c9ca3067d11b6bca7f
- https://git.kernel.org/stable/c/c4e2f577271e158d87a916afb4e87415a88ce856
- https://git.kernel.org/stable/c/cbd96d6cad6625feba9c8d101ed4977d53e82f8e
- https://git.kernel.org/stable/c/ed3dfdaa8b5f0579eabfc1c5818eed30cfe1fe84
- https://git.kernel.org/stable/c/f4de974019a0adf34d0e7de6b86252f1bd266b06
- https://git.kernel.org/stable/c/fc8f7752a82f4accb99c0f1a868906ba1eb7b86f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl Hulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ================================================================== The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can be concurrent. ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach. ubi_detach is bug-free because it uses reference counting to prevent concurrency. However, uif_init and uif_close in ubi_attach may race with ubi_cdev_ioctl. uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_del And uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double free The cause of this problem is that commit 714fb87e8bc0 make device "available" before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix the race condition between ubi device creation and udev by removing ubi_get_device in vol_attribute_show and dev_attribute_show.This avoids accessing uninitialized ubi_devices[ubi_num]. ubi_get_device is used to prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will not be deleted before all reference counting are released. The key process is shown in the following stack. device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain
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/1a3f1cf87054833242fcd0218de0481cf855f888
- https://git.kernel.org/stable/c/3cbf0e392f173ba0ce425968c8374a6aa3e90f2e
- https://git.kernel.org/stable/c/432b057f8e847ae5a2306515606f8d2defaca178
- https://git.kernel.org/stable/c/5f9e9c223e48c264241d2f34d0bfc29e5fcb5c1b
- https://git.kernel.org/stable/c/a8ecee49259f8f78d91ddb329ab2be7e6fd01974
- https://git.kernel.org/stable/c/c32fe764191b8ae8b128588beb96e3718d9179d8
- https://git.kernel.org/stable/c/d727fd32cbd1abf3465f607021bc9c746f17b5a8
- https://git.kernel.org/stable/c/f149b1bd213820363731aa119e5011ca892a2aac
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock() Function ubifs_wbuf_write_nolock() may access buf out of bounds in following process: ubifs_wbuf_write_nolock(): aligned_len = ALIGN(len, 8); // Assume len = 4089, aligned_len = 4096 if (aligned_len <= wbuf->avail) ... // Not satisfy if (wbuf->used) { ubifs_leb_write() // Fill some data in avail wbuf len -= wbuf->avail; // len is still not 8-bytes aligned aligned_len -= wbuf->avail; } n = aligned_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + written, wbuf->offs, n); // n > len, read out of bounds less than 8(n-len) bytes } , which can be catched by KASAN: ========================================================= BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0 Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128 Workqueue: writeback wb_workfn (flush-ubifs_0_0) Call Trace: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 Function ubifs_wbuf_write_nolock() accepts that parameter 'len' is not 8 bytes aligned, the 'len' represents the true length of buf (which is allocated in 'ubifs_jnl_xxx', eg. ubifs_jnl_write_inode), so ubifs_wbuf_write_nolock() must handle the length read from 'buf' carefully to write leb safely. Fetch a reproducer in [Link].
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/07a209fadee7b53b46858538e1177597273862e4
- https://git.kernel.org/stable/c/3b7fb89135a20587d57f8877c02e25003e9edbdf
- https://git.kernel.org/stable/c/4f2262a334641e05f645364d5ade1f565c85f20b
- https://git.kernel.org/stable/c/5343575aa11c5d7044107d59d43f84aec01312b0
- https://git.kernel.org/stable/c/a7054aaf1909cf40489c0ec1b728fdcf79c751a6
- https://git.kernel.org/stable/c/b80ccbec0e4804436c382d7dd60e943c386ed83a
- https://git.kernel.org/stable/c/e09fa5318d51f522e1af4fbaf8f74999355980c8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix deadlock in concurrent rename whiteout and inode writeback Following hung tasks: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0 [ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770 , are caused by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ↑ wb_wait_for_completion (Wait wb work) <-- deadlock! Reproducer (Detail program in [Link]): 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consume out of space before kernel(mdelay) doing budget for whiteout Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto tag 'out_release' in whiteout budget error handling path(It should at least recover dir i_size and unlock 4 ubifs inodes).
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/37bdf1ad592555ecda1d55b89f6e393e4c0589d1
- https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9
- https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787
- https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5
- https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185
- https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c
- https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ubifs: rename_whiteout: Fix double free for whiteout_ui->data 'whiteout_ui->data' will be freed twice if space budget fail for rename whiteout operation as following process: rename_whiteout dev = kmalloc whiteout_ui->data = dev kfree(whiteout_ui->data) // Free first time iput(whiteout) ubifs_free_inode kfree(ui->data) // Double free! KASAN reports: ================================================================== BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70 Call Trace: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Allocated by task 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Freed by task 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 The buggy address belongs to the object at ffff88810238bed8 which belongs to the cache kmalloc-8 of size 8 ================================================================== Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode() -> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it (because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release', and the nlink of whiteout inode is 0).
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/14276d38c89a170363e90b6ac0a53c3cf61b87fc
- https://git.kernel.org/stable/c/2ad07009c459e56ebdcc089d850d664660fdb742
- https://git.kernel.org/stable/c/2b3236ecf96db7af5836e1366ce39ace8ce832fa
- https://git.kernel.org/stable/c/40a8f0d5e7b3999f096570edab71c345da812e3e
- https://git.kernel.org/stable/c/6d7a158a7363c1f6604aa47ae1a280a5c65123dd
- https://git.kernel.org/stable/c/8b3c7be16f3f4dfd6e15ac651484e59d3fa36274
- https://git.kernel.org/stable/c/a90e2dbe66d2647ff95a0442ad2e86482d977fd8
- https://git.kernel.org/stable/c/b9a937f096e608b3368c1abc920d4d640ba2c94f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix early region not updated correctly The shadow's page table is not updated when PTE_RPN_SHIFT is 24 and PAGE_SHIFT is 12. It not only causes false positives but also false negative as shown the following text. Fix it by bringing the logic of kasan_early_shadow_page_entry here. 1. False Positive: ================================================================== BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50 Write of size 16 at addr f57f3be0 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1 Call Trace: [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable) [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300 [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200 [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0 [c80d1cc0] [c03018a4] memset+0x34/0x90 [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50 [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384 [c80d1ef0] [c0004b14] kernel_init+0x24/0x170 [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64 Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== 2. False Negative (with KASAN tests): ================================================================== Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan ================================================================== After fix: ok 1 - kasan
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/5a3d8f3192a409893c57808cc935e16484df1068
- https://git.kernel.org/stable/c/7f19245c3647afea8c7c41f795506ef70f64b9f2
- https://git.kernel.org/stable/c/dd75080aa8409ce10d50fb58981c6b59bf8707d3
- https://git.kernel.org/stable/c/de56beace6648065d404cd9835aa7d30e3df519d
- https://git.kernel.org/stable/c/e3d157a4b4f4e0268c98be5b7013bf4b31234bb6
- https://git.kernel.org/stable/c/f39a3309393a4a484532f6ba745c6acbcfe06115
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: cirrusfb: check pixclock to avoid divide by zero Do a sanity check on pixclock value to avoid divide by zero. If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible. Syzkaller reported a divide error in cirrusfb_check_pixclock. divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Call Trace: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
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/1d3fb46439ad4e8f0c5739eb33d1875ac9e0f135
- https://git.kernel.org/stable/c/40b13e3d85744210db13457785646634e2d056bd
- https://git.kernel.org/stable/c/45800c42ef000f417270bcfc08630e42486fca99
- https://git.kernel.org/stable/c/53a2088a396cfa1da92690a1da289634cd73bf0d
- https://git.kernel.org/stable/c/5c6f402bdcf9e7239c6bc7087eda71ac99b31379
- https://git.kernel.org/stable/c/6fe23ff94e7840097202e85c148688940b37c9b1
- https://git.kernel.org/stable/c/8c7e2141fb89c620ab4e41512e262fbf25b8260d
- https://git.kernel.org/stable/c/c656d04247a2654ede5cead2ecbf83431dad5261
- https://git.kernel.org/stable/c/e498b504f8c81b07efab9febf8503448de4dc9cf
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow Coverity complains of a possible buffer overflow. However, given the 'static' scope of nvidia_setup_i2c_bus() it looks like that can't happen after examiniing the call sites. CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) 1. fixed_size_dest: You might overrun the 48-character fixed-size string chan->adapter.name by copying name without checking the length. 2. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 89 strcpy(chan->adapter.name, name); Fix this warning by using strscpy() which will silence the warning and prevent any future buffer overflows should the names used to identify the channel become much longer.
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/055cdd2e7b992921424d4daaa285ced787fb205f
- https://git.kernel.org/stable/c/08dff482012758935c185532b1ad7d584785a86e
- https://git.kernel.org/stable/c/37a1a2e6eeeb101285cd34e12e48a881524701aa
- https://git.kernel.org/stable/c/41baa86b6c802cdc6ab8ff2d46c083c9be93de81
- https://git.kernel.org/stable/c/47e5533adf118afaf06d25a3e2aaaab89371b1c5
- https://git.kernel.org/stable/c/580e5d3815474b8349250c25c16416585a72c7fe
- https://git.kernel.org/stable/c/6a5226e544ac043bb2d8dc1bfe8920d02282f7cd
- https://git.kernel.org/stable/c/72dd5c46a152136712a55bf026a9aa8c1b12b60d
- https://git.kernel.org/stable/c/9ff2f7294ab0f011cd4d1b7dcd9a07d8fdf72834
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: Revert "Revert "block, bfq: honor already-setup queue merges"" A crash [1] happened to be triggered in conjunction with commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq: honor already-setup queue merges""). Yet, the reverted commit was not the one introducing the bug. In fact, it actually triggered a UAF introduced by a different commit, and now fixed by commit d29bd41428cf ("block, bfq: reset last_bfqq_created on group change"). So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") out. This commit restores it. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503
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/15729ff8143f8135b03988a100a19e66d7cb7ecd
- https://git.kernel.org/stable/c/4083925bd6dc89216d156474a8076feec904e607
- https://git.kernel.org/stable/c/65d8a737452e88f251fe5d925371de6d606df613
- https://git.kernel.org/stable/c/931aff627469a75c77b9fd3823146d0575afffd6
- https://git.kernel.org/stable/c/abc2129e646af7b43025d90a071f83043f1ae76c
- https://git.kernel.org/stable/c/cc051f497eac9d8a0d816cd4bffa3415f2724871
- https://git.kernel.org/stable/c/f990f0985eda59d4f29fc83fcf300c92b1225d39
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: udmabuf: validate ubuf->pagecount Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array().
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/2b6dd600dd72573c23ea180b5b0b2f1813405882
- https://git.kernel.org/stable/c/5d50f851dd307c07ca5591297093f19967c834a9
- https://git.kernel.org/stable/c/811b667cefbea9cb7511a874b169d6a92907137e
- https://git.kernel.org/stable/c/9e9b4a269f84d3230f2af84ff42322db676440d9
- https://git.kernel.org/stable/c/a3728d32fc61eb0fe283cb8ff60b2c8f751e2202
- https://git.kernel.org/stable/c/b267a8118c2b171bf7d67b90ed64154eeab9fae0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-compress: prevent the potentially use of null pointer There is one call trace that snd_soc_register_card() ->snd_soc_bind_card()->soc_init_pcm_runtime() ->snd_soc_dai_compress_new()->snd_soc_new_compress(). In the trace the 'codec_dai' transfers from card->dai_link, and we can see from the snd_soc_add_pcm_runtime() in snd_soc_bind_card() that, if value of card->dai_link->num_codecs is 0, then 'codec_dai' could be null pointer caused by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'. And snd_soc_register_card() is called by various platforms. Therefore, it is better to add the check in the case of misusing. And because 'cpu_dai' has already checked in soc_init_pcm_runtime(), there is no need to check again. Adding the check as follow, then if 'codec_dai' is null, snd_soc_new_compress() will not pass through the check 'if (playback + capture != 1)', avoiding the leftover use of 'codec_dai'.
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/08af6da684b44097ea09f1d74d5858b837ed203b
- https://git.kernel.org/stable/c/4639c1d97f385f4784f44d66a3da0672f4951ada
- https://git.kernel.org/stable/c/68a69ad8df959e5211ed4a8e120783b2d352ea74
- https://git.kernel.org/stable/c/de2c6f98817fa5decb9b7d3b3a8a3ab864c10588
- https://git.kernel.org/stable/c/f69a75cb8a98c6c487d620442c68595726a69f60
- https://git.kernel.org/stable/c/fc237b8d624f4bcb0f21a532627ce4e3b3a85569
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: rpmpd: Check for null return of devm_kcalloc Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.".
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/31b5124d742969ea8bf7a1360596f548ca23e770
- https://git.kernel.org/stable/c/5a811126d38f9767a20cc271b34db7c8efc5a46c
- https://git.kernel.org/stable/c/724376c30af5a57686b223dbcd6188e07d2a1de2
- https://git.kernel.org/stable/c/755dbc3d73789ac9f0017c729abf5e4b153bf799
- https://git.kernel.org/stable/c/84b89fa877ad576e9ee8130f412cfd592f274508
- https://git.kernel.org/stable/c/b5d6eba71997b6d661935d2b15094ac7f9f6132d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe() I got a null-ptr-deref report: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Call Trace: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will be called to destroy modelist in the error handling path. But modelist has not been initialized yet, so it will result in null-ptr-deref. Initialize modelist before calling fb_alloc_cmap() to fix 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/0fd28daec73525382e5c992db8743bf76e42cd5c
- https://git.kernel.org/stable/c/1791f487f877a9e83d81c8677bd3e7b259e7cb27
- https://git.kernel.org/stable/c/64ec3e678d76419f207b9cdd338dda438ca10b1c
- https://git.kernel.org/stable/c/9280ef235b05e8f19f8bc6d547b992f0a0ef398d
- https://git.kernel.org/stable/c/c420b540db4b5d69de0a36d8b9d9a6a79a04f05a
- https://git.kernel.org/stable/c/d1b6a1f0c23b7164250479bf92e2893291dca539
- https://git.kernel.org/stable/c/d396c651e2b508b6179bb678cc029f3becbf5170
- https://git.kernel.org/stable/c/da8b269cc0a2526ebeaccbe2484c999eb0f822cf
- https://git.kernel.org/stable/c/dd3a6cc7385b89ec2303f39dfc3bafa4e24cec4b
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: jffs2: fix use-after-free in jffs2_clear_xattr_subsystem When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super(). Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719 Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ================================================================== The triggering of the BUG is shown in the following stack: ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again ----------------------------------------------------------- An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF 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/22327bd7988f21de3a53c1373f3b81542bfe1f44
- https://git.kernel.org/stable/c/30bf7244acf32f19cb722c39f7bc1c2a9f300422
- https://git.kernel.org/stable/c/3bd2454162ec6bbb5503233c804fce6e4b6dcec5
- https://git.kernel.org/stable/c/4c7c44ee1650677fbe89d86edbad9497b7679b5c
- https://git.kernel.org/stable/c/7a75740206af5f17e9f3efa384211cba70213da1
- https://git.kernel.org/stable/c/7bb7428dd73991bf4b3a7a61b493ca50046c2b13
- https://git.kernel.org/stable/c/8c0f024f29e055840a5a89fe23b96ae3f921afed
- https://git.kernel.org/stable/c/9150cb625b46f68d524f4cfd491f1aafc23e10a9
- https://git.kernel.org/stable/c/c3b07c875fa8f906f932976460fd14798596f101
HIGH7.8
Integer Overflow or Wraparound vulnerability in io_uring of Linux Kernel allows local attacker to cause memory corruption and escalate privileges to root. This issue affects: Linux Kernel versions prior to 5.4.189; version 5.4.24 and later versions.
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CCVSS 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://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/io_uring.c?h=v5.4.189&id=1a623d361ffe5cecd4244a02f449528416360038
- https://kernel.dance/#1a623d361ffe5cecd4244a02f449528416360038
- https://security.netapp.com/advisory/ntap-20220629-0004/
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/io_uring.c?h=v5.4.189&id=1a623d361ffe5cecd4244a02f449528416360038
- https://kernel.dance/#1a623d361ffe5cecd4244a02f449528416360038
- https://security.netapp.com/advisory/ntap-20220629-0004/
HIGH7.8
A flaw was found in KVM. When updating a guest's page table entry, vm_pgoff was improperly used as the offset to get the page's pfn. As vaddr and vm_pgoff are controllable by user-mode processes, this flaw allows unprivileged local users on the host to write outside the userspace region and potentially corrupt the kernel, resulting in a denial of service condition.
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://bugzilla.redhat.com/show_bug.cgi?id=2069793
- https://security.netapp.com/advisory/ntap-20230214-0003/
- https://www.openwall.com/lists/oss-security/2022/04/08/4
- https://bugzilla.redhat.com/show_bug.cgi?id=2069793
- https://security.netapp.com/advisory/ntap-20230214-0003/
- https://www.openwall.com/lists/oss-security/2022/04/08/4
HIGH7.0
Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.0
Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.0
Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.0
Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.0
Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.0
Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.0
Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f
- https://security.netapp.com/advisory/ntap-20230214-0006/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f
- https://security.netapp.com/advisory/ntap-20230214-0006/
HIGH7.8
The Linux kernel before 5.17.2 mishandles seccomp permissions. The PTRACE_SEIZE code path allows attackers to bypass intended restrictions on setting the PT_SUSPEND_SECCOMP flag.
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 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://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2276
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220707-0001/
- https://www.debian.org/security/2022/dsa-5173
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2276
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220707-0001/
- https://www.debian.org/security/2022/dsa-5173
HIGH7.1
A NULL pointer dereference flaw in diFree in fs/jfs/inode.c in Journaled File System (JFS)in the Linux kernel. This could allow a local attacker to crash the system or leak kernel internal information.
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:HHIGH7.8
A flaw use after free in the Linux kernel video4linux driver was found in the way user triggers em28xx_usb_probe() for the Empia 28xx based TV cards. A local user could use this flaw 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c08eadca1bdfa099e20a32f8fa4b52b2f672236d
- https://security.netapp.com/advisory/ntap-20230214-0006/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c08eadca1bdfa099e20a32f8fa4b52b2f672236d
- https://security.netapp.com/advisory/ntap-20230214-0006/
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - ensure buffer for generate is completely filled The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi: kcapi-rng -b 9000000 > OUTFILE The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails. Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function returns success. Let's also have qcom_rng_generate() return the correct value. Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers: $ ent -c qcom-random-before Value Char Occurrences Fraction 0 606748 0.067416 1 33104 0.003678 2 33001 0.003667 ... 253 � 32883 0.003654 254 � 33035 0.003671 255 � 33239 0.003693 Total: 9000000 1.000000 Entropy = 7.811590 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 2 percent. Chi square distribution for 9000000 samples is 9329962.81, and randomly would exceed this value less than 0.01 percent of the times. Arithmetic mean value of data bytes is 119.3731 (127.5 = random). Monte Carlo value for Pi is 3.197293333 (error 1.77 percent). Serial correlation coefficient is 0.159130 (totally uncorrelated = 0.0). Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch: $ ent -c qcom-random-after Value Char Occurrences Fraction 0 35432 0.003937 1 35127 0.003903 2 35424 0.003936 ... 253 � 35201 0.003911 254 � 34835 0.003871 255 � 35368 0.003930 Total: 9000000 1.000000 Entropy = 7.999979 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 0 percent. Chi square distribution for 9000000 samples is 258.77, and randomly would exceed this value 42.24 percent of the times. Arithmetic mean value of data bytes is 127.5006 (127.5 = random). Monte Carlo value for Pi is 3.141277333 (error 0.01 percent). Serial correlation coefficient is 0.000468 (totally uncorrelated = 0.0). This change was tested on a Nexus 5 phone (msm8974 SoC).
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/0f9b7b8df17525e464294c916acc8194ce38446b
- https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d
- https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d
- https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b
- https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d
- https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd
- https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b
- https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d
- https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d
- https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b
- https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d
- https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
usb: usbtmc: Fix bug in pipe direction for control transfers
The syzbot fuzzer reported a minor bug in the usbtmc driver:
usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0
WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412
usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410
Modules linked in:
CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted
5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
...
Call Trace:
usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153
usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline]
The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for
all of its transfers, whether they are in or out. It's easy to fix.
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/10a805334a11acd547602d6c4cf540a0f6ab5c6e
- https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952
- https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016
- https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7
- https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b
- https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e
- https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952
- https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016
- https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7
- https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. There was a check for the number of endpoints, but not
for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with
usb_find_common_endpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Workqueue: usb_hub_wq hub_event
...
Call Trace:
aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830
input_open_device+0x1bb/0x320 drivers/input/input.c:629
kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
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/35069e654bcab567ff8b9f0e68e1caf82c15dcd7
- https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8
- https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821
- https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f
- https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c
- https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31
- https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a
- https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6
- https://git.kernel.org/stable/c/35069e654bcab567ff8b9f0e68e1caf82c15dcd7
- https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8
- https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821
- https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f
- https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c
- https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31
- https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a
- https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: prevent integer overflow in rndis_set_response() If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow.
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/138d4f739b35dfb40438a0d5d7054965763bfbe7
- https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e
- https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65
- https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c
- https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa
- https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b
- https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90
- https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0
- https://git.kernel.org/stable/c/138d4f739b35dfb40438a0d5d7054965763bfbe7
- https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e
- https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65
- https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c
- https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa
- https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b
- https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90
- https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
The syzbot fuzzer found a use-after-free bug:
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320
Read of size 8 at addr ffff88802b934098 by task udevd/3689
CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
dev_uevent+0x712/0x780 drivers/base/core.c:2320
uevent_show+0x1b8/0x380 drivers/base/core.c:2391
dev_attr_show+0x4b/0x90 drivers/base/core.c:2094
Although the bug manifested in the driver core, the real cause was a
race with the gadget core. dev_uevent() does:
if (dev->driver)
add_uevent_var(env, "DRIVER=%s", dev->driver->name);
and between the test and the dereference of dev->driver, the gadget
core sets dev->driver to NULL.
The race wouldn't occur if the gadget core registered its devices on
a real bus, using the standard synchronization techniques of the
driver core. However, it's not necessary to make such a large change
in order to fix this bug; all we need to do is make sure that
udc->dev.driver is always NULL.
In fact, there is no reason for udc->dev.driver ever to be set to
anything, let alone to the value it currently gets: the address of the
gadget's driver. After all, a gadget driver only knows how to manage
a gadget, not how to manage a UDC.
This patch simply removes the statements in the gadget core that touch
udc->dev.driver.
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/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646
- https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740
- https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a
- https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5
- https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e
- https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b
- https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e
- https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3
- https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646
- https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740
- https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a
- https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5
- https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e
- https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b
- https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e
- https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix slab-out-of-bounds access in packet_recvmsg()
syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH
and mmap operations, tpacket_rcv() is queueing skbs with
garbage in skb->cb[], triggering a too big copy [1]
Presumably, users of af_packet using mmap() already gets correct
metadata from the mapped buffer, we can simply make sure
to clear 12 bytes that might be copied to user space later.
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]
BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489
Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631
CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189
memcpy+0x39/0x60 mm/kasan/shadow.c:66
memcpy include/linux/fortify-string.h:225 [inline]
packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489
sock_recvmsg_nosec net/socket.c:948 [inline]
sock_recvmsg net/socket.c:966 [inline]
sock_recvmsg net/socket.c:962 [inline]
____sys_recvmsg+0x2c4/0x600 net/socket.c:2632
___sys_recvmsg+0x127/0x200 net/socket.c:2674
__sys_recvmsg+0xe2/0x1a0 net/socket.c:2704
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fdfd5954c29
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 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 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005
RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60
R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54
addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame:
____sys_recvmsg+0x0/0x600 include/linux/uio.h:246
this frame has 1 object:
[32, 160) 'addr'
Memory state around the buggy address:
ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
>ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3
^
ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1
ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00
==================================================================
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/268dcf1f7b3193bc446ec3d14e08a240e9561e4d
- https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02
- https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a
- https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da
- https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33
- https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0
- https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a
- https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2
- https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d
- https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02
- https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a
- https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da
- https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33
- https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0
- https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a
- https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: MIPS: smp: fill in sibling and core maps earlier After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following: [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... [ 0.048396] Call Trace: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 [ 0.048539] [ 0.048543] ---[ end trace 0000000000000000 ]--- [ 0.048636] Synchronize counters for CPU 1: done. ...for each but CPU 0/boot. Basic debug printks right before the mentioned line say: [ 0.048170] CPU: 1, smt_mask: So smt_mask, which is sibling mask obviously, is empty when entering the function. This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on MIPS). A bit of debugging led me to that set_cpu_sibling_map() performing the actual map calculation, was being invocated after notify_cpu_start(), and exactly the latter function starts CPU HP callback round (sched_core_cpu_starting() is basically a CPU HP callback). While the flow is same on ARM64 (maps after the notifier, although before calling set_cpu_online()), x86 started calculating sibling maps earlier than starting the CPU HP callbacks in Linux 4.14 (see [0] for the reference). Neither me nor my brief tests couldn't find any potential caveats in calculating the maps right after performing delay calibration, but the WARN splat is now gone. The very same debug prints now yield exactly what I expected from them: [ 0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef
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/32813321f18d5432cec1b1a6ecc964f9ea26d565
- https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7
- https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98
- https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239
- https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a
- https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7
- https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b
- https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808
- https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565
- https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7
- https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98
- https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239
- https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a
- https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7
- https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b
- https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net-sysfs: add check for netdevice being present to speed_show
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
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/081369ad088a76429984483b8a5f7e967a125aad
- https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204
- https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624
- https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f
- https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2
- https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6
- https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2
- https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c
- https://git.kernel.org/stable/c/081369ad088a76429984483b8a5f7e967a125aad
- https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204
- https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624
- https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f
- https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2
- https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6
- https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2
- https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: staging: gdm724x: fix use after free in gdm_lte_rx() The netif_rx_ni() function frees the skb so we can't dereference it to save the skb->len.
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/1fb9dd3787495b4deb0efe66c58306b65691a48f
- https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff
- https://git.kernel.org/stable/c/48ecdf3e29a6e514e8196691589c7dfc6c4ac169
- https://git.kernel.org/stable/c/6d9700b445098dbbce0caff4b8cfca214cf1e757
- https://git.kernel.org/stable/c/6dc7b87c62423bfa68139fe95e85028aab584c9a
- https://git.kernel.org/stable/c/83a9c886c2b5a0d28c0b37e1736b47f38d61332a
- https://git.kernel.org/stable/c/d39dc79513e99147b4c158a8a9e46743e23944f5
- https://git.kernel.org/stable/c/fc7f750dc9d102c1ed7bbe4591f991e770c99033
- https://git.kernel.org/stable/c/1fb9dd3787495b4deb0efe66c58306b65691a48f
- https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff
- https://git.kernel.org/stable/c/48ecdf3e29a6e514e8196691589c7dfc6c4ac169
- https://git.kernel.org/stable/c/6d9700b445098dbbce0caff4b8cfca214cf1e757
- https://git.kernel.org/stable/c/6dc7b87c62423bfa68139fe95e85028aab584c9a
- https://git.kernel.org/stable/c/83a9c886c2b5a0d28c0b37e1736b47f38d61332a
- https://git.kernel.org/stable/c/d39dc79513e99147b4c158a8a9e46743e23944f5
- https://git.kernel.org/stable/c/fc7f750dc9d102c1ed7bbe4591f991e770c99033
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails. One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved). Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NReferences
- https://git.kernel.org/stable/c/06cb238b0f7ac1669cb06390704c61794724c191
- https://git.kernel.org/stable/c/7007c894631cf43041dcfa0da7142bbaa7eb673c
- https://git.kernel.org/stable/c/901c7280ca0d5e2b4a8929fbe0bfb007ac2a6544
- https://git.kernel.org/stable/c/aaf166f37eb6bb55d81c3e40a2a460c8875c8813
- https://git.kernel.org/stable/c/b2f140a9f980806f572d672e1780acea66b9a25c
- https://git.kernel.org/stable/c/dcead36b19d999d687cd9c99b7f37520d9102b57
- https://git.kernel.org/stable/c/f2141881b530738777c28bb51c62175895c8178b
- https://git.kernel.org/stable/c/f3f2247ac31cb71d1f05f56536df5946c6652f4a
- https://git.kernel.org/stable/c/fd97de9c7b973f46a6103f4170c5efc7b8ef8797
- https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e
- https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026
- https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63
- https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192
- https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534
- https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753
- https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508f
- https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: sctp: fix kernel-infoleak for SCTP sockets syzbot reported a kernel infoleak [1] of 4 bytes. After analysis, it turned out r->idiag_expires is not initialized if inet_sctp_diag_fill() calls inet_diag_msg_common_fill() Make sure to clear idiag_timer/idiag_retrans/idiag_expires and let inet_diag_msg_sctpasoc_fill() fill them again if needed. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Bytes 68-71 of 2508 are uninitialized Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0 CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
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/1502f15b9f29c41883a6139f2923523873282a83
- https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5
- https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7
- https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8
- https://git.kernel.org/stable/c/633593a808980f82d251d0ca89730d8bb8b0220c
- https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545
- https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8
- https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c5836c76a08
- https://git.kernel.org/stable/c/1502f15b9f29c41883a6139f2923523873282a83
- https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5
- https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7
- https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8
- https://git.kernel.org/stable/c/633593a808980f82d251d0ca89730d8bb8b0220c
- https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545
- https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8
- https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c5836c76a08
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: gianfar: ethtool: Fix refcount leak in gfar_get_ts_info The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount.
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/0e1b9a2078e07fb1e6e91bf8badfd89ecab1e848
- https://git.kernel.org/stable/c/21044e679ed535345042d2023f7df0ca8e897e2a
- https://git.kernel.org/stable/c/2ac5b58e645c66932438bb021cb5b52097ce70b0
- https://git.kernel.org/stable/c/6263f2eb93a85ad7df504daf0c341a7fb6bbe8a6
- https://git.kernel.org/stable/c/f49f646f9ec296fc0afe7ae92c2bb47f23e3846c
- https://git.kernel.org/stable/c/f7b3b520349193f8a82cca74daf366199e06add9
- https://git.kernel.org/stable/c/0e1b9a2078e07fb1e6e91bf8badfd89ecab1e848
- https://git.kernel.org/stable/c/21044e679ed535345042d2023f7df0ca8e897e2a
- https://git.kernel.org/stable/c/2ac5b58e645c66932438bb021cb5b52097ce70b0
- https://git.kernel.org/stable/c/6263f2eb93a85ad7df504daf0c341a7fb6bbe8a6
- https://git.kernel.org/stable/c/f49f646f9ec296fc0afe7ae92c2bb47f23e3846c
- https://git.kernel.org/stable/c/f7b3b520349193f8a82cca74daf366199e06add9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
NFC: port100: fix use-after-free in port100_send_complete
Syzbot reported UAF in port100_send_complete(). The root case is in
missing usb_kill_urb() calls on error handling path of ->probe function.
port100_send_complete() accesses devm allocated memory which will be
freed on probe failure. We should kill this urbs before returning an
error from probe function to prevent reported use-after-free
Fail log:
BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
...
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
__usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
...
Allocated by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:436 [inline]
____kasan_kmalloc mm/kasan/common.c:515 [inline]
____kasan_kmalloc mm/kasan/common.c:474 [inline]
__kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
alloc_dr drivers/base/devres.c:116 [inline]
devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
devm_kzalloc include/linux/device.h:209 [inline]
port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502
Freed by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
kasan_slab_free include/linux/kasan.h:236 [inline]
__cache_free mm/slab.c:3437 [inline]
kfree+0xf8/0x2b0 mm/slab.c:3794
release_nodes+0x112/0x1a0 drivers/base/devres.c:501
devres_release_all+0x114/0x190 drivers/base/devres.c:530
really_probe+0x626/0xcc0 drivers/base/dd.c:670
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/0e721b8f2ee5e11376dd55363f9ccb539d754b8a
- https://git.kernel.org/stable/c/205c4ec78e71cbf561794e6043da80e7bae6790f
- https://git.kernel.org/stable/c/2b1c85f56512d49e43bc53741fce2f508cd90029
- https://git.kernel.org/stable/c/32e866ae5a7af590597ef4bcff8451bf96d5f980
- https://git.kernel.org/stable/c/7194737e1be8fdc89d2a9382bd2f371f7ee2eda8
- https://git.kernel.org/stable/c/b1db33d4e54bc35d8db96ce143ea0ef92e23d58e
- https://git.kernel.org/stable/c/cd2a5c0da0d1ddf11d1f84e9c9b1949f50f6e161
- https://git.kernel.org/stable/c/f80cfe2f26581f188429c12bd937eb905ad3ac7b
- https://git.kernel.org/stable/c/0e721b8f2ee5e11376dd55363f9ccb539d754b8a
- https://git.kernel.org/stable/c/205c4ec78e71cbf561794e6043da80e7bae6790f
- https://git.kernel.org/stable/c/2b1c85f56512d49e43bc53741fce2f508cd90029
- https://git.kernel.org/stable/c/32e866ae5a7af590597ef4bcff8451bf96d5f980
- https://git.kernel.org/stable/c/7194737e1be8fdc89d2a9382bd2f371f7ee2eda8
- https://git.kernel.org/stable/c/b1db33d4e54bc35d8db96ce143ea0ef92e23d58e
- https://git.kernel.org/stable/c/cd2a5c0da0d1ddf11d1f84e9c9b1949f50f6e161
- https://git.kernel.org/stable/c/f80cfe2f26581f188429c12bd937eb905ad3ac7b
HIGH7.0
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix a race on command flush flow
Fix a refcount use after free warning due to a race on command entry.
Such race occurs when one of the commands releases its last refcount and
frees its index and entry while another process running command flush
flow takes refcount to this command entry. The process which handles
commands flush may see this command as needed to be flushed if the other
process released its refcount but didn't release the index yet. Fix it
by adding the needed spin lock.
It fixes the following warning trace:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0
...
RIP: 0010:refcount_warn_saturate+0x80/0xe0
...
Call Trace:
mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core]
mlx5_cmd_flush+0x3a/0xf0 [mlx5_core]
enter_error_state+0x44/0x80 [mlx5_core]
mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core]
process_one_work+0x1be/0x390
worker_thread+0x4d/0x3d0
? rescuer_thread+0x350/0x350
kthread+0x141/0x160
? set_kthread_struct+0x40/0x40
ret_from_fork+0x1f/0x30
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0401bfb27a91d7bdd74b1635c1aae57cbb128da6
- https://git.kernel.org/stable/c/063bd355595428750803d8736a9bb7c8db67d42d
- https://git.kernel.org/stable/c/1a4017926eeea56c7540cc41b42106746ee8a0ee
- https://git.kernel.org/stable/c/7c519f769f555ff7d9d4ccba3497bbb589df360a
- https://git.kernel.org/stable/c/f3331bc17449f15832c31823f27573f4c0e13e5f
- https://git.kernel.org/stable/c/0401bfb27a91d7bdd74b1635c1aae57cbb128da6
- https://git.kernel.org/stable/c/063bd355595428750803d8736a9bb7c8db67d42d
- https://git.kernel.org/stable/c/1a4017926eeea56c7540cc41b42106746ee8a0ee
- https://git.kernel.org/stable/c/7c519f769f555ff7d9d4ccba3497bbb589df360a
- https://git.kernel.org/stable/c/f3331bc17449f15832c31823f27573f4c0e13e5f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ethernet: Fix error handling in xemaclite_of_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. As the remove function do.
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/1852854ee349881efb78ccdbbb237838975902e4
- https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d
- https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9
- https://git.kernel.org/stable/c/8609e29611befc4bfbe7a91bb50fc65ae72ff549
- https://git.kernel.org/stable/c/8ee065a7a9b6a3976c16340503677efc4d8351f6
- https://git.kernel.org/stable/c/979b418b96e35f07136f77962ccfaa54cf3e30e1
- https://git.kernel.org/stable/c/b19ab4b38b06aae12442b2de95ccf58b5dc53584
- https://git.kernel.org/stable/c/b7220f8e9d6c6b9594ddfb3125dad938cd478b1f
- https://git.kernel.org/stable/c/1852854ee349881efb78ccdbbb237838975902e4
- https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d
- https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9
- https://git.kernel.org/stable/c/8609e29611befc4bfbe7a91bb50fc65ae72ff549
- https://git.kernel.org/stable/c/8ee065a7a9b6a3976c16340503677efc4d8351f6
- https://git.kernel.org/stable/c/979b418b96e35f07136f77962ccfaa54cf3e30e1
- https://git.kernel.org/stable/c/b19ab4b38b06aae12442b2de95ccf58b5dc53584
- https://git.kernel.org/stable/c/b7220f8e9d6c6b9594ddfb3125dad938cd478b1f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: fix memory leak in int3400_notify()
It is easy to hit the below memory leaks in my TigerLake platform:
unreferenced object 0xffff927c8b91dbc0 (size 32):
comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
hex dump (first 32 bytes):
4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The
72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.
backtrace:
[] __kmalloc_track_caller+0x2fe/0x4a0
[] kvasprintf+0x65/0xd0
[] kasprintf+0x4e/0x70
[] int3400_notify+0x82/0x120 [int3400_thermal]
[] acpi_ev_notify_dispatch+0x54/0x71
[] acpi_os_execute_deferred+0x17/0x30
[] process_one_work+0x21a/0x3f0
[] worker_thread+0x4a/0x3b0
[] kthread+0xfd/0x130
[] ret_from_fork+0x1f/0x30
Fix it by calling kfree() accordingly.
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/2e798814e01827871938ff172d2b2ccf1e74b355
- https://git.kernel.org/stable/c/33c73a4d7e7b19313a6b417152f5365016926418
- https://git.kernel.org/stable/c/3abea10e6a8f0e7804ed4c124bea2d15aca977c8
- https://git.kernel.org/stable/c/ba9efbbf6745750d34c1e87c9539ce9db645ca0a
- https://git.kernel.org/stable/c/c3fa6d1937a8d0828131a04ae2cd2c30d0668693
- https://git.kernel.org/stable/c/e098933866f9e1dd3ef4eebbe2e3d504f970f599
- https://git.kernel.org/stable/c/f0ddc5184b0127038d05008e2a69f89d1e13f980
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
ata: sata_dwc_460ex: Fix crash due to OOB write
the driver uses libata's "tag" values from in various arrays.
Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
the value of the SATA_DWC_QCMD_MAX needs to account for that.
Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
this as reported by Tice Rex on the OpenWrt Forum and
reproduced (with symbols) here:
| BUG: Kernel NULL pointer dereference at 0x00000000
| Faulting instruction address: 0xc03ed4b8
| Oops: Kernel access of bad area, sig: 11 [#1]
| BE PAGE_SIZE=4K PowerPC 44x Platform
| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
| NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c
| REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163)
| MSR: 00021000 CR: 42000222 XER: 00000000
| DEAR: 00000000 ESR: 00000000
| GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]
| [..]
| NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254
| LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc
| Call Trace:
| [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)
| [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc
| [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524
| [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0
| [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204
| [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130
| [...]
This is because sata_dwc_dma_xfer_complete() NULLs the
dma_pending's next neighbour "chan" (a *dma_chan struct) in
this '32' case right here (line ~735):
> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;
Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes
the NULL'd hsdevp->chan to the dmaengine_slave_config() which then
causes the crash.
With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.
This avoids the OOB. But please note, there was a worthwhile discussion
on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not
be a "fake" 33 command-long queue size.
Ideally, the dw driver should account for the ATA_TAG_INTERNAL.
In Damien Le Moal's words: "... having looked at the driver, it
is a bigger change than just faking a 33rd "tag" that is in fact
not a command tag at all."
BugLink: https://github.com/openwrt/openwrt/issues/9505
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/234c0132f76f0676d175757f61b0025191a3d935
- https://git.kernel.org/stable/c/3a8751c0d4e24129e72dcec0139e99833b13904a
- https://git.kernel.org/stable/c/55e1465ba79562a191708a40eeae3f8082a209e3
- https://git.kernel.org/stable/c/596c7efd69aae94f4b0e91172b075eb197958b99
- https://git.kernel.org/stable/c/7aa8104a554713b685db729e66511b93d989dd6a
- https://git.kernel.org/stable/c/8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8
- https://git.kernel.org/stable/c/fc629224aa62f23849cae83717932985ac51232d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing.
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/0df6664531a12cdd8fc873f0cac0dcb40243d3e9
- https://git.kernel.org/stable/c/3c07cc242baf83f0bddbbd9d7945d0bee56d8b57
- https://git.kernel.org/stable/c/60e1eb4811f53f5f60c788297d978515e7a2637a
- https://git.kernel.org/stable/c/6fef3e3179e6ed8fecdd004ede541674ffa7749d
- https://git.kernel.org/stable/c/7218a789abb3e033f5f3a85636ca50d9ae7b0fc9
- https://git.kernel.org/stable/c/c7daf1b4ad809692d5c26f33c02ed8a031066548
- https://git.kernel.org/stable/c/ff24114bb08d8b90edf2aff0a4fd0689523e6c17
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve overflow the qgroup limit We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit. Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem. The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNT When running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB Since we have no control of how bytes_changed is used, it's better to set it to u64.
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/0355387ea5b02d353c9415613fab908fac5c52a6
- https://git.kernel.org/stable/c/44277c50fdba5019ca25bfad1b71e2561b0de11b
- https://git.kernel.org/stable/c/4b98799e181b4326a613108cf37acc1f55d21b45
- https://git.kernel.org/stable/c/6bfff81286d4491f02dad7814bae5c77c9ad2320
- https://git.kernel.org/stable/c/7941b74ed49b6db25efbef2256ebef843c11a010
- https://git.kernel.org/stable/c/82ae73ac963cee877ce34f7c31b2b456b516e96c
- https://git.kernel.org/stable/c/b642b52d0b50f4d398cb4293f64992d0eed2e2ce
- https://git.kernel.org/stable/c/f3d97b22a708bf9e3f3ac2ba232bcefd0b0c136b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) If an mremap() syscall with old_size=0 ends up in move_page_tables(), it will call invalidate_range_start()/invalidate_range_end() unnecessarily, i.e. with an empty range. This causes a WARN in KVM's mmu_notifier. In the past, empty ranges have been diagnosed to be off-by-one bugs, hence the WARNing. Given the low (so far) number of unique reports, the benefits of detecting more buggy callers seem to outweigh the cost of having to fix cases such as this one, where userspace is doing something silly. In this particular case, an early return from move_page_tables() is enough 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/01e67e04c28170c47700c2c226d732bbfedb1ad0
- https://git.kernel.org/stable/c/04bc13dae4a27b8d030843c85ae452bb2f1d9c1f
- https://git.kernel.org/stable/c/2358aa84ef6dafcf544a557caaa6b91afb4a0bd2
- https://git.kernel.org/stable/c/7d659cb1763ff17d1c6ee082fa6feb4267c7a30b
- https://git.kernel.org/stable/c/a04cb99c5d4668fe3f5c0e5b6da1cecd34c3f219
- https://git.kernel.org/stable/c/a05540f3903bd8295e8c4cd90dd3d416239a115b
- https://git.kernel.org/stable/c/c19d8de4e682ec4b0ea2b04a832cd8cc0be3bb31
- https://git.kernel.org/stable/c/e2c328c2a8f9de8b761bd4025b66c63120c55761
- https://git.kernel.org/stable/c/eeaf28e2a0128147d687237e59d5407ee1b14693
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.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/467d5e200ab4486b744fe1776154a43d1aa22d4b
- https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846faa0610a86029b253
- https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3
- https://git.kernel.org/stable/c/9fb8bc6cfc58773ce95414e11c9ccc8fc6ac4927
- https://git.kernel.org/stable/c/e64dbe97c05c769525cbca099ddbd22485630235
- https://git.kernel.org/stable/c/eafc0a02391b7b36617b36c97c4b5d6832cf5e24
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
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/198932a14aeb19a15cf19e51e151d023bc4cd648
- https://git.kernel.org/stable/c/25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b
- https://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93d
- https://git.kernel.org/stable/c/4ad099559b00ac01c3726e5c95dc3108ef47d03e
- https://git.kernel.org/stable/c/5e16dc5378abd749a836daa9ee4ab2c8d2668999
- https://git.kernel.org/stable/c/6e00309ac716fa8225f0cbde2cd9c24f0e74ee21
- https://git.kernel.org/stable/c/8510c2346d9e47a72b7f018a36ef0c39483e53d6
- https://git.kernel.org/stable/c/f7e183b0a7136b6dc9c7b9b2a85a608a8feba894
- https://git.kernel.org/stable/c/fe39ac59dbbf893b73b24e3184161d0bd06d6651
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: qede: confirm skb is allocated before using qede_build_skb() assumes build_skb() always works and goes straight to skb_reserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL. Add a check in case build_skb() failed to allocate and return NULL. The NULL return is handled correctly in callers to qede_build_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/034a92c6a81048128fc7b18d278d52438a13902a
- https://git.kernel.org/stable/c/4e910dbe36508654a896d5735b318c0b88172570
- https://git.kernel.org/stable/c/8928239e5e2e460d95b8a0b89f61671625e7ece0
- https://git.kernel.org/stable/c/9648adb1b3ece55c657d3a4f52bfee663b710dfe
- https://git.kernel.org/stable/c/b2d6b3db9d1cf80908964036dbe1c52a86b1afb1
- https://git.kernel.org/stable/c/c9bdce2359b5f4986eb38d1e81865b3586cc20d2
- https://git.kernel.org/stable/c/e1fd0c42acfa22bb34d2ab6a111484f466ab8093
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drbd: Fix five use after free bugs in get_initial_state In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug. What's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state calls below. Thus 4 additional uaf bugs happened. My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid. v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/
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/0489700bfeb1e53eb2039c2291c67e71b0b40103
- https://git.kernel.org/stable/c/188fe6b26765edbad4055611c0f788b6870f4024
- https://git.kernel.org/stable/c/226e993c39405292781bfcf4b039a8db56aab362
- https://git.kernel.org/stable/c/594205b4936771a250f9d141e7e0fff21c3dd2d9
- https://git.kernel.org/stable/c/a972c768723359ec995579902473028fe3cd64b1
- https://git.kernel.org/stable/c/aadb22ba2f656581b2f733deb3a467c48cc618f6
- https://git.kernel.org/stable/c/b6a4055036eed1f5e239ce3d8b0db1ce38bba447
- https://git.kernel.org/stable/c/dcf6be17b5c53b741898d2223b23e66d682de300
- https://git.kernel.org/stable/c/de63e74da2333b4068bb79983e632db730fea97e
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix a race in rxrpc_exit_net()
Current code can lead to the following race:
CPU0 CPU1
rxrpc_exit_net()
rxrpc_peer_keepalive_worker()
if (rxnet->live)
rxnet->live = false;
del_timer_sync(&rxnet->peer_keepalive_timer);
timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);
cancel_work_sync(&rxnet->peer_keepalive_work);
rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
leading to use-after-free.
syzbot report was:
ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Modules linked in:
CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__debug_check_no_obj_freed lib/debugobjects.c:992 [inline]
debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023
kfree+0xd6/0x310 mm/slab.c:3809
ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176
ops_free_list net/core/net_namespace.c:174 [inline]
cleanup_net+0x591/0xb00 net/core/net_namespace.c:598
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
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/08ff0e74fab517dbc44e11b8bc683dd4ecc65950
- https://git.kernel.org/stable/c/1946014ca3b19be9e485e780e862c375c6f98bad
- https://git.kernel.org/stable/c/41024a40f6c793abbb916a857f18fb009f07464c
- https://git.kernel.org/stable/c/571d8e1d154ca18f08dcb72b69318d36e10010a0
- https://git.kernel.org/stable/c/7ee84d29f22de6f6c63fad6c54690517659862f1
- https://git.kernel.org/stable/c/864297ee30727ae6233f80296b7fc91442620b05
- https://git.kernel.org/stable/c/cd8aef1f30d1215648e4e6686cfb422004851429
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak.
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/2b04bd4f03bba021959ca339314f6739710f0954
- https://git.kernel.org/stable/c/45fdd98b70142521739615ad1bfb760401863b73
- https://git.kernel.org/stable/c/46d120f7c163706d6c31ee00baa0be64c4572b78
- https://git.kernel.org/stable/c/599874bbc4ed832ccb578d48ac0ae7344382ef43
- https://git.kernel.org/stable/c/ebd1e3458dbf6643aa0272da398cb5b537d492b7
- https://git.kernel.org/stable/c/fbe5f4c0dd3475178f17ddd8b8d5044ebeae0be7
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition.
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/43c2d7890ecabe527448a6c391fb2d9a5e6bbfe0
- https://git.kernel.org/stable/c/4d809f69695d4e7d1378b3a072fa9aef23123018
- https://git.kernel.org/stable/c/57800cc36e55db0547461c49acf5cd84c0f502b0
- https://git.kernel.org/stable/c/77ffb2495a41098f9d6a14f8aefde3188da75944
- https://git.kernel.org/stable/c/8a50937227c385a477177c9ffa122b4230e40666
- https://git.kernel.org/stable/c/92f1947c0d26060e978b3a9f21f32ce7c8c9cca3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/imx: Fix memory leak in imx_pd_connector_get_modes Avoid leaking the display mode variable if of_get_drm_display_mode fails. Addresses-Coverity-ID: 1443943 ("Resource leak")
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/31e449302ed00c38d4068443cf0243279701ab28
- https://git.kernel.org/stable/c/38bf605bd8c83d942c8dcffaef3633b7d8b37549
- https://git.kernel.org/stable/c/41624d7c0c3df71dee170c610744aaa5909327b8
- https://git.kernel.org/stable/c/7526102d908ec5ae777aa77723d52fce12916093
- https://git.kernel.org/stable/c/bc23c327e1a23cc3555fa1e86288e13288515442
- https://git.kernel.org/stable/c/bce81feb03a20fca7bbdd1c4af16b4e9d5c0e1d3
- https://git.kernel.org/stable/c/c539a6a5896ed92bfb91494e46996d013f3d5967
- https://git.kernel.org/stable/c/d2c2758cfb0262637fd93350bdc8ad485fb1dd61
- https://git.kernel.org/stable/c/f8b0ef0a5889890b50482b6593bd8de544736351
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: fix route with nexthop object delete warning
FRR folks have hit a kernel warning[1] while deleting routes[2] which is
caused by trying to delete a route pointing to a nexthop id without
specifying nhid but matching on an interface. That is, a route is found
but we hit a warning while matching it. The warning is from
fib_info_nh() in include/net/nexthop.h because we run it on a fib_info
with nexthop object. The call chain is:
inet_rtm_delroute -> fib_table_delete -> fib_nh_match (called with a
nexthop fib_info and also with fc_oif set thus calling fib_info_nh on
the fib_info and triggering the warning). The fix is to not do any
matching in that branch if the fi has a nexthop object because those are
managed separately. I.e. we should match when deleting without nh spec and
should fail when deleting a nexthop route with old-style nh spec because
nexthop objects are managed separately, e.g.:
$ ip r show 1.2.3.4/32
1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0
$ ip r del 1.2.3.4/32
$ ip r del 1.2.3.4/32 nhid 12
$ ip r del 1.2.3.4/32 dev dummy0
[1]
[ 523.462226] ------------[ cut here ]------------
[ 523.462230] WARNING: CPU: 14 PID: 22893 at include/net/nexthop.h:468 fib_nh_match+0x210/0x460
[ 523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd
[ 523.462274] videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse
[ 523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P OE 5.16.18-200.fc35.x86_64 #1
[ 523.462302] Hardware name: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 10/29/2020
[ 523.462303] RIP: 0010:fib_nh_match+0x210/0x460
[ 523.462304] Code: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff <0f> 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00
[ 523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286
[ 523.462307] RAX: 0000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0
[ 523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380
[ 523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000
[ 523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031
[ 523.462310] R13: 0000000000000020 R14: 0000000000000000 R15: ffff9e3d331054e0
[ 523.462311] FS: 00007f2455
---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/63ea57478aaa3e06a597081a0f537318fc04e49f
- https://git.kernel.org/stable/c/6bf92d70e690b7ff12b24f4bfff5e5434d019b82
- https://git.kernel.org/stable/c/907c97986d6fa77318d17659dd76c94b65dd27c5
- https://git.kernel.org/stable/c/dcd689f9e2640c992f94eae9955b106f71c6825d
- https://git.kernel.org/stable/c/f5064531c23ad646da7be8b938292b00a7e61438
- https://git.kernel.org/stable/c/f8db5743d09523c0bb35f16e13691e3b7eb5dba0
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix slab-out-of-bounds bug in decrypt_internal
The memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting in
tls_set_sw_offload(). The return value of crypto_aead_ivsize()
for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes
memory space will trigger slab-out-of-bounds bug as following:
==================================================================
BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]
Read of size 16 at addr ffff888114e84e60 by task tls/10911
Call Trace:
dump_stack_lvl+0x34/0x44
print_report.cold+0x5e/0x5db
? decrypt_internal+0x385/0xc40 [tls]
kasan_report+0xab/0x120
? decrypt_internal+0x385/0xc40 [tls]
kasan_check_range+0xf9/0x1e0
memcpy+0x20/0x60
decrypt_internal+0x385/0xc40 [tls]
? tls_get_rec+0x2e0/0x2e0 [tls]
? process_rx_list+0x1a5/0x420 [tls]
? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls]
decrypt_skb_update+0x9d/0x400 [tls]
tls_sw_recvmsg+0x3c8/0xb50 [tls]
Allocated by task 10911:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
tls_set_sw_offload+0x2eb/0xa20 [tls]
tls_setsockopt+0x68c/0x700 [tls]
__sys_setsockopt+0xfe/0x1b0
Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_size
when memcpy() iv value in TLS_1_3_VERSION scenario.
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/2304660ab6c425df64d95301b601424c6a50f28b
- https://git.kernel.org/stable/c/29be1816cbab9a0dc6243120939fd10a92753756
- https://git.kernel.org/stable/c/2b7d14c105dd8f6412eda5a91e1e6154653731e3
- https://git.kernel.org/stable/c/589154d0f18945f41d138a5b4e49e518d294474b
- https://git.kernel.org/stable/c/6e2f1b033b17dedda51d465861b69e58317d6343
- https://git.kernel.org/stable/c/9381fe8c849cfbe50245ac01fc077554f6eaa0e2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one() The error handling path of the probe releases a resource that is not freed in the remove function. In some cases, a ioremap() must be undone. Add the missing iounmap() call in the remove function.
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/16ed828b872d12ccba8f07bcc446ae89ba662f9c
- https://git.kernel.org/stable/c/1e0c01319dedf1e63ec5df37ead048e17afd92ba
- https://git.kernel.org/stable/c/34a47f7ddb4fd1cbd12397aa6f7dad1de08b4050
- https://git.kernel.org/stable/c/a845c678e094894f38cc9526d212b21933ce44c7
- https://git.kernel.org/stable/c/aefd755a96051aa56b198cb7ecd168b22ba384f6
- https://git.kernel.org/stable/c/c5f77b595379b5191316edd365a542f8b1526066
- https://git.kernel.org/stable/c/ce430cfad6a5385d5b7f7c1dc3fa50f10abfd41b
- https://git.kernel.org/stable/c/db863ab2baf058ed05c7b723612e3c40c9dd6885
- https://git.kernel.org/stable/c/de6aee0978f164d3d0c771ce03e3066a26c371c5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix potential crash on module unload The vmbus driver relies on the panic notifier infrastructure to perform some operations when a panic event is detected. Since vmbus can be built as module, it is required that the driver handles both registering and unregistering such panic notifier callback. After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback") though, the panic notifier registration is done unconditionally in the module initialization routine whereas the unregistering procedure is conditionally guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability is set. This patch fixes that by unconditionally unregistering the panic notifier in the module's exit routine as well.
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/2133c422a103cf7c7768c37b9ac382e73b691892
- https://git.kernel.org/stable/c/3d0078f8bddd58d9bb1ad40bbe929f8633abb276
- https://git.kernel.org/stable/c/5ea98d0f5f035c1bcf1517ccec0e024ae35a48b2
- https://git.kernel.org/stable/c/6b4c0149a56147b29169e07000d566162892722a
- https://git.kernel.org/stable/c/792f232d57ff28bbd5f9c4abe0466b23d5879dc8
- https://git.kernel.org/stable/c/cf580d2e3884dbafd6b90269b03a24d661578624
- https://git.kernel.org/stable/c/dcd6b1a624c0ffa21034d8b1e02e9d068458f596
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs
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/0f3d824bd70a1303464d5e93ee3e7afe7832fe89
- https://git.kernel.org/stable/c/3504b0a177208eda85bf472bbf7c9aa77d2b8343
- https://git.kernel.org/stable/c/3fd5dee7404ce40c79cba468bb2510115639d975
- https://git.kernel.org/stable/c/44c2d5fbe7b2bd1f8cb114d608a591a73a5d4ae6
- https://git.kernel.org/stable/c/71612aee09ecea3475f8751dc841d75a011b1fd0
- https://git.kernel.org/stable/c/7deaddb704713608e0ae559e27185581b9af71a0
- https://git.kernel.org/stable/c/93e3d88321d2274fa4e26b006e19cc10fec331c2
- https://git.kernel.org/stable/c/c69b442125bf009fce26e15aa5616caf8a3673c3
- https://git.kernel.org/stable/c/fefb8a2a941338d871e2d83fbd65fbfa068857bd
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use after free in hci_send_acl
This fixes the following trace caused by receiving
HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without
first checking if conn->type is in fact AMP_LINK and in case it is
do properly cleanup upper layers with hci_disconn_cfm:
==================================================================
BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50
Read of size 8 at addr ffff88800e404818 by task bluetoothd/142
CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
dump_stack_lvl+0x45/0x59
print_address_description.constprop.0+0x1f/0x150
kasan_report.cold+0x7f/0x11b
hci_send_acl+0xaba/0xc50
l2cap_do_send+0x23f/0x3d0
l2cap_chan_send+0xc06/0x2cc0
l2cap_sock_sendmsg+0x201/0x2b0
sock_sendmsg+0xdc/0x110
sock_write_iter+0x20f/0x370
do_iter_readv_writev+0x343/0x690
do_iter_write+0x132/0x640
vfs_writev+0x198/0x570
do_writev+0x202/0x280
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3
0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015
RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77
R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580
RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001
R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0
Allocated by task 45:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
hci_chan_create+0x9a/0x2f0
l2cap_conn_add.part.0+0x1a/0xdc0
l2cap_connect_cfm+0x236/0x1000
le_conn_complete_evt+0x15a7/0x1db0
hci_le_conn_complete_evt+0x226/0x2c0
hci_le_meta_evt+0x247/0x450
hci_event_packet+0x61b/0xe90
hci_rx_work+0x4d5/0xc50
process_one_work+0x8fb/0x15a0
worker_thread+0x576/0x1240
kthread+0x29d/0x340
ret_from_fork+0x1f/0x30
Freed by task 45:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0xfb/0x130
kfree+0xac/0x350
hci_conn_cleanup+0x101/0x6a0
hci_conn_del+0x27e/0x6c0
hci_disconn_phylink_complete_evt+0xe0/0x120
hci_event_packet+0x812/0xe90
hci_rx_work+0x4d5/0xc50
process_one_work+0x8fb/0x15a0
worker_thread+0x576/0x1240
kthread+0x29d/0x340
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88800c0f0500
The buggy address is located 24 bytes inside of
which belongs to the cache kmalloc-128 of size 128
The buggy address belongs to the page:
128-byte region [ffff88800c0f0500, ffff88800c0f0580)
flags: 0x100000000000200(slab|node=0|zone=1)
page:00000000fe45cd86 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0xc0f0
raw: 0000000000000000 0000000080100010 00000001ffffffff
0000000000000000
raw: 0100000000000200 ffffea00003a2c80 dead000000000004
ffff8880078418c0
page dumped because: kasan: bad access detected
ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
Memory state around the buggy address:
>ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
---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/2cc803804ec9a296b3156855d6c8c4ca1c6b84be
- https://git.kernel.org/stable/c/3803d896ddd97c7c16689a5381c0960040727647
- https://git.kernel.org/stable/c/4da302b90b96c309987eb9b37c8547f939f042d2
- https://git.kernel.org/stable/c/643a6c26bd32e339d00ad97b8822b6db009e803c
- https://git.kernel.org/stable/c/684e505406abaeabe0058e9776f9210bf2747953
- https://git.kernel.org/stable/c/b3c2ea1fd444b3bb7b82bfd2c3a45418f85c2502
- https://git.kernel.org/stable/c/c41de54b0a963e59e4dd04c029a4a6d73f45ef9c
- https://git.kernel.org/stable/c/d404765dffdbd8dcd14758695d0c96c52fb2e624
- https://git.kernel.org/stable/c/f63d24baff787e13b723d86fe036f84bdbc35045
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free.
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/1d7effe5fff9d28e45e18ac3a564067c7ddfe898
- https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4
- https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a
- https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb
- https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232
- https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836
- https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe
- https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef
- https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mips: ralink: fix a refcount leak in ill_acc_of_setup() of_node_put(np) needs to be called when pdev == 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/060a485df4ec1183d543317511cb4caa43468b5d
- https://git.kernel.org/stable/c/142ae7d4f21524acfe073e5a3da5667aa85eb970
- https://git.kernel.org/stable/c/4a0a1436053b17e50b7c88858fb0824326641793
- https://git.kernel.org/stable/c/5fb47ca3490813d3884d8ad0b2ce511aa3537551
- https://git.kernel.org/stable/c/8d7f7ef7980f287ace1c15f2ac03d6754e12f071
- https://git.kernel.org/stable/c/c74c755daed551b9aceb8388159180861474bdfe
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm ioctl: prevent potential spectre v1 gadget It appears like cmd could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec.
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/02cc46f397eb3691c56affbd5073e54f7a82ac32
- https://git.kernel.org/stable/c/0320bac5801b31407200227173205d017488f140
- https://git.kernel.org/stable/c/44e6cb3ab177faae840bb2c1ebda9a2539876184
- https://git.kernel.org/stable/c/58880025e3362024f6d8ea01cb0c7a5df6c84ba6
- https://git.kernel.org/stable/c/71c8df33fd777c7628f6fbc09b14e84806c55914
- https://git.kernel.org/stable/c/76c94651005f58885facf9c973007f5ea01ab01f
- https://git.kernel.org/stable/c/7ae2c5b89da3cfaf856df880af27d3bb32a74b3d
- https://git.kernel.org/stable/c/cd9c88da171a62c4b0f1c70e50c75845969fbc18
- https://git.kernel.org/stable/c/dd86064417de828ff2102ddc6049c829bf7585b4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code.
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/3edd8646cb7c11b57c90e026bda6f21076223f5b
- https://git.kernel.org/stable/c/4009f104b02b223d1a11d74b36b1cc083bc37028
- https://git.kernel.org/stable/c/72d77ddb2224ebc00648f4f78f8a9a259dccbdf7
- https://git.kernel.org/stable/c/927beb05aaa429c883cc0ec6adc48964b187e291
- https://git.kernel.org/stable/c/b6d1f7d97c81ebaf2cda9c4c943ee2e484fffdcf
- https://git.kernel.org/stable/c/bc2d5c0775c839e2b072884f4ee6a93ba410f107
- https://git.kernel.org/stable/c/dfced44f122c500004a48ecc8db516bb6a295a1b
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Avoid out of bounds access when parsing _CPC data If the NumEntries field in the _CPC return package is less than 2, do not attempt to access the "Revision" element of that package, because it may not be present then. BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/
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/28d5387c1994f5e1e0d41b30a1f3dd6e1f609252
- https://git.kernel.org/stable/c/40d8abf364bcab23bc715a9221a3c8623956257b
- https://git.kernel.org/stable/c/97b5593fd1b182b3fdb180b6bbe64ec09669988b
- https://git.kernel.org/stable/c/b3f15609ffa521de12244cd6af24002030dda3f5
- https://git.kernel.org/stable/c/b80b19b32a432c9eee1cd200ef7aaddf608f54d1
- https://git.kernel.org/stable/c/cb249f8c00f40dba83b7da8207ac14ca46e9ec9e
- https://git.kernel.org/stable/c/d208ea44e25b31db5a4d5e8c31df51787a3e9303
- https://git.kernel.org/stable/c/d7339f2a3938fb56b5f28d53f5345900b5fa0e74
- https://git.kernel.org/stable/c/e5b681822cac1f8093759b02e16c06b2c64b6788
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
can: mcba_usb: properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. We should check that in endpoint is actually present to
prevent this warning.
Found pipes are now saved to struct mcba_priv and code uses them
directly instead of making pipes in place.
Fail log:
| usb 5-1: BOGUS urb xfer, pipe 3 != type 1
| WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
| Modules linked in:
| CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0
| Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| Workqueue: usb_hub_wq hub_event
| RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
| ...
| Call Trace:
|
| mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline]
| mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858
| usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
| call_driver_probe drivers/base/dd.c:517 [inline]
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/136bed0bfd3bc9c95c88aafff2d22ecb3a919f23
- https://git.kernel.org/stable/c/5598442edc29e8f6f2380e4b471dc1a3fcd80508
- https://git.kernel.org/stable/c/88272b4a37913bdf6f339162a7920bd8e9b49de2
- https://git.kernel.org/stable/c/b48d1bb3f1ca337ad653022aefb5a40a47dfe5cd
- https://git.kernel.org/stable/c/cbd110b8dd7ad763bf413f71c0484116ae9302d4
- https://git.kernel.org/stable/c/ef0acc514123140157b19a9ff2e2de5d91d612bc
- https://git.kernel.org/stable/c/f2ec3cd0f34f8c3f94bc21fbba14868301c9c49d
- https://git.kernel.org/stable/c/fa9c1f14002dc0d5293e16a2007bd89b6e79207b
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: XArray: Fix xas_create_range() when multi-order entry present If there is already an entry present that is of order >= XA_CHUNK_SHIFT when we call xas_create_range(), xas_create_range() will misinterpret that entry as a node and dereference xa_node->parent, generally leading to a crash that looks something like this: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0 RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline] RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725 It's deterministically reproducable once you know what the problem is, but producing it in a live kernel requires khugepaged to hit a race. While the problem has been present since xas_create_range() was introduced, I'm not aware of a way to hit it before the page cache was converted to use multi-index entries.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair() [ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e
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/1ab81d82fb1db7ec4be4b0d04563513e6d4bcdd5
- https://git.kernel.org/stable/c/43195a0c620761fbb88db04e2475313855b948a4
- https://git.kernel.org/stable/c/8077a7162bc3cf658dd9ff112bc77716c08458c5
- https://git.kernel.org/stable/c/9c33d49ab9f3d8bd7512b3070cd2f07c4a8849d5
- https://git.kernel.org/stable/c/a60447e7d451df42c7bde43af53b34f10f34f469
- https://git.kernel.org/stable/c/a669a22aef0ceff706b885370af74b5a60a8ac85
- https://git.kernel.org/stable/c/f68776f28d9134fa65056e7e63bfc734049730b7
- https://git.kernel.org/stable/c/f97316dd393bc8df1cc2af6295a97b876eecf252
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: sm712fb: Fix crash in smtcfb_write() When the sm712fb driver writes three bytes to the framebuffer, the driver will crash: BUG: unable to handle page fault for address: ffffc90001ffffff RIP: 0010:smtcfb_write+0x454/0x5b0 Call Trace: vfs_write+0x291/0xd60 ? do_sys_openat2+0x27d/0x350 ? __fget_light+0x54/0x340 ksys_write+0xce/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Fix it by removing the open-coded endianness fixup-code.
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/0ec746674296c94137f074309c26d17e644c0498
- https://git.kernel.org/stable/c/1aea36a62f0a0ad67eccc945bac0bd6422ef720f
- https://git.kernel.org/stable/c/3b36c05f68ba32d0dfb63abc9016d6fe9117829f
- https://git.kernel.org/stable/c/4f01d09b2bbfbcb47b3eb305560a7f4857a32260
- https://git.kernel.org/stable/c/809b8cde86320698661eec677222bc5c5df76176
- https://git.kernel.org/stable/c/aeb635b49530b7d19e140949753409f759ba99be
- https://git.kernel.org/stable/c/b1c28577529cdfad40c8242673285f1e1e4c314e
- https://git.kernel.org/stable/c/eae90015d10f0c9a47fc4adccba4cd79dce664e4
- https://git.kernel.org/stable/c/fb791514acf9070225eed46e1ccbb0aa7aae5da5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ntfs: add sanity check on allocation size ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation size. It triggers one BUG in the __ntfs_malloc function. Fix this by adding sanity check on ni->attr_list_size.
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/07793d2e55563124108762f4e5f811db92ffe02f
- https://git.kernel.org/stable/c/115fae2c1566eacc5ad2055f72521354612e72c3
- https://git.kernel.org/stable/c/21d490232f323ed4053eb9924615e6fea291f154
- https://git.kernel.org/stable/c/24ab2d4ef52c2dbb62a60844b87fc8872383407a
- https://git.kernel.org/stable/c/714fbf2647b1a33d914edd695d4da92029c7e7c0
- https://git.kernel.org/stable/c/b230f2d9441a34c7f483d39ab78519bcf73cc2e0
- https://git.kernel.org/stable/c/bd8d7daa0e53b184a2f3c6e0d47330780d0a0650
- https://git.kernel.org/stable/c/c641087d381a08363e5f14179bc6b0a23eca7c47
- https://git.kernel.org/stable/c/fe41ad8be036a3de3e4bdde709551aeb4de2fe7d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ext4: don't BUG if someone dirty pages without asking ext4 first [un]pin_user_pages_remote is dirtying pages without properly warning the file system in advance. A related race was noted by Jan Kara in 2018[1]; however, more recently instead of it being a very hard-to-hit race, it could be reliably triggered by process_vm_writev(2) which was discovered by Syzbot[2]. This is technically a bug in mm/gup.c, but arguably ext4 is fragile in that if some other kernel subsystem dirty pages without properly notifying the file system using page_mkwrite(), ext4 will BUG, while other file systems will not BUG (although data will still be lost). So instead of crashing with a BUG, issue a warning (since there may be potential data loss) and just mark the page as clean to avoid unprivileged denial of service attacks until the problem can be properly fixed. More discussion and background can be found in the thread starting at [2]. [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com
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/0d3a6926f7e8be3c897fa46216ce13b119a9f56a
- https://git.kernel.org/stable/c/330d0e44fc5a47c27df958ecdd4693a3cb1d8b81
- https://git.kernel.org/stable/c/343117559ef41e992e326f7a92da1a8f254dfa8c
- https://git.kernel.org/stable/c/5a016c053f426a73752c3b41b60b497b58694d48
- https://git.kernel.org/stable/c/5db60e76edf5680ff1f3a7221036fc44b308f146
- https://git.kernel.org/stable/c/677c9d30e8487bee6c8e3b034070319d98f6e203
- https://git.kernel.org/stable/c/a0856764dc1276ad2dc7891288c2e9246bf11a37
- https://git.kernel.org/stable/c/cc5095747edfb054ca2068d01af20be3fcc3634f
- https://git.kernel.org/stable/c/d666dfaa571465a19f014534a214c255ea33f301
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
PM: core: keep irq flags in device_pm_check_callbacks()
The function device_pm_check_callbacks() can be called under the spin
lock (in the reported case it happens from genpd_add_device() ->
dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.
However this function uncoditionally uses spin_lock_irq() /
spin_unlock_irq(), thus not preserving the CPU flags. Use the
irqsave/irqrestore instead.
The backtrace for the reference:
[ 2.752010] ------------[ cut here ]------------
[ 2.756769] raw_local_irq_restore() called with IRQs enabled
[ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50
[ 2.772338] Modules linked in:
[ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684
[ 2.781384] Freeing initrd memory: 46024K
[ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50
[ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50
[ 2.785846] sp : ffff80000805b7d0
[ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002
[ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800
[ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00
[ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff
[ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7
[ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8
[ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0
[ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0
[ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000
[ 2.889774] Call trace:
[ 2.892290] warn_bogus_irq_restore+0x34/0x50
[ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0
[ 2.901690] genpd_unlock_spin+0x20/0x30
[ 2.905724] genpd_add_device+0x100/0x2d0
[ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c
[ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190
[ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0
[ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30
[ 2.929102] psci_dt_attach_cpu+0x24/0x90
[ 2.933230] psci_cpuidle_probe+0x2d4/0x46c
[ 2.937534] platform_probe+0x68/0xe0
[ 2.941304] really_probe.part.0+0x9c/0x2fc
[ 2.945605] __driver_probe_device+0x98/0x144
[ 2.950085] driver_probe_device+0x44/0x15c
[ 2.954385] __device_attach_driver+0xb8/0x120
[ 2.958950] bus_for_each_drv+0x78/0xd0
[ 2.962896] __device_attach+0xd8/0x180
[ 2.966843] device_initial_probe+0x14/0x20
[ 2.971144] bus_probe_device+0x9c/0xa4
[ 2.975092] device_add+0x380/0x88c
[ 2.978679] platform_device_add+0x114/0x234
[ 2.983067] platform_device_register_full+0x100/0x190
[ 2.988344] psci_idle_init+0x6c/0xb0
[ 2.992113] do_one_initcall+0x74/0x3a0
[ 2.996060] kernel_init_freeable+0x2fc/0x384
[ 3.000543] kernel_init+0x28/0x130
[ 3.004132] ret_from_fork+0x10/0x20
[ 3.007817] irq event stamp: 319826
[ 3.011404] hardirqs last enabled at (319825): [] __up_console_sem+0x78/0x84
[ 3.020332] hardirqs last disabled at (319826): [] el1_dbg+0x24/0x8c
[ 3.028458] softirqs last enabled at (318312): [] _stext+0x410/0x588
[ 3.036678] softirqs last disabled at (318299): [] __irq_exit_rcu+0x158/0x174
[ 3.045607] ---[ end trace 0000000000000000 ]---
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/0cccf9d4fb45f1acbc0bbf6d7e4d8d0fb7a10416
- https://git.kernel.org/stable/c/2add538e57a2825c61d639260386f385c75e4166
- https://git.kernel.org/stable/c/3ec80d52b9b74b9e691997632a543c73eddfeba0
- https://git.kernel.org/stable/c/524bb1da785a7ae43dd413cd392b5071c6c367f8
- https://git.kernel.org/stable/c/78c4d68b952f5f537788dbd454031ea9bf50f642
- https://git.kernel.org/stable/c/be8bc05f38d667eda1e820bc6f69234795be7809
- https://git.kernel.org/stable/c/c29642ba72f87c0a3d7449f7db5d6d76a7ed53c3
- https://git.kernel.org/stable/c/c7c0ec5a1dcc3eaa1e85c804c2ccf46e457788a3
- https://git.kernel.org/stable/c/ede1ef1a7de973321699736ef96d01a4b9a6fe9e
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bfq: fix use-after-free in bfq_dispatch_request KASAN reports a use-after-free report when doing normal scsi-mq test [69832.239032] ================================================================== [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0 [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8 [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [69832.249069] Workqueue: kblockd blk_mq_run_work_fn [69832.250022] Call Trace: [69832.250541] dump_stack+0x9b/0xce [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0 [69832.252243] print_address_description.constprop.6+0x3e/0x60 [69832.253381] ? __cpuidle_text_end+0x5/0x5 [69832.254211] ? vprintk_func+0x6b/0x120 [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0 [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0 [69832.256914] kasan_report.cold.9+0x22/0x3a [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0 [69832.258755] check_memory_region+0x1c1/0x1e0 [69832.260248] bfq_dispatch_request+0x1045/0x44b0 [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440 [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170 [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100 [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570 [69832.267147] ? __switch_to+0x5f4/0xee0 [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270 [69832.269840] blk_mq_run_work_fn+0x51/0x60 [69832.278170] process_one_work+0x6d4/0xfe0 [69832.278984] worker_thread+0x91/0xc80 [69832.279726] ? __kthread_parkme+0xb0/0x110 [69832.280554] ? process_one_work+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthread_park+0x170/0x170 [69832.282849] ret_from_fork+0x1f/0x30 [69832.283573] [69832.283886] Allocated by task 7725: [69832.284599] kasan_save_stack+0x19/0x40 [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmem_cache_alloc_node+0x13f/0x460 [69832.287237] bfq_get_queue+0x3d4/0x1140 [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510 [69832.289015] bfq_init_rq+0x337/0x2d50 [69832.289749] bfq_insert_requests+0x304/0x4e10 [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390 [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760 [69832.292538] blk_flush_plug_list+0x2c5/0x480 [69832.293392] io_schedule_prepare+0xb2/0xd0 [69832.294209] io_schedule_timeout+0x13/0x80 [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270 [69832.296137] submit_bio_wait+0x103/0x1a0 [69832.296932] blkdev_issue_discard+0xe6/0x160 [69832.297794] blk_ioctl_discard+0x219/0x290 [69832.298614] blkdev_common_ioctl+0x50a/0x1750 [69832.304715] blkdev_ioctl+0x470/0x600 [69832.305474] block_ioctl+0xde/0x120 [69832.306232] vfs_ioctl+0x6c/0xc0 [69832.306877] __se_sys_ioctl+0x90/0xa0 [69832.307629] do_syscall_64+0x2d/0x40 [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasan_save_stack+0x19/0x40 [69832.311121] kasan_set_track+0x1c/0x30 [69832.311868] kasan_set_free_info+0x1b/0x30 [69832.312699] __kasan_slab_free+0x111/0x160 [69832.313524] kmem_cache_free+0x94/0x460 [69832.314367] bfq_put_queue+0x582/0x940 [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0 [69832.317275] bfq_bfqq_expire+0xb27/0x2440 [69832.318084] bfq_dispatch_request+0x697/0x44b0 [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270 [69832.323114] blk_mq_run_work_fn+0x51/0x6 ---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/080665e2c3cbfc68359b9a348a3546ed9b908e7a
- https://git.kernel.org/stable/c/40b4ba0030e0b02cbacd424ebb9f4c8b0976c786
- https://git.kernel.org/stable/c/5117c9ff4c2ebae0f5c2c262d42a25a8fbc086e6
- https://git.kernel.org/stable/c/5687958bf18f84384d809f521210d0f5deed03b0
- https://git.kernel.org/stable/c/74e610b5ee0d95e751280567100509eb11517efa
- https://git.kernel.org/stable/c/ab552fcb17cc9e4afe0e4ac4df95fc7b30e8490a
- https://git.kernel.org/stable/c/df6e00b1a53c57dca82c63b5ecbcad5452231bc7
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: block, bfq: don't move oom_bfqq Our test report a UAF: [ 2073.019181] ================================================================== [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5 [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Call trace: [ 2073.019203] dump_backtrace+0x0/0x310 [ 2073.019206] show_stack+0x28/0x38 [ 2073.019210] dump_stack+0xec/0x15c [ 2073.019216] print_address_description+0x68/0x2d0 [ 2073.019220] kasan_report+0x238/0x2f0 [ 2073.019224] __asan_store8+0x88/0xb0 [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019233] bfq_put_async_queues+0xbc/0x208 [ 2073.019236] bfq_pd_offline+0x178/0x238 [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019244] bfq_exit_queue+0x128/0x178 [ 2073.019249] blk_mq_exit_sched+0x12c/0x160 [ 2073.019252] elevator_exit+0xc8/0xd0 [ 2073.019256] blk_exit_queue+0x50/0x88 [ 2073.019259] blk_cleanup_queue+0x228/0x3d8 [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019274] null_exit+0x90/0x114 [null_blk] [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019282] el0_svc_common+0xc8/0x320 [ 2073.019287] el0_svc_handler+0xf8/0x160 [ 2073.019290] el0_svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Allocated by task 14163: [ 2073.019301] kasan_kmalloc+0xe0/0x190 [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418 [ 2073.019308] bfq_pd_alloc+0x54/0x118 [ 2073.019313] blkcg_activate_policy+0x250/0x460 [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110 [ 2073.019321] bfq_init_queue+0x6d0/0x948 [ 2073.019325] blk_mq_init_sched+0x1d8/0x390 [ 2073.019330] elevator_switch_mq+0x88/0x170 [ 2073.019334] elevator_switch+0x140/0x270 [ 2073.019338] elv_iosched_store+0x1a4/0x2a0 [ 2073.019342] queue_attr_store+0x90/0xe0 [ 2073.019348] sysfs_kf_write+0xa8/0xe8 [ 2073.019351] kernfs_fop_write+0x1f8/0x378 [ 2073.019359] __vfs_write+0xe0/0x360 [ 2073.019363] vfs_write+0xf0/0x270 [ 2073.019367] ksys_write+0xdc/0x1b8 [ 2073.019371] __arm64_sys_write+0x50/0x60 [ 2073.019375] el0_svc_common+0xc8/0x320 [ 2073.019380] el0_svc_handler+0xf8/0x160 [ 2073.019383] el0_svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Freed by task 72584: [ 2073.019391] __kasan_slab_free+0x120/0x228 [ 2073.019394] kasan_slab_free+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqg_put+0x64/0xb0 [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0 [ 2073.019408] bfq_put_queue+0x220/0x228 [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168 [ 2073.019416] bfq_put_async_queues+0xbc/0x208 [ 2073.019420] bfq_pd_offline+0x178/0x238 [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019429] bfq_exit_queue+0x128/0x178 [ 2073.019433] blk_mq_exit_sched+0x12c/0x160 [ 2073.019437] elevator_exit+0xc8/0xd0 [ 2073.019440] blk_exit_queue+0x50/0x88 [ 2073.019443] blk_cleanup_queue+0x228/0x3d8 [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019459] null_exit+0x90/0x114 [null_blk] [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019467] el0_svc_common+0xc8/0x320 [ 2073.019471] el0_svc_handler+0xf8/0x160 [ 2073.019474] el0_svc+0x10/0x218 [ 2073.019475] [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024 [ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] The buggy address belongs to the page: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---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/7507ead1e9d42957c2340f2c4a0e9d00034e3366
- https://git.kernel.org/stable/c/8410f70977734f21b8ed45c37e925d311dfda2e7
- https://git.kernel.org/stable/c/87fdfe8589d43e471dffb4c60f75eeb6f37afc4c
- https://git.kernel.org/stable/c/8f34dea99cd7761156a146a5258a67d045d862f7
- https://git.kernel.org/stable/c/c01fced8d38fbccc82787065229578006f28e020
- https://git.kernel.org/stable/c/c4f5a678add58a8a0e7ee5e038496b376ea6d205
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: LSM: general protection fault in legacy_parse_param The usual LSM hook "bail on fail" scheme doesn't work for cases where a security module may return an error code indicating that it does not recognize an input. In this particular case Smack sees a mount option that it recognizes, and returns 0. A call to a BPF hook follows, which returns -ENOPARAM, which confuses the caller because Smack has processed its data. The SELinux hook incorrectly returns 1 on success. There was a time when this was correct, however the current expectation is that it return 0 on success. This is repaired.
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/00fc07fa0b4a004711b6e1a944f0d2e46f7093b7
- https://git.kernel.org/stable/c/2784604c8c6fc523248f8f80a421c313a9d790b7
- https://git.kernel.org/stable/c/cadae7c5e477aaafcba819b8e4a3d1c1a1503b62
- https://git.kernel.org/stable/c/ddcdda888e14ca451b3ee83d11b65b2a9c8e783b
- https://git.kernel.org/stable/c/ecff30575b5ad0eda149aadad247b7f75411fd47
- https://git.kernel.org/stable/c/f3f93a1aaafc3032e0a9655fb43deccfb3e953a3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
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/0067ba448f1c29ca06e5aee00d8506889ed1f9d0
- https://git.kernel.org/stable/c/0356d4b64a03d23daf99a2a29d7d7d91d6ec2ea8
- https://git.kernel.org/stable/c/59250d547542f1c7765a78dc97ddfe5e6b0d2ab0
- https://git.kernel.org/stable/c/62580a40c9bef3d8a90629c64dda381344b35ffd
- https://git.kernel.org/stable/c/669b05ff43bd7ed684379c6e2006a6dad5127b71
- https://git.kernel.org/stable/c/9511c6018cd772668def8b034bc67269847e591a
- https://git.kernel.org/stable/c/bc1e29a35147c1ba6ea2b06a16cb0028f7c852d2
- https://git.kernel.org/stable/c/c09ac191b1f97cfa06f394dbfd7a5db07986cefc
- https://git.kernel.org/stable/c/c52703355766c347f270df222a744e0c491a02f2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: clk-rcg2: Update logic to calculate D value for RCG The display pixel clock has a requirement on certain newer platforms to support M/N as (2/3) and the final D value calculated results in underflow errors. As the current implementation does not check for D value is within the accepted range for a given M & N value. Update the logic to calculate the final D value based on the range.
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/334720f418f57b1d969dad2117b21f9388cb9395
- https://git.kernel.org/stable/c/34dca60982e93e69ae442aa2d36ce61c9a3bb563
- https://git.kernel.org/stable/c/52592f9afbfe01bce8f8953e4f19cbe3bcbdbd3a
- https://git.kernel.org/stable/c/58922910add18583d5273c2edcdb9fd7bf4eca02
- https://git.kernel.org/stable/c/96888f0dcf351e758b9df57e015a48427ca709c1
- https://git.kernel.org/stable/c/a4e2e31971354790b0d1fa3e783452a9d135fcff
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mxser: fix xmit_buf leak in activate when LSR == 0xff When LSR is 0xff in ->activate() (rather unlike), we return an error. Provided ->shutdown() is not called when ->activate() fails, nothing actually frees the buffer in this case. Fix this by properly freeing the buffer in a designated label. We jump there also from the "!info->type" if now too.
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/125b7c929fc9b1e5eaa344bceb6367dfa6fd3f9d
- https://git.kernel.org/stable/c/2cd05c38a27bee7fb42aa4d43174d68ac55dac0f
- https://git.kernel.org/stable/c/376922045009f8ea2d20a8fa3475e95b47c41690
- https://git.kernel.org/stable/c/685b6d16bf89595310b5d61394c9b97cc9505c7c
- https://git.kernel.org/stable/c/6c9041b2f90c0eace73106f22350e1d2c98f5edc
- https://git.kernel.org/stable/c/6dffc2035fbaada60ca8db59e0962e34f760370a
- https://git.kernel.org/stable/c/996291d06851a26678a0fab488b6e1f0677c0576
- https://git.kernel.org/stable/c/b125b08dbee3611f03f53b71471813ed4ccafcdd
- https://git.kernel.org/stable/c/cd3a4907ee334b40d7aa880c7ab310b154fd5cd4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: af_netlink: Fix shift out of bounds in group mask calculation When a netlink message is received, netlink_recvmsg() fills in the address of the sender. One of the fields is the 32-bit bitfield nl_groups, which carries the multicast group on which the message was received. The least significant bit corresponds to group 1, and therefore the highest group that the field can represent is 32. Above that, the UB sanitizer flags the out-of-bounds shift attempts. Which bits end up being set in such case is implementation defined, but it's either going to be a wrong non-zero value, or zero, which is at least not misleading. Make the latter choice deterministic by always setting to 0 for higher-numbered multicast groups. To get information about membership in groups >= 32, userspace is expected to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO socket option. [0] https://lwn.net/Articles/147608/ The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridge Which produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'
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/0caf6d9922192dd1afa8dc2131abfb4df1443b9f
- https://git.kernel.org/stable/c/41249fff507387c3323b198d0052faed08b14de4
- https://git.kernel.org/stable/c/7409ff6393a67ff9838d0ae1bd102fb5f020d07a
- https://git.kernel.org/stable/c/ac5883a8890a11c00b32a19949a25d4afeaa2f5a
- https://git.kernel.org/stable/c/b0898362188e05b2202656058cc32d98fabf3bac
- https://git.kernel.org/stable/c/e1c5d46f05aa23d740daae5cd3a6472145afac42
- https://git.kernel.org/stable/c/e23e1e981247feb3c7d0236fe58aceb685f234ae
- https://git.kernel.org/stable/c/e8aaf3134bc5e943048eefe9f2ddaabf41d92b1a
- https://git.kernel.org/stable/c/f75f4abeec4c04b600a15b50c89a481f1e7435ee
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt Fix the following kernel oops in btmtksdio_interrrupt [ 14.339134] btmtksdio_interrupt+0x28/0x54 [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0 [ 14.339144] sdio_irq_work+0x40/0x70 [ 14.339154] process_one_work+0x184/0x39c [ 14.339160] worker_thread+0x228/0x3e8 [ 14.339168] kthread+0x148/0x3ac [ 14.339176] ret_from_fork+0x10/0x30 That happened because hdev->power_on is already called before sdio_set_drvdata which btmtksdio_interrupt handler relies on is not properly set up. The details are shown as the below: hci_register_dev would run queue_work(hdev->req_workqueue, &hdev->power_on) as WQ_HIGHPRI workqueue_struct to complete the power-on sequeunce and thus hci_power_on may run before sdio_set_drvdata is done in btmtksdio_probe. The hci_dev_do_open in hci_power_on would initialize the device and enable the interrupt and thus it is possible that btmtksdio_interrupt is being called right before sdio_set_drvdata is filled out. When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled , the kernel oops is going to happen because btmtksdio_interrupt access an uninitialized pointer.
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/4d3d1f2c35a19988d3c5f0ee86038b525e830840
- https://git.kernel.org/stable/c/6d7be5afbb41c918d2f12f857f8c7efa50500be2
- https://git.kernel.org/stable/c/70a6cf749d9ff9f463490248322e5343199bc267
- https://git.kernel.org/stable/c/770a97d3f34b801de1b04737b43e02c55118c41a
- https://git.kernel.org/stable/c/874eca93966a786eace87fa6dfb206c2dd9519b1
- https://git.kernel.org/stable/c/b062a0b9c1dc1ff63094337dccfe1568d5b62023
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix more uncharged while msg has more_data
In tcp_bpf_send_verdict(), if msg has more data after
tcp_bpf_sendmsg_redir():
tcp_bpf_send_verdict()
tosend = msg->sg.size //msg->sg.size = 22220
case __SK_REDIRECT:
sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc
tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000
goto more_data;
tosend = msg->sg.size //msg->sg.size = 11000
case __SK_REDIRECT:
sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_alloc
The msg->sg.size(11000) has been uncharged twice, to fix we can charge the
remaining msg->sg.size before goto more data.
This issue can cause the following info:
WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
inet_csk_destroy_sock+0x55/0x110
__tcp_close+0x279/0x470
tcp_close+0x1f/0x60
inet_release+0x3f/0x80
__sock_release+0x3d/0xb0
sock_close+0x11/0x20
__fput+0x92/0x250
task_work_run+0x6a/0xa0
do_exit+0x33b/0xb60
do_group_exit+0x2f/0xa0
get_signal+0xb6/0x950
arch_do_signal_or_restart+0xac/0x2a0
? vfs_write+0x237/0x290
exit_to_user_mode_prepare+0xa9/0x200
syscall_exit_to_user_mode+0x12/0x30
do_syscall_64+0x46/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
worker_thread+0x30/0x350
? process_one_work+0x3c0/0x3c0
kthread+0xe6/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
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/168ff181f5b6e7fce684c98a30d35da1dbf8f82a
- https://git.kernel.org/stable/c/244ce90c8d0bd10ebf957da02c6f3fcd5d920bdf
- https://git.kernel.org/stable/c/7b812a369e6416ab06d83cdd39d8e3f752781dd0
- https://git.kernel.org/stable/c/84472b436e760ba439e1969a9e3c5ae7c86de39d
- https://git.kernel.org/stable/c/87d532d41ef937e16f61b3d2094f3a2ac49be365
- https://git.kernel.org/stable/c/abb4caa477a5450817d2aa1198edce66450aecf8
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix double uncharge the mem of sk_msg
If tcp_bpf_sendmsg is running during a tear down operation, psock may be
freed.
tcp_bpf_sendmsg()
tcp_bpf_send_verdict()
sk_msg_return()
tcp_bpf_sendmsg_redir()
unlikely(!psock))
sk_msg_free()
The mem of msg has been uncharged in tcp_bpf_send_verdict() by
sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock
is null, we can simply returning an error code, this would then trigger
the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have
the side effect of throwing an error up to user space. This would be a
slight change in behavior from user side but would look the same as an
error if the redirect on the socket threw an error.
This issue can cause the following info:
WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
worker_thread+0x30/0x350
? process_one_work+0x3c0/0x3c0
kthread+0xe6/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
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/223f3c51ab163852dd4819d357dcf33039929434
- https://git.kernel.org/stable/c/2486ab434b2c2a14e9237296db00b1e1b7ae3273
- https://git.kernel.org/stable/c/94c6ac22abcdede72bfaa0f4c22fb370891f4002
- https://git.kernel.org/stable/c/ac3ecb7760c750c8e4fc09c719241d8e6e88028c
- https://git.kernel.org/stable/c/cb6f141ae705af0101e819065a79e6d029f6e393
- https://git.kernel.org/stable/c/cd84ea3920aef936c559b63099ef0013ce6b2325
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix memory leak in error flow for subscribe event routine In case the second xa_insert() fails, the obj_event is not released. Fix the error unwind flow to free that memory to avoid a memory leak.
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/0174a89663a5ef83617da15bf24c0af2f62b6c7f
- https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d
- https://git.kernel.org/stable/c/414b4e8738484379f18d6c4e780787c80dbf8a2c
- https://git.kernel.org/stable/c/8dd392e352d3269938fea32061a74655a613f929
- https://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5
- https://git.kernel.org/stable/c/d66498507801fd9a20307a15a0814a0a016c3cde
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
inet_csk_destroy_sock+0x55/0x110
__tcp_close+0x279/0x470
tcp_close+0x1f/0x60
inet_release+0x3f/0x80
__sock_release+0x3d/0xb0
sock_close+0x11/0x20
__fput+0x92/0x250
task_work_run+0x6a/0xa0
do_exit+0x33b/0xb60
do_group_exit+0x2f/0xa0
get_signal+0xb6/0x950
arch_do_signal_or_restart+0xac/0x2a0
exit_to_user_mode_prepare+0xa9/0x200
syscall_exit_to_user_mode+0x12/0x30
do_syscall_64+0x46/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
kthread+0xe6/0x110
ret_from_fork+0x22/0x30
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/6d03722c34d9603df325f67c6d30dc1b7b3c6067
- https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8
- https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047
- https://git.kernel.org/stable/c/d0b85dfc6f01d26808e2576c6537c131b590e270
- https://git.kernel.org/stable/c/de3a8d8fab0710186f7864ec812836d8d70da3c9
- https://git.kernel.org/stable/c/f677328f05f52d535cbdc15cb04476db49477eb4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init The reference counting issue happens in several error handling paths on a refcounted object "nc->dmac". In these paths, the function simply returns the error code, forgetting to balance the reference count of "nc->dmac", increased earlier by dma_request_channel(), which may cause refcount leaks. Fix it by decrementing the refcount of specific object in those error paths.
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/0856bf27057561f42b37df111603cf5a0d040294
- https://git.kernel.org/stable/c/8baea2b96fa90af8d0f937caf4cf2105ee094d93
- https://git.kernel.org/stable/c/9843c9c98f26c6ad843260b19bfdaa2598f2ae1e
- https://git.kernel.org/stable/c/9b08d211db4c447eb1a07df65e45e0aa772e0fa6
- https://git.kernel.org/stable/c/a3587259ae553e41d1ce8c7435351a5d6b299a11
- https://git.kernel.org/stable/c/f1694169f3674cdf7553aed06864254635679878
- https://git.kernel.org/stable/c/fe0e2ce5c87e9c0b9485ff566362030aa55972cf
- https://git.kernel.org/stable/c/fecbd4a317c95d73c849648c406bcf1b6a0ec1cf
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix reference leak in tegra_dsi_ganged_probe The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add put_device() call to fix this.
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/0e2f4e434e71dffd1085c3dccd676514bd71d316
- https://git.kernel.org/stable/c/1e06710c43a090f14bb67714265a01cd1d7a37c5
- https://git.kernel.org/stable/c/221e3638feb8bc42143833c9a704fa89b6c366bb
- https://git.kernel.org/stable/c/2d6ae8b747fe55f54de4a4441d636974aa53f56a
- https://git.kernel.org/stable/c/5e8fdb6392d945d33fef959eab73f8c34bc0a63b
- https://git.kernel.org/stable/c/852c1f5f3119a38ee68e319bab10277fc1ab06b7
- https://git.kernel.org/stable/c/a725070701883fe62266ee6d2f31d67e6cdd31df
- https://git.kernel.org/stable/c/cd78b74031cbc94133965f1017deb822657fc1a6
- https://git.kernel.org/stable/c/f3c99c686e098300c246e5e8a1474133e3dacb05
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix abort all task initialization
In pm80xx_send_abort_all(), the n_elem field of the ccb used is not
initialized to 0. This missing initialization sometimes lead to the task
completion path seeing the ccb with a non-zero n_elem resulting in the
execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),
causing a crash such as:
[ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280
[ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012
[ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0
[ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0
[ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b
[ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000
[ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000
[ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000
[ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0
[ 197.762656] Call Trace:
[ 197.765127]
[ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]
[ 197.772364] ? do_raw_spin_unlock+0x54/0x220
[ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]
[ 197.782406] process_oq+0xe85/0x7890 [pm80xx]
[ 197.786817] ? lock_acquire+0x194/0x490
[ 197.790697] ? handle_irq_event+0x10e/0x1b0
[ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]
[ 197.800378] ? __wake_up_bit+0x100/0x100
[ 197.804340] ? lock_is_held_type+0x98/0x110
[ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx]
[ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0
[ 197.818785] __do_softirq+0x1b5/0x82d
[ 197.822485] ? do_raw_spin_unlock+0x54/0x220
[ 197.826799] __irq_exit_rcu+0x17e/0x1e0
[ 197.830678] irq_exit_rcu+0xa/0x20
[ 197.834114] common_interrupt+0x78/0x90
[ 197.840051]
[ 197.844236]
[ 197.848397] asm_common_interrupt+0x1e/0x40
Avoid this issue by always initializing the ccb n_elem field to 0 in
pm8001_send_abort_all(), pm8001_send_read_log() and
pm80xx_send_abort_all().
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/16cd02e0951b520bef324adb9a35afcc92501caf
- https://git.kernel.org/stable/c/1824a21b2cedc5774a5adfa74f5f7b90472d8677
- https://git.kernel.org/stable/c/279f318bd7d6e04e6e0bc7b8cd8e190da8fa37a4
- https://git.kernel.org/stable/c/326d894adf89f3c707b7784becbe241830daaab6
- https://git.kernel.org/stable/c/765674e3b30121782a2b792684554baa48c61f5e
- https://git.kernel.org/stable/c/7f12845c8389855dbcc67baa068b6832dc4a396e
- https://git.kernel.org/stable/c/9914461db82caee6c519acfbe10a86fe11bcdeca
- https://git.kernel.org/stable/c/c8db786858d895ac58342f67767b4999ae6538fa
- https://git.kernel.org/stable/c/d6ec4471550cc53e96485a7124c5891e6a38d1c3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dax: make sure inodes are flushed before destroy cache A bug can be triggered by following command $ modprobe nd_pmem && modprobe -r nd_pmem [ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown() [ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node) [ 10.062433] Call Trace: [ 10.062673] dump_stack_lvl+0x34/0x44 [ 10.062865] slab_err+0x90/0xd0 [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0 [ 10.063848] kmem_cache_destroy+0x4a/0x110 [ 10.064058] __x64_sys_delete_module+0x265/0x300 This is caused by dax_fs_exit() not flushing inodes before destroy cache. To fix this issue, call rcu_barrier() before destroy cache.
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/770d42fff12d8595adda9025a0b92091f543e775
- https://git.kernel.org/stable/c/a7e8de822e0b1979f08767c751f6c8a9c1d4ad86
- https://git.kernel.org/stable/c/b786abe7c67c6ef71410c8e23292b3091d616ad1
- https://git.kernel.org/stable/c/e2951eaa9398415ac054b7bd80b8163b6838ead4
- https://git.kernel.org/stable/c/ec376f5c11c88c0215d173599db8449cd4196759
- https://git.kernel.org/stable/c/f2a1e0eb70c2d954176c07d75d28742bde30e9f3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()： If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put().
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/19aa3c98ed7b2616e105946cec804f897837ab84
- https://git.kernel.org/stable/c/261041097ab3470f1120b7733cbf472712304d1e
- https://git.kernel.org/stable/c/31cdf7897dba1f096b74f69d840f0575b8cdb9ae
- https://git.kernel.org/stable/c/41ed61364285ff38bbbe9ca8a45c8372ba72921d
- https://git.kernel.org/stable/c/6a4760463dbc6b603690938c468839985189ce0a
- https://git.kernel.org/stable/c/879356a6a05559582b0a7895d86d2d4359745c08
- https://git.kernel.org/stable/c/c32f6b6196b6efc1c68990dfeaac36fb8eb3b8e1
- https://git.kernel.org/stable/c/db3a61ef8e6aef3b888baa6a85926c2230c2cc56
- https://git.kernel.org/stable/c/ffb8e92b4cef92bd25563cf3d8b4489eb22bc61f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix this by adding a NULL check of mode. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code.
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/19a7eba284790cfbba2945deb2363cf03ce41648
- https://git.kernel.org/stable/c/2c729dec8c1e3e2892fde5ce8181553860914e74
- https://git.kernel.org/stable/c/57f4ad5e286fe4599c8fc63cf89f85f9eec7f9c9
- https://git.kernel.org/stable/c/588a70177df3b1777484267584ef38ab2ca899a2
- https://git.kernel.org/stable/c/639b3b9def0a6a3f316a195d705d14113236e89c
- https://git.kernel.org/stable/c/bdc7429708a0772d90c208975694f7c2133b1202
- https://git.kernel.org/stable/c/f4eaa999fec78dec2a9c2d797438e05cbffb125b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix uninit value bugs Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization. In htc_connect_service() svc_meta_len and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svc_meta_len to 0. htc_issue_send() does not initialize htc_frame_hdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy Fail logs: BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00
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/0b700f7d06492de34964b6f414120043364f8191
- https://git.kernel.org/stable/c/11f11ac281f0c0b363d2940204f28bae0422ed71
- https://git.kernel.org/stable/c/4d244b731188e0b63fc40a9d2dec72e9181fb37c
- https://git.kernel.org/stable/c/5abf2b761b998063f5e2bae93fd4ab10e2a80f10
- https://git.kernel.org/stable/c/5c2a6a8daa17a3f65b38b9a5574bb362c13fa1d9
- https://git.kernel.org/stable/c/7da6169b6ebb75816b57be3beb829afa74f3b4b6
- https://git.kernel.org/stable/c/d1e0df1c57bd30871dd1c855742a7c346dbca853
- https://git.kernel.org/stable/c/e352acdd378e9263cc4c6018e588f2dac7161d07
- https://git.kernel.org/stable/c/ee4222052a76559c20e821bc3519cefb58b6d3e9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs: Fix error handling in mxs_sgtl5000_probe This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. For example, when codec_np is NULL, saif_np[0] and saif_np[1] are not NULL, it will cause leaks. of_node_put() will check if the node pointer is NULL, so we can call it directly to release the refcount of regular pointers.
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/44acdaf7acb60054d872bed18ce0e7db8ce900ce
- https://git.kernel.org/stable/c/67e12f1cb2f97468c12b59e21975eaa0f332e7d2
- https://git.kernel.org/stable/c/6ae0a4d8fec551ec581d620f0eb1fe31f755551c
- https://git.kernel.org/stable/c/790d2628e3fcc819d8f5572eb5615113fb2e727a
- https://git.kernel.org/stable/c/86b6cf989437e694fd0a15782b5a513853a739e0
- https://git.kernel.org/stable/c/8d880226c86f37624e2a5f3c6d92ac0ec3375f96
- https://git.kernel.org/stable/c/d2923b48d99fe663cb93d8b481c93299fcd68656
- https://git.kernel.org/stable/c/f16ad2c0e22687f80e5981c67374023f51c204b9
- https://git.kernel.org/stable/c/f8d38056bcd220ea6f0802a5586d1a12ebcce849
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Add missing of_node_put() in at91sam9g20ek_audio_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
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/0325193cf40dc3a6e27d55a5b98680936deebcd0
- https://git.kernel.org/stable/c/32e6ceb05f36432811753852c674a301f944a24b
- https://git.kernel.org/stable/c/4793a02deb31b71b3984abc67bf1011a03c13b18
- https://git.kernel.org/stable/c/662ee5ac6b451aa5a27b8eebd397f2f5c7f42cec
- https://git.kernel.org/stable/c/81f266396237cea09a8c6322a6a78535f06ed345
- https://git.kernel.org/stable/c/a0bc36b247dcf4d21bf820bfc4bcbaf7f6cf19b5
- https://git.kernel.org/stable/c/b0c56a0071116a37c24df998166c22a7e4684626
- https://git.kernel.org/stable/c/f590797fa3c1bccdd19e55441592a23b46aef449
- https://git.kernel.org/stable/c/f8b7b9a0594715ecfbe6f18db2328d992242654a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUED If the callback 'start_streaming' fails, then all queued buffers in the driver should be returned with state 'VB2_BUF_STATE_QUEUED'. Currently, they are returned with 'VB2_BUF_STATE_ERROR' which is wrong. Fix this. This also fixes the warning: [ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6 [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14 [ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT) [ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common] [ 65.592395] sp : ffff800012bc3ad0 [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8 [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612 [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0 [ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78 [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228 [ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78 [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880 [ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0 [ 65.598940] Call trace: [ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common] [ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2] [ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2] [ 65.601103] v4l_streamon+0x3c/0x50 [videodev] [ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev] [ 65.601977] video_usercopy+0x320/0x828 [videodev] [ 65.602419] video_ioctl2+0x3c/0x58 [videodev] [ 65.602830] v4l2_ioctl+0x60/0x90 [videodev] [ 65.603227] __arm64_sys_ioctl+0xa8/0xe0 [ 65.603576] invoke_syscall+0x54/0x118 [ 65.603911] el0_svc_common.constprop.3+0x84/0x100 [ 65.604332] do_el0_svc+0x34/0xa0 [ 65.604625] el0_svc+0x1c/0x50 [ 65.604897] el0t_64_sync_handler+0x88/0xb0 [ 65.605264] el0t_64_sync+0x16c/0x170 [ 65.605587] ---[ end trace 578e0ba07742170d ]---
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/03054f22d5abd80ad89547512c2bfbfb2714d3ed
- https://git.kernel.org/stable/c/2874122ca4ca74adec72d6d6bf8828228ec20f15
- https://git.kernel.org/stable/c/3cc050df73e3d973f1870a8dc0e177e77670bc7f
- https://git.kernel.org/stable/c/4d68603cc4382174bc1e7d532e10675c48c6b257
- https://git.kernel.org/stable/c/a09e9882800fdfc5aab93f77c3f0132071d2191b
- https://git.kernel.org/stable/c/f04a520a422222fc921bf035dc67414c500a286a
- https://git.kernel.org/stable/c/f66e6fd1488d26229f11d86616de1b658c70fa8a
- https://git.kernel.org/stable/c/fbe04b49a54e31f4321d632270207f0e6304cd16
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA:
firewire-lib: Add support for deferred transaction") while 'deferrable'
flag can be uninitialized for non-control/notify AV/C transactions.
UBSAN reports it:
kernel: ================================================================================
kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9
kernel: load of value 158 is not a valid value for type '_Bool'
kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu
kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019
kernel: Call Trace:
kernel:
kernel: show_stack+0x52/0x58
kernel: dump_stack_lvl+0x4a/0x5f
kernel: dump_stack+0x10/0x12
kernel: ubsan_epilogue+0x9/0x45
kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49
kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]
kernel: fcp_response+0x28/0x30 [snd_firewire_lib]
kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core]
kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci]
kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]
kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core]
kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]
kernel: tasklet_action_common.constprop.0+0xea/0xf0
kernel: tasklet_action+0x22/0x30
kernel: __do_softirq+0xd9/0x2e3
kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0
kernel: do_softirq+0x75/0xa0
kernel:
kernel:
kernel: __local_bh_enable_ip+0x50/0x60
kernel: irq_forced_thread_fn+0x7e/0x90
kernel: irq_thread+0xba/0x190
kernel: ? irq_thread_fn+0x60/0x60
kernel: kthread+0x11e/0x140
kernel: ? irq_thread_check_affinity+0xf0/0xf0
kernel: ? set_kthread_struct+0x50/0x50
kernel: ret_from_fork+0x22/0x30
kernel:
kernel: ================================================================================
This commit fixes the bug. The bug has no disadvantage for the non-
control/notify AV/C transactions since the flag has an effect for AV/C
response with INTERIM (0x0f) status which is not used for the transactions
in AV/C general specification.
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/39d2c4a33dc1b4402cec68a3c8f82c6588b6edce
- https://git.kernel.org/stable/c/60e5d391805d70458a01998de00d0c28cba40bf3
- https://git.kernel.org/stable/c/7025f40690a235a118c87674cfb93072694aa66d
- https://git.kernel.org/stable/c/7e6f5786621df060f8296f074efd275eaf20361a
- https://git.kernel.org/stable/c/99582e4b19f367fa95bdd150b3034d7ce8113342
- https://git.kernel.org/stable/c/b2b65c9013dc28836d82e25d0f0c94d794a14aba
- https://git.kernel.org/stable/c/bf0cd60b7e33cf221fbe1114e4acb2c828b0af0d
- https://git.kernel.org/stable/c/d07e4bbaff6fbba6f70c04b092ea7d9afcdf392e
- https://git.kernel.org/stable/c/eab74c41612083bd627b60da650e19234e4f1051
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: usb: go7007: s2250-board: fix leak in probe() Call i2c_unregister_device(audio) on this error path.
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/14cd5a8e61c654828a1f1056d56f0b0a524d2c69
- https://git.kernel.org/stable/c/44973633b0064c46083833b55dd0a45e6235f8ca
- https://git.kernel.org/stable/c/67e4550ecd6164bfbdff54c169e5bbf9ccfaf14d
- https://git.kernel.org/stable/c/895364fa97e60749855f789bc4568883fc7a8b39
- https://git.kernel.org/stable/c/948ad5e5624487079c24cb5c81c74ddd02832440
- https://git.kernel.org/stable/c/a97130cd5b0c00eec169b10a16d922b9ea67324a
- https://git.kernel.org/stable/c/b5470f3efa530b10296257bb578ce4b1769e9a04
- https://git.kernel.org/stable/c/b7dd177225355da55f8d80d8e568928e0eec3608
- https://git.kernel.org/stable/c/bbdd0e15738336e6b1208304ae98525117877bbd
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix missing free nid in f2fs_handle_failed_inode
This patch fixes xfstests/generic/475 failure.
[ 293.680694] F2FS-fs (dm-1): May loss orphan inode, run fsck to fix.
[ 293.685358] Buffer I/O error on dev dm-1, logical block 8388592, async page read
[ 293.691527] Buffer I/O error on dev dm-1, logical block 8388592, async page read
[ 293.691764] sh (7615): drop_caches: 3
[ 293.691819] sh (7616): drop_caches: 3
[ 293.694017] Buffer I/O error on dev dm-1, logical block 1, async page read
[ 293.695659] sh (7618): drop_caches: 3
[ 293.696979] sh (7617): drop_caches: 3
[ 293.700290] sh (7623): drop_caches: 3
[ 293.708621] sh (7626): drop_caches: 3
[ 293.711386] sh (7628): drop_caches: 3
[ 293.711825] sh (7627): drop_caches: 3
[ 293.716738] sh (7630): drop_caches: 3
[ 293.719613] sh (7632): drop_caches: 3
[ 293.720971] sh (7633): drop_caches: 3
[ 293.727741] sh (7634): drop_caches: 3
[ 293.730783] sh (7636): drop_caches: 3
[ 293.732681] sh (7635): drop_caches: 3
[ 293.732988] sh (7637): drop_caches: 3
[ 293.738836] sh (7639): drop_caches: 3
[ 293.740568] sh (7641): drop_caches: 3
[ 293.743053] sh (7640): drop_caches: 3
[ 293.821889] ------------[ cut here ]------------
[ 293.824654] kernel BUG at fs/f2fs/node.c:3334!
[ 293.826226] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 293.828713] CPU: 0 PID: 7653 Comm: umount Tainted: G OE 5.17.0-rc1-custom #1
[ 293.830946] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 293.832526] RIP: 0010:f2fs_destroy_node_manager+0x33f/0x350 [f2fs]
[ 293.833905] Code: e8 d6 3d f9 f9 48 8b 45 d0 65 48 2b 04 25 28 00 00 00 75 1a 48 81 c4 28 03 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b
[ 293.837783] RSP: 0018:ffffb04ec31e7a20 EFLAGS: 00010202
[ 293.839062] RAX: 0000000000000001 RBX: ffff9df947db2eb8 RCX: 0000000080aa0072
[ 293.840666] RDX: 0000000000000000 RSI: ffffe86c0432a140 RDI: ffffffffc0b72a21
[ 293.842261] RBP: ffffb04ec31e7d70 R08: ffff9df94ca85780 R09: 0000000080aa0072
[ 293.843909] R10: ffff9df94ca85700 R11: ffff9df94e1ccf58 R12: ffff9df947db2e00
[ 293.845594] R13: ffff9df947db2ed0 R14: ffff9df947db2eb8 R15: ffff9df947db2eb8
[ 293.847855] FS: 00007f5a97379800(0000) GS:ffff9dfa77c00000(0000) knlGS:0000000000000000
[ 293.850647] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 293.852940] CR2: 00007f5a97528730 CR3: 000000010bc76005 CR4: 0000000000370ef0
[ 293.854680] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 293.856423] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 293.858380] Call Trace:
[ 293.859302]
[ 293.860311] ? ttwu_do_wakeup+0x1c/0x170
[ 293.861800] ? ttwu_do_activate+0x6d/0xb0
[ 293.863057] ? _raw_spin_unlock_irqrestore+0x29/0x40
[ 293.864411] ? try_to_wake_up+0x9d/0x5e0
[ 293.865618] ? debug_smp_processor_id+0x17/0x20
[ 293.866934] ? debug_smp_processor_id+0x17/0x20
[ 293.868223] ? free_unref_page+0xbf/0x120
[ 293.869470] ? __free_slab+0xcb/0x1c0
[ 293.870614] ? preempt_count_add+0x7a/0xc0
[ 293.871811] ? __slab_free+0xa0/0x2d0
[ 293.872918] ? __wake_up_common_lock+0x8a/0xc0
[ 293.874186] ? __slab_free+0xa0/0x2d0
[ 293.875305] ? free_inode_nonrcu+0x20/0x20
[ 293.876466] ? free_inode_nonrcu+0x20/0x20
[ 293.877650] ? debug_smp_processor_id+0x17/0x20
[ 293.878949] ? call_rcu+0x11a/0x240
[ 293.880060] ? f2fs_destroy_stats+0x59/0x60 [f2fs]
[ 293.881437] ? kfree+0x1fe/0x230
[ 293.882674] f2fs_put_super+0x160/0x390 [f2fs]
[ 293.883978] generic_shutdown_super+0x7a/0x120
[ 293.885274] kill_block_super+0x27/0x50
[ 293.886496] kill_f2fs_super+0x7f/0x100 [f2fs]
[ 293.887806] deactivate_locked_super+0x35/0xa0
[ 293.889271] deactivate_super+0x40/0x50
[ 293.890513] cleanup_mnt+0x139/0x190
[ 293.891689] __cleanup_mnt+0x12/0x20
[ 293.892850] task_work_run+0x64/0xa0
[ 293.894035] exit_to_user_mode_prepare+0x1b7/
---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/005f9cdab70c915702254c5eb67a8efced80e821
- https://git.kernel.org/stable/c/1a11a873749c6375bb668953fa1a196d8538d26b
- https://git.kernel.org/stable/c/2fef99b8372c1ae3d8445ab570e888b5a358dbe9
- https://git.kernel.org/stable/c/8579b413af100ec5f3592bd6cf11559312b380c0
- https://git.kernel.org/stable/c/aa80bf73e3b3fb7026d343c77b3ddc849e26a095
- https://git.kernel.org/stable/c/d1eaaf6cadedf638e17017b0a04d56308405ac10
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: block: don't delete queue kobject before its children kobjects aren't supposed to be deleted before their child kobjects are deleted. Apparently this is usually benign; however, a WARN will be triggered if one of the child kobjects has a named attribute group: sysfs group 'modes' not found for kobject 'crypto' WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80 ... Call Trace: sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312 __kobject_del+0x20/0x80 lib/kobject.c:611 kobject_cleanup+0xa4/0x140 lib/kobject.c:696 kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x53/0x70 lib/kobject.c:753 blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159 blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962 del_gendisk+0x117/0x250 block/genhd.c:610 Fix this by moving the kobject_del() and the corresponding kobject_uevent() to the correct place.
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/0b5924a14d64487ebd51127b0358d06066ef5384
- https://git.kernel.org/stable/c/0f69288253e9fc7c495047720e523b9f1aba5712
- https://git.kernel.org/stable/c/3d7e32c8da45957326f56937e0471c686d1a7711
- https://git.kernel.org/stable/c/84fe3ca6e7910beb47ec13509d484f84fa2a41ad
- https://git.kernel.org/stable/c/b2001eb10f59363da930cdd6e086a2861986fa18
- https://git.kernel.org/stable/c/cf0cb8686e55d9c022944bc6ba9e19e832889e83
- https://git.kernel.org/stable/c/efaa0e969261e97c1fdd8e0338e5dd3ba5b9219c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that the CLM blob is released in the device remove path.
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/0347bdfdb1529994ac3a4cb425087c477a74eb2c
- https://git.kernel.org/stable/c/4e0b507597e1a86e9b4c056ab274c427223cf8ea
- https://git.kernel.org/stable/c/5e90f0f3ead014867dade7a22f93958119f5efab
- https://git.kernel.org/stable/c/a88337a06966f2d733ad9a97714b874469133f14
- https://git.kernel.org/stable/c/d0ab87f8dcdfe72dc1d763be3392c1fc51a1ace2
- https://git.kernel.org/stable/c/f3820ddaf4f3ac80c7401ccc6a42e663c9317f31
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEM
Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns
-ENOMEM because it leads to a NULL pointer dereference bug.
The dmesg says:
[ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12
[ T1387] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ T1387] #PF: supervisor read access in kernel mode
[ T1387] #PF: error_code(0x0000) - not-present page
[ T1387] PGD 0 P4D 0
[ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: G W 5.17.0-rc4-superb-owl-00055-g80d47f5de5e3
[ T1387] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021
[ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80
[ T1387] Code: [... snip ...]
[ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246
[ T1387] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0
[ T1387] RBP: 00000000fffffff4 R08: 0000000000000000 R09: 0000000000000000
[ T1387] R10: 0000000000000000 R11: ffffc90002b874d0 R12: 0000000000000001
[ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828
[ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000
[ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0
[ T1387] PKRU: 55555554
[ T1387] Call Trace:
[ T1387]
[ T1387] cl_stream_prepare+0x10a/0x120 [snd_sof_intel_hda_common 146addf995b9279ae7f509621078cccbe4f875e1]
[... snip ...]
[ T1387]
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/01df5f7627f1624d6bb0b8c0870a569b32adfbf8
- https://git.kernel.org/stable/c/09eca322d4118dc26570ca6100fa34e59e5a5143
- https://git.kernel.org/stable/c/0c307349fe060971625b856c92f0361b8ea9a120
- https://git.kernel.org/stable/c/67f7bd9ff9079c1ee2de58e024fb582905c74c16
- https://git.kernel.org/stable/c/b6094744e261083d3790c3def770ebf5060d383b
- https://git.kernel.org/stable/c/b7fb0ae09009d076964afe4c1a2bde1ee2bd88a9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_scan_medium
If an error is returned in jffs2_scan_eraseblock() and some memory
has been added to the jffs2_summary *s, we can observe the following
kmemleak report:
--------------------------------------------
unreferenced object 0xffff88812b889c40 (size 64):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
hex dump (first 32 bytes):
40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.
00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................
backtrace:
[] __kmalloc+0x613/0x910
[] jffs2_sum_add_dirent_mem+0x5c/0xa0
[] jffs2_scan_medium.cold+0x36e5/0x4794
[] jffs2_do_mount_fs.cold+0xa7/0x2267
[] jffs2_do_fill_super+0x383/0xc30
[] jffs2_fill_super+0x2ea/0x4c0
[] mtd_get_sb+0x254/0x400
[] mtd_get_sb_by_nr+0x4f/0xd0
[] get_tree_mtd+0x498/0x840
[] jffs2_get_tree+0x25/0x30
[] vfs_get_tree+0x8d/0x2e0
[] path_mount+0x50f/0x1e50
[] do_mount+0x107/0x130
[] __se_sys_mount+0x1c5/0x2f0
[] __x64_sys_mount+0xc7/0x160
[] do_syscall_64+0x45/0x70
unreferenced object 0xffff888114b54840 (size 32):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
hex dump (first 32 bytes):
c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............
00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.
backtrace:
[] kmem_cache_alloc_trace+0x584/0x880
[] jffs2_sum_add_inode_mem+0x54/0x90
[] jffs2_scan_medium.cold+0x4481/0x4794
[...]
unreferenced object 0xffff888114b57280 (size 32):
comm "mount", pid 692, jiffies 4294838393 (age 34.357s)
hex dump (first 32 bytes):
10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............
00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.
backtrace:
[] kmem_cache_alloc_trace+0x584/0x880
[] jffs2_sum_add_xattr_mem+0x54/0x90
[] jffs2_scan_medium.cold+0x298c/0x4794
[...]
unreferenced object 0xffff8881116cd510 (size 16):
comm "mount", pid 692, jiffies 4294838395 (age 34.355s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.
backtrace:
[] kmem_cache_alloc_trace+0x584/0x880
[] jffs2_sum_add_xref_mem+0x54/0x90
[] jffs2_scan_medium.cold+0x3a20/0x4794
[...]
--------------------------------------------
Therefore, we should call jffs2_sum_reset_collected(s) on exit to
release the memory added in s. In addition, a new tag "out_buf" is
added to prevent the NULL pointer reference caused by s being NULL.
(thanks to Zhang Yi for this analysis)
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/455f4a23490bfcbedc8e5c245c463a59b19e5ddd
- https://git.kernel.org/stable/c/51dbb5e36d59f62e34d462b801c1068248149cfe
- https://git.kernel.org/stable/c/52ba0ab4f0a606f02a6163493378989faa1ec10a
- https://git.kernel.org/stable/c/82462324bf35b6b553400af1c1aa265069cee28f
- https://git.kernel.org/stable/c/9b0c69182f09b70779817af4dcf89780955d5c4c
- https://git.kernel.org/stable/c/9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df
- https://git.kernel.org/stable/c/b26bbc0c122cad038831f226a4cb4de702225e16
- https://git.kernel.org/stable/c/b36bccb04e14cc0c1e2d0e92d477fe220314fad6
- https://git.kernel.org/stable/c/e711913463af916d777a4873068f415f1fe2ad33
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_mount_fs
If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,
we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff88811b25a640 (size 64):
comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmem_cache_alloc_trace+0x584/0x880
[] jffs2_sum_init+0x86/0x130
[] jffs2_do_mount_fs+0x798/0xac0
[] jffs2_do_fill_super+0x383/0xc30
[] jffs2_fill_super+0x2ea/0x4c0
[...]
unreferenced object 0xffff88812c760000 (size 65536):
comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
hex dump (first 32 bytes):
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
backtrace:
[] __kmalloc+0x6b9/0x910
[] jffs2_sum_init+0xd7/0x130
[] jffs2_do_mount_fs+0x798/0xac0
[] jffs2_do_fill_super+0x383/0xc30
[] jffs2_fill_super+0x2ea/0x4c0
[...]
--------------------------------------------
This is because the resources allocated in jffs2_sum_init() are not
released. Call jffs2_sum_exit() to release these resources to solve
the 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/0978e9af4559a171ac7a74a1b3ef21804b0a0fa9
- https://git.kernel.org/stable/c/2a9d8184458562e6bf2f40d0e677fc85e2dd3834
- https://git.kernel.org/stable/c/4392e8aeebc5a4f8073620bccba7de1b1f6d7c88
- https://git.kernel.org/stable/c/5f34310d1376ca5b2ed798258def2c2ab3cc6699
- https://git.kernel.org/stable/c/607d3aab7349f18e0d9dba4100d09d16fe27caca
- https://git.kernel.org/stable/c/9a0f6610c7daedd2eace430beeb08a8b7ac80699
- https://git.kernel.org/stable/c/c94128470e6fe53d9bd9d16d2d3271813f9d37af
- https://git.kernel.org/stable/c/d051cef784de4d54835f6b6836d98a8f6935772c
- https://git.kernel.org/stable/c/dbe0d0521eaa6a3d235517319266c539bb5c5112
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent integer overflow on 32 bit systems On a 32 bit system, the "len * sizeof(*p)" operation can have an integer overflow.
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/23a9dbbe0faf124fc4c139615633b9d12a3a89ef
- https://git.kernel.org/stable/c/303cd6173dce0a28d26526c77814eb90a41bd898
- https://git.kernel.org/stable/c/3a2789e8ccb4a3e2a631f6817a2d3bb98b8c4fd8
- https://git.kernel.org/stable/c/79b1c54fc6ce09ee0d5fe088bb3de26ae2150e3c
- https://git.kernel.org/stable/c/7af164fa2f1abc577d357d22d83a2f3490875d7e
- https://git.kernel.org/stable/c/ce1aa09cc14ed625104acc2d487bd92b9a88efe2
- https://git.kernel.org/stable/c/e4195d27306ea468a6dc3a27af6f586709951229
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent underflow in nfssvc_decode_writeargs() Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len' Change the type to unsigned to prevent this 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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: f2fs: quota: fix loop condition at f2fs_quota_sync() cnt should be passed to sb_has_quota_active() instead of type to check active quota properly. Moreover, when the type is -1, the compiler with enough inline knowledge can discard sb_has_quota_active() check altogether, causing a NULL pointer dereference at the following inode_lock(dqopt->files[cnt]): [ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 2.796024] Mem abort info: [ 2.796025] ESR = 0x96000005 [ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.796029] SET = 0, FnV = 0 [ 2.796031] EA = 0, S1PTW = 0 [ 2.796032] Data abort info: [ 2.796034] ISV = 0, ISS = 0x00000005 [ 2.796035] CM = 0, WnR = 0 [ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000 [ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000 [ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1 [ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT) [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 2.796065] pc : down_write+0x28/0x70 [ 2.796070] lr : f2fs_quota_sync+0x100/0x294 [ 2.796071] sp : ffffffa3f48ffc30 [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000 [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80 [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001 [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000 [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110 [ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038 [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0 [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0 [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000 [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948 [ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0 [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001 [ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0 [ 2.796098] Call trace: [ 2.796100] down_write+0x28/0x70 [ 2.796102] f2fs_quota_sync+0x100/0x294 [ 2.796104] block_operations+0x120/0x204 [ 2.796106] f2fs_write_checkpoint+0x11c/0x520 [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34 [ 2.796109] issue_checkpoint_thread+0x6c/0xb8 [ 2.796112] kthread+0x138/0x414 [ 2.796114] ret_from_fork+0x10/0x18 [ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02) [ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]--- [ 2.800116] Kernel panic - not syncing: Fatal exception [ 2.800120] SMP: stopping secondary CPUs
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/680af5b824a52faa819167628665804a14f0e0df
- https://git.kernel.org/stable/c/724469814d805820cd37ea789769dba94123ff1a
- https://git.kernel.org/stable/c/e58ee6bd939b773675240f5d0f5b88a367c037c4
- https://git.kernel.org/stable/c/e9ebf1e8fc50b6a9336f9aea1082d7845e568d0e
- https://git.kernel.org/stable/c/f1d5946d47c0827bae39e1537959ce8d6f0224c5
- https://git.kernel.org/stable/c/f9156db0987f1b426015d56505e2c58dee70c90d
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: tpm: use try_get_ops() in tpm-space.c As part of the series conversion to remove nested TPM operations: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ exposure of the chip->tpm_mutex was removed from much of the upper level code. In this conversion, tpm2_del_space() was missed. This didn't matter much because it's usually called closely after a converted operation, so there's only a very tiny race window where the chip can be removed before the space flushing is done which causes a NULL deref on the mutex. However, there are reports of this window being hit in practice, so fix this by converting tpm2_del_space() to use tpm_try_get_ops(), which performs all the teardown checks before acquring the mutex.
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/476ddd23f818fb94cf86fb5617f3bb9a7c92113d
- https://git.kernel.org/stable/c/5b1d2561a03e534064b51c50c774657833d3d2cf
- https://git.kernel.org/stable/c/95193d12f10a8a088843b25e0f5fe1d83ec6b079
- https://git.kernel.org/stable/c/ba84f9a48366dcc3cdef978599433efe101dd5bd
- https://git.kernel.org/stable/c/eda1662cce964c8a65bb86321f8d9cfa6e9ceaab
- https://git.kernel.org/stable/c/fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
tpm: fix reference counting for struct tpm_chip
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
refcount_t: addition on 0; use-after-free.
Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
Hardware name: BCM2711
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xc4/0xd8)
[] (dump_stack) from [] (__warn+0x104/0x108)
[] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8)
[] (warn_slowpath_fmt) from [] (kobject_get+0xa0/0xa4)
[] (kobject_get) from [] (tpm_try_get_ops+0x14/0x54 [tpm])
[] (tpm_try_get_ops [tpm]) from [] (tpm_common_write+0x38/0x60 [tpm])
[] (tpm_common_write [tpm]) from [] (vfs_write+0xc4/0x3c0)
[] (vfs_write) from [] (ksys_write+0x58/0xcc)
[] (ksys_write) from [] (ret_fast_syscall+0x0/0x4c)
Exception stack(0xc226bfa8 to 0xc226bff0)
bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000
bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684
bfe0: 0000006c beafe648 0001056c b6eb6944
---[ end trace d4b8409def9b8b1f ]---
The reason for this warning is the attempt to get the chip->dev reference
in tpm_common_write() although the reference counter is already zero.
Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the
extra reference used to prevent a premature zero counter is never taken,
because the required TPM_CHIP_FLAG_TPM2 flag is never set.
Fix this by moving the TPM 2 character device handling from
tpm_chip_alloc() to tpm_add_char_device() which is called at a later point
in time when the flag has been set in case of TPM2.
Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
already introduced function tpm_devs_release() to release the extra
reference but did not implement the required put on chip->devs that results
in the call of this function.
Fix this by putting chip->devs in tpm_chip_unregister().
Finally move the new implementation for the TPM 2 handling into a new
function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the
good case and error cases.
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/290e05f346d1829e849662c97e42d5ad984f5258
- https://git.kernel.org/stable/c/2f928c0d5c02dbab49e8c19d98725c822f6fc409
- https://git.kernel.org/stable/c/473a66f99cb8173c14138c5a5c69bfad04e8f9ac
- https://git.kernel.org/stable/c/662893b4f6bd466ff9e1cd454c44c26d32d554fe
- https://git.kernel.org/stable/c/6e7baf84149fb43950631415de231b3a41915aa3
- https://git.kernel.org/stable/c/7e0438f83dc769465ee663bb5dcf8cc154940712
- https://git.kernel.org/stable/c/a27ed2f3695baf15f9b34d2d7a1f9fc105539a81
- https://git.kernel.org/stable/c/cb64bd038beacb4331fe464a36c8b5481e8f51e2
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mac80211: fix potential double free on mesh join While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") fixed a memory leak on mesh leave / teardown it introduced a potential memory corruption caused by a double free when rejoining the mesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); This double free / kernel panics can be reproduced by using wpa_supplicant with an encrypted mesh (if set up without encryption via "iw" then ifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Note that typically these commands are not used / working when using wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids the memory corruption, too. The issue was first observed in an application which was not using wpa_supplicant but "Senf" instead, which implements its own calls to nl80211. Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh join function and leaving it solely up to the mesh leave to free the mesh IE.
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/12e407a8ef17623823fd0c066fbd7f103953d28d
- https://git.kernel.org/stable/c/273ebddc5fda2967492cb0b6cdd7d81cfb821b76
- https://git.kernel.org/stable/c/3bbd0000d012f92aec423b224784fbf0f7bf40f8
- https://git.kernel.org/stable/c/46bb87d40683337757a2f902fcd4244b32bb4e86
- https://git.kernel.org/stable/c/4a2d4496e15ea5bb5c8e83b94ca8ca7fb045e7d3
- https://git.kernel.org/stable/c/582d8c60c0c053684f7138875e8150d5749ffc17
- https://git.kernel.org/stable/c/5d3ff9542a40ce034416bca03864709540a36016
- https://git.kernel.org/stable/c/615716af8644813355e014314a0bc1e961250f5a
- https://git.kernel.org/stable/c/c1d9c3628ef0a0ca197595d0f9e01cd3b5dda186
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: oss: Fix PCM OSS buffer allocation overflow We've got syzbot reports hitting INT_MAX overflow at vmalloc() allocation that is called from snd_pcm_plug_alloc(). Although we apply the restrictions to input parameters, it's based only on the hw_params of the underlying PCM device. Since the PCM OSS layer allocates a temporary buffer for the data conversion, the size may become unexpectedly large when more channels or higher rates is given; in the reported case, it went over INT_MAX, hence it hits WARN_ON(). This patch is an attempt to avoid such an overflow and an allocation for too large buffers. First off, it adds the limit of 1MB as the upper bound for period bytes. This must be large enough for all use cases, and we really don't want to handle a larger temporary buffer than this size. The size check is performed at two places, where the original period bytes is calculated and where the plugin buffer size is calculated. In addition, the driver uses array_size() and array3_size() for multiplications to catch overflows for the converted period size and buffer bytes.
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/0c4190b41a69990666b4000999e27f8f1b2a426b
- https://git.kernel.org/stable/c/5ce74ff7059341d8b2f4d01c3383491df63d1898
- https://git.kernel.org/stable/c/7a40cbf3579a8e14849ba7ce46309c1992658d2b
- https://git.kernel.org/stable/c/a63af1baf0a5e11827db60e3127f87e437cab6e5
- https://git.kernel.org/stable/c/e74a069c6a7bb505f3ade141dddf85f4b0b5145a
- https://git.kernel.org/stable/c/efb6402c3c4a7c26d97c92d70186424097b6e366
- https://git.kernel.org/stable/c/fb08bf99195a87c798bc8ae1357337a981faeade
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: initialize registers in nft_do_chain() Initialize registers to avoid stack leak into userspace.
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/06f0ff82c70241a766a811ae1acf07d6e2734dcb
- https://git.kernel.org/stable/c/2c74374c2e88c7b7992bf808d9f9391f7452f9d9
- https://git.kernel.org/stable/c/4c905f6740a365464e91467aa50916555b28213d
- https://git.kernel.org/stable/c/4d28522acd1c4415c85f6b33463713a268f68965
- https://git.kernel.org/stable/c/64f24c76dd0ce53d0fa3a0bfb9aeea507c769485
- https://git.kernel.org/stable/c/88791b79a1eb2ba94e95d039243e28433583a67b
- https://git.kernel.org/stable/c/a3cc32863b175168283cb0a5fde08de6a1e27df9
- https://git.kernel.org/stable/c/dd03640529204ef4b8189fbdea08217d8d98271f
- https://git.kernel.org/stable/c/fafb904156fbb8f1dd34970cd5223e00b47c33be