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-2344-12Package update kernel-image-xenomai in branch p10
Severity:
Closed issues (443)
HIGH8.8
Уязвимость драйвера USB-устройства Xilinx (drivers/usb/gadget/udc/udc-xilinx.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:CReferences
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.8
Уязвимость функции u32_change() счетчика ссылок в компоненте net/sched ядра операционной системы 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
HIGH8.8
Уязвимость функции nft_expr_init программного обеспечения фильтрации пакетов Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0CRITICAL 9.0
CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции dx_insert_block() (fs/ext4/namei.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
Уязвимость функции bad_flp_intr ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.5
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:N/A:NReferences
HIGH7.1
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы 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.5
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:N/A:NReferences
HIGH7.1
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы 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
Уязвимость функции reserve_sfa_size() модуля openvswitch ядра операционной системы 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.0
Уязвимость звуковой подсистемы ядра операционной системы 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.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
HIGH7.1
Уязвимость функции sl_tx_timeout() в модуле drivers/net/slip.c драйвера SLIP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
HIGH7.1
Уязвимость функции vhost_net_set_backend (drivers/vhost/net.c) подкомпонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании и раскрыть защищаемую информацию
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CReferences
HIGH7.1
Уязвимость функции vmxnet3_rq_alloc_rx_buf() в модуле drivers/net/vmxnet3/vmxnet3_drv.c драйвера vmxnet3 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции 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
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
HIGH7.8
Уязвимость функции __nf_register_net_hook() в компоненте netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость компонента cifs ядра операционной системы 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
Уязвимость компонента 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 ядра операционной системы 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
Уязвимость компонента men_z188_adc ядра операционной системы 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
Уязвимость компонента RDMA ядра операционной системы 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
Уязвимость компонента configfs ядра операционной системы 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
Уязвимость компонента 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
MEDIUM5.5
Уязвимость компонента ibmvnic ядра операционной системы 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
Уязвимость компонента com20020 ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
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
Уязвимость компонента 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
Уязвимость компонента xen ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
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
Уязвимость компонента 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
HIGH7.0
Уязвимость функции nvme_async_event_work() драйвера NVMe ядра операционной системы 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
HIGH7.8
Уязвимость функции iwl_req_fw_callback() драйвера Intel Wireless WiFi Next Gen AGN ядра операционной системы 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
Уязвимость функции nvme_rdma_error_recovery_work() драйвера NVMe ядра операционной системы 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
Уязвимость функции ffs_func_eps_disable() драйвера USB gadget ядра операционной системы 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
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента pciehp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.4
Уязвимость компонента vsock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:LCVSS 2.0LOW 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:PReferences
MEDIUM4.4
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость компонента net ядра операционной системы 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
Уязвимость компонентов ipmr, ip6mr ядра операционной системы 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
Уязвимость функции bprm_stack_limits() ядра операционной системы 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
Уязвимость функции start_io_acct() модуля drivers/md/dm.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
HIGH7.8
Уязвимость функции nfc_unregister_device() модуля net/nfc/core.c подсистемы NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции radeon_fp_native_mode() модуля drivers/gpu/drm/radeon/radeon_connectors.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы 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
Уязвимость функции ___slab_alloc() модуля mm/slub.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
Уязвимость функции bond_3ad_unbind_slave() модуля drivers/net/bonding/bond_3ad.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
Уязвимость функции cx23885_initdev() модуля drivers/media/pci/cx23885/cx23885-core.c - драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы 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
Уязвимость функции rt5645_i2c_remove() модуля sound/soc/codecs/rt5645.c поддержки звука SoC ядра операционной системы 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
Уязвимость функции sco_sock_connect() модуля net/bluetooth/sco.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.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции nci_close_device() модуля net/nfc/nci/core.c поддержки реализации NFC NCI ядра операционной системы 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
Уязвимость функции tcmu_try_get_block_page() модуля drivers/target/target_core_user.c - драйвера поддержки TCM ядра операционной системы 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
Уязвимость функции 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
MEDIUM5.5
Уязвимость функции tun_dst_unclone() модуля include/net/dst_metadata.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
HIGH7.8
Уязвимость функции iio_sysfs_trigger_remove() модуля drivers/iio/trigger/iio-trig-sysfs.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
Уязвимость функции veth_xmit() модуля drivers/net/veth.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
Уязвимость функции parse_mf_symlink() модуля fs/cifs/link.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
Уязвимость функции 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
MEDIUM5.5
Уязвимость функций nla_alloc_flow_actions() и ovs_nla_free_set_action() модуля net/openvswitch/flow_netlink.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
Уязвимость функции 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
Уязвимость функции snd_pcm_lib_preallocate_proc_write() модуля sound/core/pcm_memory.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.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:PReferences
HIGH7.8
Уязвимость функции snd_pcm_attach_substream() модуля sound/core/pcm.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.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:PReferences
HIGH7.8
Уязвимость функции ext4_get_first_dir_block() модуля fs/ext4/namei.c поддержки файловой системы Ext4 ядра операционной системы 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
Уязвимость функции ieee80211_vif_use_reserved_context() модуля net/mac80211/chan.c реализации стека mac80211 ядра операционной системы 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
Уязвимость функции ubi_create_volume() модуля drivers/mtd/ubi/vmt.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_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
Уязвимость функции vmbus_add_channel_kobj() модуля drivers/hv/vmbus_drv.c драйвера поддержки гостевого режима Microsoft Hyper-V ядра операционной системы 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
Уязвимость функций 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
Уязвимость функции alloc_event_waiters() модуля drivers/gpu/drm/amd/amdkfd/kfd_events.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы 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
Уязвимость функции nbd_alloc_config() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
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
Уязвимость функции si_parse_power_table() ядра операционной системы 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
Уязвимость функции ext4_resize_begin() модуля fs/ext4/resize.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции 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
MEDIUM5.5
Уязвимость функции hdlcdev_init() модуля drivers/tty/synclink_gt.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
Уязвимость функции extcon_dev_register() модуля drivers/extcon/extcon.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
Уязвимость функции _nfs4_open_and_get_state() модуля fs/nfs/nfs4proc.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
Уязвимость функции rpcrdma_is_bcall() модуля net/sunrpc/xprtrdma/rpc_rdma.c реализации протокола RPC ядра операционной системы 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
Уязвимость функции trace_event_buffer_lock_reserve() модуля kernel/trace/trace.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
Уязвимость функции dx_probe() модуля fs/ext4/namei.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
Уязвимость функции ext4_convert_inline_data() модуля fs/ext4/inline.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
Уязвимость функции icp_opal_init() модуля arch/powerpc/sysdev/xics/icp-opal.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции nvme_alloc_admin_tags() модуля drivers/nvme/host/pci.c - драйвера поддержки NVME ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции snd_jack_dev_register() модуля sound/core/jack.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
Уязвимость функции raid5_add_disk() модуля drivers/md/raid5.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
MEDIUM5.5
Уязвимость функции ata_host_alloc_pinfo() модуля drivers/ata/libata-core.c - драйвера поддержки SATA/PATA ядра операционной системы 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
HIGH7.1
Уязвимость функции validate_region_size() модуля drivers/md/dm-raid.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы 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
Уязвимость функции cx25821_finidev() модуля drivers/media/pci/cx25821/cx25821-core.c драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы 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
Уязвимость функции dcscb_init() модуля arch/arm/mach-vexpress/dcscb.c поддержки платформы ARM ядра операционной системы 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
Уязвимость функции hfi1_write_iter() модуля drivers/infiniband/hw/hfi1/file_ops.c драйвера поддержки InfiniBand ядра операционной системы 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
Уязвимость функции pci_dev_lock() модуля drivers/pci/pci.c драйвера поддержки утройств PCI ядра операционной системы 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
Уязвимость функции md_bitmap_read_sb() модуля drivers/md/md-bitmap.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
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
Уязвимость функции r871xu_drv_init() модуля drivers/staging/rtl8712/usb_intf.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
Уязвимость функции isp116x_remove() модуля drivers/usb/host/isp116x-hcd.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
Уязвимость функции sa1100_set_termios() модуля drivers/tty/serial/sa1100.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
Уязвимость функции ieee80211_beacons_stop() модуля drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.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
Уязвимость функции oxu_bus_suspend() модуля drivers/usb/host/oxu210hp-hcd.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
Уязвимость функции mips_cpc_default_phys_base() модуля arch/mips/kernel/mips-cpc.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
MEDIUM5.5
Уязвимость функции rtl8180_tx() модуля drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c - драйвера поддержки адаптеров беспроводной связи Realtek ядра операционной системы 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
Уязвимость функции user_dlm_destroy_lock() модуля fs/ocfs2/dlmfs/userdlm.c поддержки файловой системы OCFS2 ядра операционной системы 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
Уязвимость функции hi3xxx_smp_prepare_cpus() модуля arch/arm/mach-hisi/platsmp.c поддержки платформы ARM ядра операционной системы 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
Уязвимость функции kszphy_config_reset() модуля drivers/net/phy/micrel.c - драйвера поддержки сети физического уровня (PHY) ядра операционной системы 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
Уязвимость функции virtio_gpu_conn_get_modes() модуля drivers/gpu/drm/virtio/virtgpu_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
Уязвимость функции libipw_xmit() модуля drivers/net/wireless/intel/ipw2x00/libipw_tx.c - драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы 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
Уязвимость функции machine_setup() модуля arch/xtensa/platforms/xtfpga/setup.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
Уязвимость функции calibrate_ccount() модуля arch/xtensa/kernel/time.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
Уязвимость функции l2tp_ip6_sendmsg() модуля net/l2tp/l2tp_ip6.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
Уязвимость функции nfcmrvl_play_deferred() модуля drivers/nfc/nfcmrvl/usb.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
Уязвимость функции icom_probe() модуля drivers/tty/serial/icom.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
Уязвимость функции rtllib_beacons_stop() модуля drivers/staging/rtl8192e/rtllib_softmac.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
Уязвимость функции clcdfb_of_vram_setup() модуля drivers/video/fbdev/amba-clcd.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
Уязвимость функции tcp_mtup_probe_success() модуля net/ipv4/tcp_input.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
Уязвимость функции seg6_hmac_init() модуля net/ipv6/seg6_hmac.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
Уязвимость функции xfrm4_protocol_init() модуля net/ipv4/xfrm4_protocol.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
Уязвимость функции mdio_bus_init() модуля drivers/net/phy/mdio_bus.c драйвера поддержки сети физического уровня (PHY) ядра операционной системы 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
HIGH7.8
Уязвимость функции dm_integrity_ctr() модуля drivers/md/dm-integrity.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы 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:CMEDIUM5.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
Уязвимость функции 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
Уязвимость функции 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
MEDIUM4.7
Уязвимость функции nbd_cleanup() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции nbd_start_device_ioctl() модуля drivers/block/nbd.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
Уязвимость функции bpf_int_jit_compile() модуля arch/arm64/net/bpf_jit_comp.c поддержки сети на платформе ARM 64бит ядра операционной системы 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
Уязвимость функции tcp_rtx_synack() модуля net/ipv4/tcp_output.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
Уязвимость функции goldfish_tty_probe() модуля drivers/tty/goldfish.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
HIGH7.1
Уязвимость функции ath9k_rx_prepare() модуля drivers/net/wireless/ath/ath9k/htc_drv_txrx.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:CMEDIUM5.5
Уязвимость функции f2fs_drop_inmem_page() модуля fs/f2fs/segment.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
Уязвимость функции nf_conntrack_confirm() модуля include/net/netfilter/nf_conntrack_core.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:CMEDIUM5.5
Уязвимость функции rk3399_dmcfreq_remove() модуля drivers/devfreq/rk3399_dmc.c драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции gs_can_open() модуля drivers/net/can/usb/gs_usb.c драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции erspan_fb_xmit() модуля net/ipv4/ip_gre.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
Уязвимость функции ext4_mb_normalize_request() модуля fs/ext4/mballoc.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CHIGH7.8
Уязвимость функции goldfish_tty_remove() модуля drivers/tty/goldfish.c драйвера поддержки консоли TTY ядра операционной системы 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
Уязвимость функции i40e_diag_test() модуля drivers/net/ethernet/intel/i40e/i40e_ethtool.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции __drm_universal_plane_init() модуля drivers/gpu/drm/drm_plane.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции swap_readpage() модуля mm/page_io.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
Уязвимость функции 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
Уязвимость функции dlm_posix_lock() модуля fs/dlm/plock.c поддержки распределенного менеджера блокировок ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CMEDIUM5.5
Уязвимость функции register_node() модуля drivers/base/node.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
Уязвимость функции tun_detach_all() модуля drivers/net/tun.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
Уязвимость функции blkcg_iolatency_throttle() модуля block/blk-iolatency.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
MEDIUM4.7
Уязвимость функции reset_page() модуля mm/zsmalloc.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CReferences
MEDIUM5.5
Уязвимость функции mdp5_crtc_setup_pipeline() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.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
Уязвимость функции mdp5_pipe_assign() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.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
Уязвимость функции sdma_clean() модуля drivers/infiniband/hw/hfi1/sdma.c драйвера поддержки InfiniBand ядра операционной системы 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
Уязвимость функции ipgre_xmit() модуля net/ipv4/ip_gre.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
Уязвимость функции 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
Уязвимость функции ip6_forward() модуля net/ipv6/ip6_output.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
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы 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
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы 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
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
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: dm: fix mempool NULL pointer race when completing IO dm_io_dec_pending() calls end_io_acct() first and will then dec md in-flight pending count. But if a task is swapping DM table at same time this can result in a crash due to mempool->elements being NULL: task1 task2 do_resume ->do_suspend ->dm_wait_for_completion bio_endio ->clone_endio ->dm_io_dec_pending ->end_io_acct ->wakeup task1 ->dm_swap_table ->__bind ->__bind_mempools ->bioset_exit ->mempool_exit ->free_io [ 67.330330] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ...... [ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 67.330510] pc : mempool_free+0x70/0xa0 [ 67.330515] lr : mempool_free+0x4c/0xa0 [ 67.330520] sp : ffffff8008013b20 [ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004 [ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8 [ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800 [ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800 [ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80 [ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c [ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd [ 67.330563] x15: 000000000093b41e x14: 0000000000000010 [ 67.330569] x13: 0000000000007f7a x12: 0000000034155555 [ 67.330574] x11: 0000000000000001 x10: 0000000000000001 [ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000 [ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a [ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001 [ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8 [ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970 [ 67.330609] Call trace: [ 67.330616] mempool_free+0x70/0xa0 [ 67.330627] bio_put+0xf8/0x110 [ 67.330638] dec_pending+0x13c/0x230 [ 67.330644] clone_endio+0x90/0x180 [ 67.330649] bio_endio+0x198/0x1b8 [ 67.330655] dec_pending+0x190/0x230 [ 67.330660] clone_endio+0x90/0x180 [ 67.330665] bio_endio+0x198/0x1b8 [ 67.330673] blk_update_request+0x214/0x428 [ 67.330683] scsi_end_request+0x2c/0x300 [ 67.330688] scsi_io_completion+0xa0/0x710 [ 67.330695] scsi_finish_command+0xd8/0x110 [ 67.330700] scsi_softirq_done+0x114/0x148 [ 67.330708] blk_done_softirq+0x74/0xd0 [ 67.330716] __do_softirq+0x18c/0x374 [ 67.330724] irq_exit+0xb4/0xb8 [ 67.330732] __handle_domain_irq+0x84/0xc0 [ 67.330737] gic_handle_irq+0x148/0x1b0 [ 67.330744] el1_irq+0xe8/0x190 [ 67.330753] lpm_cpuidle_enter+0x4f8/0x538 [ 67.330759] cpuidle_enter_state+0x1fc/0x398 [ 67.330764] cpuidle_enter+0x18/0x20 [ 67.330772] do_idle+0x1b4/0x290 [ 67.330778] cpu_startup_entry+0x20/0x28 [ 67.330786] secondary_start_kernel+0x160/0x170 Fix this by: 1) Establishing pointers to 'struct dm_io' members in dm_io_dec_pending() so that they may be passed into end_io_acct() _after_ free_io() is called. 2) Moving end_io_acct() after free_io().
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/6e506f07c5b561d673dd0b0d8f7f420cc48024fb
- https://git.kernel.org/stable/c/9e07272cca2ed76f7f6073f4444b1143828c8d87
- https://git.kernel.org/stable/c/9fb7cd5c7fef0f1c982e3cd27745a0dec260eaed
- https://git.kernel.org/stable/c/ad1393b92e5059218d055bfec8f4946d85ad04c4
- https://git.kernel.org/stable/c/d208b89401e073de986dc891037c5a668f5d5d95
- https://git.kernel.org/stable/c/d29c78d3f9c5d2604548c1065bf1ec212728ea61
- https://git.kernel.org/stable/c/d35aef9c60d310eff3eaddacce301efe877e2b7c
- https://git.kernel.org/stable/c/6e506f07c5b561d673dd0b0d8f7f420cc48024fb
- https://git.kernel.org/stable/c/9e07272cca2ed76f7f6073f4444b1143828c8d87
- https://git.kernel.org/stable/c/9fb7cd5c7fef0f1c982e3cd27745a0dec260eaed
- https://git.kernel.org/stable/c/ad1393b92e5059218d055bfec8f4946d85ad04c4
- https://git.kernel.org/stable/c/d208b89401e073de986dc891037c5a668f5d5d95
- https://git.kernel.org/stable/c/d29c78d3f9c5d2604548c1065bf1ec212728ea61
- https://git.kernel.org/stable/c/d35aef9c60d310eff3eaddacce301efe877e2b7c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler.
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/1db58c6584a72102e98af2e600ea184ddaf2b8af
- https://git.kernel.org/stable/c/23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12
- https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9
- https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d
- https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9ed24dd5
- https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a
- https://git.kernel.org/stable/c/1db58c6584a72102e98af2e600ea184ddaf2b8af
- https://git.kernel.org/stable/c/23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12
- https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9
- https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d
- https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9ed24dd5
- https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: davinci: da850-evm: Avoid NULL pointer dereference With newer versions of GCC, there is a panic in da850_evm_config_emac() when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine: Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850_evm_config_emac+0x1c/0x120 LR is at do_one_initcall+0x50/0x1e0 The emac_pdata pointer in soc_info is NULL because davinci_soc_info only gets populated on davinci machines but da850_evm_config_emac() is called on all machines via device_initcall(). Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported 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/0940795c6834fbe7705acc5c3d4b2f7a5f67527a
- https://git.kernel.org/stable/c/0a312ec66a03133d28570f07bc52749ccfef54da
- https://git.kernel.org/stable/c/83a1cde5c74bfb44b49cb2a940d044bb2380f4ea
- https://git.kernel.org/stable/c/89931d4762572aaee6edbe5673d41f8082de110f
- https://git.kernel.org/stable/c/a12b356d45cbb6e8a1b718d1436b3d6239a862f3
- https://git.kernel.org/stable/c/c06f476e5b74bcabb8c4a2fba55864a37e62843b
- https://git.kernel.org/stable/c/c5628533a3ece64235d04fe11ec44d2be99e423d
- https://git.kernel.org/stable/c/c64e2ed5cc376e137e572babfd2edc38b2cfb61b
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
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: 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/plane: Move range check for format_count earlier While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first 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/1e29d829ad51d1472dd035487953a6724b56fc33
- https://git.kernel.org/stable/c/4ab7e453a3ee88c274cf97bee9487ab92a66d313
- https://git.kernel.org/stable/c/4b674dd69701c2e22e8e7770c1706a69f3b17269
- https://git.kernel.org/stable/c/787163d19bc3cdc6ca4b96223f62208534d1cf6b
- https://git.kernel.org/stable/c/978e3d023256bfaf34a0033d40c94e8a8e70cf3c
- https://git.kernel.org/stable/c/ad6dd7a2bac86118985c7b3426e175b9d3c1ec4f
- https://git.kernel.org/stable/c/b5cd108143513e4498027b96ec4710702d186f11
HIGH7.0
A use-after-free flaw was found in the Linux kernel’s sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system.
CVSS 2.0MEDIUM 6.9
CVSS:2.0/AV:L/AC:M/Au:N/C:C/I:C/A:CCVSS 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://bugzilla.redhat.com/show_bug.cgi?id=2066706
- https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3
- https://security.netapp.com/advisory/ntap-20220629-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://bugzilla.redhat.com/show_bug.cgi?id=2066706
- https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3
- https://security.netapp.com/advisory/ntap-20220629-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
MEDIUM5.5
A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel’s filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service.
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://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
- https://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
HIGH7.8
Linux Kernel could allow a local attacker to execute arbitrary code on the system, caused by a concurrency use-after-free flaw in the bad_flp_intr function. By executing a specially-crafted program, an attacker could exploit this vulnerability to execute arbitrary code or cause a denial of service condition 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=1832397
- https://francozappa.github.io/about-bias/
- https://kb.cert.org/vuls/id/647177/
- https://security.netapp.com/advisory/ntap-20220722-0002/
- https://www.debian.org/security/2022/dsa-5173
- https://bugzilla.redhat.com/show_bug.cgi?id=1832397
- https://francozappa.github.io/about-bias/
- https://kb.cert.org/vuls/id/647177/
- https://security.netapp.com/advisory/ntap-20220722-0002/
- https://www.debian.org/security/2022/dsa-5173
HIGH7.0
A race condition was found the Linux kernel in perf_event_open() which can be exploited by an unprivileged user to gain root privileges. The bug allows to build several exploit primitives such as kernel address information leak, arbitrary execution, etc.
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/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac6487e584a1eb54071dbe1212e05b884136704
- https://security.netapp.com/advisory/ntap-20230214-0006/
- https://www.openwall.com/lists/oss-security/2022/05/20/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac6487e584a1eb54071dbe1212e05b884136704
- https://security.netapp.com/advisory/ntap-20230214-0006/
- https://www.openwall.com/lists/oss-security/2022/05/20/2
HIGH7.1
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
CVSS 2.0LOW 3.6
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:N/A:PCVSS 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
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
HIGH7.8
An integer coercion error was found in the openvswitch kernel module. Given a sufficiently large number of actions, while copying and reserving memory for a new action of a new flow, the reserve_sfa_size() function does not return -EMSGSIZE as expected, potentially leading to an out-of-bounds write access. This flaw allows a local user to crash 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:HHIGH8.8
In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.
CVSS 2.0MEDIUM 6.5
CVSS:2.0/AV:N/AC:L/Au:S/C:P/I:P/A:PCVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12
- https://github.com/torvalds/linux/commit/7f14c7227f342d9932f9b918893c8814f86d2a0d
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220419-0001/
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12
- https://github.com/torvalds/linux/commit/7f14c7227f342d9932f9b918893c8814f86d2a0d
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220419-0001/
HIGH7.8
Improper Update of Reference Count vulnerability in net/sched of Linux Kernel allows local attacker to cause privilege escalation to root. This issue affects: Linux Kernel versions prior to 5.18; version 4.14 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
- http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html
- http://www.openwall.com/lists/oss-security/2022/05/18/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3db09e762dc79584a69c10d74a6b98f89a9979f8
- https://kernel.dance/#3db09e762dc79584a69c10d74a6b98f89a9979f8
- https://security.netapp.com/advisory/ntap-20220629-0005/
- 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/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html
- http://www.openwall.com/lists/oss-security/2022/05/18/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3db09e762dc79584a69c10d74a6b98f89a9979f8
- https://kernel.dance/#3db09e762dc79584a69c10d74a6b98f89a9979f8
- https://security.netapp.com/advisory/ntap-20220629-0005/
- https://www.debian.org/security/2022/dsa-5173
HIGH7.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
net/netfilter/nf_tables_api.c in the Linux kernel through 5.18.1 allows a local user (able to create user/net namespaces) to escalate privileges to root because an incorrect NFT_STATEFUL_EXPR check leads to a use-after-free.
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://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
- http://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
HIGH7.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/
HIGH7.1
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
CVSS 2.0LOW 3.6
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:N/A:PCVSS 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
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
HIGH7.1
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
CVSS 2.0LOW 3.6
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:N/A:PCVSS 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
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
HIGH7.1
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
CVSS 2.0LOW 3.6
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:N/A:PCVSS 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
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
HIGH7.1
A flaw was found in the Linux kernel. A NULL pointer dereference may occur while a slip driver is in progress to detach in sl_tx_timeout in drivers/net/slip/slip.c. This issue could allow an attacker to crash the system or leak internal kernel 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:HMEDIUM5.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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix a possible null pointer dereference In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. The failure status of drm_cvt_mode() on the other path is checked 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/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
- https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj 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/417947891bd5ae327f15efed1a0da2b12ef24962
- https://git.kernel.org/stable/c/8bc69f86328e87a0ffa79438430cc82f3aa6a194
- https://git.kernel.org/stable/c/91d8866ca55232d21995a3d54fac96de33c9e20c
- https://git.kernel.org/stable/c/92e25b637cd4e010f776c86e4810300e773eac5c
- https://git.kernel.org/stable/c/c377e2ba78d3fe9a1f0b4ec424e75f81da7e81e9
- https://git.kernel.org/stable/c/fe595759c2a4a5bb41c438474f15947d8ae32f5c
- https://git.kernel.org/stable/c/417947891bd5ae327f15efed1a0da2b12ef24962
- https://git.kernel.org/stable/c/8bc69f86328e87a0ffa79438430cc82f3aa6a194
- https://git.kernel.org/stable/c/91d8866ca55232d21995a3d54fac96de33c9e20c
- https://git.kernel.org/stable/c/92e25b637cd4e010f776c86e4810300e773eac5c
- https://git.kernel.org/stable/c/c377e2ba78d3fe9a1f0b4ec424e75f81da7e81e9
- https://git.kernel.org/stable/c/fe595759c2a4a5bb41c438474f15947d8ae32f5c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: vsock: remove vsock from connected table when connect is interrupted by a signal vsock_connect() expects that the socket could already be in the TCP_ESTABLISHED state when the connecting task wakes up with a signal pending. If this happens the socket will be in the connected table, and it is not removed when the socket state is reset. In this situation it's common for the process to retry connect(), and if the connection is successful the socket will be added to the connected table a second time, corrupting the list. Prevent this by calling vsock_remove_connected() if a signal is received while waiting for a connection. This is harmless if the socket is not in the connected table, and if it is in the table then removing it will prevent list corruption from a double add. Note for backporting: this patch requires d5afa82c977e ("vsock: correct removal of socket from the list"), which is in all current stable trees except 4.9.y.
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/0bb88f3f7e8d506f3efe46d694964117e20efbfc
- https://git.kernel.org/stable/c/2910bcb9f67551a45397735e47b6d456eb8cd549
- https://git.kernel.org/stable/c/5f326fe2aef411a6575628f92bd861463ea91df7
- https://git.kernel.org/stable/c/787468ee7a435777521d33399d012fd591ae2f94
- https://git.kernel.org/stable/c/87cd1bbd6677411e17369cd4b7389ab1e1fdba44
- https://git.kernel.org/stable/c/addd62a8cb6fa90aa322365c62487da61f6baab8
- https://git.kernel.org/stable/c/b9208492fcaecff8f43915529ae34b3bcb03877c
- https://git.kernel.org/stable/c/e3b3939fd137aab6d00d54bee0ee9244b286a608
- https://git.kernel.org/stable/c/0bb88f3f7e8d506f3efe46d694964117e20efbfc
- https://git.kernel.org/stable/c/2910bcb9f67551a45397735e47b6d456eb8cd549
- https://git.kernel.org/stable/c/5f326fe2aef411a6575628f92bd861463ea91df7
- https://git.kernel.org/stable/c/787468ee7a435777521d33399d012fd591ae2f94
- https://git.kernel.org/stable/c/87cd1bbd6677411e17369cd4b7389ab1e1fdba44
- https://git.kernel.org/stable/c/addd62a8cb6fa90aa322365c62487da61f6baab8
- https://git.kernel.org/stable/c/b9208492fcaecff8f43915529ae34b3bcb03877c
- https://git.kernel.org/stable/c/e3b3939fd137aab6d00d54bee0ee9244b286a608
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: iwlwifi: fix use-after-free If no firmware was present at all (or, presumably, all of the firmware files failed to parse), we end up unbinding by calling device_release_driver(), which calls remove(), which then in iwlwifi calls iwl_drv_stop(), freeing the 'drv' struct. However the new code I added will still erroneously access it after it was freed. Set 'failure=false' in this case to avoid the access, all data was already freed anyway.
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/008508c16af0087cda0394e1ac6f0493b01b6063
- https://git.kernel.org/stable/c/494de920d98f125b099f27a2d274850750aff957
- https://git.kernel.org/stable/c/7d6475179b85a83186ccce59cdc359d4f07d0bcb
- https://git.kernel.org/stable/c/9958b9cbb22145295ee1ffaea0904c383da2c05d
- https://git.kernel.org/stable/c/bea2662e7818e15d7607d17d57912ac984275d94
- https://git.kernel.org/stable/c/d3b98fe36f8a06ce654049540773256ab59cb53d
- https://git.kernel.org/stable/c/ddd46059f7d99119b62d44c519df7a79f2e6a515
- https://git.kernel.org/stable/c/008508c16af0087cda0394e1ac6f0493b01b6063
- https://git.kernel.org/stable/c/494de920d98f125b099f27a2d274850750aff957
- https://git.kernel.org/stable/c/7d6475179b85a83186ccce59cdc359d4f07d0bcb
- https://git.kernel.org/stable/c/9958b9cbb22145295ee1ffaea0904c383da2c05d
- https://git.kernel.org/stable/c/bea2662e7818e15d7607d17d57912ac984275d94
- https://git.kernel.org/stable/c/d3b98fe36f8a06ce654049540773256ab59cb53d
- https://git.kernel.org/stable/c/ddd46059f7d99119b62d44c519df7a79f2e6a515
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state.
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/324f5bdc52ecb6a6dadb31a62823ef8c709d1439
- https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9
- https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1
- https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2
- https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace
- https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99
- https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439
- https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9
- https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1
- https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2
- https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace
- https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99
HIGH7.0
In the Linux kernel, the following vulnerability has been resolved: nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp. The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should: 1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER.
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/0ead57ceb21bbf15963b4874c2ac67143455382f
- https://git.kernel.org/stable/c/0fa0f99fc84e41057cbdd2efbfe91c6b2f47dd9d
- https://git.kernel.org/stable/c/70356b756a58704e5c8818cb09da5854af87e765
- https://git.kernel.org/stable/c/9e956a2596ae276124ef0d96829c013dd0faf861
- https://git.kernel.org/stable/c/a25e460fbb0340488d119fb2e28fe3f829b7417e
- https://git.kernel.org/stable/c/e043fb5a0336ee74614e26f0d9f36f1f5bb6d606
- https://git.kernel.org/stable/c/0ead57ceb21bbf15963b4874c2ac67143455382f
- https://git.kernel.org/stable/c/0fa0f99fc84e41057cbdd2efbfe91c6b2f47dd9d
- https://git.kernel.org/stable/c/70356b756a58704e5c8818cb09da5854af87e765
- https://git.kernel.org/stable/c/9e956a2596ae276124ef0d96829c013dd0faf861
- https://git.kernel.org/stable/c/a25e460fbb0340488d119fb2e28fe3f829b7417e
- https://git.kernel.org/stable/c/e043fb5a0336ee74614e26f0d9f36f1f5bb6d606
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: at86rf230: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. In the Tx case we then leak the skb structure. Free the skb structure upon error before returning when appropriate. As the 'is_tx = 0' cannot be moved in the complete handler because of a possible race between the delay in switching to STATE_RX_AACK_ON and a new interrupt, we introduce an intermediate 'was_tx' boolean just for this purpose. There is no Fixes tag applying here, many changes have been made on this area and the issue kind of always existed.
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/0fd484644c68897c490a3307bfcc8bf767df5a43
- https://git.kernel.org/stable/c/1c72f04d52b7200bb83426a9bed378668271ea4a
- https://git.kernel.org/stable/c/23b2a25382400168427ea278f3d8bf4ecfd333bf
- https://git.kernel.org/stable/c/455ef08d6e5473526fa6763f75a93f7198206966
- https://git.kernel.org/stable/c/6312f6a53fd3ea38125dcaca5e3c9aa7d8a60cf7
- https://git.kernel.org/stable/c/af649e5c95f56df64363bc46f6746b87819f9c0d
- https://git.kernel.org/stable/c/d2a1eaf51b7d4412319adb6acef114ba472d1692
- https://git.kernel.org/stable/c/e5ce576d45bf72fd0e3dc37eff897bfcc488f6a9
- https://git.kernel.org/stable/c/0fd484644c68897c490a3307bfcc8bf767df5a43
- https://git.kernel.org/stable/c/1c72f04d52b7200bb83426a9bed378668271ea4a
- https://git.kernel.org/stable/c/23b2a25382400168427ea278f3d8bf4ecfd333bf
- https://git.kernel.org/stable/c/455ef08d6e5473526fa6763f75a93f7198206966
- https://git.kernel.org/stable/c/6312f6a53fd3ea38125dcaca5e3c9aa7d8a60cf7
- https://git.kernel.org/stable/c/af649e5c95f56df64363bc46f6746b87819f9c0d
- https://git.kernel.org/stable/c/d2a1eaf51b7d4412319adb6acef114ba472d1692
- https://git.kernel.org/stable/c/e5ce576d45bf72fd0e3dc37eff897bfcc488f6a9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix data TLB miss in sba_unmap_sg Rolf Eike Beer reported the following bug: [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018 [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891] ORIG_R28: 0000000040acdd58 [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118 [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118 [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891] [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70 [1274934.746891] [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60 [1274934.746891] [<00000000407a3488>] mptscsih_io_done+0x150/0xd70 [1274934.746891] [<0000000040798600>] mpt_interrupt+0x168/0xa68 [1274934.746891] [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278 [1274934.746891] [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8 [1274934.746891] [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0 [1274934.746891] [<00000000402548e0>] generic_handle_irq+0x50/0x70 [1274934.746891] [<000000004019a254>] call_on_stack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?) The bug is caused by overrunning the sglist and incorrectly testing sg_dma_len(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code: while (sg_dma_len(sglist) && nents--) { The fix is simply to test nents first and move the decrement of nents into the loop.
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/867e50231c7605547d9334904d70a181f39f2d9e
- https://git.kernel.org/stable/c/8c8e949ae81e7f5ab58f9f9f8e9b573b93173dd2
- https://git.kernel.org/stable/c/b7d6f44a0fa716a82969725516dc0b16bc7cd514
- https://git.kernel.org/stable/c/de75676ee99bf9f25b1124ff301b3f7b8ba597d4
- https://git.kernel.org/stable/c/e40ae3133ed87d6d526f3c8fc6a5f9a2d72dcdbf
- https://git.kernel.org/stable/c/efccc9b0c7e28d0eb7918a236e59f60dc23db4c3
- https://git.kernel.org/stable/c/f23f0444ead4d941165aa82ce2fcbb997dc00e97
- https://git.kernel.org/stable/c/f8f519d7df66c334b5e08f896ac70ee3b53add3b
- https://git.kernel.org/stable/c/867e50231c7605547d9334904d70a181f39f2d9e
- https://git.kernel.org/stable/c/8c8e949ae81e7f5ab58f9f9f8e9b573b93173dd2
- https://git.kernel.org/stable/c/b7d6f44a0fa716a82969725516dc0b16bc7cd514
- https://git.kernel.org/stable/c/de75676ee99bf9f25b1124ff301b3f7b8ba597d4
- https://git.kernel.org/stable/c/e40ae3133ed87d6d526f3c8fc6a5f9a2d72dcdbf
- https://git.kernel.org/stable/c/efccc9b0c7e28d0eb7918a236e59f60dc23db4c3
- https://git.kernel.org/stable/c/f23f0444ead4d941165aa82ce2fcbb997dc00e97
- https://git.kernel.org/stable/c/f8f519d7df66c334b5e08f896ac70ee3b53add3b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: perf: Fix list corruption in perf_cgroup_switch() There's list corruption on cgrp_cpuctx_list. This happens on the following path: perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) cpu_ctx_sched_in ctx_sched_in ctx_pinned_sched_in merge_sched_in perf_cgroup_event_disable: remove the event from the list Use list_for_each_entry_safe() to allow removing an entry during iteration.
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/2142bc1469a316fddd10012d76428f7265258f81
- https://git.kernel.org/stable/c/30d9f3cbe47e1018ddc8069ac5b5c9e66fbdf727
- https://git.kernel.org/stable/c/5d76ed4223403f90421782adb2f20a9ecbc93186
- https://git.kernel.org/stable/c/5f4e5ce638e6a490b976ade4a40017b40abb2da0
- https://git.kernel.org/stable/c/7969fe91c9830e045901970e9d755b7505881d4a
- https://git.kernel.org/stable/c/a2ed7b29d0673ba361546e2d87dbbed149456c45
- https://git.kernel.org/stable/c/f6b5d51976fcefef5732da3e3feb3ccff680f7c8
- https://git.kernel.org/stable/c/2142bc1469a316fddd10012d76428f7265258f81
- https://git.kernel.org/stable/c/30d9f3cbe47e1018ddc8069ac5b5c9e66fbdf727
- https://git.kernel.org/stable/c/5d76ed4223403f90421782adb2f20a9ecbc93186
- https://git.kernel.org/stable/c/5f4e5ce638e6a490b976ade4a40017b40abb2da0
- https://git.kernel.org/stable/c/7969fe91c9830e045901970e9d755b7505881d4a
- https://git.kernel.org/stable/c/a2ed7b29d0673ba361546e2d87dbbed149456c45
- https://git.kernel.org/stable/c/f6b5d51976fcefef5732da3e3feb3ccff680f7c8
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup ax88179_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. I have tested that this can be used by a malicious USB device to send a bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response that contains random kernel heap data. It's probably also possible to get OOB writes from this on a little-endian system somehow - maybe by triggering skb_cow() via IP options processing -, but I haven't tested that.
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/1668781ed24da43498799aa4f65714a7de201930
- https://git.kernel.org/stable/c/57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581
- https://git.kernel.org/stable/c/63f0cfb36c1f1964a59ce544156677601e2d8740
- https://git.kernel.org/stable/c/711b6bf3fb052f0a6b5b3205d50e30c0c2980382
- https://git.kernel.org/stable/c/758290defe93a865a2880d10c5d5abd288b64b5d
- https://git.kernel.org/stable/c/9681823f96a811268265f35307072ad80713c274
- https://git.kernel.org/stable/c/a0fd5492ee769029a636f1fb521716b022b1423d
- https://git.kernel.org/stable/c/ffd0393adcdcefab7e131488e10dcfde5e02d6eb
- https://git.kernel.org/stable/c/1668781ed24da43498799aa4f65714a7de201930
- https://git.kernel.org/stable/c/57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581
- https://git.kernel.org/stable/c/63f0cfb36c1f1964a59ce544156677601e2d8740
- https://git.kernel.org/stable/c/711b6bf3fb052f0a6b5b3205d50e30c0c2980382
- https://git.kernel.org/stable/c/758290defe93a865a2880d10c5d5abd288b64b5d
- https://git.kernel.org/stable/c/9681823f96a811268265f35307072ad80713c274
- https://git.kernel.org/stable/c/a0fd5492ee769029a636f1fb521716b022b1423d
- https://git.kernel.org/stable/c/ffd0393adcdcefab7e131488e10dcfde5e02d6eb
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: fix a memleak when uncloning an skb dst and its metadata When uncloning an skb dst and its associated metadata, a new dst+metadata is allocated and later replaces the old one in the skb. This is helpful to have a non-shared dst+metadata attached to a specific skb. The issue is the uncloned dst+metadata is initialized with a refcount of 1, which is increased to 2 before attaching it to the skb. When tun_dst_unclone returns, the dst+metadata is only referenced from a single place (the skb) while its refcount is 2. Its refcount will never drop to 0 (when the skb is consumed), leading to a memory leak. Fix this by removing the call to dst_hold in tun_dst_unclone, as the dst+metadata refcount is already 1.
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/00e6d6c3bc14dfe32824e2c515f0e0f2d6ecf2f1
- https://git.kernel.org/stable/c/0be943916d781df2b652793bb2d3ae4f9624c10a
- https://git.kernel.org/stable/c/4ac84498fbe84a00e7aef185e2bb3e40ce71eca4
- https://git.kernel.org/stable/c/8b1087b998e273f07be13dcb5f3ca4c309c7f108
- https://git.kernel.org/stable/c/9eeabdf17fa0ab75381045c867c370f4cc75a613
- https://git.kernel.org/stable/c/a80817adc2a4c1ba26a7aa5f3ed886e4a18dff88
- https://git.kernel.org/stable/c/c1ff27d100e2670b03cbfddb9117e5f9fc672540
- https://git.kernel.org/stable/c/fdcb263fa5cda15b8cb24a641fa2718c47605314
- https://git.kernel.org/stable/c/00e6d6c3bc14dfe32824e2c515f0e0f2d6ecf2f1
- https://git.kernel.org/stable/c/0be943916d781df2b652793bb2d3ae4f9624c10a
- https://git.kernel.org/stable/c/4ac84498fbe84a00e7aef185e2bb3e40ce71eca4
- https://git.kernel.org/stable/c/8b1087b998e273f07be13dcb5f3ca4c309c7f108
- https://git.kernel.org/stable/c/9eeabdf17fa0ab75381045c867c370f4cc75a613
- https://git.kernel.org/stable/c/a80817adc2a4c1ba26a7aa5f3ed886e4a18dff88
- https://git.kernel.org/stable/c/c1ff27d100e2670b03cbfddb9117e5f9fc672540
- https://git.kernel.org/stable/c/fdcb263fa5cda15b8cb24a641fa2718c47605314
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path
ip[6]mr_free_table() can only be called under RTNL lock.
RTNL: assertion failed at net/core/dev.c (10367)
WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Modules linked in:
CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee
RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4
R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000
FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509
ip6mr_free_table net/ipv6/ip6mr.c:389 [inline]
ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline]
ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline]
ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298
ops_init+0xaf/0x470 net/core/net_namespace.c:140
setup_net+0x54f/0xbb0 net/core/net_namespace.c:331
copy_net_ns+0x318/0x760 net/core/net_namespace.c:475
create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
copy_namespaces+0x391/0x450 kernel/nsproxy.c:178
copy_process+0x2e0c/0x7300 kernel/fork.c:2167
kernel_clone+0xe7/0xab0 kernel/fork.c:2555
__do_sys_clone+0xc8/0x110 kernel/fork.c:2672
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:0x7f4ab89f9059
Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.
RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059
RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000
RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300
R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000
R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000
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/09ac0fcb0a82d647f2c61d3d488d367b7ee5bd51
- https://git.kernel.org/stable/c/12b6703e9546902c56b4b9048b893ad49d62bdd4
- https://git.kernel.org/stable/c/16dcfde98a25340ff0f7879a16bea141d824a196
- https://git.kernel.org/stable/c/3cab045c99dbb9a94eb2d1d405f399916eec698a
- https://git.kernel.org/stable/c/5611a00697c8ecc5aad04392bea629e9d6a20463
- https://git.kernel.org/stable/c/80c529322600dfb1f985b5e3f14c3c6f522ce154
- https://git.kernel.org/stable/c/b541845dfc4e7df551955e70deec0921d6b297c3
- https://git.kernel.org/stable/c/feb9597e22755dce782aae26ac0590c06737e049
- https://git.kernel.org/stable/c/09ac0fcb0a82d647f2c61d3d488d367b7ee5bd51
- https://git.kernel.org/stable/c/12b6703e9546902c56b4b9048b893ad49d62bdd4
- https://git.kernel.org/stable/c/16dcfde98a25340ff0f7879a16bea141d824a196
- https://git.kernel.org/stable/c/3cab045c99dbb9a94eb2d1d405f399916eec698a
- https://git.kernel.org/stable/c/5611a00697c8ecc5aad04392bea629e9d6a20463
- https://git.kernel.org/stable/c/80c529322600dfb1f985b5e3f14c3c6f522ce154
- https://git.kernel.org/stable/c/b541845dfc4e7df551955e70deec0921d6b297c3
- https://git.kernel.org/stable/c/feb9597e22755dce782aae26ac0590c06737e049
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: usb: f_fs: Fix use-after-free for epfile Consider a case where ffs_func_eps_disable is called from ffs_func_disable as part of composition switch and at the same time ffs_epfile_release get called from userspace. ffs_epfile_release will free up the read buffer and call ffs_data_closed which in turn destroys ffs->epfiles and mark it as NULL. While this was happening the driver has already initialized the local epfile in ffs_func_eps_disable which is now freed and waiting to acquire the spinlock. Once spinlock is acquired the driver proceeds with the stale value of epfile and tries to free the already freed read buffer causing use-after-free. Following is the illustration of the race: CPU1 CPU2 ffs_func_eps_disable epfiles (local copy) ffs_epfile_release ffs_data_closed if (last file closed) ffs_data_reset ffs_data_clear ffs_epfiles_destroy spin_lock dereference epfiles Fix this races by taking epfiles local copy & assigning it under spinlock and if epfiles(local) is null then update it in ffs->epfiles then finally destroy it. Extending the scope further from the race, protecting the ep related structures, and concurrent accesses.
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/0042178a69eb77a979e36a50dcce9794a3140ef8
- https://git.kernel.org/stable/c/32048f4be071f9a6966744243f1786f45bb22dc2
- https://git.kernel.org/stable/c/3e078b18753669615301d946297bafd69294ad2c
- https://git.kernel.org/stable/c/72a8aee863af099d4434314c4536d6c9a61dcf3c
- https://git.kernel.org/stable/c/c9fc422c9a43e3d58d246334a71f3390401781dc
- https://git.kernel.org/stable/c/cfe5f6fd335d882bcc829a1c8a7d462a455c626e
- https://git.kernel.org/stable/c/ebe2b1add1055b903e2acd86b290a85297edc0b3
- https://git.kernel.org/stable/c/0042178a69eb77a979e36a50dcce9794a3140ef8
- https://git.kernel.org/stable/c/32048f4be071f9a6966744243f1786f45bb22dc2
- https://git.kernel.org/stable/c/3e078b18753669615301d946297bafd69294ad2c
- https://git.kernel.org/stable/c/72a8aee863af099d4434314c4536d6c9a61dcf3c
- https://git.kernel.org/stable/c/c9fc422c9a43e3d58d246334a71f3390401781dc
- https://git.kernel.org/stable/c/cfe5f6fd335d882bcc829a1c8a7d462a455c626e
- https://git.kernel.org/stable/c/ebe2b1add1055b903e2acd86b290a85297edc0b3
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
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
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: ibmvnic: free reset-work-item when flushing Fix a tiny memory leak when flushing the reset work queue.
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/39738a2346b270e8f72f88d8856de2c167bd2899
- https://git.kernel.org/stable/c/4c26745e4576cec224092e6cc12e37829333b183
- https://git.kernel.org/stable/c/58b07100c20e95c78b8cb4d6d28ca53eb9ef81f2
- https://git.kernel.org/stable/c/6acbc8875282d3ca8a73fa93cd7a9b166de5019c
- https://git.kernel.org/stable/c/786576c03b313a9ff6585458aa0dfd039d897f51
- https://git.kernel.org/stable/c/8d0657f39f487d904fca713e0bc39c2707382553
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe() During driver initialization, the pointer of card info, i.e. the variable 'ci' is required. However, the definition of 'com20020pci_id_table' reveals that this field is empty for some devices, which will cause null pointer dereference when initializing these devices. The following log reveals it: [ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci] [ 3.975181] Call Trace: [ 3.976208] local_pci_probe+0x13f/0x210 [ 3.977248] pci_device_probe+0x34c/0x6d0 [ 3.977255] ? pci_uevent+0x470/0x470 [ 3.978265] really_probe+0x24c/0x8d0 [ 3.978273] __driver_probe_device+0x1b3/0x280 [ 3.979288] driver_probe_device+0x50/0x370 Fix this by checking whether the 'ci' is a null pointer first.
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/5f394102ee27dbf051a4e283390cd8d1759dacea
- https://git.kernel.org/stable/c/8e3bc7c5bbf87e86e9cd652ca2a9166942d86206
- https://git.kernel.org/stable/c/b1ee6b9340a38bdb9e5c90f0eac5b22b122c3049
- https://git.kernel.org/stable/c/b838add93e1dd98210482dc433768daaf752bdef
- https://git.kernel.org/stable/c/bd6f1fd5d33dfe5d1b4f2502d3694a7cc13f166d
- https://git.kernel.org/stable/c/ca0bdff4249a644f2ca7a49d410d95b8dacf1f72
- https://git.kernel.org/stable/c/e50c589678e50f8d574612e473ca60ef45190896
- https://git.kernel.org/stable/c/ea372aab54903310756217d81610901a8e66cb7d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: fix possible use-after-free Eric Dumazet says: The sock_hold() side seems suspect, because there is no guarantee that sk_refcnt is not already 0. On failure, we cannot queue the packet and need to indicate an error. The packet will be dropped by the caller. v2: split skb prefetch hunk into separate change
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/21b27b2baa27423286e9b8d3f0b194d587083d95
- https://git.kernel.org/stable/c/34dc4a6a7f261736ef7183868a5bddad31c7f9e3
- https://git.kernel.org/stable/c/43c25da41e3091b31a906651a43e80a2719aa1ff
- https://git.kernel.org/stable/c/4d05239203fa38ea8a6f31e228460da4cb17a71a
- https://git.kernel.org/stable/c/c3873070247d9e3c7a6b0cf9bf9b45e8018427b1
- https://git.kernel.org/stable/c/dcc3cb920bf7ba66ac5e9272293a9ba5f80917ee
- https://git.kernel.org/stable/c/dd648bd1b33a828f62befa696b206c688da0ec43
- https://git.kernel.org/stable/c/ef97921ccdc243170fcef857ba2a17cf697aece5
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
netfilter: fix use-after-free in __nf_register_net_hook()
We must not dereference @new_hooks after nf_hook_mutex has been released,
because other threads might have freed our allocated hooks already.
BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline]
BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430
CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #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+0x8d/0x336 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
hooks_validate net/netfilter/core.c:171 [inline]
__nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571
nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587
nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218
synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81
xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038
check_target net/ipv6/netfilter/ip6_tables.c:530 [inline]
find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573
translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735
do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline]
do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639
nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101
ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024
rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084
__sys_setsockopt+0x2db/0x610 net/socket.c:2180
__do_sys_setsockopt net/socket.c:2191 [inline]
__se_sys_setsockopt net/socket.c:2188 [inline]
__x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
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:0x7f65a1ace7d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9
RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003
RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130
R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000
The buggy address belongs to the page:
page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993
prep_new_page mm/page_alloc.c:2434 [inline]
get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389
__alloc_pages_node include/linux/gfp.h:572 [inline]
alloc_pages_node include/linux/gfp.h:595 [inline]
kmalloc_large_node+0x62/0x130 mm/slub.c:4438
__kmalloc_node+0x35a/0x4a0 mm/slub.
---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/05f7927b25d2635e87267ff6c79db79fb46cf313
- https://git.kernel.org/stable/c/49c24579cec41e32f13d57b337fd28fb208d4a5b
- https://git.kernel.org/stable/c/56763f12b0f02706576a088e85ef856deacc98a0
- https://git.kernel.org/stable/c/5a8076e98dde17224dd47283b894a8b1dbe1bc72
- https://git.kernel.org/stable/c/8b0142c4143c1ca297dcf2c0cdd045d65dae2344
- https://git.kernel.org/stable/c/bd61f192a339b1095dfd6d56073a5265934c2979
- https://git.kernel.org/stable/c/bdd8fc1b826e6f23963f5bef3f7431c6188ec954
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: destroy queues before real_num_tx_queues is zeroed
xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to
delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5
("net-sysfs: update the queue counts in the unregistration path"),
unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two
facts together means, that xennet_destroy_queues() called from
xennet_remove() cannot do its job, because it's called after
unregister_netdev(). This results in kfree-ing queues that are still
linked in napi, which ultimately crashes:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226
RIP: 0010:free_netdev+0xa3/0x1a0
Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00
RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff
RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050
R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680
FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0
Call Trace:
xennet_remove+0x13d/0x300 [xen_netfront]
xenbus_dev_remove+0x6d/0xf0
__device_release_driver+0x17a/0x240
device_release_driver+0x24/0x30
bus_remove_device+0xd8/0x140
device_del+0x18b/0x410
? _raw_spin_unlock+0x16/0x30
? klist_iter_exit+0x14/0x20
? xenbus_dev_request_and_reply+0x80/0x80
device_unregister+0x13/0x60
xenbus_dev_changed+0x18e/0x1f0
xenwatch_thread+0xc0/0x1a0
? do_wait_intr_irq+0xa0/0xa0
kthread+0x16b/0x190
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
Fix this by calling xennet_destroy_queues() from xennet_uninit(),
when real_num_tx_queues is still available. This ensures that queues are
destroyed when real_num_tx_queues is set to 0, regardless of how
unregister_netdev() was called.
Originally reported at
https://github.com/QubesOS/qubes-issues/issues/7257
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/198cdc287769c717dafff5887c6125cb7a373bf3
- https://git.kernel.org/stable/c/47e2f166ed9fe17f24561d6315be2228f6a90209
- https://git.kernel.org/stable/c/a1753d5c29a6fb9a8966dcf04cb4f3b71e303ae8
- https://git.kernel.org/stable/c/a63eb1e4a2e1a191a90217871e67fba42fd39255
- https://git.kernel.org/stable/c/b40c912624775a21da32d1105e158db5f6d0554a
- https://git.kernel.org/stable/c/dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix double free race when mount fails in cifs_get_root()
When cifs_get_root() fails during cifs_smb3_do_mount() we call
deactivate_locked_super() which eventually will call delayed_free() which
will free the context.
In this situation we should not proceed to enter the out: section in
cifs_smb3_do_mount() and free the same resources a second time.
[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0
[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4
[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[Thu Feb 10 12:59:06 2022] Call Trace:
[Thu Feb 10 12:59:06 2022]
[Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78
[Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0
[Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0
[Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0
[Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20
[Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140
[Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10
[Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b
[Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150
[Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30
[Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0
...
[Thu Feb 10 12:59:07 2022] Freed by task 58179:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30
[Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40
[Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170
[Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20
[Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0
[Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
[Thu Feb 10 12:59:07 2022] Last potentially related work creation:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0
[Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10
[Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0
[Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
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:HMEDIUM5.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: usb: gadget: rndis: add spinlock for rndis response list There's no lock for rndis response list. It could cause list corruption if there're two different list_add at the same time like below. It's better to add in rndis_add_response / rndis_free_response / rndis_get_next_response to prevent any race condition on response list. [ 361.894299] [1: irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0). [ 361.904380] [1: irq/191-dwc3:16979] Call trace: [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4 [ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec [ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c
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/33222d1571d7ce8c1c75f6b488f38968fa93d2d9
- https://git.kernel.org/stable/c/4ce247af3f30078d5b97554f1ae6200a0222c15a
- https://git.kernel.org/stable/c/669c2b178956718407af5631ccbc61c24413f038
- https://git.kernel.org/stable/c/9ab652d41deab49848673c3dadb57ad338485376
- https://git.kernel.org/stable/c/9f5d8ba538ef81cd86ea587ca3f8c77e26bea405
- https://git.kernel.org/stable/c/9f688aadede6b862a0a898792b1a35421c93636f
- https://git.kernel.org/stable/c/aaaba1c86d04dac8e49bf508b492f81506257da3
- https://git.kernel.org/stable/c/da514063440b53a27309a4528b726f92c3cfe56f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: iio: adc: men_z188_adc: Fix a resource leak in an error handling path If iio_device_register() fails, a previous ioremap() is left unbalanced. Update the error handling path and add the missing iounmap() call, as already done 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/0f88722313645a903f4d420ba61ddc690ec2481d
- https://git.kernel.org/stable/c/1aa12ecfdcbafebc218910ec47acf6262e600cf5
- https://git.kernel.org/stable/c/53d43a9c8dd224e66559fe86af1e473802c7130e
- https://git.kernel.org/stable/c/c5723b422f564af15f2e3bc0592fd6376a0a6c45
- https://git.kernel.org/stable/c/ce1076b33e299dc8d270e4450a420a18bfb3e190
- https://git.kernel.org/stable/c/d6ed5426a7fad36cf928c244483ba24e72359638
- https://git.kernel.org/stable/c/e0a2e37f303828d030a83f33ffe14b36cb88d563
- https://git.kernel.org/stable/c/fe73477802981bd0d0d70f2b22f109bcca801bdb
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/ib_srp: Fix a deadlock Remove the flush_workqueue(system_long_wq) call since flushing system_long_wq is deadlock-prone and since that call is redundant with a preceding cancel_work_sync()
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/081bdc9fe05bb23248f5effb6f811da3da4b8252
- https://git.kernel.org/stable/c/4752fafb461821f8c8581090c923ababba68c5bd
- https://git.kernel.org/stable/c/8cc342508f9e7fdccd2e9758ae9d52aff72dab7f
- https://git.kernel.org/stable/c/901206f71e6ad2b2e7accefc5199a438d173c25f
- https://git.kernel.org/stable/c/98d056603ce55ceb90631b3927151c190dfb1b27
- https://git.kernel.org/stable/c/99eb8d694174c777558dc902d575d1997d5ca650
- https://git.kernel.org/stable/c/c8b56e51aa91b8e7df3a98388dce3fdabd15c1d4
- https://git.kernel.org/stable/c/d7997d19dfa7001ca41e971cd9efd091bb195b51
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_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/3aadfd46858b1f64d4d6a0654b863e21aabff975
- https://git.kernel.org/stable/c/40805099af11f68c5ca7dbcfacf455da8f99f622
- https://git.kernel.org/stable/c/84ec758fb2daa236026506868c8796b0500c047d
- https://git.kernel.org/stable/c/a37024f7757c25550accdebf49e497ad6ae239fe
- https://git.kernel.org/stable/c/a7ab53d3c27dfe83bb594456b9f38a37796ec39b
- https://git.kernel.org/stable/c/b7e2b91fcb5c78c414e33dc8d50642e307ca0c5a
- https://git.kernel.org/stable/c/d1654de19d42f513b6cfe955cc77e7f427e05a77
- https://git.kernel.org/stable/c/e7a66dd2687758718eddd79b542a95cf3aa488cc
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: dm integrity: fix memory corruption when tag_size is less than digest size It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final. Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array.
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/08c1af8f1c13bbf210f1760132f4df24d0ed46d6
- https://git.kernel.org/stable/c/4d485cf9b609709e45d5113e6e2b1b01254b2fe9
- https://git.kernel.org/stable/c/6a95d91c0b315c965198f6ab7dec7c94129e17e0
- https://git.kernel.org/stable/c/6b4bf97587ef6c1927a78934b700204920655123
- https://git.kernel.org/stable/c/7f84c937222944c03f4615ca4742df6bed0e5adf
- https://git.kernel.org/stable/c/cd02b2687d66f0a8e716384de4b9a0671331f1dc
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix panic when forwarding a pkt with no in6 dev kongweibin reported a kernel panic in ip6_forward() when input interface has no in6 dev associated. The following tc commands were used to reproduce this panic: tc qdisc del dev vxlan100 root tc qdisc add dev vxlan100 root netem corrupt 5%
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/74b68f5249f16c5f7f675d0f604fa6ae20e3a151
- https://git.kernel.org/stable/c/a263712ba8c9ded25dd9d2d5ced11bcea5b33a3e
- https://git.kernel.org/stable/c/ab2f5afb7af5c68389e8c7dd29e0a98fbeaaa435
- https://git.kernel.org/stable/c/adee01bbf6cb5b3e4ed08be8ff866aac90f13836
- https://git.kernel.org/stable/c/e3fa461d8b0e185b7da8a101fe94dfe6dd500ac0
- https://git.kernel.org/stable/c/e69fb3de87a8923e5931a272a38fa3cceb01da44
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm: fix unexpected zeroed page mapping with zram swap Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly.
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/12ba1d38115a101c45d8e0ca3aa1181fd148e57f
- https://git.kernel.org/stable/c/20ed94f8181a25212e7404e44958e234f407624b
- https://git.kernel.org/stable/c/afac4b88699a06c8b9369f9d759a1ec3c254b788
- https://git.kernel.org/stable/c/e914d8f00391520ecc4495dd0ca0124538ab7119
- https://git.kernel.org/stable/c/f098f8b9820fe3f2e41aefc4329dfe8a3859d1c1
- https://git.kernel.org/stable/c/f86d55cf616199404c05f5b0c5c41b17351baa02
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcmu: Fix possible page UAF tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not take refcount properly and just returns page pointer. When tcmu_try_get_data_page() returns, the returned page may have been freed by tcmu_blocks_release(). We need to get_page() under cmdr_lock to avoid concurrent tcmu_blocks_release().
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/a6968f7a367f128d120447360734344d5a3d5336
- https://git.kernel.org/stable/c/a9564d84ed9f6ee71017d062d0d2182154294a4b
- https://git.kernel.org/stable/c/aec36b98a1bbaa84bfd8299a306e4c12314af626
- https://git.kernel.org/stable/c/b7f3b5d70c834f49f7d87a2f2ed1c6284d9a0322
- https://git.kernel.org/stable/c/d7c5d79e50be6e06b669141e3db1f977a0dd4e8e
- https://git.kernel.org/stable/c/e3e0e067d5b34e4a68e3cc55f8eebc413f56f8ed
- https://git.kernel.org/stable/c/fb7a5115422fbd6a4d505e8844f1ef5529f10489
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check for potential null return of kmalloc_array() As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.
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/0a692c625e373fef692ffbc7fc41f8a025f01cb7
- https://git.kernel.org/stable/c/1d7a5aae884ca727d41c7ed15d4c82fdb67c040c
- https://git.kernel.org/stable/c/32cf90a521dcc0f136db7ee5ba32bfe5f79e460e
- https://git.kernel.org/stable/c/40bf32dbfef866c83a3e74800b81d79e52b6d20b
- https://git.kernel.org/stable/c/94869bb0de69a812f70231b0eb480bb2f7ae73a6
- https://git.kernel.org/stable/c/c7a268b33882d5feaafd29c1734456f41ba41396
- https://git.kernel.org/stable/c/ebbb7bb9e80305820dc2328a371c1b35679f2667
- https://git.kernel.org/stable/c/f2658d5966bcee8c3eb487875f459756d4f7cdfc
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: cifs: potential buffer overflow in handling symlinks Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1316c28569a80ab3596eeab05bf5e01991e7e739
- https://git.kernel.org/stable/c/22d658c6c5affed10c8907e67160cef0b6c92186
- https://git.kernel.org/stable/c/3e582749e742e662a8e9bb37cffac62dccaaa1e2
- https://git.kernel.org/stable/c/4e166a41180be2f1e66bbb6d46448e80a9a5ec05
- https://git.kernel.org/stable/c/515e7ba11ef043d6febe69389949c8ef5f25e9d0
- https://git.kernel.org/stable/c/64c4a37ac04eeb43c42d272f6e6c8c12bfcf4304
- https://git.kernel.org/stable/c/9901b07ba42b39266b34a888e48d7306fd707bee
- https://git.kernel.org/stable/c/eb5f51756944735ac70cd8bb38637cc202e29c91
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: add flush_workqueue to prevent uaf
Our detector found a concurrent use-after-free bug when detaching an
NCI device. The main reason for this bug is the unexpected scheduling
between the used delayed mechanism (timer and workqueue).
The race can be demonstrated below:
Thread-1 Thread-2
| nci_dev_up()
| nci_open_device()
| __nci_request(nci_reset_req)
| nci_send_cmd
| queue_work(cmd_work)
nci_unregister_device() |
nci_close_device() | ...
del_timer_sync(cmd_timer)[1] |
... | Worker
nci_free_device() | nci_cmd_work()
kfree(ndev)[3] | mod_timer(cmd_timer)[2]
In short, the cleanup routine thought that the cmd_timer has already
been detached by [1] but the mod_timer can re-attach the timer [2], even
it is already released [3], resulting in UAF.
This UAF is easy to trigger, crash trace by POC is like below
[ 66.703713] ==================================================================
[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490
[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33
[ 66.703974]
[ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5
[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work
[ 66.703974] Call Trace:
[ 66.703974]
[ 66.703974] dump_stack_lvl+0x57/0x7d
[ 66.703974] print_report.cold+0x5e/0x5db
[ 66.703974] ? enqueue_timer+0x448/0x490
[ 66.703974] kasan_report+0xbe/0x1c0
[ 66.703974] ? enqueue_timer+0x448/0x490
[ 66.703974] enqueue_timer+0x448/0x490
[ 66.703974] __mod_timer+0x5e6/0xb80
[ 66.703974] ? mark_held_locks+0x9e/0xe0
[ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0
[ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410
[ 66.703974] ? queue_work_on+0x61/0x80
[ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130
[ 66.703974] process_one_work+0x8bb/0x1510
[ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230
[ 66.703974] ? rwlock_bug.part.0+0x90/0x90
[ 66.703974] ? _raw_spin_lock_irq+0x41/0x50
[ 66.703974] worker_thread+0x575/0x1190
[ 66.703974] ? process_one_work+0x1510/0x1510
[ 66.703974] kthread+0x2a0/0x340
[ 66.703974] ? kthread_complete_and_exit+0x20/0x20
[ 66.703974] ret_from_fork+0x22/0x30
[ 66.703974]
[ 66.703974]
[ 66.703974] Allocated by task 267:
[ 66.703974] kasan_save_stack+0x1e/0x40
[ 66.703974] __kasan_kmalloc+0x81/0xa0
[ 66.703974] nci_allocate_device+0xd3/0x390
[ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0
[ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd
[ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0
[ 66.703974] tty_ioctl+0x764/0x1310
[ 66.703974] __x64_sys_ioctl+0x122/0x190
[ 66.703974] do_syscall_64+0x3b/0x90
[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 66.703974]
[ 66.703974] Freed by task 406:
[ 66.703974] kasan_save_stack+0x1e/0x40
[ 66.703974] kasan_set_track+0x21/0x30
[ 66.703974] kasan_set_free_info+0x20/0x30
[ 66.703974] __kasan_slab_free+0x108/0x170
[ 66.703974] kfree+0xb0/0x330
[ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0
[ 66.703974] nci_uart_tty_close+0xdf/0x180
[ 66.703974] tty_ldisc_kill+0x73/0x110
[ 66.703974] tty_ldisc_hangup+0x281/0x5b0
[ 66.703974] __tty_hangup.part.0+0x431/0x890
[ 66.703974] tty_release+0x3a8/0xc80
[ 66.703974] __fput+0x1f0/0x8c0
[ 66.703974] task_work_run+0xc9/0x170
[ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0
[ 66.703974] syscall_exit_to_user_mode+0x19/0x50
[ 66.703974] do_syscall_64+0x48/0x90
[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x
---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/1a1748d0dd0f0a98535c6baeef671c8722107639
- https://git.kernel.org/stable/c/5c63ad2b0a267a524c12c88acb1ba9c2d109a801
- https://git.kernel.org/stable/c/67677050cecbe0edfdd81cd508415e9636ba7c65
- https://git.kernel.org/stable/c/7d3232214ca4ea8f7d18df264c3b254aa8089d7f
- https://git.kernel.org/stable/c/9d243aff5f7e6b04e907c617426bbdf26e996ac8
- https://git.kernel.org/stable/c/9ded5ae40f4fe37fcc28f36d76bf45df20be5432
- https://git.kernel.org/stable/c/edd4600120641e1714e30112e69a548cfb68e067
- https://git.kernel.org/stable/c/ef27324e2cb7bb24542d6cb2571740eefe6b00dc
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
veth: Ensure eth header is in skb's linear part
After feeding a decapsulated packet to a veth device with act_mirred,
skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(),
which expects at least ETH_HLEN byte of linear data (as
__dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes
unconditionally).
Use pskb_may_pull() to ensure veth_xmit() respects this constraint.
kernel BUG at include/linux/skbuff.h:2328!
RIP: 0010:eth_type_trans+0xcf/0x140
Call Trace:
__dev_forward_skb2+0xe3/0x160
veth_xmit+0x6e/0x250 [veth]
dev_hard_start_xmit+0xc7/0x200
__dev_queue_xmit+0x47f/0x520
? skb_ensure_writable+0x85/0xa0
? skb_mpls_pop+0x98/0x1c0
tcf_mirred_act+0x442/0x47e [act_mirred]
tcf_action_exec+0x86/0x140
fl_classify+0x1d8/0x1e0 [cls_flower]
? dma_pte_clear_level+0x129/0x1a0
? dma_pte_clear_level+0x129/0x1a0
? prb_fill_curr_block+0x2f/0xc0
? skb_copy_bits+0x11a/0x220
__tcf_classify+0x58/0x110
tcf_classify_ingress+0x6b/0x140
__netif_receive_skb_core.constprop.0+0x47d/0xfd0
? __iommu_dma_unmap_swiotlb+0x44/0x90
__netif_receive_skb_one_core+0x3d/0xa0
netif_receive_skb+0x116/0x170
be_process_rx+0x22f/0x330 [be2net]
be_poll+0x13c/0x370 [be2net]
__napi_poll+0x2a/0x170
net_rx_action+0x22f/0x2f0
__do_softirq+0xca/0x2a8
__irq_exit_rcu+0xc1/0xe0
common_interrupt+0x83/0xa0
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/1ef0088e43af1de4e3b365218c4d3179d9a37eec
- https://git.kernel.org/stable/c/2fd90b86dff413fbf8128780c04ea9c6849c16e2
- https://git.kernel.org/stable/c/3de2a02b60a4ef0ab76263216f08c7d095fc7c42
- https://git.kernel.org/stable/c/46bc359fec0c6d87b70d7a008bcd9a5e30dd6f27
- https://git.kernel.org/stable/c/726e2c5929de841fdcef4e2bf995680688ae1b87
- https://git.kernel.org/stable/c/93940fc4cb81840dc0fa202de48cccb949a0261d
- https://git.kernel.org/stable/c/d417a859221f127e8edf09c14b76ab50f825e171
- https://git.kernel.org/stable/c/d67c900f1947d64ba8a64f693504bcaab8d9000c
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
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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0) Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization 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/1f30fb9166d4f15a1aa19449b9da871fe0ed4796
- https://git.kernel.org/stable/c/3554c214b83ec9a839ed574263a34218f372990c
- https://git.kernel.org/stable/c/53bce9d19b0a9d245b25cd050b81652ed974a509
- https://git.kernel.org/stable/c/5ae05b5eb58773cfec307ff88aff4cfd843c4cff
- https://git.kernel.org/stable/c/7438dc55c0709819b813f4778aec2c48b782990b
- https://git.kernel.org/stable/c/837b96d8103938e35e7d92cd9db96af914ca4fff
- https://git.kernel.org/stable/c/ef6f9ce0a79aa23b10fc5f3b3cab3814a25aac40
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: 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: 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: 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
MEDIUM5.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
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: 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: 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: 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: 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: exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/
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/1290eb4412aa0f0e9f3434b406dc8e255da85f9e
- https://git.kernel.org/stable/c/1fe82bfd9e4ce93399d815ca458b58505191c3e8
- https://git.kernel.org/stable/c/27a6f495b63a1804cc71be45911065db7757a98c
- https://git.kernel.org/stable/c/41f6ea5b9aaa28b740d47ffe995a5013211fdbb0
- https://git.kernel.org/stable/c/98e0c7c702894987732776736c99b85ade6fba45
- https://git.kernel.org/stable/c/a8054d3fa5deb84b215d6be1b910a978f3cb840d
- https://git.kernel.org/stable/c/b50fb8dbc8b81aaa126387de428f4c42a7c72a73
- https://git.kernel.org/stable/c/cfbfff8ce5e3d674947581f1eb9af0a1b1807950
- https://git.kernel.org/stable/c/dcd46d897adb70d63e025f175a00a89797d31a43
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:HHIGH7.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: ALSA: pcm: Fix races among concurrent prealloc proc writes We have no protection against concurrent PCM buffer preallocation changes via proc files, and it may potentially lead to UAF or some weird problem. This patch applies the PCM open_mutex to the proc write operation for avoiding the racy proc writes and the PCM stream open (and further operations).
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/37b12c16beb6f6c1c3c678c1aacbc46525c250f7
- https://git.kernel.org/stable/c/51fce708ab8986a9879ee5da946a2cc120f1036d
- https://git.kernel.org/stable/c/5ed8f8e3c4e59d0396b9ccf2e639711e24295bb6
- https://git.kernel.org/stable/c/69534c48ba8ce552ce383b3dfdb271ffe51820c3
- https://git.kernel.org/stable/c/a21d2f323b5a978dedf9ff1d50f101f85e39b3f2
- https://git.kernel.org/stable/c/b560d670c87d7d40b3cf6949246fa4c7aa65a00a
- https://git.kernel.org/stable/c/e14dca613e0a6ddc2bf6e360f16936a9f865205b
- https://git.kernel.org/stable/c/e7786c445bb67a9a6e64f66ebd6b7215b153ff7d
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: pcm: Fix races among concurrent hw_params and hw_free calls Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity.
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/0090c13cbbdffd7da079ac56f80373a9a1be0bf8
- https://git.kernel.org/stable/c/0f6947f5f5208f6ebd4d76a82a4757e2839a23f8
- https://git.kernel.org/stable/c/1bbf82d9f961414d6c76a08f7f843ea068e0ab7b
- https://git.kernel.org/stable/c/33061d0fba51d2bf70a2ef9645f703c33fe8e438
- https://git.kernel.org/stable/c/92ee3c60ec9fe64404dc035e7c41277d74aa26cb
- https://git.kernel.org/stable/c/9cb6c40a6ebe4a0cfc9d6a181958211682cffea9
- https://git.kernel.org/stable/c/a42aa926843acca96c0dfbde2e835b8137f2f092
- https://git.kernel.org/stable/c/fbeb492694ce0441053de57699e1e2b7bc148a69
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
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-)
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/013a79f1b5c89290e2e97f1ebf14b14e0cf5fe5c
- https://git.kernel.org/stable/c/06c4da89c24e7023ea448cadf8e9daf06a0aae6e
- https://git.kernel.org/stable/c/1be608e1ee1f222464b2856bda9b85ab5184a33e
- https://git.kernel.org/stable/c/3d5da1ffba3388c2ae2e6c598855a4d887d3bf79
- https://git.kernel.org/stable/c/6f505bbb8063fd3a238a4239d2d8c165e5279f6f
- https://git.kernel.org/stable/c/8a1435c862ea09b06be7acda325128dc08458e25
- https://git.kernel.org/stable/c/c0868f6e728c3c28bef0e8bee89d2daf86a8bbca
- https://git.kernel.org/stable/c/cbeafa7a79d08ecdb55f8f1d41a11323d0f709db
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix io hung while disconnecting device
In our tests, "qemu-nbd" triggers a io hung:
INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000
Call Trace:
__schedule+0x480/0x1050
? _raw_spin_lock_irqsave+0x3e/0xb0
schedule+0x9c/0x1b0
blk_mq_freeze_queue_wait+0x9d/0xf0
? ipi_rseq+0x70/0x70
blk_mq_freeze_queue+0x2b/0x40
nbd_add_socket+0x6b/0x270 [nbd]
nbd_ioctl+0x383/0x510 [nbd]
blkdev_ioctl+0x18e/0x3e0
__x64_sys_ioctl+0xac/0x120
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fd8ff706577
RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577
RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f
RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0
R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d
R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0
"qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following
message was found:
block nbd0: Send disconnect failed -32
Which indicate that something is wrong with the server. Then,
"qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear
requests after commit 2516ab1543fd("nbd: only clear the queue on device
teardown"). And in the meantime, request can't complete through timeout
because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which
means such request will never be completed in this situation.
Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't
complete multiple times, switch back to call nbd_clear_sock() in
nbd_clear_sock_ioctl(), so that inflight requests can be cleared.
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/09dadb5985023e27d4740ebd17e6fea4640110e5
- https://git.kernel.org/stable/c/141318e62db87105b0103fccc59c9c5940da248d
- https://git.kernel.org/stable/c/54b06dc2a206b4d67349bb56b92d4bd32700b7b1
- https://git.kernel.org/stable/c/62d227f67a8c25d5e16f40e5290607f9306d2188
- https://git.kernel.org/stable/c/67e403136a0e1a55fef6a05f103a3979a39ad3fd
- https://git.kernel.org/stable/c/69893d6d7f5c10d8306c1b5fc64b71efc91aa6cd
- https://git.kernel.org/stable/c/c4ba982bd5084fa659ef518aaf159e4dab02ecda
- https://git.kernel.org/stable/c/f72df77600a43e59b3189e53b47f8685739867d3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in r871xu_drv_init() When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
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/0458e5428e5e959d201a40ffe71d762a79ecedc4
- https://git.kernel.org/stable/c/0b7371a22489cbb2e8e826ca03fb5ce92afb04fe
- https://git.kernel.org/stable/c/277faa442fe0c59f418ac53f47a78e1266addd65
- https://git.kernel.org/stable/c/52a0d88c328098b4e9fb8f2f3877fec0eff4104b
- https://git.kernel.org/stable/c/70df04433fd351ba72bc635bd0b5fe443d9ac964
- https://git.kernel.org/stable/c/76a964ad0ea8f2b10abd69a7532e174a28258283
- https://git.kernel.org/stable/c/a6535d00a9d54ce1c2a8d86a85001ffb6844f9b2
- https://git.kernel.org/stable/c/f36e754a1f0bafb9feeea63463de78080acb6de0
- https://git.kernel.org/stable/c/ff727ab0b7d7a56b5ef281f12abd00c4b85894e9
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between nbd_alloc_config() and module removal When nbd module is being removing, nbd_alloc_config() may be called concurrently by nbd_genl_connect(), although try_module_get() will return false, but nbd_alloc_config() doesn't handle it. The race may lead to the leak of nbd_config and its related resources (e.g, recv_workq) and oops in nbd_read_stat() due to the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Fixing it by checking the return value of try_module_get() in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV), assign nbd->config only when nbd_alloc_config() succeeds to ensure the value of nbd->config is binary (valid or NULL). Also adding a debug message to check the reference counter of nbd_config during module removal.
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/122e4adaff2439f1cc18cc7e931980fa7560df5c
- https://git.kernel.org/stable/c/165cf2e0019fa6cedc75b456490c41494c34abb4
- https://git.kernel.org/stable/c/2573f2375b64280be977431701ed5d33b75b9ad0
- https://git.kernel.org/stable/c/2888fa41985f93ed0a6837cfbb06bcbfd7fa2314
- https://git.kernel.org/stable/c/71c142f910da44421213ade601bcbd23ceae19fa
- https://git.kernel.org/stable/c/8a7da4ced236ce6637fe70f14ca18e718d4bf9e9
- https://git.kernel.org/stable/c/c55b2b983b0fa012942c3eb16384b2b722caa810
- https://git.kernel.org/stable/c/d09525720dd5201756f698bee1076de9aefd4602
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: USB: host: isp116x: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e
- https://git.kernel.org/stable/c/3592cfd8b848bf0c4d7740d78a87a7b8f6e1fa9a
- https://git.kernel.org/stable/c/3825db88d8c704e7992b685618a03f82bffcf2ef
- https://git.kernel.org/stable/c/7bffda1560a6f255fdf504e059fbbdb5d46b9e44
- https://git.kernel.org/stable/c/804de302ada3544699c5f48c5314b249af76faa3
- https://git.kernel.org/stable/c/82a101f14943f479fd190b1e5b40d91c77e2ac1b
- https://git.kernel.org/stable/c/aca0cab0e9ed33b6371aafb519a6c38f2850ffc3
- https://git.kernel.org/stable/c/c91a74b1f0f2d2d7e728742ae55e3ffe9ba7853d
- https://git.kernel.org/stable/c/ee105039d3653444de4d3ede642383c92855dc1e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drivers: tty: serial: Fix deadlock in sa1100_set_termios() There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever. This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock.
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/0976808d0d171ec837d4bd3e9f4ad4a00ab703b8
- https://git.kernel.org/stable/c/09a5958a2452ad22d0cb638711ef34ea1863a829
- https://git.kernel.org/stable/c/2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b
- https://git.kernel.org/stable/c/34d91e555e5582cffdbcbb75517bc9217866823e
- https://git.kernel.org/stable/c/553213432ef0c295becdc08c0207d2094468f673
- https://git.kernel.org/stable/c/62b2caef400c1738b6d22f636c628d9f85cd4c4c
- https://git.kernel.org/stable/c/6e2273eefab54a521d9c59efb6e1114e742bdf41
- https://git.kernel.org/stable/c/85e20f8bd31a46d8c60103d0274a8ebe8f47f2b2
- https://git.kernel.org/stable/c/920f0ae7a129ffee98a106e3bbdfd61a2a59e939
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
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/042915c1bfedd684c1d98a841794ee203200571a
- https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25
- https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710
- https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273
- https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2
- https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e
- https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
When the driver fails at alloc_hdlcdev(), and then we remove the driver
module, we will get the following splat:
[ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
[ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
[ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
[ 25.077709] Call Trace:
[ 25.077924]
[ 25.078108] unregister_hdlc_device+0x16/0x30
[ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt]
Fix this by checking whether the 'info->netdev' is a null pointer first.
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/078212ad15dbd88840c82c97f12c93d83703c8fd
- https://git.kernel.org/stable/c/1ceb4ca9543a8a788febf6bc8dad2e605e172d5e
- https://git.kernel.org/stable/c/50c341f9a2adc4c32a8ad5a39eb99d9c4a419e0d
- https://git.kernel.org/stable/c/689ca31c542687709ba21ec2195c1fbce34fd029
- https://git.kernel.org/stable/c/8a95696bdc0e13f8980f05b54a3b9081963d1256
- https://git.kernel.org/stable/c/ba08cbc5b53e151d0acf1930fb526fc65b7f3e65
- https://git.kernel.org/stable/c/d68d5e68b7f64de7170f8e04dd9b995c36b2c71c
- https://git.kernel.org/stable/c/ddd67751ab86c6a65f95c35293c42f85a42ac05d
- https://git.kernel.org/stable/c/f6e07eb7ebec53ffe81fc2489589320fbe4a6b75
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
extcon: Modify extcon device to be created after driver data is set
Currently, someone can invoke the sysfs such as state_show()
intermittently before dev_set_drvdata() is done.
And it can be a cause of kernel Oops because of edev is Null at that time.
So modified the driver registration to after setting drviver data.
- Oops's backtrace.
Backtrace:
[] (state_show) from [] (dev_attr_show)
[] (dev_attr_show) from [] (sysfs_kf_seq_show)
[] (sysfs_kf_seq_show) from [] (kernfs_seq_show)
[] (kernfs_seq_show) from [] (seq_read)
[] (seq_read) from [] (kernfs_fop_read)
[] (kernfs_fop_read) from [] (__vfs_read)
[] (__vfs_read) from [] (vfs_read)
[] (vfs_read) from [] (ksys_read)
[] (ksys_read) from [] (sys_read)
[] (sys_read) from [] (__sys_trace_return)
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/033ec4e7e59ae5e1ef1e8c10bc6552926044ed1c
- https://git.kernel.org/stable/c/35ff1ac55d301efb3f467cf5426faaeb3452994b
- https://git.kernel.org/stable/c/368e68ad6da4317fc4170e8d92b51c13d1bfe7a7
- https://git.kernel.org/stable/c/5dcc2afe716d69f5112ce035cb14f007461ff189
- https://git.kernel.org/stable/c/6e721f3ad0535b24f19a62420f4da95212cf069c
- https://git.kernel.org/stable/c/abf3b222614f49f98e606fccdd269161c0d70204
- https://git.kernel.org/stable/c/cb81ea998c461868d1168411a867d8ffee12f23f
- https://git.kernel.org/stable/c/d472c78cc82999d07bd09193a6718016ce9cd386
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.
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/2dcec0bc142be2096af71a5703d63237127db204
- https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868
- https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524
- https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58
- https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124
- https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677
- https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab
- https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221
- https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tty: Fix a possible resource leak in icom_probe When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated.
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/23e155b51d403c0ccedc60c0d6c3c452afed07fe
- https://git.kernel.org/stable/c/5f9b2e4ca88cab1a96b86ecd45544e488ca43faf
- https://git.kernel.org/stable/c/8c014373f178a4f13a08e045ef63bdb23f62e892
- https://git.kernel.org/stable/c/9a8305f357a8d03698fc7bc855ff9c6865d5486b
- https://git.kernel.org/stable/c/a2df0b4d080cc770b4da7bff487048c803dfd07e
- https://git.kernel.org/stable/c/cb7147afd328c07edeeee287710d8d96ac0459f5
- https://git.kernel.org/stable/c/d703d912a985c1c5b50dd38c3181fc3540fa77cb
- https://git.kernel.org/stable/c/ee157a79e7c82b01ae4c25de0ac75899801f322c
- https://git.kernel.org/stable/c/f4c836d90da1ece88905d62ce2ce39a962f25d1a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
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/08bacf871c019163ccd1389d0bc957a43324967a
- https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada
- https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446
- https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12
- https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72
- https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b
- https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303
- https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db
- https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Don't hold the layoutget locks across multiple RPC calls When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock.
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/08d7a26d115cc7892668baa9750f64bd8baca29b
- https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c
- https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee
- https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010
- https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd
- https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e
- https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ...
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/11270e7ca268e8d61b5d9e5c3a54bd1550642c9c
- https://git.kernel.org/stable/c/8dbae5affbdbf524b48000f9d357925bb001e5f4
- https://git.kernel.org/stable/c/8e3943c50764dc7c5f25911970c3ff062ec1f18c
- https://git.kernel.org/stable/c/90c4f73104016748533a5707ecd15930fbeff402
- https://git.kernel.org/stable/c/91784f3d77b73885e1b2e6b59d3cbf0de0a1126a
- https://git.kernel.org/stable/c/998d35a2aff4b81a1c784f3aa45cd3afff6814c1
- https://git.kernel.org/stable/c/a3fc8051ee061e31db13e2fe011e8e0b71a7f815
- https://git.kernel.org/stable/c/da99331fa62131a38a0947a8204c5208de7b0454
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
be triggered.
Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
[] try_to_wake_up+0x7e/0xba0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
dump_stack_lvl+0x60/0x8c
dump_stack+0x10/0x12
__might_resched.cold+0x11d/0x155
rt_spin_lock+0x40/0x70
trace_event_buffer_commit+0x2fa/0x4c0
? map_vsyscall+0x93/0x93
trace_event_raw_event_initcall_start+0xbe/0x110
? perf_trace_initcall_finish+0x210/0x210
? probe_sched_wakeup+0x34/0x40
? ttwu_do_wakeup+0xda/0x310
? trace_hardirqs_on+0x35/0x170
? map_vsyscall+0x93/0x93
do_one_initcall+0x217/0x3c0
? trace_event_raw_event_initcall_level+0x170/0x170
? push_cpu_stop+0x400/0x400
? cblist_init_generic+0x241/0x290
kernel_init_freeable+0x1ac/0x347
? _raw_spin_unlock_irq+0x65/0x80
? rest_init+0xf0/0xf0
kernel_init+0x1e/0x150
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/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd
- https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762
- https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4
- https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b
- https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0
- https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59
- https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec
- https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mips: cpc: Fix refcount leak in mips_cpc_default_phys_base Add the missing of_node_put() to release the refcount incremented by of_find_compatible_node().
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/1699ec1bfb59304a788901474f6bb003f7831b61
- https://git.kernel.org/stable/c/4107fa700f314592850e2c64608f6ede4c077476
- https://git.kernel.org/stable/c/8f843cdfc202caaa5d67db3395d893e56362e43a
- https://git.kernel.org/stable/c/961ee8a6eeef4632a215d995d837b204f8c7c2d4
- https://git.kernel.org/stable/c/aae6b4bb63c694bc91714412718f15468407fe51
- https://git.kernel.org/stable/c/bed702566dcdb6ebe300bc0c62bf3600cf4d5874
- https://git.kernel.org/stable/c/c667b3872a4c435a3f29d4e15971cd8c378b0043
- https://git.kernel.org/stable/c/cc0aed22d33ced9e266c50bdf1cbe668c5acfdf8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized.
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/6ad81ad0cf5744738ce94c8e64051ddd80a1734c
- https://git.kernel.org/stable/c/746285cf81dc19502ab238249d75f5990bd2d231
- https://git.kernel.org/stable/c/769ec2a824deae2f1268dfda14999a4d14d0d0c5
- https://git.kernel.org/stable/c/98e55b0b876bde3353f4e074883d66ecb55c65a3
- https://git.kernel.org/stable/c/9ad1981fc4de3afb7db3e8eb5a6a52d4c7d0d577
- https://git.kernel.org/stable/c/9d5e96cc1f1720019ce27b127a31695148d38bb0
- https://git.kernel.org/stable/c/b5dca2cd3f0239512da808598b4e70557eb4c2a1
- https://git.kernel.org/stable/c/b8ce58ab80faaea015c206382041ff3bcf5495ff
- https://git.kernel.org/stable/c/d7e30dfc166d33470bba31a42f9bbc346e5409d5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
syzbot got a new report [1] finally pointing to a very old bug,
added in initial support for MTU probing.
tcp_mtu_probe() has checks about starting an MTU probe if
tcp_snd_cwnd(tp) >= 11.
But nothing prevents tcp_snd_cwnd(tp) to be reduced later
and before the MTU probe succeeds.
This bug would lead to potential zero-divides.
Debugging added in commit 40570375356c ("tcp: add accessors
to read/set tp->snd_cwnd") has paid off :)
While we are at it, address potential overflows in this code.
[1]
WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Modules linked in:
CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356
tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861
tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973
tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476
sk_backlog_rcv include/net/sock.h:1061 [inline]
__release_sock+0x1d8/0x4c0 net/core/sock.c:2849
release_sock+0x5d/0x1c0 net/core/sock.c:3404
sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145
tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410
tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
__sys_sendto+0x439/0x5c0 net/socket.c:2119
__do_sys_sendto net/socket.c:2131 [inline]
__se_sys_sendto net/socket.c:2127 [inline]
__x64_sys_sendto+0xda/0xf0 net/socket.c:2127
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f6431289109
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109
RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a
RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000
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/11825765291a93d8e7f44230da67b9f607c777bf
- https://git.kernel.org/stable/c/29e13f6b38f0816af2012e0725507754e8f4569c
- https://git.kernel.org/stable/c/38ca71a24cd4845021eed35fd2594d89dba9a5a8
- https://git.kernel.org/stable/c/42726877453afdbe1508a8a96884ea907741d9a7
- https://git.kernel.org/stable/c/602b338e3c3cd7f935f3f5011882961d074e5ac1
- https://git.kernel.org/stable/c/90385f2b65d0cd2b3b1ac8909f0cc6dd31062cfc
- https://git.kernel.org/stable/c/9ba2b4ac35935f05ac98cff722f36ba07d62270e
- https://git.kernel.org/stable/c/aa7f333efd1138a68517a6a6a69ae540dd59d800
- https://git.kernel.org/stable/c/f2845e1504a3bc4f3381394f057e8b63cb5f3f7a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure 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/3eca2c42daa4659965db6817479027cbc6df7899
- https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f
- https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd
- https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74
- https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded
- https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe
- https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383
- https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7
- https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
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/15c3bcc9b5349d40207e5f8d4d799b8b4b7d13b8
- https://git.kernel.org/stable/c/20b947e5a3c74c5084d661c097517a554989d462
- https://git.kernel.org/stable/c/31ab27b14daaa75541a415c6794d6f3567fea44a
- https://git.kernel.org/stable/c/70276460e914d560e96bfc208695a872fe9469c9
- https://git.kernel.org/stable/c/7086a23890d255bb5761604e39174b20d06231a4
- https://git.kernel.org/stable/c/8189f44270db1be78169e11eec51a3eeb980bc63
- https://git.kernel.org/stable/c/aa25acbe96692e4bf8482311c293f72d8c6034c0
- https://git.kernel.org/stable/c/be585921f29df5422a39c952d188b418ad48ffab
- https://git.kernel.org/stable/c/c12984cdb077b9042d2dc20ca18cb16a87bcc774
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_lock failed, it didn't clean up the flags it set
before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of
lock is still in used, next time when unlink invokes this function, it
will return succeed, and then unlink will remove inode and dentry if lock
is not in used(file closed), but the dlm lock is still linked in dlm lock
resource, then when bast come in, it will trigger a panic due to
user-after-free. See the following panic call trace. To fix this,
USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should
be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink
fail.
For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,
USER_LOCK_BUSY is also required to be cleared. Even though spin lock is
released in between, but USER_LOCK_IN_TEARDOWN is still set, for
USER_LOCK_BUSY, if before every place that waits on this flag,
USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow
waits on the busy flag set by user_dlm_destroy_lock(), then we can
simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix
user_dlm_cluster_lock() which is the only function not following this.
[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink
004fb0000060000b5a90b8c847b72e1, error -16 from destroy
[ 989.757536] ------------[ cut here ]------------
[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!
[ 989.757876] invalid opcode: 0000 [#1] SMP
[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)
ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc
xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5
auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs
ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc
fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc
rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad
rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)
mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad
ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support
pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si
ipmi_msghandler
[ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp
pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel
be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio
libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi
dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
ksplice_2zhuk2jr_ib_ipoib_old]
[ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE
4.1.12-124.57.1.el6uek.x86_64 #2
[ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021
[ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:
ffff88017f7c8000
[ 989.762848] RIP: e030:[] []
__user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]
[ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246
[ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:
0000000000000003
[ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:
ffff880174d48170
[ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:
0000000000000000
[ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:
ffff880174d48008
[ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:
ffff88021db7a000
[ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)
knlGS:ffff880247480000
[ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:
0000000000042660
[ 989.765081] Stack:
[ 989.765167] 00000000000
---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/02480e2e82ae0e5588374bbbcf4fa6e4959fa174
- https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207c
- https://git.kernel.org/stable/c/2c5e26a626fe46675bceba853e12aaf13c712e10
- https://git.kernel.org/stable/c/337e36550788dbe03254f0593a231c1c4873b20d
- https://git.kernel.org/stable/c/733a35c00ef363a1c774d7ea486e0735b7c13a15
- https://git.kernel.org/stable/c/82bf8e7271fade40184177cb406203addc34c4a0
- https://git.kernel.org/stable/c/863e0d81b6683c4cbc588ad831f560c90e494bef
- https://git.kernel.org/stable/c/9c96238fac045b289993d7bc5aae7b2d72b25c76
- https://git.kernel.org/stable/c/efb54ec548829e1d3605f0434526f86e345b1b28
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the caller (net/ipv6/seg6.c) and the callee (net/ipv6/seg6_hmac.c) belong to the same module. It seems an internal function call in ipv6.ko.
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/1084716f76c8045eadf92a9d9a62641f3c8d8c90
- https://git.kernel.org/stable/c/317260b3eb6384a05a8af212308fa50f3b2e8290
- https://git.kernel.org/stable/c/3e6de5037148c5a93a436b1e8d2edad3dac11755
- https://git.kernel.org/stable/c/5801f064e35181c71857a80ff18af4dbec3c5f5c
- https://git.kernel.org/stable/c/5d9c1b081ad28c852a97e10dd75412546497694a
- https://git.kernel.org/stable/c/64aef8efe96c1616142c4476a05731306fc4494e
- https://git.kernel.org/stable/c/9ba4416b831eeb4d185e88e73488d1d21288e63a
- https://git.kernel.org/stable/c/ab8b2c2de273ec1d698a18e399896a6febb5cda0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local checksum offload on CHECKSUM_PARTIAL packets. ipgre_xmit must validate csum_start after an optional skb_pull, else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; This had false positives when skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement was straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; But was eventually revised more thoroughly: - restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull. - test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath. Turns out skbs can arrive in this branch without the transport header set, e.g., through BPF redirection. Revise the check back to check csum_start directly, and only if CHECKSUM_PARTIAL. Do leave the check in the updated location. Check field regardless of whether TUNNEL_CSUM is configured.
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/0c92d813c7c9ca2212ecd879232e7d87362fce98
- https://git.kernel.org/stable/c/0ffa268724656633af5f37a38c212326d98ebe8c
- https://git.kernel.org/stable/c/3d08bc3a5d9b2106f5c8bcf1adb73147824aa006
- https://git.kernel.org/stable/c/7596bd7920985f7fc8579a92e48bc53ce4475b21
- https://git.kernel.org/stable/c/8d21e9963bec1aad2280cdd034c8993033ef2948
- https://git.kernel.org/stable/c/e6b6f98fc7605c06c0a3baa70f62c534d7b4ce58
- https://git.kernel.org/stable/c/fbeb8dfa8b87ef259eef0c89e39b53962a3cf604
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0cf7aaff290cdc4d7cee683d4a18138b0dacac48
- https://git.kernel.org/stable/c/10f3b29c65bb2fe0d47c2945cd0b4087be1c5218
- https://git.kernel.org/stable/c/3f4d5e727aeaa610688d46c9f101f78b7f712583
- https://git.kernel.org/stable/c/41f7c4f85d402043687e863627a1a84fa867c62d
- https://git.kernel.org/stable/c/5c25a3040bc0486c41a7b63a1fb0de7cdb846ad7
- https://git.kernel.org/stable/c/aaf61a312af63e1cfe2264c4c5b8cd4ea3626025
- https://git.kernel.org/stable/c/e412b3d178ea4bf746f6b8ee086761613704c6be
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique.
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/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3
- https://git.kernel.org/stable/c/3a3ce941645407cd0b0b7f01ad9e2ea3770f46cc
- https://git.kernel.org/stable/c/3ba733f879c2a88910744647e41edeefbc0d92b2
- https://git.kernel.org/stable/c/6084240bfc44bf265ab6ae7d96980469b05be0f1
- https://git.kernel.org/stable/c/b3ad9ff6f06c1dc6abf7437691c88ca3d6da3ac0
- https://git.kernel.org/stable/c/d5a16a6df2c16eaf4de04948553ef0089dee463f
- https://git.kernel.org/stable/c/e157c8f87e8fac112d6c955e69a60cdb9bc80a60
- https://git.kernel.org/stable/c/ff4cafa51762da3824881a9000ca421d4b78b138
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race.
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/556720013c36c193d9cbfb06e7b33e51f0c39fbf
- https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432
- https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2
- https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6
- https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca
- https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f
- https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean)
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/2b253fbc9f7b5db18d716436bdcf8ecef09fd63d
- https://git.kernel.org/stable/c/31f3c6a4dcd3260a386e62cef2d5b36e902600a1
- https://git.kernel.org/stable/c/4a388f08d8784af48f352193d2b72aaf167a57a1
- https://git.kernel.org/stable/c/85a055c03691e51499123194a14a0c249cf33227
- https://git.kernel.org/stable/c/be3884d5cd04ccd58294b83a02d70b7c5fca19d3
- https://git.kernel.org/stable/c/c58d82a1264813e69119c13e9804e2e60b664ad5
- https://git.kernel.org/stable/c/e04d59cfe0c0129df7aba7ef7bb17b96be2a64f2
- https://git.kernel.org/stable/c/e53cd3814504b2cadaba4d5a8a07eeea9ddacd03
- https://git.kernel.org/stable/c/ef6d2354de238b065d8799c80da4be9a6af18e39
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on in ext4_writepages
we got issue as follows:
EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls
------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2708!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155
RIP: 0010:ext4_writepages+0x1977/0x1c10
RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000
RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002
RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000
R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001
R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028
FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
do_writepages+0x130/0x3a0
filemap_fdatawrite_wbc+0x83/0xa0
filemap_flush+0xab/0xe0
ext4_alloc_da_blocks+0x51/0x120
__ext4_ioctl+0x1534/0x3210
__x64_sys_ioctl+0x12c/0x170
do_syscall_64+0x3b/0x90
It may happen as follows:
1. write inline_data inode
vfs_write
new_sync_write
ext4_file_write_iter
ext4_buffered_write_iter
generic_perform_write
ext4_da_write_begin
ext4_da_write_inline_data_begin -> If inline data size too
small will allocate block to write, then mapping will has
dirty page
ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA
2. fallocate
do_vfs_ioctl
ioctl_preallocate
vfs_fallocate
ext4_fallocate
ext4_convert_inline_data
ext4_convert_inline_data_nolock
ext4_map_blocks -> fail will goto restore data
ext4_restore_inline_data
ext4_create_inline_data
ext4_write_inline_data
ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA
3. writepages
__ext4_ioctl
ext4_alloc_da_blocks
filemap_flush
filemap_fdatawrite_wbc
do_writepages
ext4_writepages
if (ext4_has_inline_data(inode))
BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
The root cause of this issue is we destory inline data until call
ext4_writepages under delay allocation mode. But there maybe already
convert from inline to extent. To solve this issue, we call
filemap_flush first..
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/013f12bdedb96816aaa27ee04349f4433d361f52
- https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4
- https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce
- https://git.kernel.org/stable/c/1b061af037646c9cdb0afd8a8d2f1e1c06285866
- https://git.kernel.org/stable/c/1cde35417edc0370fb0179a4e38b78a15350a8d0
- https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9
- https://git.kernel.org/stable/c/b2b78f5bf2d453dda3903955efee059260787a42
- https://git.kernel.org/stable/c/de1732b5c1693ad489c5d254f124f67cb775f37d
- https://git.kernel.org/stable/c/ef09ed5d37b84d18562b30cf7253e57062d0db05
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ]
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/0be698ecbe4471fcad80e81ec6a05001421041b3
- https://git.kernel.org/stable/c/0ff38b99fa075ddd246487a28cb9af049f4ceef1
- https://git.kernel.org/stable/c/10801095224de0d0ab06ae60698680c1f883a3ae
- https://git.kernel.org/stable/c/1a3a15bf6f9963d755270cbdb282863b84839195
- https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f
- https://git.kernel.org/stable/c/4a2bea60cf7ff957b3eda0b17750d483876a02fa
- https://git.kernel.org/stable/c/97f802a652a749422dede32071d29a53cf4bd034
- https://git.kernel.org/stable/c/dd887f83ea54aea5b780a84527e23ab95f777fed
- https://git.kernel.org/stable/c/eaecf7ebfd5dd09038a80b14be46b844f54cfc5c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phy_device.c is never compiled as modular. (CONFIG_PHYLIB is boolean)
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/35b42dce619701f1300fb8498dae82c9bb1f0263
- https://git.kernel.org/stable/c/5534bcd7c40299862237c4a8fd9c5031b3db1538
- https://git.kernel.org/stable/c/59fa94cddf9eef8d8dae587373eed8b8f4eb11d7
- https://git.kernel.org/stable/c/6a90a44d53428a3bf01bd80df9ba78b19959270c
- https://git.kernel.org/stable/c/7759c3222815b945a94b212bc0c6cdec475cfec2
- https://git.kernel.org/stable/c/ab64ec2c75683f30ccde9eaaf0761002f901aa12
- https://git.kernel.org/stable/c/f2f0f8c18b60ca64ff50892ed899cf1c77864755
- https://git.kernel.org/stable/c/f5c68137f1191ba3fcf6260ec71b30be2e2bf4c3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid 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/11ec18b1d8d92b9df307d31950dcba0b3dd7283c
- https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584
- https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de
- https://git.kernel.org/stable/c/5cd0e22fa11f4a21a8c09cc258f20b1474c95801
- https://git.kernel.org/stable/c/803b217f1fb49a2dbb2123acdb45111b9c48b8be
- https://git.kernel.org/stable/c/8174acbef87b8dd8bf3731eba2a5af1ac857e239
- https://git.kernel.org/stable/c/96bf5ed057df2d157274d4e2079002f9a9404bb8
- https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833
- https://git.kernel.org/stable/c/e31d9ba169860687dba19bdc8fccbfd34077f655
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid 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/10d6bdf532902be1d8aa5900b3c03c5671612aa2
- https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1
- https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf
- https://git.kernel.org/stable/c/888312dc297a8a103f6371ef668c7e04f57a7679
- https://git.kernel.org/stable/c/8d8ad067b90f231b8fdb14acee673ca4012f6045
- https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b
- https://git.kernel.org/stable/c/c9782e1b21bee4b783a64b2a91e7e71406c21a21
- https://git.kernel.org/stable/c/d5a1e7f33c88780b279835d63665d7e38ccb671f
- https://git.kernel.org/stable/c/fb2cb409b504bb3a69e65a17f3120328c8e50219
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid 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/02ded5a173619b11728b8bf75a3fd995a2c1ff28
- https://git.kernel.org/stable/c/42658e47f1abbbe592007d3ba303de466114d0bb
- https://git.kernel.org/stable/c/86c3c5f8e4bd1325e24f6fba9017cade29933377
- https://git.kernel.org/stable/c/8a1a1255152da4fb934290e7ababc66f24985520
- https://git.kernel.org/stable/c/a101793994c0a14c70bb4e44c7fda597eeebba0a
- https://git.kernel.org/stable/c/c1df9cb756e5a9ba1841648c44ee5d92306b9c65
- https://git.kernel.org/stable/c/dc1cf8c6f9793546696fded437a5b4c84944c48b
- https://git.kernel.org/stable/c/e0d763d0c7665c7897e4f5a0847ab0c82543345f
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8
- https://git.kernel.org/stable/c/2bd1faedb74dc2a2be3972abcd4239b75a3e7b00
- https://git.kernel.org/stable/c/4cde554c70d7397cfa2e4116bacb4accdfb6fd48
- https://git.kernel.org/stable/c/5ba81f82607ead85fe36f50869fc4f5661359ab8
- https://git.kernel.org/stable/c/657e7174603f0aab2cdedc64ac81edffd2a87afe
- https://git.kernel.org/stable/c/71ae30662ec610b92644d13f79c78f76f17873b3
- https://git.kernel.org/stable/c/b24ca1cf846273361d5bd73a35de95a486a54b6d
- https://git.kernel.org/stable/c/b4f0e57ea0d867aacffad7999527e48bd4ea9293
- https://git.kernel.org/stable/c/e7e7104e2d5ddf3806a28695670f21bef471f1e1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle 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 this issue 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/3ba359ebe914ac3f8c6c832b28007c14c39d3766
- https://git.kernel.org/stable/c/660ba678f9998aca6db74f2dd912fa5124f0fa31
- https://git.kernel.org/stable/c/985706bd3bbeffc8737bc05965ca8d24837bc7db
- https://git.kernel.org/stable/c/a724634b2a49f6ff0177a9e19a5a92fc1545e1b7
- https://git.kernel.org/stable/c/a9bfb37d6ba7c376b0d53337a4c5f5ff324bd725
- https://git.kernel.org/stable/c/c66cc3c62870a27ea8f060a7e4c1ad8d26dd3f0d
- https://git.kernel.org/stable/c/ec752973aa721ee281d5441e497364637c626c7b
- https://git.kernel.org/stable/c/ed38d04342dfbe9e5aca745c8b5eb4188a74f0ef
- https://git.kernel.org/stable/c/fdffa4ad8f6bf1ece877edfb807f2b2c729d8578
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_rtx_synack() can be called from process context
Laurent reported the enclosed report [1]
This bug triggers with following coditions:
0) Kernel built with CONFIG_DEBUG_PREEMPT=y
1) A new passive FastOpen TCP socket is created.
This FO socket waits for an ACK coming from client to be a complete
ESTABLISHED one.
2) A socket operation on this socket goes through lock_sock()
release_sock() dance.
3) While the socket is owned by the user in step 2),
a retransmit of the SYN is received and stored in socket backlog.
4) At release_sock() time, the socket backlog is processed while
in process context.
5) A SYNACK packet is cooked in response of the SYN retransmit.
6) -> tcp_rtx_synack() is called in process context.
Before blamed commit, tcp_rtx_synack() was always called from BH handler,
from a timer handler.
Fix this by using TCP_INC_STATS() & NET_INC_STATS()
which do not assume caller is in non preemptible context.
[1]
BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
caller is tcp_rtx_synack.part.0+0x36/0xc0
CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1
Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
Call Trace:
dump_stack_lvl+0x48/0x5e
check_preemption_disabled+0xde/0xe0
tcp_rtx_synack.part.0+0x36/0xc0
tcp_rtx_synack+0x8d/0xa0
? kmem_cache_alloc+0x2e0/0x3e0
? apparmor_file_alloc_security+0x3b/0x1f0
inet_rtx_syn_ack+0x16/0x30
tcp_check_req+0x367/0x610
tcp_rcv_state_process+0x91/0xf60
? get_nohz_timer_target+0x18/0x1a0
? lock_timer_base+0x61/0x80
? preempt_count_add+0x68/0xa0
tcp_v4_do_rcv+0xbd/0x270
__release_sock+0x6d/0xb0
release_sock+0x2b/0x90
sock_setsockopt+0x138/0x1140
? __sys_getsockname+0x7e/0xc0
? aa_sk_perm+0x3e/0x1a0
__sys_setsockopt+0x198/0x1e0
__x64_sys_setsockopt+0x21/0x30
do_syscall_64+0x38/0xc0
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/0a0f7f84148445c9f02f226928803a870139d820
- https://git.kernel.org/stable/c/0a375c822497ed6ad6b5da0792a12a6f1af10c0b
- https://git.kernel.org/stable/c/3db889f883e65bbd3b1401279bfc1e9ed255c481
- https://git.kernel.org/stable/c/58bd38cbc961fd799842b7be8c5222310f04b908
- https://git.kernel.org/stable/c/88cd232146207ff1d41dededed5e77c0d4438113
- https://git.kernel.org/stable/c/bdc28a8fb43cc476e33b11519235adb816ce00e8
- https://git.kernel.org/stable/c/c348b0f8d035fc4bdc040796889beec7218bd1b8
- https://git.kernel.org/stable/c/d05c2fdf8e10528bb6751bd95243e862d5402a9b
- https://git.kernel.org/stable/c/d8e1bc6029acac796293310aacef7b7336f35b6a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tipc: check attribute length for bearer name syzbot reported uninit-value: ===================================================== BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME. - Do not use 'illegal name' in printing message.
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/292be63c382ce20673ee61dff1ee9ed4a3dcaae7
- https://git.kernel.org/stable/c/3af15272cde28fe5c8489174b8624e232c1775ec
- https://git.kernel.org/stable/c/7f36f798f89bf32c0164049cb0e3fd1af613d0bb
- https://git.kernel.org/stable/c/8b91d0dfc839e67708c905648cd0e7507a2263e5
- https://git.kernel.org/stable/c/92a930fcf4250fe961f6238b99af0bc405799f39
- https://git.kernel.org/stable/c/b8fac8e321044a9ac50f7185b4e9d91a7745e4b0
- https://git.kernel.org/stable/c/f07670871f4d19e613740eebe210e7e9ea535973
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3867f0bbb94773d41e789257abec0d14f37da217
- https://git.kernel.org/stable/c/58a729c55ce3a432eb827fdaa24c7909cd3b0a6b
- https://git.kernel.org/stable/c/6ecd4d5c28408df36a1a6f0b1973f633c949ac1f
- https://git.kernel.org/stable/c/79fa3f5758d8712df0678df98161f948fc4370e5
- https://git.kernel.org/stable/c/82bfea344e8f7e9a0e0b1bf9af27552baa756620
- https://git.kernel.org/stable/c/865051de2d9eaa50630e055b73921ceaf3c4a7fc
- https://git.kernel.org/stable/c/d3b43eb505bffb8e4cdf6800c15660c001553fe6
- https://git.kernel.org/stable/c/d77f28c1bc9d3043a52069fe42e4a26fbf961ebd
- https://git.kernel.org/stable/c/da38e86d6cf6dd3bc65c602d998f357145aa1a0b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_fill_super
If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
an error, we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff888105a65340 (size 64):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
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+0x475/0x8a0
[] jffs2_sum_init+0x96/0x1a0
[] jffs2_do_mount_fs+0x745/0x2120
[] jffs2_do_fill_super+0x35c/0x810
[] jffs2_fill_super+0x2b9/0x3b0
[...]
unreferenced object 0xffff8881bd7f0000 (size 65536):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
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_order+0xda/0x110
[] kmalloc_order_trace+0x21/0x130
[] __kmalloc+0x711/0x8a0
[] jffs2_sum_init+0xd9/0x1a0
[] jffs2_do_mount_fs+0x745/0x2120
[] jffs2_do_fill_super+0x35c/0x810
[] jffs2_fill_super+0x2b9/0x3b0
[...]
--------------------------------------------
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/28048a4cf3813b7cf5cc8cce629dfdc7951cb1c2
- https://git.kernel.org/stable/c/3252d327f977b14663a10967f3b0930d6c325687
- https://git.kernel.org/stable/c/4ba7bbeab8009faf3a726e565d98816593ddd5b0
- https://git.kernel.org/stable/c/4da8763a3d2b684c773b72ed80fad40bc264bc40
- https://git.kernel.org/stable/c/69295267c481545f636b69ff341b8db75aa136b9
- https://git.kernel.org/stable/c/c14adb1cf70a984ed081c67e9d27bc3caad9537c
- https://git.kernel.org/stable/c/cf9db013e167bc8fc2ecd7a13ed97a37df0c9dab
- https://git.kernel.org/stable/c/d3a4fff1e7e408c32649030daa7c2c42a7e19a95
- https://git.kernel.org/stable/c/ecc53e58596542791e82eff00702f8af7a313f70
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid 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/042571fe1d171773655ad706715ecc865913d9a4
- https://git.kernel.org/stable/c/28133325526b92921f3269fdf97a20d90b92b217
- https://git.kernel.org/stable/c/5b3e990f85eb034faa461e691e719e8ce9e2a3c8
- https://git.kernel.org/stable/c/69a30b2ed620c2206cbbd1e9c112e4fc584e02bd
- https://git.kernel.org/stable/c/8f64e84924604bb969ee1fbc4b8d7d09b9214889
- https://git.kernel.org/stable/c/9b59588d8be91c96bfb0371e912ceb4f16315dbf
- https://git.kernel.org/stable/c/aab25b669cb9fd3698c2631be4435f4fe92d9e59
- https://git.kernel.org/stable/c/d5422f323858cad3ac3581075f9a3a5e0d41c0d8
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link].
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/1174ab8ba36a48025b68b5ff1085000b1e510217
- https://git.kernel.org/stable/c/25ff1e3a1351c0d936dd1ac2f9e58231ea1510c9
- https://git.kernel.org/stable/c/5ff2514e4fb55dcf3d88294686040ca73ea0c1a2
- https://git.kernel.org/stable/c/6d8d3f68cbecfd31925796f0fb668eb21ab06734
- https://git.kernel.org/stable/c/8302620aeb940f386817321d272b12411ae7d39f
- https://git.kernel.org/stable/c/8c03a1c21d72210f81cb369cc528e3fde4b45411
- https://git.kernel.org/stable/c/abb67043060f2bf4c03d7c3debb9ae980e2b6db3
- https://git.kernel.org/stable/c/e27ecf325e51abd06aaefba57a6322a46fa4178b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review.
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/11c65408bd0ba1d9cd1307caa38169292de9cdfb
- https://git.kernel.org/stable/c/247d3809e45a34d9e1a3a2bb7012e31ed8b46031
- https://git.kernel.org/stable/c/2f0ae93ec33c8456cdfbf7876b80403a6318ebce
- https://git.kernel.org/stable/c/51422046be504515eb5a591adf0f424b62f46804
- https://git.kernel.org/stable/c/6bafee2f18af5e5ac125e42960bc65496d0e56a0
- https://git.kernel.org/stable/c/8afb048800919d0ab10c57983940eba956339f21
- https://git.kernel.org/stable/c/9ec4cbf1cc55d126759051acfe328d489c5d6e60
- https://git.kernel.org/stable/c/bcbb795a9e78180d74c6ab21518da87e803dfdce
- https://git.kernel.org/stable/c/f20d2d3b3364ce6525c050a8b6b4c54c8c19674d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix inflight count imbalances and IO hangs on offline iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.
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/515d077ee3085ae343b6bea7fd031f9906645f38
- https://git.kernel.org/stable/c/5b0ff3ebbef791341695b718f8d2870869cf1d01
- https://git.kernel.org/stable/c/77692c02e1517c54f2fd0535f41aa4286ac9f140
- https://git.kernel.org/stable/c/8a177a36da6c54c98b8685d4f914cb3637d53c0d
- https://git.kernel.org/stable/c/968f7a239c590454ffba79c126fbe0e963a0ba78
- https://git.kernel.org/stable/c/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547
- https://git.kernel.org/stable/c/d19fa8f252000d141f9199ca32959c50314e1f05
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: um: Fix out-of-bounds read in LDT setup syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================
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/10995a382271254bd276627ec74136da4a23c4a6
- https://git.kernel.org/stable/c/24ca648bf5f72ed8878cf09b5d4431935779681e
- https://git.kernel.org/stable/c/2a4a62a14be1947fa945c5c11ebf67326381a568
- https://git.kernel.org/stable/c/3549ab4b962cf619e8c55484a0d870a34b3f845f
- https://git.kernel.org/stable/c/668ca34a428d6ffc0f99a1a6a9b661a288d4183b
- https://git.kernel.org/stable/c/91e5ba2af2d729d5126aefd5aa3eadc69b8426e5
- https://git.kernel.org/stable/c/9caad70819aef3431abaf73ba5163b55b161aba0
- https://git.kernel.org/stable/c/cf0dabc37446c5ee538ae7b4c467ab0e53fa5463
- https://git.kernel.org/stable/c/ef1dc929a1e5fa1b2d842256db9fb8710d3be910
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix reset-controller leak on probe errors Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly.
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/2156dc390402043ba5982489c6625adcb0b0975c
- https://git.kernel.org/stable/c/4d2900f20edfe541f75756a00deeb2ffe7c66bc1
- https://git.kernel.org/stable/c/7ac21b24af859c097eb4034e93430056068f8f31
- https://git.kernel.org/stable/c/8c03eb0c8982677b4e17174073a011788891304d
- https://git.kernel.org/stable/c/a39d9eccb333b8c07c43ebea1c6dfda122378a0f
- https://git.kernel.org/stable/c/b7b5fbcaac5355e2e695dc0c08a0fcf248250388
- https://git.kernel.org/stable/c/ba173a6f8d8dffed64bb13ab23081bdddfb464f0
- https://git.kernel.org/stable/c/feb05b10b3ed3ae21b851520a0d0b71685439517
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix struct clk leak on probe errors Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral).
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/1668ad103679306ba2ef37f758d704e58a3ef1a0
- https://git.kernel.org/stable/c/621a4bcfb7aa031e7760d7b156bad7a45df58387
- https://git.kernel.org/stable/c/6f3673c8d8eff0c4ab5a5ee0d3ca9717d85419b4
- https://git.kernel.org/stable/c/ad9b0fad02f9b3a06ad5ac7df11f244e316a6254
- https://git.kernel.org/stable/c/b246695636a861a09f0e2cde92bb2dd8f114f024
- https://git.kernel.org/stable/c/b999d48b0869b8599de532ff6081575a7ab5358a
- https://git.kernel.org/stable/c/f0a4bc38a12f5a0cc5ad68670d9480e91e6a94df
- https://git.kernel.org/stable/c/f8d23895a41243c6a8dbf392e531fff9497bb023
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Use tty_port_destroy() to destroy port In goldfish_tty_probe(), the port initialized through tty_port_init() should be destroyed in error paths.In goldfish_tty_remove(), qtty->port also should be destroyed or else might leak resources. Fix the above by calling tty_port_destroy().
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/241fcb79dd1df276d80b19f5f6acc9eaaaa63309
- https://git.kernel.org/stable/c/326192b99c903a2193d820c30ed936cc2402382c
- https://git.kernel.org/stable/c/45f6ce70abfb7ccf9d787781cbc4c03294a775a1
- https://git.kernel.org/stable/c/4639d1b992de8f37d66f698056875c274efcd45f
- https://git.kernel.org/stable/c/507b05063d1b7a1fcb9f7d7c47586fc4f3508f98
- https://git.kernel.org/stable/c/9ae3d073f7db5578ae1907544f0c15947e9678e6
- https://git.kernel.org/stable/c/da64f419d7f78272bfe40dde1262602d4ff6b32c
- https://git.kernel.org/stable/c/ee6c33b29e624f515202a31bf6ef0437f26a1867
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no 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/06039d8afefdbac05bcea5f397188407eba2996d
- https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a
- https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6
- https://git.kernel.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b
- https://git.kernel.org/stable/c/79c164e61f818054cd6012e9035701840d895c51
- https://git.kernel.org/stable/c/8858284dd74906fa00f04f0252c75df4893a7959
- https://git.kernel.org/stable/c/a89cb7ddf6a89bab6012e19da38b7cdb26175c19
- https://git.kernel.org/stable/c/ef5ab2e48a5f9960e2352332b7cdb7064bb49032
- https://git.kernel.org/stable/c/f93e91a0372c922c20d5bee260b0f43b4b8a1bee
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: dlm: fix plock invalid read This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated---
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/2c55155cc365861044d9e6e80e342693e8805e33
- https://git.kernel.org/stable/c/42252d0d2aa9b94d168241710a761588b3959019
- https://git.kernel.org/stable/c/49cd9eb7b9a7b88124b31e31f8e539acaf1b3a6d
- https://git.kernel.org/stable/c/56aa8d1fbd02357f3bf81bdfba1cde87ce8402fc
- https://git.kernel.org/stable/c/5a1765adf9855cf0f6d3f7e0eb4b78ca66f70dee
- https://git.kernel.org/stable/c/72f2f68970f9bdc252d59e119b385a6441b0b155
- https://git.kernel.org/stable/c/899bc4429174861122f0c236588700a4710c1fec
- https://git.kernel.org/stable/c/acdad5bc9827922ec2f2e84fd198718aa8e8ab92
- https://git.kernel.org/stable/c/e421872fa17542cf33747071fb141b0130ce9ef7
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref().
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/058cb6d86b9789377216c936506b346aaa1eb581
- https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50
- https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e
- https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f
- https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae
- https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2
- https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx.
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/265bec4779a38b65e86a25120370f200822dfa76
- https://git.kernel.org/stable/c/2965c4cdf7ad9ce0796fac5e57debb9519ea721e
- https://git.kernel.org/stable/c/4ba81e794f0fad6234f644c2da1ae14d5b95e1c4
- https://git.kernel.org/stable/c/4f05a9e15edcdf5b97e0d86ab6ecd5f187289f6c
- https://git.kernel.org/stable/c/6118bbdf69f4718b02d26bbcf2e497eb66004331
- https://git.kernel.org/stable/c/82c8e7bbdd06c7ed58e22450cc5b37f33a25bb2c
- https://git.kernel.org/stable/c/88cc8f963febe192d6ded9df7217f92f380b449a
- https://git.kernel.org/stable/c/9f1e5cc85ad77e52f54049a94db0407445ae2a34
- https://git.kernel.org/stable/c/b79110f2bf6022e60e590d2e094728a8eec3e79e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid 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/2e2e2c71b2642289438392edbf5d08cdbc0b138b
- https://git.kernel.org/stable/c/38d245cebf545338a6bc1c7762023de3fbecd7b7
- https://git.kernel.org/stable/c/51eb1bb6baeb478538dd4ec6459fd68c44a855b1
- https://git.kernel.org/stable/c/6c92711db7c90f78e0b67ac2a8944d0fe7e12d83
- https://git.kernel.org/stable/c/8db59df7f5826e104db82cfddbf22a33a151193e
- https://git.kernel.org/stable/c/b23789a59fa6f00e98a319291819f91fbba0deb8
- https://git.kernel.org/stable/c/bbb2a24e863b6a10129546a0a4ceea2f07deec39
- https://git.kernel.org/stable/c/c1c4405222b6fc98c16e8c2aa679c14e41d81465
- https://git.kernel.org/stable/c/f2dfb4ab887d67be7d0892ba041d3c8d738d3356
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dereference of stale list iterator after loop body The list iterator variable will be a bogus pointer if no break was hit. Dereferencing it (cur->page in this case) could load an out-of-bounds/undefined value making it unsafe to use that in the comparision to determine if the specific element was found. Since 'cur->page' *can* be out-ouf-bounds it cannot be guaranteed that by chance (or intention of an attacker) it matches the value of 'page' even though the correct element was not found. This is fixed by using a separate list iterator variable for the loop and only setting the original variable if a suitable element was found. Then determing if the element was found is simply checking if the variable is set.
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/2aaf51dd39afb6d01d13f1e6fe20b684733b37d5
- https://git.kernel.org/stable/c/385edd3ce5b4b1e9d31f474a5e35a39779ec1110
- https://git.kernel.org/stable/c/45b2b7d7108ae1e25a5036cab04ab9273e792332
- https://git.kernel.org/stable/c/51d584704d18e60fa473823654f35611c777b291
- https://git.kernel.org/stable/c/5e47a7add3dda7f236548c5ec3017776dc2a729f
- https://git.kernel.org/stable/c/b26e1c777890e4b938136deb8ec07a29f33862e4
- https://git.kernel.org/stable/c/ed7efc472c00986dcd6903ab6ed165c7fa167674
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent panic when SDMA is disabled If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.
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/0e4dda8b3f4c07ee9ea670a10ea3171a5e63a86f
- https://git.kernel.org/stable/c/22e7e400fd1a890db2ea13686324aff50e972f4f
- https://git.kernel.org/stable/c/29952ab85d6c3fe0b7909d9a737f10c58bf6824d
- https://git.kernel.org/stable/c/32e6aea33944f364d51cd263e4cd236393a188b6
- https://git.kernel.org/stable/c/33794e8e9bcb4affc0ebff9cdec85acc8b8a1762
- https://git.kernel.org/stable/c/629e052d0c98e46dde9f0824f0aa437f678d9b8f
- https://git.kernel.org/stable/c/cc80d3c37cec9d6ddb140483647901bc7cc6c31d
- https://git.kernel.org/stable/c/e60ad83f645ee6fadd5a8057ba267aeec54f08fe
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/xics: fix refcount leak in icp_opal_init() The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done.
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/1d5c8cea85fb1680eae8d645b96b92146cb4633c
- https://git.kernel.org/stable/c/2357bd7499a81c70b460e2191852bbfc7b63c354
- https://git.kernel.org/stable/c/537a317e5ff45d1f5a0ecaf6a0d7c8043c878cb1
- https://git.kernel.org/stable/c/53f3f7f73e609b934083f896cb7ca2c2cb009b9f
- https://git.kernel.org/stable/c/5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9
- https://git.kernel.org/stable/c/6a61a97106279c2aa16fbbb2a171fd5dde127d23
- https://git.kernel.org/stable/c/977dbc81d0f866ef63b93c127b7404f07734b3cc
- https://git.kernel.org/stable/c/9a42bc2494fadb453de00ce61042e588563ddc6d
- https://git.kernel.org/stable/c/df802880a7f9cd96b921b00639b00871f18a9a57
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent use of lock before it is initialized If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized.
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/05c03dfd09c069c4ffd783b47b2da5dcc9421f2c
- https://git.kernel.org/stable/c/288d198f50434f29b4a26a9de4394ae2305ad8af
- https://git.kernel.org/stable/c/30eb275e7ed588270ae159cc590a96658e0cfd8f
- https://git.kernel.org/stable/c/66090815a24ce14cf51ef5453fc0218fe8a39bc2
- https://git.kernel.org/stable/c/addb192000d8819c0b1553453994df9bb54c28db
- https://git.kernel.org/stable/c/ca55150bff5817af4f857a746ecab9862c23e12a
- https://git.kernel.org/stable/c/fc0750e659db7b315bf6348902cc8ca3cdd4b8d8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.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/2cdd5284035322795b0964f899eefba254cfe483
- https://git.kernel.org/stable/c/59ea6b3ae51df7cd6bfd84c9c0030609b9315622
- https://git.kernel.org/stable/c/a91ee0e9fca9d7501286cfbced9b30a33e52740a
- https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c
- https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831
- https://git.kernel.org/stable/c/c9a81f9ed6ae3554621d6a50220b1bc74b67d81e
- https://git.kernel.org/stable/c/ea047f51172aa68841adef7f52d375002438b8f0
- https://git.kernel.org/stable/c/eff3587b9c01439b738298475e555c028ac9f55e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Input: sparcspkr - fix refcount leak in bbc_beep_probe of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid 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/1124e39fea0e2fdb4202f95b716cb97cc7de7cc7
- https://git.kernel.org/stable/c/2f51db16cb740ff90086189a1ef2581eab665591
- https://git.kernel.org/stable/c/353bc58ac6c782d4dcde9136a91d1f90867938fe
- https://git.kernel.org/stable/c/418b6a3e12f75638abc5673eb76cb32127d0ab13
- https://git.kernel.org/stable/c/6e07ccc7d56130f760d23f67a70c45366c07debc
- https://git.kernel.org/stable/c/73d6f42d8d86648bec2e73d34fe1648cb6d23e08
- https://git.kernel.org/stable/c/bbc2b0ce6042dd3117827f10ea8cb67e0ab786da
- https://git.kernel.org/stable/c/c8994b30d71d64d5dcc9bc0edbfdf367171aa96f
- https://git.kernel.org/stable/c/f13064b0f2c651a3fbb0749932795c6fd21556a8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid 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/46fd994763cf6884b88a2da712af918f3ed54d7b
- https://git.kernel.org/stable/c/51e25fbf20c9152d84a34b7afac15a41fe5c9116
- https://git.kernel.org/stable/c/5607a77a365df8c0fd5ff43ac424812b95775527
- https://git.kernel.org/stable/c/5b8aa2ba38c010f47c965dd9bb5a8561813ed649
- https://git.kernel.org/stable/c/7b668a59ddfb32727e39b06fdf52b28e58c684e0
- https://git.kernel.org/stable/c/bcb6c4c5eb4836a21411dfe8247bf9951eb6e7c3
- https://git.kernel.org/stable/c/c70dd353d37158e06bf8d450d4b31a7091609924
- https://git.kernel.org/stable/c/fcee96924ba1596ca80a6770b2567ca546f9a482
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---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/04ee31678c128a6cc7bb057ea189a8624ba5a314
- https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50
- https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded
- https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28
- https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246
- https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9
- https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3
- https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede
- https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drivers/base/node.c: fix compaction sysfs file leak Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix 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:HReferences
- https://git.kernel.org/stable/c/386e69e068177ee91cac27f2f0e6ebda1515f5ca
- https://git.kernel.org/stable/c/39642b0feddb9c39faa6de469a94bfeb4dc0d3a9
- https://git.kernel.org/stable/c/466134df7561aeb801baddf6666b512e0e1a1707
- https://git.kernel.org/stable/c/606732650a2c88e66c59c22dd5464ea0d820250e
- https://git.kernel.org/stable/c/6905be93d1ab54f73718047536fec0ca488d5315
- https://git.kernel.org/stable/c/b3fcf1f583b1a0946d9d9bfb7362c9c186801775
- https://git.kernel.org/stable/c/d8a5bdc767f17281da648555cdbd286f98fd98ee
- https://git.kernel.org/stable/c/da63dc84befaa9e6079a0bc363ff0eaa975f9073
- https://git.kernel.org/stable/c/f76ddc8fcf6d81fe89bfa4d3efcbc4fe69a91d48
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: hisi: Add missing of_node_put after of_find_compatible_node of_find_compatible_node will increment the refcount of the returned device_node. 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/21a3effe446dd6dc5eed7fe897c2f9b88c9a5d6d
- https://git.kernel.org/stable/c/45d211668d33c49d73f5213e8c2b58468108647c
- https://git.kernel.org/stable/c/46cb7868811d025c3d29c10d18b3422db1cf20d5
- https://git.kernel.org/stable/c/9bc72e47d4630d58a840a66a869c56b29554cfe4
- https://git.kernel.org/stable/c/a3265a9440030068547a20dfee646666f3ca5278
- https://git.kernel.org/stable/c/cafaaae4bb9ce84a2791fa29bf6907a9466c3883
- https://git.kernel.org/stable/c/dd4be8ecfb41a29e7c4e551b4e866157ce4a3429
- https://git.kernel.org/stable/c/e109058165137ef42841abd989f080adfefa14fa
- https://git.kernel.org/stable/c/f8da78b2bae1f54746647a2bb44f8bd6025c57af
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump
up the sysctl), but whilst the preallocation circular buffers have 32 slots
in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket
is closed because rxrpc_service_prealloc_one() allocated one too many calls
and rxrpc_discard_prealloc() won't then be able to get rid of them because
it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries
to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match
the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086
...
RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]
Call Trace:
? __wake_up_common_lock+0x7a/0x90
? rxrpc_notify_socket+0x8e/0x140 [rxrpc]
? rxrpc_abort_call+0x4c/0x60 [rxrpc]
rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc]
rxrpc_release+0xc9/0x1c0 [rxrpc]
__sock_release+0x37/0xa0
sock_close+0x11/0x20
__fput+0x89/0x240
task_work_run+0x59/0x90
do_exit+0x319/0xaa0
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/369de57492c4f1a42563c5a3bd365822ca3bfc79
- https://git.kernel.org/stable/c/4a3a78b7918bdd723d8c7c9786522ca969bffcc4
- https://git.kernel.org/stable/c/5b4826657d36c218e9f08e8d3223b0edce3de88f
- https://git.kernel.org/stable/c/616f76498d5ddf26b997caf64a95cda3c8a55533
- https://git.kernel.org/stable/c/61fb38cfbb1d54d3dafd0c25752f684b3cd00b32
- https://git.kernel.org/stable/c/88e22159750b0d55793302eeed8ee603f5c1a95c
- https://git.kernel.org/stable/c/91b34bf0409f43bb60453bab23c5beadd726d022
- https://git.kernel.org/stable/c/b3a9b227d5e7467b8518160ff034ea22bb9de573
- https://git.kernel.org/stable/c/e198f1930050e3115c80b67d9249f80f98a27c67
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix list protocols enumeration in the base protocol While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition.
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/1052f22e127d0c34c3387bb389424ba1c61491ff
- https://git.kernel.org/stable/c/2ccfcd7a09c826516edcfe464b05071961aada3f
- https://git.kernel.org/stable/c/444a2d27fe9867d0da4b28fc45b793f32e099ab8
- https://git.kernel.org/stable/c/6e7978695f4a6cbd83616b5a702b77fa2087b247
- https://git.kernel.org/stable/c/8009120e0354a67068e920eb10dce532391361d0
- https://git.kernel.org/stable/c/98342148a8cd242855d7e257f298c966c96dba9f
- https://git.kernel.org/stable/c/b0e4bafac8963c2d85ee18d3d01f393735acceec
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: versatile: Add missing of_node_put in dcscb_init The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use 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/23b44f9c649bbef10b45fa33080cd8b4166800ae
- https://git.kernel.org/stable/c/2d7b23db35254b7d46e852967090c64cdccf24da
- https://git.kernel.org/stable/c/3c6006faed9aba5144b33176d061031a9be66954
- https://git.kernel.org/stable/c/83c329b980bddbc8c6a3d287d91f2103a4d4a860
- https://git.kernel.org/stable/c/a0fc05cd17617e63fc13ad0c01f3f0afd890d8ec
- https://git.kernel.org/stable/c/bbdfb7d4f036118d36415a2575efa6f5246505ae
- https://git.kernel.org/stable/c/d146e2a9864ade19914494de3fb520390b415d58
- https://git.kernel.org/stable/c/d6de7b181c29cd4578ec139aafb5eac062abbe1b
- https://git.kernel.org/stable/c/fcd1999ba97445a12cc394f5f42ffd9116bf0185
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: rk3399_dmc: Disable edev on remove() Otherwise we hit an unablanced enable-count when unbinding the DFI device: [ 1279.659119] ------------[ cut here ]------------ [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c ... [ 1279.659352] Hardware name: Google Kevin (DT) [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28 ... [ 1279.659571] Call trace: [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c [ 1279.659590] devm_devfreq_event_release+0x1c/0x28 [ 1279.659602] release_nodes+0x1cc/0x244 [ 1279.659611] devres_release_all+0x44/0x60 [ 1279.659621] device_release_driver_internal+0x11c/0x1ac [ 1279.659629] device_driver_detach+0x20/0x2c [ 1279.659641] unbind_store+0x7c/0xb0 [ 1279.659650] drv_attr_store+0x2c/0x40 [ 1279.659663] sysfs_kf_write+0x44/0x58 [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190 [ 1279.659684] vfs_write+0x2b0/0x2e4 [ 1279.659693] ksys_write+0x80/0xec [ 1279.659701] __arm64_sys_write+0x24/0x30 [ 1279.659714] el0_svc_common+0xf0/0x1d8 [ 1279.659724] do_el0_svc_compat+0x28/0x3c [ 1279.659738] el0_svc_compat+0x10/0x1c [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc [ 1279.659758] el0_sync_compat+0x188/0x1c0 [ 1279.659768] ---[ end trace cec200e5094155b4 ]---
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/2fccf9e6050e0e3b8b4cd275d41daf7f7fa22804
- https://git.kernel.org/stable/c/664736e2cc09e504ce58ec61164d029d1f2651bb
- https://git.kernel.org/stable/c/86b091b6894c449d2734de7aa7d79ccb33ffd97d
- https://git.kernel.org/stable/c/a0180e324a9a63de8f770da300477b48cb4a53f1
- https://git.kernel.org/stable/c/a9c2b23a7ac6ab19214cad8cac8af8608a4d9cef
- https://git.kernel.org/stable/c/cb1be1d4be18fe286ba5a67d928598378fd7fbe5
- https://git.kernel.org/stable/c/fb089b6f21de03a685dd31df3789bbb01c59f8e3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails.
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/33546183c16c7b9650682dc610bedd732d9c6919
- https://git.kernel.org/stable/c/449374565f349d4233beec811d4286fdfe5de44b
- https://git.kernel.org/stable/c/656aa3c51fc662064f17179b38ec3ce43af53bca
- https://git.kernel.org/stable/c/947a844bb3ebff0f4736d244d792ce129f6700d7
- https://git.kernel.org/stable/c/d544880482a5558ec06393b1b3d5dc9275b7a32b
- https://git.kernel.org/stable/c/d63ffe3fb3f8327ca21cf91b6a14a2961bc629b4
- https://git.kernel.org/stable/c/f8cd192752a1f613b14eee77783c6f0aebb49691
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type.
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/143878e18001c5a61fcc7ae5c5240323753bb641
- https://git.kernel.org/stable/c/1e5fbfc2a6f384e3195446c14bbd3bc298eb88c2
- https://git.kernel.org/stable/c/660dfa033ccc9afb032015b6dc76e846bba42cfb
- https://git.kernel.org/stable/c/7dcb404662839a4ed1a9703658fee979eb894ca4
- https://git.kernel.org/stable/c/91e720b32cba25fa58eaa4c88fe957009cffe9f3
- https://git.kernel.org/stable/c/abb5594ae2ba7b82cce85917cc6337ec5d774837
- https://git.kernel.org/stable/c/bd219273b4e004a3f853da72e111fc8f81357501
- https://git.kernel.org/stable/c/f2ef6f7539c68c6bd6c32323d8845ee102b7c450
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/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/36c644c63bfcaee2d3a426f45e89a9cd09799318
- https://git.kernel.org/stable/c/390d82733a953c1fabf3de9c9618091a7a9c90a6
- https://git.kernel.org/stable/c/537f619dea4e3fa8ed1f8f938abffe3615794bcc
- https://git.kernel.org/stable/c/65d347cb39e2e6bd0c2a745ad7c928998ebb0162
- https://git.kernel.org/stable/c/6f55fac0af3531cf60d11369454c41f5fc81ab3f
- https://git.kernel.org/stable/c/7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2
- https://git.kernel.org/stable/c/7d61dbd7311ab978d8ddac1749a758de4de00374
- https://git.kernel.org/stable/c/99df16007f4bbf9abfc3478cb17d10f0d7f8906e
- https://git.kernel.org/stable/c/9de3dc09e56f8deacd2bdbf4cecb71e11a312405
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work.
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/1310fc3538dcc375a2f46ef0a438512c2ca32827
- https://git.kernel.org/stable/c/24e807541e4a9263ed928e6ae3498de3ad43bd1e
- https://git.kernel.org/stable/c/2e004fe914b243db41fa96f9e583385f360ea58e
- https://git.kernel.org/stable/c/3309c2c574e13b21b44729f5bdbf21f60189b79a
- https://git.kernel.org/stable/c/4351bfe36aba9fa7dc9d68d498d25d41a0f45e67
- https://git.kernel.org/stable/c/471bec68457aaf981add77b4f590d65dd7da1059
- https://git.kernel.org/stable/c/a3304766d9384886e6d3092c776273526947a2e9
- https://git.kernel.org/stable/c/a3660e06675bccec4bf149c7229ea1d491ba10d7
- https://git.kernel.org/stable/c/f99a8b1ec0eddc2931aeaa4f490277a15b39f511
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore.
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/0be5d9da5743b9825a95baec85a67500b2c1d362
- https://git.kernel.org/stable/c/49d785baeb91568332197be356d138e5e59c7ddb
- https://git.kernel.org/stable/c/56ab0c01027492cd161c64148e1dc892c56887ad
- https://git.kernel.org/stable/c/671be14fc31374b1a10a3abd93db6a8480838fc9
- https://git.kernel.org/stable/c/6ca675f4abbc74bc991d154a1ecc8b384dc2aae4
- https://git.kernel.org/stable/c/984cfef0675ed7398814e14af2c5323911723e1c
- https://git.kernel.org/stable/c/9f564e29a51210a49df3d925117777c157a17d6d
- https://git.kernel.org/stable/c/afaa7b933ef00a2d3262f4d1252087613fb5c06d
- https://git.kernel.org/stable/c/b74c0dd9179d21b7260260e075d597b23970100c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done.
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/18b907ff0ae4bf20120aae1538f7156b9d08e3a7
- https://git.kernel.org/stable/c/24491124406666bf0dcb9ee10c5575c6ce6a1730
- https://git.kernel.org/stable/c/2a0da7641e1f17a744ac7b3f76471388c97b63dc
- https://git.kernel.org/stable/c/2be84f73785fa9ed6443e3c5b158730266f1c2ee
- https://git.kernel.org/stable/c/30d110ca703ce60162ec337aa564a3e4da30715f
- https://git.kernel.org/stable/c/4e2a1bcc51bdebed48176f6e88c150f175983f9c
- https://git.kernel.org/stable/c/c933829cbf3338b684869e6c4c8931abf5d68fbd
- https://git.kernel.org/stable/c/d42601e93fce7802bb8d70dd59b60cfeefa20469
- https://git.kernel.org/stable/c/d855505851ee8ba666eb204149b49f906130dc17
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Patchwork: https://patchwork.freedesktop.org/patch/485181/
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/09bdeedc1fc53e64b8282e1de67752c69e43bdba
- https://git.kernel.org/stable/c/1a5d1474026ea4f1a6f931075ca2adb884af39cf
- https://git.kernel.org/stable/c/22d8424913b1348c6324916745fadaeea5273f0e
- https://git.kernel.org/stable/c/46e5ce63924a96af452c4fc5ee0bb3b241e1b9f4
- https://git.kernel.org/stable/c/47e393061049aff6818d1b9fdca7351411a23fc2
- https://git.kernel.org/stable/c/883f1d52a57bf51e1d7a80c432345e2c6222477e
- https://git.kernel.org/stable/c/ca75f6f7c6f89365e40f10f641b15981b1f07c31
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag]
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/134760263f6441741db0b2970e7face6b34b6d1c
- https://git.kernel.org/stable/c/5b0adf5cbf3b74721e4e4c4e0cadc91b8df8bcc2
- https://git.kernel.org/stable/c/97ac682b6f7d36be5d934f86c9911066540a68f1
- https://git.kernel.org/stable/c/aa4cb188988dc6f1b3f4917d4dbc452150a5d871
- https://git.kernel.org/stable/c/ef10d0c68e8608848cd58fca2589685718426607
- https://git.kernel.org/stable/c/ef4bdaac7cb5416f236613ed9337ff0ea8ee329b
- https://git.kernel.org/stable/c/fa5186b279ecf44b14fb435540d2065be91cb1ed
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Patchwork: https://patchwork.freedesktop.org/patch/485179/
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/04bef5f1ba8ea6d7c1c8f5f65e0395c62db59cb8
- https://git.kernel.org/stable/c/19964dfb39bda4d7716a71009488f0668ecbcf52
- https://git.kernel.org/stable/c/33dc5aac46e0fad8f5eb193e5906ed0eb6b66ceb
- https://git.kernel.org/stable/c/49dc28b4b2e28ef7564e355c91487996c1cbebd7
- https://git.kernel.org/stable/c/776f5c58bfe16cf322d71eeed3c5dda1eeac7e6b
- https://git.kernel.org/stable/c/b2aa2c4efe93e2580d6a8774b04fe2b99756a322
- https://git.kernel.org/stable/c/d59be579fa932c46b908f37509f319cbd4ca9a68
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3451852312303d54a003c73bd0ae39cebb960bd5
- https://git.kernel.org/stable/c/452922955df215a417c80d09dab72bbc667a1861
- https://git.kernel.org/stable/c/6ff986e057bf28e2f7690dad410768b2270f9453
- https://git.kernel.org/stable/c/769c53bb6116d0eaec0f1fe4ec4b27a74465cad1
- https://git.kernel.org/stable/c/a9b4599665e437de8a1152799c34841b799a2e1c
- https://git.kernel.org/stable/c/b54926bd558d97c888c3d2d87886f3c159d3254a
- https://git.kernel.org/stable/c/ecfa52654d0c9c333c1fe1611f47105f6bce9591
- https://git.kernel.org/stable/c/f8c242908ad15bbd604d3bcb54961b7d454c43f8
- https://git.kernel.org/stable/c/fcd6a886443730c39170b8383411e52118aec0a3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/54a4c1e47d1b2585e74920399455bd9abbfb2bd7
- https://git.kernel.org/stable/c/7a28556082d1fbcbc599baf1c24252dfc73efefc
- https://git.kernel.org/stable/c/8321b17789f614414206af07e17ce4751c95dc76
- https://git.kernel.org/stable/c/8da2b7bdb47e94bbc4062a3978c708926bcb022c
- https://git.kernel.org/stable/c/906c81dba8ee8057523859b5e1a2479e9fd34860
- https://git.kernel.org/stable/c/9e649471b396fa0139d53919354ce1eace9b9a24
- https://git.kernel.org/stable/c/af98940dd33c9f9e1beb4f71c0a39260100e2a65
- https://git.kernel.org/stable/c/da42761181627e9bdc37d18368b827948a583929
- https://git.kernel.org/stable/c/f76729662650cd7bc8f8194e057af381370349a7
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix errorenous cleanup order There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync.
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/061a6159cea583f1155f67d1915917a6b9282662
- https://git.kernel.org/stable/c/0941150100173d4eaf3fe08ff4b16740e7c3026f
- https://git.kernel.org/stable/c/1a5a3dfd9f172dcb115072f0aea5e27d3083c20e
- https://git.kernel.org/stable/c/236d29c5857f02e0a53fdf15d3dce1536c4322ce
- https://git.kernel.org/stable/c/2def44d3aec59e38d2701c568d65540783f90f2f
- https://git.kernel.org/stable/c/453f0920ffc1a28e28ddb9c3cd5562472b2895b0
- https://git.kernel.org/stable/c/88c09e4812d72c3153afc8e5a45ecac2d0eae3ff
- https://git.kernel.org/stable/c/abe7554da62cb489712a54de69ef5665c250e564
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/
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/0978fcce91b90b561b8c82e7c492ba9fc8440eef
- https://git.kernel.org/stable/c/2b3ed7547b1a052209da6c4ab886ffe0eed88c42
- https://git.kernel.org/stable/c/4cd66a8016b872a153bf892fe4258cbc0dacf5b1
- https://git.kernel.org/stable/c/6369dda4a2209142ab819f01d3d2076d81e3ebdd
- https://git.kernel.org/stable/c/9cb1ee33efccb8b107ee04b7b3441820de3fd2da
- https://git.kernel.org/stable/c/9f5495a5c51c1d11c6ffc13aa2befffec0c2651a
- https://git.kernel.org/stable/c/a36e506711548df923ceb7ec9f6001375be799a5
- https://git.kernel.org/stable/c/c1bfacf0daf25a5fc7d667399d6ff2dffda84cd8
- https://git.kernel.org/stable/c/d9cb951d11a4ace4de5c50b1178ad211de17079e
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()'
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/0bcb528402cd5e1a6e1833e956fd58a12d509e8e
- https://git.kernel.org/stable/c/2326d398ccd41ba6d93b8346532dfa432ab00fee
- https://git.kernel.org/stable/c/2dc509305cf956381532792cb8dceef2b1504765
- https://git.kernel.org/stable/c/3dad3fed5672828c7fb0465cb66a3d9a70952fa6
- https://git.kernel.org/stable/c/461e4c1f199076275f16bf6f3d3e42c6b6c79f33
- https://git.kernel.org/stable/c/4bdcf32c965c27f55ccc4ee71c1927131115b0bb
- https://git.kernel.org/stable/c/7f6defe0fabc79f29603c6fa3c80e4fe0456a3e9
- https://git.kernel.org/stable/c/a048e0c3caa852397b7b50d4c82a0415c05f7ac3
- https://git.kernel.org/stable/c/eda518db7db16c360bc84379d90675650daa3048
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
NFC: NULL out the dev->rfkill to prevent UAF
Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
assumes the device_is_registered() in function nfc_dev_up() will help
to check when the rfkill is unregistered. However, this check only
take effect when device_del(&dev->dev) is done in nfc_unregister_device().
Hence, the rfkill object is still possible be dereferenced.
The crash trace in latest kernel (5.18-rc2):
[ 68.760105] ==================================================================
[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750
[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313
[ 68.760756]
[ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4
[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 68.760756] Call Trace:
[ 68.760756]
[ 68.760756] dump_stack_lvl+0x57/0x7d
[ 68.760756] print_report.cold+0x5e/0x5db
[ 68.760756] ? __lock_acquire+0x3ec1/0x6750
[ 68.760756] kasan_report+0xbe/0x1c0
[ 68.760756] ? __lock_acquire+0x3ec1/0x6750
[ 68.760756] __lock_acquire+0x3ec1/0x6750
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] ? register_lock_class+0x18d0/0x18d0
[ 68.760756] lock_acquire+0x1ac/0x4f0
[ 68.760756] ? rfkill_blocked+0xe/0x60
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0
[ 68.760756] ? nla_get_range_signed+0x540/0x540
[ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50
[ 68.760756] _raw_spin_lock_irqsave+0x39/0x50
[ 68.760756] ? rfkill_blocked+0xe/0x60
[ 68.760756] rfkill_blocked+0xe/0x60
[ 68.760756] nfc_dev_up+0x84/0x260
[ 68.760756] nfc_genl_dev_up+0x90/0xe0
[ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0
[ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230
[ 68.760756] ? security_capable+0x51/0x90
[ 68.760756] genl_rcv_msg+0x280/0x500
[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0
[ 68.760756] ? lock_acquire+0x1ac/0x4f0
[ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] netlink_rcv_skb+0x11b/0x340
[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0
[ 68.760756] ? netlink_ack+0x9c0/0x9c0
[ 68.760756] ? netlink_deliver_tap+0x136/0xb00
[ 68.760756] genl_rcv+0x1f/0x30
[ 68.760756] netlink_unicast+0x430/0x710
[ 68.760756] ? memset+0x20/0x40
[ 68.760756] ? netlink_attachskb+0x740/0x740
[ 68.760756] ? __build_skb_around+0x1f4/0x2a0
[ 68.760756] netlink_sendmsg+0x75d/0xc00
[ 68.760756] ? netlink_unicast+0x710/0x710
[ 68.760756] ? netlink_unicast+0x710/0x710
[ 68.760756] sock_sendmsg+0xdf/0x110
[ 68.760756] __sys_sendto+0x19e/0x270
[ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0
[ 68.760756] ? fd_install+0x178/0x4c0
[ 68.760756] ? fd_install+0x195/0x4c0
[ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0
[ 68.760756] __x64_sys_sendto+0xd8/0x1b0
[ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130
[ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50
[ 68.760756] do_syscall_64+0x3b/0x90
[ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 68.760756] RIP: 0033:0x7f67fb50e6b3
...
[ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
[ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3
[ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003
[ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c
[ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e
[ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003
[ 68.760756]
[ 68.760756]
[ 68.760756] Allocated by task 279:
[ 68.760756] kasan_save_stack+0x1e/0x40
[
---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/1632be63862f183cd5cf1cc094e698e6ec005dfd
- https://git.kernel.org/stable/c/1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9
- https://git.kernel.org/stable/c/2a1b5110c95e4d49c8c3906270dfcde680a5a7be
- https://git.kernel.org/stable/c/4a68938f43b7c2663e4c90bb9bbe29ac8b9a42a0
- https://git.kernel.org/stable/c/4f5d71930f41be78557f9714393179025baacd65
- https://git.kernel.org/stable/c/6abfaca8711803d0d7cc8c0fac1070a88509d463
- https://git.kernel.org/stable/c/a8e03bcad52dc9afabf650fdbad84f739cec9efa
- https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf
- https://git.kernel.org/stable/c/fbf9c4c714d3cdeb98b6a18e4d057f931cad1d81
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails).
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/1af20714fedad238362571620be0bd690ded05b6
- https://git.kernel.org/stable/c/24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47
- https://git.kernel.org/stable/c/5291451851feeb66fd4bf0826710f482f3b1ab38
- https://git.kernel.org/stable/c/6d0726725c7c560495f5ff364862a2cefea542e3
- https://git.kernel.org/stable/c/8bb1716507ebf12d50bbf181764481de3b6bc7fd
- https://git.kernel.org/stable/c/c92ec22a991778a096342cf1a917ae36c5c86a90
- https://git.kernel.org/stable/c/f1d4f19a796551edc6679a681ea1756b8c578c08
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe Call of_node_put(platform_node) to avoid refcount leak in the 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/0a1901f34f775b83ea4b8dbb5ed992147b9b8531
- https://git.kernel.org/stable/c/1e932aba3c7628c9f880ee9c2cfcc2ae3ba0c01e
- https://git.kernel.org/stable/c/23f340ed906c758cec6527376768e3bc1474ac30
- https://git.kernel.org/stable/c/48889eb3cce91d7f58e02bc07277b7f724b7a54a
- https://git.kernel.org/stable/c/4f4e0454e226de3bf4efd7e7924d1edc571c52d5
- https://git.kernel.org/stable/c/98d5afe868df998b0244f4c229ab758b4083684a
- https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6
- https://git.kernel.org/stable/c/ebd5cb4f1f3f10b839e7575219e0f17b60c23113
- https://git.kernel.org/stable/c/fb66e0512e5ccc093070e21cf88cce8d98c181b5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_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/05654431a18fe24e5e46a375d98904134628a102
- https://git.kernel.org/stable/c/318afb1442eeef089fe7f8a8297d97c0302ff6f6
- https://git.kernel.org/stable/c/61a85a20e8df5e0a92cfe169c92425c7bae0753b
- https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912
- https://git.kernel.org/stable/c/94587aa17abf8b26f543d2b29c44abc21bc36836
- https://git.kernel.org/stable/c/bc2afecaabd2a2c9f17e43b4793a30e3461bfb29
- https://git.kernel.org/stable/c/c71494f5f2b444adfd992a7359a0d2a791642b39
- https://git.kernel.org/stable/c/f279c49f17ce10866087ea6c0c57382158974b63
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: Fix the error handling in cx23885_initdev() When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask().
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/453514a874c78df1e7804e6e3aaa60c8d8deb6a8
- https://git.kernel.org/stable/c/6041d1a0365baa729b6adfb6ed5386d9388018db
- https://git.kernel.org/stable/c/7b9978e1c94e569d65a0e7e719abb9340f5db4a0
- https://git.kernel.org/stable/c/86bd6a579c6c60547706cabf299cd2c9feab3332
- https://git.kernel.org/stable/c/98106f100f50c487469903b9cf6d966785fc9cc3
- https://git.kernel.org/stable/c/ca17e7a532d1a55466cc007b3f4d319541a27493
- https://git.kernel.org/stable/c/e8123311cf06d7dae71e8c5fe78e0510d20cd30b
- https://git.kernel.org/stable/c/fa636e9ee4442215cd9a2e079cd5a8e1fe0cb8ba
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
media: cx25821: Fix the warning when removing the module
When removing the module, we will get the following warning:
[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'
[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0
[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0
[ 14.759589] Call Trace:
[ 14.759792]
[ 14.759975] unregister_irq_proc+0x14c/0x170
[ 14.760340] irq_free_descs+0x94/0xe0
[ 14.760640] mp_unmap_irq+0xb6/0x100
[ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40
[ 14.761334] acpi_pci_irq_disable+0x1d3/0x320
[ 14.761688] pci_disable_device+0x1ad/0x380
[ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60
[ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821]
[ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821]
[ 14.763242] pci_device_remove+0x92/0x240
Fix this by freeing the irq before call pci_disable_device().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/005fd553f5f10fe8618d92f94ad10f9051eac331
- https://git.kernel.org/stable/c/1f0fc1dfb5fdd456657519a97fab83691b96c6a0
- https://git.kernel.org/stable/c/2203436a4d24302871617373a7eb21bc17e38762
- https://git.kernel.org/stable/c/222292930c8ecc3516e03ec1f9fa8448be7ff496
- https://git.kernel.org/stable/c/258639bc55a586ee6df92d89786ccf1c71546d70
- https://git.kernel.org/stable/c/3f94169affa33c9db4a439d88f09cb2ed3a33332
- https://git.kernel.org/stable/c/4d6295b6d986476232332fffd08575b185f90d81
- https://git.kernel.org/stable/c/5beb85ff7d005ddb7bf604a4f2dc76f01b84b318
- https://git.kernel.org/stable/c/9d92291698e5cc35a2b8a1106a01ddd7d60ade2d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: md/bitmap: don't set sb values if can't pass sanity check If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed. How to trigger: (faulty injection) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
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/0959aa00f9765bd8c654b1365012e41b51c733cc
- https://git.kernel.org/stable/c/27f672af28a8e9b783ff7f0eaf7ef2fbd5a2f4ba
- https://git.kernel.org/stable/c/422e8f7ba1e08c8e0e88d375bcb550bc2bbfe96d
- https://git.kernel.org/stable/c/cf9392282a2cf5a8d83dd1c5aa1a097e12f172bc
- https://git.kernel.org/stable/c/d8f1558e1daf54f53a90b4c5700ae3e3a4b13412
- https://git.kernel.org/stable/c/e68cb83a57a458b01c9739e2ad9cb70b04d1e6d2
- https://git.kernel.org/stable/c/e69e93120f6219b9cc4fba3b515b6ababd8548aa
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: avoid null dereference in deinit If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary.
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/0ac84ab50712879eac3c1dd2598440652a85d3d0
- https://git.kernel.org/stable/c/0ed5a643b1a4a46b9b7bfba5d468c10cc30e1359
- https://git.kernel.org/stable/c/2533acb652359c9e097dfa33587896af782e8a91
- https://git.kernel.org/stable/c/27ad46da44177a78a4a0cae6fe03906888c61aa1
- https://git.kernel.org/stable/c/86594f6af867b5165d2ba7b5a71fae3a5961e56c
- https://git.kernel.org/stable/c/9c385b961d4c378228e80f6abea8509cb67feab6
- https://git.kernel.org/stable/c/a21d15dde21d7e8ae047eb8368677407db45d840
- https://git.kernel.org/stable/c/b73ed0510bb8d9647cd8e8a4c4c8772bbe545c3a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix double free in si_parse_power_table() In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated.
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/2615464854505188f909d0c07c37a6623693b5c7
- https://git.kernel.org/stable/c/43eb9b667b95f2a31c63e8949b0d2161b9be59c3
- https://git.kernel.org/stable/c/6c5bdaa1325be7f04b79ea992ab216739192d342
- https://git.kernel.org/stable/c/a5ce7051db044290b1a95045ff03c249005a3aa4
- https://git.kernel.org/stable/c/af832028af6f44c6c45645757079c4ed6884ade5
- https://git.kernel.org/stable/c/c0e811c4ccf3b42705976285e3a94cc82dea7300
- https://git.kernel.org/stable/c/ca1ce206894dd976275c78ee38dbc19873f22de9
- https://git.kernel.org/stable/c/f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd
- https://git.kernel.org/stable/c/fd2eff8b9dcbe469c3b7bbbc7083ab5ed94de07b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218
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/0f8bc147a963686b7351aa35d1701124ffacac08
- https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e9846957402
- https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c
- https://git.kernel.org/stable/c/848dd072744ea662ab3097e3c8282bee552df218
- https://git.kernel.org/stable/c/c51d00472fa54b9b05c17789ed665c17adf3a25d
- https://git.kernel.org/stable/c/e0828456578cc8ba0a69147f7ae3428392eec287
- https://git.kernel.org/stable/c/edafcad84c4134ebec4bc24b29ca4497a1184eea
- https://git.kernel.org/stable/c/f85cb059fad03a3b33a50023be91e944bb065ae8
- https://git.kernel.org/stable/c/fadc626cae99aaa1325094edc6a9e2b883f3e562
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: jack: Access input_dev under mutex It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock.
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/1b6a6fc5280e97559287b61eade2d4b363e836f2
- https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348
- https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5
- https://git.kernel.org/stable/c/74bab3bcf422593c582e47130aa8eb41ebb2dc09
- https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879
- https://git.kernel.org/stable/c/9e6a73b0c0f2014eb89249fb1640c5a3d58221c4
- https://git.kernel.org/stable/c/c093b62c40027c21d649c5534ad7aa3605a99b00
- https://git.kernel.org/stable/c/e2b8681769f6e205382f026b907d28aa5ec9d59a
- https://git.kernel.org/stable/c/f68bed124c7699e23ffb4ce4fcc84671e9193cde
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21
- https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd
- https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882
- https://git.kernel.org/stable/c/528d2023ccf4748fd542582955236c1634a7d293
- https://git.kernel.org/stable/c/5f7ea274e88c0eeffe6bd6dbf6cf5c479d356af6
- https://git.kernel.org/stable/c/8fb1b9beb085bb767ae43e441db5ac6fcd66a04d
- https://git.kernel.org/stable/c/98d1dc32f890642476dbb78ed3437a456bf421b0
- https://git.kernel.org/stable/c/b4628e0d3754ab2fc98ee6e3d21851ba45798077
- https://git.kernel.org/stable/c/e8366bbabe1d207cf7c5b11ae50e223ae6fc278b
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: zsmalloc: fix races between asynchronous zspage free and page migration The asynchronous zspage free worker tries to lock a zspage's entire page list without defending against page migration. Since pages which haven't yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage's pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.
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/2505a981114dcb715f8977b8433f7540854851d8
- https://git.kernel.org/stable/c/3674d8a8dadd03a447dd21069d4dacfc3399b63b
- https://git.kernel.org/stable/c/3ec459c8810e658401be428d3168eacfc380bdd0
- https://git.kernel.org/stable/c/645996efc2ae391246d595832aaa6f9d3cc338c7
- https://git.kernel.org/stable/c/8ba7b7c1dad1f6503c541778f31b33f7f62eb966
- https://git.kernel.org/stable/c/c5402fb5f71f1a725f1e55d9c6799c0c7bec308f
- https://git.kernel.org/stable/c/fae05b2314b147a78fbed1dc4c645d9a66313758
- https://git.kernel.org/stable/c/fc658c083904427abbf8f18280d517ee2668677c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: re-fetch conntrack after insertion In case the conntrack is clashing, insertion can free skb->_nfct and set skb->_nfct to the already-confirmed entry. This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger.
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/01989d7eebb61c99bd4b88ebc8e261bd2f02caed
- https://git.kernel.org/stable/c/04e4a11dc723c52db7a36dc58f0d69ce6426f8f0
- https://git.kernel.org/stable/c/04f9e9104c969d8ce10a4a43634f641ed082092d
- https://git.kernel.org/stable/c/56b14ecec97f39118bf85c9ac2438c5a949509ed
- https://git.kernel.org/stable/c/91a36ec160ec1a0c8f5352b772dffcbb0b6023e3
- https://git.kernel.org/stable/c/92a999d1963eed0df666284e20055136ceabd12f
- https://git.kernel.org/stable/c/b16bb373988da3ceb0308381634117e18b6ec60d
- https://git.kernel.org/stable/c/e97222b785e70e8973281666d709baad6523d8af
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in 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/37147e22cd8dfc0412495cb361708836157a4486
- https://git.kernel.org/stable/c/3bd66010398871807c1cebacee07d60ded1b1402
- https://git.kernel.org/stable/c/452b9dfd7aca96befce22634fadb111737f22bbe
- https://git.kernel.org/stable/c/61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc
- https://git.kernel.org/stable/c/b31ab132561c7f1b6459039152b8d09e44eb3565
- https://git.kernel.org/stable/c/b5a817f8d62e9e13280928f3756e54854ae4962e
- https://git.kernel.org/stable/c/c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a
- https://git.kernel.org/stable/c/cb9813d7eae917acd34436160a278b8b5d48ca53
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: meson: Fix refcount leak in meson_smp_prepare_cpus of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid 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/2e1bcd33478ef44e63a45457055060b5fe4118ad
- https://git.kernel.org/stable/c/34d2cd3fccced12b958b8848e3eff0ee4296764c
- https://git.kernel.org/stable/c/3cf8ece9113242c10f83c7675ea4f4f67959ee43
- https://git.kernel.org/stable/c/3d90607e7e6afa89768b0aaa915b58bd2b849276
- https://git.kernel.org/stable/c/7208101ded1e9dcc52c8f0f8b16474211c871c1a
- https://git.kernel.org/stable/c/c5fbf4f74c94fd60d5e9bf9f7f8268c3601562ca
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: usbnet: fix memory leak in error case usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf 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/0085da9df3dced730027923a6b48f58e9016af91
- https://git.kernel.org/stable/c/04894ab34faf40ab72a8a5ab5b404bb0606bbbff
- https://git.kernel.org/stable/c/3eed421ca5c809da93456f69203d164d5220be3d
- https://git.kernel.org/stable/c/5269209f54dd8dfd15f9383f3a3a1fe8370764f8
- https://git.kernel.org/stable/c/b55a21b764c1e182014630fa5486d717484ac58f
- https://git.kernel.org/stable/c/d5165e657987ff4ba0ace896d4376a3718a9fbc3
- https://git.kernel.org/stable/c/db89582ff330556188da856e01382ccbf3a5e706
- https://git.kernel.org/stable/c/e7b4f69946a38209b4a4f660bf0e4cbed94f9b4b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_open/close(): fix memory leak The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver. This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2. For more information, see the 928150fad41b ("can: esd_usb2: fix 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/0e60230bc64355c80abe993d1719fdb318094e20
- https://git.kernel.org/stable/c/2bda24ef95c0311ab93bda00db40486acf30bd0a
- https://git.kernel.org/stable/c/339fa9f80d3b94177a7a459c6d115d3b56007d5a
- https://git.kernel.org/stable/c/6f655b5e13fa4b27e915b6c209ac0da74fd75963
- https://git.kernel.org/stable/c/c1d806bc29ff7ffe0e2a023583c8720ed96cb0b0
- https://git.kernel.org/stable/c/d0b8e223998866b3e7b2895927d4e9689b0a80d8
- https://git.kernel.org/stable/c/d91492638b054f4a359621ef216242be5973ed6b
- https://git.kernel.org/stable/c/ffb6cc6601ec7c8fa963dcf76025df4a02f2cf5c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [ 767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148] __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470
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/050133e1aa2cb49bb17be847d48a4431598ef562
- https://git.kernel.org/stable/c/2765749def4765c5052a4c66445cf4c96fcccdbc
- https://git.kernel.org/stable/c/63b2fe509f69b90168a75e04e14573dccf7984e6
- https://git.kernel.org/stable/c/893825289ba840afd86bfffcb6f7f363c73efff8
- https://git.kernel.org/stable/c/a853b7a3a9fd1d74a4ccdd9cd73512b7dace2f1e
- https://git.kernel.org/stable/c/b90ac60303063a43e17dd4aec159067599d255e6
- https://git.kernel.org/stable/c/ef0af7d08d26c5333ff4944a559279464edf6f15
- https://git.kernel.org/stable/c/f162f7c348fa2a5555bafdb5cc890b89b221e69c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: tun: unlink NAPI from device on destruction Syzbot found a race between tun file and device destruction. NAPIs live in struct tun_file which can get destroyed before the netdev so we have to del them explicitly. The current code is missing deleting the NAPI if the queue was detached first.
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/3b9bc84d311104906d2b4995a9a02d7b7ddab2db
- https://git.kernel.org/stable/c/8145f77d38de4f88b8a69e1463f5c09ba189d77c
- https://git.kernel.org/stable/c/82e729aee59acefe135fceffadcbc5b86dd4f1b9
- https://git.kernel.org/stable/c/8661d4b8faa2f7ee7a559969c0a7c57f077b1728
- https://git.kernel.org/stable/c/a8cf919022373c97a84fe596bbea544f909c485d
- https://git.kernel.org/stable/c/bec1be0a745ab420718217e3e0d9542a75108989
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix KASAN warning in raid5_add_disks There's a KASAN warning in raid5_add_disk when running the LVM testsuite. The warning happens in the test lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning by verifying that rdev->saved_raid_disk is within limits.
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/02cffb1921edadd9b6e4eee7ada4a5213e8ba12e
- https://git.kernel.org/stable/c/2d4e7c9898c20fb3d3f55381cab601761aab7d64
- https://git.kernel.org/stable/c/2fb2928728038280bd925ce2aafb4997e9d47ee9
- https://git.kernel.org/stable/c/3553a69bb52be2deba61d0ca064c41aee842bb35
- https://git.kernel.org/stable/c/617b365872a247480e9dcd50a32c8d1806b21861
- https://git.kernel.org/stable/c/d5b06039b195d4b6f94f5d345b1e4ac1975a9832
- https://git.kernel.org/stable/c/d8bca518d5272fe349e0a722fdb9e3acb661f3f0
- https://git.kernel.org/stable/c/f157bd9cf377a947fdb7035e69466b6ecdc17c17
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled).
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/332bd0778775d0cf105c4b9e03e460b590749916
- https://git.kernel.org/stable/c/5e161a8826b63c0b8b43e4a7fad1f956780f42ab
- https://git.kernel.org/stable/c/6352b2f4d8e95ec0ae576d7705435d64cfa29503
- https://git.kernel.org/stable/c/90de15357504c8097ab29769dc6852e16281e9e8
- https://git.kernel.org/stable/c/9bf2b0757b04c78dc5d6e3a198acca98457b32a1
- https://git.kernel.org/stable/c/bcff98500ea3b4e7615ec31d2bdd326bc1ef5134
- https://git.kernel.org/stable/c/df1a5ab0dd0775f2ea101c71f2addbc4c0ea0f85
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: cns3xxx: Fix refcount leak in cns3xxx_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid 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/1ba904b6b16e08de5aed7c1349838d9cd0d178c5
- https://git.kernel.org/stable/c/45bebbc8cea7d586a6216dc62814bdb380b9b29b
- https://git.kernel.org/stable/c/68d4303bf59662b64bd555e2aa0518282d20aa4f
- https://git.kernel.org/stable/c/b8b84e01ca94e2e1f5492353e9c24dab520b2e5b
- https://git.kernel.org/stable/c/c980392af1473d6d5662f70d8089c8e6d85144a4
- https://git.kernel.org/stable/c/d1359e4129ad43e43972a28838b87291c51de23d
- https://git.kernel.org/stable/c/da3ee7cd2f15922ad88a7ca6deee2eafdc7cd214
- https://git.kernel.org/stable/c/dc5170aae24e04068fd5ea125d06c0ab51f48a27
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In brcmstb_init_sram, it pass dn to of_address_to_resource(), of_address_to_resource() will call of_find_device_by_node() to take reference, so we should release the reference returned by of_find_matching_node().
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/10ba9d499a9fd82ed40897e734ba19870a879407
- https://git.kernel.org/stable/c/30bbfeb480ae8b5ee43199d72417b232590440c2
- https://git.kernel.org/stable/c/37d838de369b07b596c19ff3662bf0293fdb09ee
- https://git.kernel.org/stable/c/4f5877bdf7b593e988f1924f4c3df6523f80b39c
- https://git.kernel.org/stable/c/734a4d15142bb4c8ecad2d8ec70d7564e78ae34d
- https://git.kernel.org/stable/c/dcafd5463d8f20c4f90ddc138a5738adb99f74c8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: Fix refcount leak in axxia_boot_secondary of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid 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/29ca9c4efacccdc15104a8d4bf10b5183fc92840
- https://git.kernel.org/stable/c/3c19fe3f04f4f4e7a2b722c2fd3c98356fc1d72b
- https://git.kernel.org/stable/c/44a5b3a073e5aaa5720929dba95b2725eb32bb65
- https://git.kernel.org/stable/c/4d9c60e868f7cf8e09956e7d5bb44d807d712699
- https://git.kernel.org/stable/c/71e12e5b02674459a24f16e965255d63b31fe049
- https://git.kernel.org/stable/c/7c7ff68daa93d8c4cdea482da4f2429c0398fcde
- https://git.kernel.org/stable/c/a9b76c232a1ce4cbf27862097f7eb634dcc779eb
- https://git.kernel.org/stable/c/b385cb59aac8d61c29bc72ebf3d19a536914af96
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: exynos: Fix refcount leak in exynos_map_pmu of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null 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/31d09571bb071c20f6bdc0bb7ac1ef8dd2987c04
- https://git.kernel.org/stable/c/545ae5cbae839ce39bfe09828e413f1c916082de
- https://git.kernel.org/stable/c/68f28d52e6cbab8dcfa249cac4356d1d0573e868
- https://git.kernel.org/stable/c/7571bcecf01b69f0d3ec60ca41ce5d4c75411a4a
- https://git.kernel.org/stable/c/c4c79525042a4a7df96b73477feaf232fe44ae81
- https://git.kernel.org/stable/c/d23f76018e17618559da9eea179d137362023f95
- https://git.kernel.org/stable/c/f9b77a52937582a5b99a5a07e4ef1e2f48f87347
- https://git.kernel.org/stable/c/fc354856e9fad9cd36e2ad28f9da70716025055a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: xtensa: xtfpga: Fix refcount leak bug in setup In machine_setup(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
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/0162451723178602c37f0555d235dfa17e486112
- https://git.kernel.org/stable/c/0715d0e60052662c3f225342062f174dd721d1c7
- https://git.kernel.org/stable/c/173940b3ae40114d4179c251a98ee039dc9cd5b3
- https://git.kernel.org/stable/c/35d7e961be68732eb3acaeba81fb81ca16eafd05
- https://git.kernel.org/stable/c/6c0839cf1b9e1b3c88da6af76794583cbfae8da3
- https://git.kernel.org/stable/c/9b30c5c8884eda3f541229899671cebbad15979b
- https://git.kernel.org/stable/c/a52972ee706b438302eb0350e61f378eb191e3d1
- https://git.kernel.org/stable/c/b12d5c52f073a0420622aaf2f21b615cce8b36cc
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: xtensa: Fix refcount leak bug in time.c In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
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/0dcc1dd8a5dd9240639f1051dfaa2dffc9fbbde5
- https://git.kernel.org/stable/c/0e403a383c14b63c86bd9df085b7e573e9caee64
- https://git.kernel.org/stable/c/3e5eb904d9ba657308fc75a5de434b0e58dcb8d7
- https://git.kernel.org/stable/c/7de4502af68f4f3932f450157f5483eb7b33cb74
- https://git.kernel.org/stable/c/a0117dc956429f2ede17b323046e1968d1849150
- https://git.kernel.org/stable/c/af0ff2da01521144bc11194f4c26485d7c9cee73
- https://git.kernel.org/stable/c/e5234a9d64a976abd134a14710dcd5188158a7c5
- https://git.kernel.org/stable/c/f1eaf4ba5372ad111f687a80c67e270708e14c23
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix use-after-free on remove Ensure that the irq_work has completed before the trigger is freed. ================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25 Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write ==================================================================
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/31ff3309b47d98313c61b8301bf595820cc3cc33
- https://git.kernel.org/stable/c/4687c3f955240ca2a576bdc3f742d4d915b6272d
- https://git.kernel.org/stable/c/4ef1e521be610b720daeb7cf899fedc7db0274c4
- https://git.kernel.org/stable/c/5e39397d60dacc7f5d81d442c1c958eaaaf31128
- https://git.kernel.org/stable/c/78601726d4a59a291acc5a52da1d3a0a6831e4e8
- https://git.kernel.org/stable/c/b07a30a774b3c3e584a68dc91779c68ea2da4813
- https://git.kernel.org/stable/c/d6111e7bdb8ec27eb43d01c4cd4ff1620a75f7f2
- https://git.kernel.org/stable/c/fd5d8fb298a2866c337da635c79d63c3afabcaf7
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix xdp_rxq_info bug after suspend/resume
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
# ip link set eth0 down
Missing register, driver bug
WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60
Call trace:
xdp_rxq_info_unreg+0x58/0x60
virtnet_close+0x58/0xac
__dev_close_many+0xac/0x140
__dev_change_flags+0xd8/0x210
dev_change_flags+0x24/0x64
do_setlink+0x230/0xdd0
...
This happens because virtnet_freeze() frees the receive_queue
completely (including struct xdp_rxq_info) but does not call
xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the
receive_queue again but does not call xdp_rxq_info_reg().
Actually, parts of virtnet_freeze_down() and virtnet_restore_up()
are almost identical to virtnet_close() and virtnet_open(): only
the calls to xdp_rxq_info_(un)reg() are missing. This means that
we can fix this easily and avoid such problems in the future by
just calling virtnet_close()/open() from the freeze/restore handlers.
Aside from adding the missing xdp_rxq_info calls the only difference
is that the refill work is only cancelled if netif_running(). However,
this should not make any functional difference since the refill work
should only be active if the network interface is actually up.
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/340fbdc8011f2dc678f622c5ce1cbb5ab8305de7
- https://git.kernel.org/stable/c/57ee40f1b198b59d43c216fbc4672f9300d3c8b0
- https://git.kernel.org/stable/c/8af52fe9fd3bf5e7478da99193c0632276e1dfce
- https://git.kernel.org/stable/c/8c7a32b7c15555beddc5810c3334d9cefff061bf
- https://git.kernel.org/stable/c/8d7fe9ad6fddc2af8bde4b921b4f8fab231ed38c
- https://git.kernel.org/stable/c/9222672fa6370f0ec3d899662cb8680e9282fc4c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
erspan: do not assume transport header is always set
Rewrite tests in ip6erspan_tunnel_xmit() and
erspan_fb_xmit() to not assume transport header is set.
syzbot reported:
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Modules linked in:
CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00
RSP: 0018:ffffc90005daf910 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003
RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40
R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000
FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0
Call Trace:
__netdev_start_xmit include/linux/netdevice.h:4805 [inline]
netdev_start_xmit include/linux/netdevice.h:4819 [inline]
xmit_one net/core/dev.c:3588 [inline]
dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604
sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342
__dev_xmit_skb net/core/dev.c:3815 [inline]
__dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219
dev_queue_xmit include/linux/netdevice.h:2994 [inline]
tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63
kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
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/02da602bc2f353dccd9e489a604490034ded941e
- https://git.kernel.org/stable/c/2c8aeffc7c586d53e1d380f010bdca4f710f2480
- https://git.kernel.org/stable/c/301bd140ed0b24f0da660874c7e8a47dad8c8222
- https://git.kernel.org/stable/c/a3b2470399f679587c45abe56e551caf10becca2
- https://git.kernel.org/stable/c/cec9867ee55478ef5dcb2adf030fe0c442a4c4ee
- https://git.kernel.org/stable/c/fb401f37f6eadf24956d93687e5758c163c0d12b
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mm/slub: add missing TID updates on slab deactivation The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab. If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects. (I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...) The race leading to state inconsistency is (all operations on the same CPU and kmem_cache): - task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu_ptr() (enables preemption) - [PREEMPT B->A] - task A: finish do_slab_free(): - this_cpu_cmpxchg_double() succeeds() - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL] From there, the object on c->freelist will get lost if task B is allowed to continue from here: It will proceed to the retry_load_slab label, set c->slab, then jump to load_freelist, which clobbers c->freelist. But if we instead continue as follows, we get worse corruption: - task A: run __slab_free() on object from other struct slab: - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial) - task A: run slab_alloc_node() with NUMA node constraint: - fastpath fails (c->slab is NULL) - call __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - c->slab is NULL: goto new_slab - slub_percpu_partial() is non-NULL - set c->slab to slub_percpu_partial(c) - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects from slab-2] - goto redo - node_match() fails - goto deactivate_slab - existing c->freelist is passed into deactivate_slab() - inuse count of slab-1 is decremented to account for object from slab-2 At this point, the inuse count of slab-1 is 1 lower than it should be. This means that if we free all allocated objects in slab-1 except for one, SLUB will think that slab-1 is completely unused, and may free its page, leading to 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/0515cc9b6b24877f59b222ade704bfaa42caa2a6
- https://git.kernel.org/stable/c/197e257da473c725dfe47759c3ee02f2398d8ea5
- https://git.kernel.org/stable/c/308c6d0e1f200fd26c71270c6e6bfcf0fc6ff082
- https://git.kernel.org/stable/c/6c32496964da0dc230cea763a0e934b2e02dabd5
- https://git.kernel.org/stable/c/d6a597450e686d4c6388bd3cdcb17224b4dae7f0
- https://git.kernel.org/stable/c/e2b2f0e2e34d71ae6c2a1114fd3c525930e84bc7
- https://git.kernel.org/stable/c/e7e3e90d671078455a3a08189f89d85b3da2de9e
- https://git.kernel.org/stable/c/eeaa345e128515135ccb864c04482180c08e3259
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ext4: add reserved GDT blocks check
We capture a NULL pointer issue when resizing a corrupt ext4 image which
is freshly clear resize_inode feature (not run e2fsck). It could be
simply reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
not reduced to zero, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.
mkfs.ext4 /dev/sda 3G
tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
mount /dev/sda /mnt
resize2fs /dev/sda 8G
========
BUG: kernel NULL pointer dereference, address: 0000000000000028
CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
...
RIP: 0010:ext4_flex_group_add+0xe08/0x2570
...
Call Trace:
ext4_resize_fs+0xbec/0x1660
__ext4_ioctl+0x1749/0x24e0
ext4_ioctl+0x12/0x20
__x64_sys_ioctl+0xa6/0x110
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f2dd739617b
========
The fix is simple, add a check in ext4_resize_begin() to make sure that
the es->s_reserved_gdt_blocks is zero when the resize_inode feature is
disabled.
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/0dc2fca8e4f9ac4a40e8424a10163369cca0cc06
- https://git.kernel.org/stable/c/33b1bba31f4c784d33d2c2517964bdccdc9204cd
- https://git.kernel.org/stable/c/7c921328ac760bba780bdace41f4cd045f7f1405
- https://git.kernel.org/stable/c/af75c481a2e45e70f62f5942c93695e95bf7bd21
- https://git.kernel.org/stable/c/b55c3cd102a6f48b90e61c44f7f3dda8c290c694
- https://git.kernel.org/stable/c/b9747263b13e5290ac4d63bec47e38f701303cad
- https://git.kernel.org/stable/c/bfd004a1d3a062aac300523d406ac1f3e5f1a82c
- https://git.kernel.org/stable/c/fba54289176702a7caac0b64738406775817f451
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on ext4_mb_use_inode_pa Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f [...] Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0 [...] ================================================================== Above issue may happen as follows: ------------------------------------- do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0); we can easily reproduce this problem with the following commands: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1` The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP. Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur when the size is truncated. So start should be the start position of the group where ac_o_ex.fe_logical is located after alignment. In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP is very large, the value calculated by start_off is more accurate.
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/5707d721d1819db57dba57b1d4623034fcb32047
- https://git.kernel.org/stable/c/6880fb2e64331b9fdc85d3f32b1d7e81ad8703f1
- https://git.kernel.org/stable/c/6fdaf31ad5f3d3afab744dfd9a8b0d9142aa881f
- https://git.kernel.org/stable/c/887a3e9ad4b8309a2266bce7ae749b2bf1f7a687
- https://git.kernel.org/stable/c/90f0f9d45dff0128c0fca0d2358c4153b024afa6
- https://git.kernel.org/stable/c/a08f789d2ab5242c07e716baf9a835725046be89
- https://git.kernel.org/stable/c/a37c1359714da42517dd19d36fc3c4d17edba832
- https://git.kernel.org/stable/c/a6b31616e5afe1d3972cb0682a373e50597faf5c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL 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/0ef6917c0524da5b88496b9706628ffef108b9bb
- https://git.kernel.org/stable/c/2a598da14856ead80c726b38ba426c68637d9211
- https://git.kernel.org/stable/c/46da1e4a8b6329479433b2a4056941dfdd7f3efd
- https://git.kernel.org/stable/c/4757c9ade34178b351580133771f510b5ffcf9c8
- https://git.kernel.org/stable/c/57901c658f77d9ea2e772f35cb38e47efb54c558
- https://git.kernel.org/stable/c/727c82d003e0ec64411fd1257a9a57de4ad7a99a
- https://git.kernel.org/stable/c/b75bddfcc18170ce8e3fb695a76ec2dec4ce0ea5
- https://git.kernel.org/stable/c/d85e4e6284a91aa2d1ab004e9d84b9c09b4aa203
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix memory leak in dwc2_hcd_init usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 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/3755278f078460b021cd0384562977bf2039a57a
- https://git.kernel.org/stable/c/52bfcedbfd5bf962dbdcb6e761f4d0dd3ba26dfd
- https://git.kernel.org/stable/c/6506aff2dc2f7059aa3d45ee2e8639b25e87090f
- https://git.kernel.org/stable/c/701d8ec01e0f229d4db6f43d3d64ee479120cbeb
- https://git.kernel.org/stable/c/84e6d0af87e27bbc0db94f2e7323b34abe17b6e5
- https://git.kernel.org/stable/c/981ee40649e5fd9550f82db1fbb3bfab037da346
- https://git.kernel.org/stable/c/a44a8a762f7fe9ad3c065813d058e835a6180cb2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid 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/506a88a5bf261d76a5214c0338a320f2214c67ac
- https://git.kernel.org/stable/c/8d884c08eeb83142a7173cb46bcff0434ec42cf1
- https://git.kernel.org/stable/c/c136c2924a59a399aa789858cfb320d481964fb7
- https://git.kernel.org/stable/c/cc5984cf270b69d03f9f4b27063e535036c659e9
- https://git.kernel.org/stable/c/e824482e2c5edacc961b7dd30a92fd47606c3036
- https://git.kernel.org/stable/c/fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic/realview: Fix refcount leak in realview_gic_of_init of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid 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/16b603cb8d34c2d917983918db1f88c8b831baaa
- https://git.kernel.org/stable/c/486f68f85085d9b16ae097679b1486dcb1b6eb69
- https://git.kernel.org/stable/c/56526c3883fc7a1f5898b1d40a02c8b8685a5d92
- https://git.kernel.org/stable/c/5d38720661a4b9c87705c206a6081177ffb8ec1d
- https://git.kernel.org/stable/c/87da903ce632d5689bef66d56ee5dae700d82104
- https://git.kernel.org/stable/c/b634af84bc1edece4e63317b0ad95618dd3a8693
- https://git.kernel.org/stable/c/e52a58b79f11755ea7e877015c4a1704303fa55f
- https://git.kernel.org/stable/c/f4b98e314888cc51486421bcf6d52852452ea48b
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Fix free_irq() on remove Pass the correct dev_id to free_irq() to fix this splat when the driver is unbound: WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq Trying to free already-free IRQ 65 Call Trace: warn_slowpath_fmt free_irq goldfish_tty_remove platform_remove device_remove device_release_driver_internal device_driver_detach unbind_store drv_attr_store ...
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/499e13aac6c762e1e828172b0f0f5275651d6512
- https://git.kernel.org/stable/c/65ca4db68b6819244df9024aea4be55edf8af1ef
- https://git.kernel.org/stable/c/a6fcd7ffd76a9c1d998a2d02d518c78a55c5bed8
- https://git.kernel.org/stable/c/c4b0b8edccb0cfb15a8cecf4161e0571d3daac64
- https://git.kernel.org/stable/c/c83a1d40dc624070a203eb383ef9fb60eb634136
- https://git.kernel.org/stable/c/f7183c76d500324b8b5bd0af5e663cfa57b7b836
- https://git.kernel.org/stable/c/fb15e79cacddfbc62264e6e807bde50ad688e988
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix call trace in setup_tx_descriptors After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors. Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash. Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test()
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a4e5a3dc5e41212870e6043895ae02455c93f63
- https://git.kernel.org/stable/c/15950157e2c24865b696db1c9ccc72743ae0e967
- https://git.kernel.org/stable/c/322271351b0e41565171e4cce70ea41854fac115
- https://git.kernel.org/stable/c/5ba9956ca57e361fb13ea369bb753eb33177acc7
- https://git.kernel.org/stable/c/814092927a215f5ca6c08249ec72a205e0b473cd
- https://git.kernel.org/stable/c/fd5855e6b1358e816710afee68a1d2bc685176ca
- https://git.kernel.org/stable/c/ff6e03fe84bc917bb0c907d02de668c2fe101712
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max.
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/034246122f5c5e2e2a0b9fe04e24517920e9beb1
- https://git.kernel.org/stable/c/0e818d433fc2718fe4da044ffca7431812a7e04e
- https://git.kernel.org/stable/c/27a37755ceb401111ded76810359d3adc4b268a1
- https://git.kernel.org/stable/c/2cf73c7cb6125083408d77f43d0e84d86aed0000
- https://git.kernel.org/stable/c/2f42389d270f2304c8855b0b63498a5a4d0c053d
- https://git.kernel.org/stable/c/6c4e3486d21173d60925ef52e512cae727b43d30
- https://git.kernel.org/stable/c/b8879ca1fd7348b4d5db7db86dcb97f60c73d751
- https://git.kernel.org/stable/c/f638a84afef3dfe10554c51820c16e39a278c915
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well. Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak. Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.
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/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed
- https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee
- https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f
- https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4
- https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d
- https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537
- https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e
- https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
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/07cbdb4807d369fbda73062a91b570c4dc5ec429
- https://git.kernel.org/stable/c/1ac5efee33f29e704226506d429b84575a5d66f8
- https://git.kernel.org/stable/c/253334f84c81bc6a43af489f108c0bddad989eef
- https://git.kernel.org/stable/c/36cd19e7d4e5571d77a2ed20c5b6ef50cf57734a
- https://git.kernel.org/stable/c/a810bd5af06977a847d1f202b22d7defd5c62497
- https://git.kernel.org/stable/c/bf476fe22aa1851bab4728e0c49025a6a0bea307
- https://git.kernel.org/stable/c/ca4693e6e06e4fd2b240c0fec47aa2498c94848e
- https://git.kernel.org/stable/c/ff128fbea720bf763fa345680dda5f050bc24a47
HIGH7.1
A use-after-free flaw was found in vhost_net_set_backend in drivers/vhost/net.c in virtio network subcomponent in the Linux kernel due to a double fget. This flaw could allow a local attacker to crash the system, and could even lead to a kernel information leak problem.
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.1
A use-after-free flaw was found in vmxnet3_rq_alloc_rx_buf in drivers/net/vmxnet3/vmxnet3_drv.c in VMware's vmxnet3 ethernet NIC driver in the Linux Kernel. This issue could allow a local attacker to crash the system due to a double-free while cleaning up vmxnet3_rq_cleanup_all, which could also lead to a kernel information leak problem.
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://access.redhat.com/errata/RHSA-2022:7683
- https://access.redhat.com/errata/RHSA-2022:8267
- https://access.redhat.com/security/cve/CVE-2023-4387
- https://bugzilla.redhat.com/show_bug.cgi?id=2219270
- https://github.com/torvalds/linux/commit/9e7fef9521e73ca8afd7da9e58c14654b02dfad8
- https://access.redhat.com/security/cve/CVE-2023-4387
- https://bugzilla.redhat.com/show_bug.cgi?id=2219270
- https://github.com/torvalds/linux/commit/9e7fef9521e73ca8afd7da9e58c14654b02dfad8
HIGH7.0
Unpatched extfs vulnerabilities are exploitable through suid-mode Apptainer
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://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
- https://nvd.nist.gov/vuln/detail/CVE-2022-1184
- https://nvd.nist.gov/vuln/detail/CVE-2023-30549
- https://github.com/apptainer/apptainer/commit/5a4964f5ba9c8d89a0e353b97f51fd607670a9f7
- https://github.com/torvalds/linux/commit/2220eaf90992c11d888fe771055d4de3303
- https://github.com/torvalds/linux/commit/4f04351888a83e595571de672e0a4a8b74f
- https://github.com/torvalds/linux/commit/61a1d87a324ad5e3ed27c6699dfc93218fcf3201
- https://github.com/torvalds/linux/commit/65f8ea4cd57dbd46ea13b41dc8bac03176b04233
- https://www.suse.com/security/cve/CVE-2022-1184.html
- https://ubuntu.com/security/CVE-2022-1184
- https://sylabs.io/2023/04/response-to-cve-2023-30549
- https://security.gentoo.org/glsa/202311-13
- https://security-tracker.debian.org/tracker/CVE-2022-1184
- https://lwn.net/Articles/932137
- https://lwn.net/Articles/932136
- https://github.com/apptainer/apptainer/releases/tag/v1.1.8
- https://github.com/apptainer/apptainer
- https://access.redhat.com/security/cve/cve-2022-1184