HIGH7.8
Уязвимость подсистемы eBPF ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
ALT-PU-2022-1387-2Обновление пакета kernel-image-un-def в ветке sisyphus
Серьёзность:
Закрытые проблемы (142)
HIGH7.8
Уязвимость драйвера drivers/usb/gadget/composite.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
LOW3.3
Уязвимость драйвера drivers/usb/gadget/function/rndis.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
CVSS 3.xНИЗКАЯ 3.3
CVSS:3.x/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:NCVSS 2.0НИЗКАЯ 2.1
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:N/A:NСсылки
HIGH7.8
Уязвимость ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0КРИТИЧЕСКАЯ 9.0
CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функций copy_page_to_iter_pipe и push_pipe ядра операционной системы Linux, позволяющая нарушителю перезаписать содержимое страничного кэша произвольных файлов
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CHIGH7.8
Уязвимость функции BPF_BTF_LOAD() подсистемы eBPF ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
MEDIUM5.5
Уязвимость компонента drivers/hid/hid-elo.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0НИЗКАЯ 2.1
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:PСсылки
HIGH8.4
Уязвимость драйвера ядра операционной системы Linux для устройств USB 2.0/3.0 Gigabit Ethernet на базе ASIX AX88179_178A, позволяющая нарушителю получить потенциально конфиденциальную информацию
CVSS 3.xВЫСОКАЯ 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0ВЫСОКАЯ 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CСсылки
MEDIUM5.5
Уязвимость службы межпроцессной связи (TIPC) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемым данным
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:NСсылки
MEDIUM5.5
Уязвимость функции mld_newpack() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.2
Уязвимость функции mctp_route_input() реализации протокола Management Component Transport Protocol (MCTP) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xСРЕДНЯЯ 5.2
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:HCVSS 2.0СРЕДНЯЯ 5.0
CVSS:2.0/AV:L/AC:H/Au:S/C:P/I:P/A:CСсылки
MEDIUM5.2
Уязвимость функции ocelot_vlan_del() драйвера сетевых адаптеров Microsemi ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xСРЕДНЯЯ 5.2
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:HCVSS 2.0СРЕДНЯЯ 5.0
CVSS:2.0/AV:L/AC:H/Au:S/C:P/I:P/A:CСсылки
HIGH7.8
Уязвимость функции pm8001_exec_internal_tmf_task() драйвера PMC-Sierra SPC 8001 SAS/SATA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость компонента iommu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
MEDIUM5.5
Уязвимость функции nested_svm_load_cr3() в компоненте nSVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента vmscan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
HIGH7.0
Уязвимость функции nvme_async_event_work() драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции iwl_req_fw_callback() драйвера Intel Wireless WiFi Next Gen AGN ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции nvme_rdma_error_recovery_work() драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции nvme_tcp_error_recovery_work() драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции mpi_ssp_completion() драйвера PMC-Sierra SPC 8001 SAS/SATA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции ffs_func_eps_disable() драйвера USB gadget ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.1
Уязвимость функции rpc_sysfs_xprt_state_change() (net/sunrpc/sysfs.c) реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию и вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0СРЕДНЯЯ 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CСсылки
HIGH7.8
Уязвимость функции gpmi_nfc_exec_op() (drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c) драйвера MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.1
Уязвимость функции stm32_usbphyc_pll_enable() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HCVSS 2.0СРЕДНЯЯ 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:CMEDIUM5.5
Уязвимость функций tcp_remove_empty_skb(), tcp_mark_push() и min_t() модуля net/ipv4/tcp.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CMEDIUM4.4
Уязвимость компонента mtd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.7
Уязвимость компонента cfg80211 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
CVSS 3.xСРЕДНЯЯ 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента vsock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:LCVSS 2.0НИЗКАЯ 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:PСсылки
MEDIUM4.4
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.7
Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 5.0
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:P/A:CСсылки
MEDIUM5.5
Уязвимость компонентов s390/cio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонентов fs/proc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента eeprom ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонентов ipmr, ip6mr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента ibmvnic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента misc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента NFSD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента NFSD ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента NFSD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента can ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента ima ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость компонентов powerpc/fixmap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:CСсылки
LOW2.5
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
CVSS 3.xНИЗКАЯ 2.5
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:LCVSS 2.0НИЗКАЯ 1.0
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:PСсылки
MEDIUM5.5
Уязвимость компонента SUNRPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CMEDIUM5.5
Уязвимость ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции vt_ioctl() модуля drivers/tty/vt/vt_ioctl.c - драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции ufshcd_exec_dev_cmd() модуля drivers/scsi/ufs/ufshcd.c - драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции tun_dst_unclone() модуля include/net/dst_metadata.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции parse_qcomsmem_part() модуля drivers/mtd/parsers/qcomsmempart.c - драйвера поддержки памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость модуля drivers/gpu/drm/vc4/vc4_dsi.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции rpcrdma_ep_create() модуля net/sunrpc/xprtrdma/verbs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции vmbus_add_channel_kobj() модуля drivers/hv/vmbus_drv.c драйвера поддержки гостевого режима Microsoft Hyper-V ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость структуры alg_type_list{} модуля crypto/af_alg.c криптографической подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции myrs_cleanup() модуля drivers/scsi/myrs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции audit_match_perm() модуля kernel/auditsc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: Fix a deadlock in the error handler The following deadlock has been observed on a test setup: - All tags allocated - The SCSI error handler calls ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler() - ufshcd_err_handler() locks up as follows: Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724
- https://git.kernel.org/stable/c/945c3cca05d78351bba29fa65d93834cb7934c7b
- https://git.kernel.org/stable/c/d69d98d8edf90e25e4e09930dd36dd6d09dd6768
- https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724
- https://git.kernel.org/stable/c/945c3cca05d78351bba29fa65d93834cb7934c7b
- https://git.kernel.org/stable/c/d69d98d8edf90e25e4e09930dd36dd6d09dd6768
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
powerpc/fixmap: Fix VM debug warning on unmap
Unmapping a fixmap entry is done by calling __set_fixmap()
with FIXMAP_PAGE_CLEAR as flags.
Today, powerpc __set_fixmap() calls map_kernel_page().
map_kernel_page() is not happy when called a second time
for the same page.
WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8
CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682
NIP: c0017cd4 LR: c00187f0 CTR: 00000010
REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty)
MSR: 00029032 CR: 42000208 XER: 00000000
GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c
GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000
NIP [c0017cd4] set_pte_at+0xc/0x1e8
LR [c00187f0] map_kernel_page+0x9c/0x100
Call Trace:
[e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable)
[e1011e30] [c0165fec] __set_fixmap+0x30/0x44
[e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170
[e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0
[e1011e90] [c0c03634] do_one_initcall+0x80/0x178
[e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250
[e1011f20] [c0007e34] kernel_init+0x24/0x140
[e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010
4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030
Implement unmap_kernel_page() which clears an existing pte.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/033fd42c18d9b2121595b6f1e8419a115f9ac5b7
- https://git.kernel.org/stable/c/43ae0ccc4d2722b833fb59b905af129428e06d03
- https://git.kernel.org/stable/c/67baac10dd5ad1e9f50e8f2659984b3b0728d54e
- https://git.kernel.org/stable/c/aec982603aa8cc0a21143681feb5f60ecc69d718
- https://git.kernel.org/stable/c/033fd42c18d9b2121595b6f1e8419a115f9ac5b7
- https://git.kernel.org/stable/c/43ae0ccc4d2722b833fb59b905af129428e06d03
- https://git.kernel.org/stable/c/67baac10dd5ad1e9f50e8f2659984b3b0728d54e
- https://git.kernel.org/stable/c/aec982603aa8cc0a21143681feb5f60ecc69d718
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change The refcount leak issues take place in an error handling path. When the 3rd argument buf doesn't match with "offline", "online" or "remove", the function simply returns -EINVAL and forgets to decrease the reference count of a rpc_xprt object and a rpc_xprt_switch object increased by rpc_sysfs_xprt_kobj_get_xprt() and rpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference count leaks of both unused objects. Fix this issue by jumping to the error handling path labelled with out_put when buf matches none of "offline", "online" or "remove".
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/4b22aa42bd4d2d630ef1854c139275c3532937cb
- https://git.kernel.org/stable/c/5f6024c05a2c0fdd180b29395aaf686d25af3a0f
- https://git.kernel.org/stable/c/776d794f28c95051bc70405a7b1fa40115658a18
- https://git.kernel.org/stable/c/4b22aa42bd4d2d630ef1854c139275c3532937cb
- https://git.kernel.org/stable/c/5f6024c05a2c0fdd180b29395aaf686d25af3a0f
- https://git.kernel.org/stable/c/776d794f28c95051bc70405a7b1fa40115658a18
MEDIUM5.5
An information leak flaw was found due to uninitialized memory in the Linux kernel's TIPC protocol subsystem, in the way a user sends a TIPC datagram to one or more destinations. This flaw allows a local user to read some kernel memory. This issue is limited to no more than 7 bytes, and the user cannot control what is read. This flaw affects the Linux kernel versions prior to 5.17-rc1.
CVSS 2.0НИЗКАЯ 2.1
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:N/A:NCVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NHIGH7.8
A flaw was found in unrestricted eBPF usage by the BPF_BTF_LOAD, leading to a possible out-of-bounds memory write in the Linux kernel’s BPF subsystem due to the way a user loads BTF. This flaw allows a local user to crash or escalate their privileges on the system.
CVSS 2.0ВЫСОКАЯ 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CCVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://bugzilla.redhat.com/show_bug.cgi?id=2044578
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20b2aff4bc15bda809f994761d5719827d66c0b4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=216e3cd2f28dbbf1fe86848e0e29e6693b9f0a20
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34d3a78c681e8e7844b43d1a2f4671a04249c821
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4807322660d4290ac9062c034aed6b87243861
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48946bd6a5d695c50b34546864b79c1f910a33c1
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25b2ae136039ffa820c26138ed4a5e5f3ab3841
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf9f2f8d62eca810afbd1ee6cc0800202b000e57
- https://security.netapp.com/advisory/ntap-20220519-0001/
- https://bugzilla.redhat.com/show_bug.cgi?id=2044578
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20b2aff4bc15bda809f994761d5719827d66c0b4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=216e3cd2f28dbbf1fe86848e0e29e6693b9f0a20
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34d3a78c681e8e7844b43d1a2f4671a04249c821
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4807322660d4290ac9062c034aed6b87243861
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48946bd6a5d695c50b34546864b79c1f910a33c1
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25b2ae136039ffa820c26138ed4a5e5f3ab3841
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf9f2f8d62eca810afbd1ee6cc0800202b000e57
- https://security.netapp.com/advisory/ntap-20220519-0001/
HIGH7.8
A flaw was found in the way the "flags" member of the new pipe buffer structure was lacking proper initialization in copy_page_to_iter_pipe and push_pipe functions in the Linux kernel and could thus contain stale values. An unprivileged local user could use this flaw to write to pages in the page cache backed by read only files and as such escalate their privileges on the system.
CVSS 2.0ВЫСОКАЯ 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CCVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- http://packetstormsecurity.com/files/166229/Dirty-Pipe-Linux-Privilege-Escalation.html
- http://packetstormsecurity.com/files/166230/Dirty-Pipe-SUID-Binary-Hijack-Privilege-Escalation.html
- http://packetstormsecurity.com/files/166258/Dirty-Pipe-Local-Privilege-Escalation.html
- http://packetstormsecurity.com/files/176534/Linux-4.20-KTLS-Read-Only-Write.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2060795
- https://cert-portal.siemens.com/productcert/pdf/ssa-222547.pdf
- https://dirtypipe.cm4all.com/
- https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2022-0015
- https://security.netapp.com/advisory/ntap-20220325-0005/
- https://www.suse.com/support/kb/doc/?id=000020603
- http://packetstormsecurity.com/files/166229/Dirty-Pipe-Linux-Privilege-Escalation.html
- http://packetstormsecurity.com/files/166230/Dirty-Pipe-SUID-Binary-Hijack-Privilege-Escalation.html
- http://packetstormsecurity.com/files/166258/Dirty-Pipe-Local-Privilege-Escalation.html
- http://packetstormsecurity.com/files/176534/Linux-4.20-KTLS-Read-Only-Write.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2060795
- https://cert-portal.siemens.com/productcert/pdf/ssa-222547.pdf
- https://dirtypipe.cm4all.com/
- https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2022-0015
- https://security.netapp.com/advisory/ntap-20220325-0005/
- https://www.suse.com/support/kb/doc/?id=000020603
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-0847
HIGH7.8
kernel/bpf/verifier.c in the Linux kernel through 5.15.14 allows local users to gain privileges because of the availability of pointer arithmetic via certain *_OR_NULL pointer types.
CVSS 2.0ВЫСОКАЯ 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:CCVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- http://www.openwall.com/lists/oss-security/2022/01/14/1
- http://www.openwall.com/lists/oss-security/2022/01/18/2
- http://www.openwall.com/lists/oss-security/2022/06/01/1
- http://www.openwall.com/lists/oss-security/2022/06/04/3
- http://www.openwall.com/lists/oss-security/2022/06/07/3
- https://bugzilla.suse.com/show_bug.cgi?id=1194765
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64620e0a1e712a778095bd35cbb277dc2259281f
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FCR3LIRUEXR7CA63W5M2HT3K63MZGKBR/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z5VTIZZUPC73IEJNZX66BY2YCBRZAELB/
- https://security.netapp.com/advisory/ntap-20220217-0002/
- https://www.debian.org/security/2022/dsa-5050
- https://www.openwall.com/lists/oss-security/2022/01/13/1
- http://www.openwall.com/lists/oss-security/2022/01/14/1
- http://www.openwall.com/lists/oss-security/2022/01/18/2
- http://www.openwall.com/lists/oss-security/2022/06/01/1
- http://www.openwall.com/lists/oss-security/2022/06/04/3
- http://www.openwall.com/lists/oss-security/2022/06/07/3
- https://bugzilla.suse.com/show_bug.cgi?id=1194765
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64620e0a1e712a778095bd35cbb277dc2259281f
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FCR3LIRUEXR7CA63W5M2HT3K63MZGKBR/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z5VTIZZUPC73IEJNZX66BY2YCBRZAELB/
- https://security.netapp.com/advisory/ntap-20220217-0002/
- https://www.debian.org/security/2022/dsa-5050
- https://www.openwall.com/lists/oss-security/2022/01/13/1
MEDIUM4.6
An issue was discovered in drivers/usb/gadget/composite.c in the Linux kernel before 5.16.10. The USB Gadget subsystem lacks certain validation of interface OS descriptor requests (ones with a large array index and ones associated with NULL function pointer retrieval). Memory corruption might occur.
CVSS 2.0СРЕДНЯЯ 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:CCVSS 3.xСРЕДНЯЯ 4.6
CVSS:3.x/CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10
- https://github.com/szymonh/d-os-descriptor
- https://github.com/torvalds/linux/commit/75e5b4849b81e19e9efe1654b30d7f3151c33c2c
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/
- https://security.netapp.com/advisory/ntap-20221028-0007/
- https://www.debian.org/security/2022/dsa-5092
- https://www.debian.org/security/2022/dsa-5096
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10
- https://github.com/szymonh/d-os-descriptor
- https://github.com/torvalds/linux/commit/75e5b4849b81e19e9efe1654b30d7f3151c33c2c
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/
- https://security.netapp.com/advisory/ntap-20221028-0007/
- https://www.debian.org/security/2022/dsa-5092
- https://www.debian.org/security/2022/dsa-5096
HIGH7.8
In the Linux kernel through 5.16.10, certain binary files may have the exec-all attribute if they were built in approximately 2003 (e.g., with GCC 3.2.2 and Linux kernel 2.4.20). This can cause execution of bytes located in supposedly non-executable regions of a file.
CVSS 2.0СРЕДНЯЯ 4.4
CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:PCVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://github.com/torvalds/linux/blob/1c33bb0507508af24fd754dd7123bd8e997fab2f/arch/x86/include/asm/elf.h#L281-L294
- https://github.com/x0reaxeax/exec-prot-bypass
- https://security.netapp.com/advisory/ntap-20220318-0005/
- https://github.com/torvalds/linux/blob/1c33bb0507508af24fd754dd7123bd8e997fab2f/arch/x86/include/asm/elf.h#L281-L294
- https://github.com/x0reaxeax/exec-prot-bypass
- https://security.netapp.com/advisory/ntap-20220318-0005/
MEDIUM5.5
An issue was discovered in drivers/usb/gadget/function/rndis.c in the Linux kernel before 5.16.10. The RNDIS USB gadget lacks validation of the size of the RNDIS_MSG_SET command. Attackers can obtain sensitive information from kernel memory.
CVSS 2.0НИЗКАЯ 2.1
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:N/A:NCVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NСсылки
- http://www.openwall.com/lists/oss-security/2022/02/21/1
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10
- https://github.com/szymonh/rndis-co
- https://github.com/torvalds/linux/commit/38ea1eac7d88072bbffb630e2b3db83ca649b826
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://www.debian.org/security/2022/dsa-5092
- https://www.debian.org/security/2022/dsa-5096
- http://www.openwall.com/lists/oss-security/2022/02/21/1
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10
- https://github.com/szymonh/rndis-co
- https://github.com/torvalds/linux/commit/38ea1eac7d88072bbffb630e2b3db83ca649b826
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://www.debian.org/security/2022/dsa-5092
- https://www.debian.org/security/2022/dsa-5096
MEDIUM5.5
In drivers/hid/hid-elo.c in the Linux kernel before 5.16.11, a memory leak exists for a certain hid_parse error condition.
CVSS 2.0НИЗКАЯ 2.1
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:PCVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.11
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=817b8b9c5396d2b2d92311b46719aad5d3339dbe
- https://github.com/torvalds/linux/commit/817b8b9c5396d2b2d92311b46719aad5d3339dbe
- https://www.openwall.com/lists/oss-security/2022/03/13/1
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.11
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=817b8b9c5396d2b2d92311b46719aad5d3339dbe
- https://github.com/torvalds/linux/commit/817b8b9c5396d2b2d92311b46719aad5d3339dbe
- https://www.openwall.com/lists/oss-security/2022/03/13/1
HIGH7.8
A flaw was found in the Linux kernel’s driver for the ASIX AX88179_178A-based USB 2.0/3.0 Gigabit Ethernet Devices. The vulnerability contains multiple out-of-bounds reads and possible out-of-bounds writes.
CVSS 3.xВЫСОКАЯ 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: xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create If there are failures then we must not leave the non-NULL pointers with the error value, otherwise `rpcrdma_ep_destroy` gets confused and tries free them, resulting in an Oops.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1e7433fb95ccc01629a5edaa4ced0cd8c98d0ae0
- https://git.kernel.org/stable/c/2526d4d8b209dc5ac1fbeb468149774888b2a141
- https://git.kernel.org/stable/c/9921c866dc369577c3ebb9adf2383b01b58c18de
- https://git.kernel.org/stable/c/a9c10b5b3b67b3750a10c8b089b2e05f5e176e33
- https://git.kernel.org/stable/c/1e7433fb95ccc01629a5edaa4ced0cd8c98d0ae0
- https://git.kernel.org/stable/c/2526d4d8b209dc5ac1fbeb468149774888b2a141
- https://git.kernel.org/stable/c/9921c866dc369577c3ebb9adf2383b01b58c18de
- https://git.kernel.org/stable/c/a9c10b5b3b67b3750a10c8b089b2e05f5e176e33
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ptdma: Fix the error handling path in pt_core_init() In order to free resources correctly in the error handling path of pt_core_init(), 2 goto's have to be switched. Otherwise, some resources will leak and we will try to release things that have not been allocated yet. Also move a dev_err() to a place where it is more meaningful.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3c62fd3406e0b2277c76a6984d3979c7f3f1d129
- https://git.kernel.org/stable/c/3e41445287afa3cf6d572778e5aab31d25e60a8d
- https://git.kernel.org/stable/c/d7de1e4820c5a42441ff7276174c8c0e63575c1b
- https://git.kernel.org/stable/c/3c62fd3406e0b2277c76a6984d3979c7f3f1d129
- https://git.kernel.org/stable/c/3e41445287afa3cf6d572778e5aab31d25e60a8d
- https://git.kernel.org/stable/c/d7de1e4820c5a42441ff7276174c8c0e63575c1b
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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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: mtd: parsers: qcom: Fix missing free for pparts in cleanup Mtdpart doesn't free pparts when a cleanup function is declared. Add missing free for pparts in cleanup function for smem to fix the leak.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1b37889f9a151d26a3fb0d3870f6e1046dee2e24
- https://git.kernel.org/stable/c/3dd8ba961b9356c4113b96541c752c73d98fef70
- https://git.kernel.org/stable/c/3eb5185896a68373714dc7d0009111744adc3345
- https://git.kernel.org/stable/c/1b37889f9a151d26a3fb0d3870f6e1046dee2e24
- https://git.kernel.org/stable/c/3dd8ba961b9356c4113b96541c752c73d98fef70
- https://git.kernel.org/stable/c/3eb5185896a68373714dc7d0009111744adc3345
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mtd: parsers: qcom: Fix kernel panic on skipped partition In the event of a skipped partition (case when the entry name is empty) the kernel panics in the cleanup function as the name entry is NULL. Rework the parser logic by first checking the real partition number and then allocate the space and set the data for the valid partitions. The logic was also fundamentally wrong as with a skipped partition, the parts number returned was incorrect by not decreasing it for the skipped partitions.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/65d003cca335cabc0160d3cd7daa689eaa9dd3cd
- https://git.kernel.org/stable/c/a2995fe23095ceda2dc382fbe057f5e164595548
- https://git.kernel.org/stable/c/eb03cb6e03ffd9173e18e5fe87e4e3ce83820453
- https://git.kernel.org/stable/c/65d003cca335cabc0160d3cd7daa689eaa9dd3cd
- https://git.kernel.org/stable/c/a2995fe23095ceda2dc382fbe057f5e164595548
- https://git.kernel.org/stable/c/eb03cb6e03ffd9173e18e5fe87e4e3ce83820453
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: gpmi: don't leak PM reference in error path If gpmi_nfc_apply_timings() fails, the PM runtime usage counter must be dropped.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/4a7ec50298b1127c5024a750c969ea0794899545
- https://git.kernel.org/stable/c/4cd3281a910a5adf73b2a0a82241dd67844d0b25
- https://git.kernel.org/stable/c/58d3111eafce9e4398654b07f0b1dac27f26ee5b
- https://git.kernel.org/stable/c/9161f365c91614e5a3f5c6dcc44c3b1b33bc59c0
- https://git.kernel.org/stable/c/a4eeeaca50199e3f19eb13ac3b7e0bbb93e22de4
- https://git.kernel.org/stable/c/4a7ec50298b1127c5024a750c969ea0794899545
- https://git.kernel.org/stable/c/4cd3281a910a5adf73b2a0a82241dd67844d0b25
- https://git.kernel.org/stable/c/58d3111eafce9e4398654b07f0b1dac27f26ee5b
- https://git.kernel.org/stable/c/9161f365c91614e5a3f5c6dcc44c3b1b33bc59c0
- https://git.kernel.org/stable/c/a4eeeaca50199e3f19eb13ac3b7e0bbb93e22de4
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: fix use-after-free in ocelot_vlan_del() ocelot_vlan_member_del() will free the struct ocelot_bridge_vlan, so if this is the same as the port's pvid_vlan which we access afterwards, what we're accessing is freed memory. Fix the bug by determining whether to clear ocelot_port->pvid_vlan prior to calling ocelot_vlan_member_del().
CVSS 3.xВЫСОКАЯ 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: net/smc: Avoid overwriting the copies of clcsock callback functions The callback functions of clcsock will be saved and replaced during the fallback. But if the fallback happens more than once, then the copies of these callback functions will be overwritten incorrectly, resulting in a loop call issue: clcsk->sk_error_report |- smc_fback_error_report() <------------------------------| |- smc_fback_forward_wakeup() | (loop) |- clcsock_callback() (incorrectly overwritten) | |- smc->clcsk_error_report() ------------------| So this patch fixes the issue by saving these function pointers only once in the fallback and avoiding overwriting.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1de9770d121ee9294794cca0e0be8fbfa0134ee8
- https://git.kernel.org/stable/c/7de7ba7a8bd4fde0141de8674c13514d0072f0e6
- https://git.kernel.org/stable/c/f00b6c976ae0dfbd9b891175f713f59095d23842
- https://git.kernel.org/stable/c/1de9770d121ee9294794cca0e0be8fbfa0134ee8
- https://git.kernel.org/stable/c/7de7ba7a8bd4fde0141de8674c13514d0072f0e6
- https://git.kernel.org/stable/c/f00b6c976ae0dfbd9b891175f713f59095d23842
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - get rid of alg_memory_allocated
alg_memory_allocated does not seem to be really used.
alg_proto does have a .memory_allocated field, but no
corresponding .sysctl_mem.
This means sk_has_account() returns true, but all sk_prot_mem_limits()
users will trigger a NULL dereference [1].
THis was not a problem until SO_RESERVE_MEM addition.
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 3591 Comm: syz-executor153 Not tainted 5.17.0-rc3-syzkaller-00316-gb81b1829e7e3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:sk_prot_mem_limits include/net/sock.h:1523 [inline]
RIP: 0010:sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000
Code: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48
RSP: 0018:ffffc90001f1fb68 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000
RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff90e18120
RBP: 0000000000000008 R08: dffffc0000000000 R09: fffffbfff21c3025
R10: fffffbfff21c3025 R11: 0000000000000000 R12: ffffffff8d109840
R13: 0000000000001002 R14: 0000000000000001 R15: 0000000000000001
FS: 0000555556e08300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc74416f130 CR3: 0000000073d9e000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sock_setsockopt+0x14a9/0x3a30 net/core/sock.c:1446
__sys_setsockopt+0x5af/0x980 net/socket.c:2176
__do_sys_setsockopt net/socket.c:2191 [inline]
__se_sys_setsockopt net/socket.c:2188 [inline]
__x64_sys_setsockopt+0xb1/0xc0 net/socket.c:2188
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fc7440fddc9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 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:00007ffe98f07968 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc7440fddc9
RDX: 0000000000000049 RSI: 0000000000000001 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000004 R09: 00007ffe98f07990
R10: 0000000020000000 R11: 0000000000000246 R12: 00007ffe98f0798c
R13: 00007ffe98f079a0 R14: 00007ffe98f079e0 R15: 0000000000000000
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:sk_prot_mem_limits include/net/sock.h:1523 [inline]
RIP: 0010:sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000
Code: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48
RSP: 0018:ffffc90001f1fb68 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000
RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff90e18120
RBP: 0000000000000008 R08: dffffc0000000000 R09: fffffbfff21c3025
R10: fffffbfff21c3025 R11: 0000000000000000 R12: ffffffff8d109840
R13: 0000000000001002 R14: 0000000000000001 R15: 0000000000000001
FS: 0000555556e08300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc74416f130 CR3: 0000000073d9e000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
CVSS 3.xСРЕДНЯЯ 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: mctp: fix use after free Clang static analysis reports this problem route.c:425:4: warning: Use of memory after it is freed trace_mctp_key_acquire(key); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ When mctp_key_add() fails, key is freed but then is later used in trace_mctp_key_acquire(). Add an else statement to use the key only when mctp_key_add() is successful.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: cfg80211: fix race in netlink owner interface destruction My previous fix here to fix the deadlock left a race where the exact same deadlock (see the original commit referenced below) can still happen if cfg80211_destroy_ifaces() already runs while nl80211_netlink_notify() is still marking some interfaces as nl_owner_dead. The race happens because we have two loops here - first we dev_close() all the netdevs, and then we destroy them. If we also have two netdevs (first one need only be a wdev though) then we can find one during the first iteration, close it, and go to the second iteration -- but then find two, and try to destroy also the one we didn't close yet. Fix this by only iterating once.
CVSS 3.xСРЕДНЯЯ 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/241e633cb379c4f332fc1baf2abec95ec840cbeb
- https://git.kernel.org/stable/c/c979f792a2baf6d0f3419587668a1a6eba46a3d2
- https://git.kernel.org/stable/c/f0a6fd1527067da537e9c48390237488719948ed
- https://git.kernel.org/stable/c/241e633cb379c4f332fc1baf2abec95ec840cbeb
- https://git.kernel.org/stable/c/c979f792a2baf6d0f3419587668a1a6eba46a3d2
- https://git.kernel.org/stable/c/f0a6fd1527067da537e9c48390237488719948ed
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: use rcu-safe version of ipv6_get_lladdr()
Some time ago 8965779d2c0e ("ipv6,mcast: always hold idev->lock before mca_lock")
switched ipv6_get_lladdr() to __ipv6_get_lladdr(), which is rcu-unsafe
version. That was OK, because idev->lock was held for these codepaths.
In 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") these external locks were
removed, so we probably need to restore the original rcu-safe call.
Otherwise, we occasionally get a machine crashed/stalled with the following
in dmesg:
[ 3405.966610][T230589] general protection fault, probably for non-canonical address 0xdead00000000008c: 0000 [#1] SMP NOPTI
[ 3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: G O 5.15.19-cloudflare-2022.2.1 #1
[ 3405.998061][T230589] Hardware name: SUPA-COOL-SERV
[ 3406.009552][T230589] Workqueue: mld mld_ifc_work
[ 3406.017224][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60
[ 3406.025780][T230589] Code: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 <66> 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b
[ 3406.055748][T230589] RSP: 0018:ffff94e4b3fc3d10 EFLAGS: 00010202
[ 3406.065617][T230589] RAX: dead00000000005a RBX: ffff94e4b3fc3d30 RCX: 0000000000000040
[ 3406.077477][T230589] RDX: dead000000000122 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008
[ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000
[ 3406.101445][T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100
[ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 00000000000005dc R15: ffff8c3a31431000
[ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000
[ 3406.138992][T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0000000000350ee0
[ 3406.162421][T230589] Call Trace:
[ 3406.170235][T230589]
[ 3406.177736][T230589] mld_newpack+0xfe/0x1a0
[ 3406.186686][T230589] add_grhead+0x87/0xa0
[ 3406.195498][T230589] add_grec+0x485/0x4e0
[ 3406.204310][T230589] ? newidle_balance+0x126/0x3f0
[ 3406.214024][T230589] mld_ifc_work+0x15d/0x450
[ 3406.223279][T230589] process_one_work+0x1e6/0x380
[ 3406.232982][T230589] worker_thread+0x50/0x3a0
[ 3406.242371][T230589] ? rescuer_thread+0x360/0x360
[ 3406.252175][T230589] kthread+0x127/0x150
[ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40
[ 3406.271287][T230589] ret_from_fork+0x22/0x30
[ 3406.280812][T230589]
[ 3406.288937][T230589] Modules linked in: ... [last unloaded: kheaders]
[ 3406.476714][T230589] ---[ end trace 3525a7655f2f3b9e ]---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/26394fc118d6115390bd5b3a0fb17096271da227
- https://git.kernel.org/stable/c/27f567c84f446048670376827e356f9c92033bf9
- https://git.kernel.org/stable/c/3e11ef1903cf6c2fba35594b193a3570854d9e9e
- https://git.kernel.org/stable/c/26394fc118d6115390bd5b3a0fb17096271da227
- https://git.kernel.org/stable/c/27f567c84f446048670376827e356f9c92033bf9
- https://git.kernel.org/stable/c/3e11ef1903cf6c2fba35594b193a3570854d9e9e
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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.8
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/5e42fca37ccc76f39f73732661bd47254cad5982
- https://git.kernel.org/stable/c/61a26ffd5ad3ece456d74c4c79f7b5e3f440a141
- https://git.kernel.org/stable/c/bb0d8fb35c4ff00a503c2c4dca4cce8d102a21c4
- https://git.kernel.org/stable/c/e192184cf8bce8dd55d619f5611a2eaba996fa05
- https://git.kernel.org/stable/c/ff9fc7ebf5c06de1ef72a69f9b1ab40af8b07f9e
- https://git.kernel.org/stable/c/5e42fca37ccc76f39f73732661bd47254cad5982
- https://git.kernel.org/stable/c/61a26ffd5ad3ece456d74c4c79f7b5e3f440a141
- https://git.kernel.org/stable/c/bb0d8fb35c4ff00a503c2c4dca4cce8d102a21c4
- https://git.kernel.org/stable/c/e192184cf8bce8dd55d619f5611a2eaba996fa05
- https://git.kernel.org/stable/c/ff9fc7ebf5c06de1ef72a69f9b1ab40af8b07f9e
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.xВЫСОКАЯ 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this pointer is cleared.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/3c334cdfd94945b8edb94022a0371a8665b17366
- https://git.kernel.org/stable/c/510b21442c3a2e3ecc071ba3e666b320e7acdd61
- https://git.kernel.org/stable/c/61f162aa4381845acbdc7f2be4dfb694d027c018
- https://git.kernel.org/stable/c/d872e7b5fe38f325f5206b6872746fa02c2b4819
- https://git.kernel.org/stable/c/3c334cdfd94945b8edb94022a0371a8665b17366
- https://git.kernel.org/stable/c/510b21442c3a2e3ecc071ba3e666b320e7acdd61
- https://git.kernel.org/stable/c/61f162aa4381845acbdc7f2be4dfb694d027c018
- https://git.kernel.org/stable/c/d872e7b5fe38f325f5206b6872746fa02c2b4819
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task Currently a use-after-free may occur if a sas_task is aborted by the upper layer before we handle the I/O completion in mpi_ssp_completion() or mpi_sata_completion(). In this case, the following are the two steps in handling those I/O completions: - Call complete() to inform the upper layer handler of completion of the I/O. - Release driver resources associated with the sas_task in pm8001_ccb_task_free() call. When complete() is called, the upper layer may free the sas_task. As such, we should not touch the associated sas_task afterwards, but we do so in the pm8001_ccb_task_free() call. Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/d9d93f32534a0a80a1c26bdb0746d90a7b19c2c2
- https://git.kernel.org/stable/c/df7abcaa1246e2537ab4016077b5443bb3c09378
- https://git.kernel.org/stable/c/f61f9fccb2cb4bb275674a79d638704db6bc2171
- https://git.kernel.org/stable/c/fe9ac3eaa2e387a5742b380b73a5a6bc237bf184
- https://git.kernel.org/stable/c/d9d93f32534a0a80a1c26bdb0746d90a7b19c2c2
- https://git.kernel.org/stable/c/df7abcaa1246e2537ab4016077b5443bb3c09378
- https://git.kernel.org/stable/c/f61f9fccb2cb4bb275674a79d638704db6bc2171
- https://git.kernel.org/stable/c/fe9ac3eaa2e387a5742b380b73a5a6bc237bf184
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: nSVM: fix potential NULL derefernce on nested migration Turns out that due to review feedback and/or rebases I accidentally moved the call to nested_svm_load_cr3 to be too early, before the NPT is enabled, which is very wrong to do. KVM can't even access guest memory at that point as nested NPT is needed for that, and of course it won't initialize the walk_mmu, which is main issue the patch was addressing. Fix this for real.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/352193edda48e08e8824a7ece09aec830a603cfe
- https://git.kernel.org/stable/c/74b426bea4f7e3b081add2b88d4fba16d3af7ab6
- https://git.kernel.org/stable/c/e1779c2714c3023e4629825762bcbc43a3b943df
- https://git.kernel.org/stable/c/352193edda48e08e8824a7ece09aec830a603cfe
- https://git.kernel.org/stable/c/74b426bea4f7e3b081add2b88d4fba16d3af7ab6
- https://git.kernel.org/stable/c/e1779c2714c3023e4629825762bcbc43a3b943df
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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: iommu: Fix potential use-after-free during probe Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free. BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153 Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78 __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228 __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18 Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/65ab30f6a6952fa9ee13009862736cf8d110e6e5
- https://git.kernel.org/stable/c/b54240ad494300ff0994c4539a531727874381f4
- https://git.kernel.org/stable/c/cb86e511e78e796de6947b8f3acca1b7c76fb2ff
- https://git.kernel.org/stable/c/f74fc4b5bd533ea3d30ce47cccb8ef8d21fda85a
- https://git.kernel.org/stable/c/65ab30f6a6952fa9ee13009862736cf8d110e6e5
- https://git.kernel.org/stable/c/b54240ad494300ff0994c4539a531727874381f4
- https://git.kernel.org/stable/c/cb86e511e78e796de6947b8f3acca1b7c76fb2ff
- https://git.kernel.org/stable/c/f74fc4b5bd533ea3d30ce47cccb8ef8d21fda85a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm: don't try to NUMA-migrate COW pages that have other uses Oded Gabbay reports that enabling NUMA balancing causes corruption with his Gaudi accelerator test load: "All the details are in the bug, but the bottom line is that somehow, this patch causes corruption when the numa balancing feature is enabled AND we don't use process affinity AND we use GUP to pin pages so our accelerator can DMA to/from system memory. Either disabling numa balancing, using process affinity to bind to specific numa-node or reverting this patch causes the bug to disappear" and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page() simplification"). Now, the NUMA balancing shouldn't actually be changing the writability of a page, and as such shouldn't matter for COW. But it appears it does. Suspicious. However, regardless of that, the condition for enabling NUMA faults in change_pte_range() is nonsensical. It uses "page_mapcount(page)" to decide if a COW page should be NUMA-protected or not, and that makes absolutely no sense. The number of mappings a page has is irrelevant: not only does GUP get a reference to a page as in Oded's case, but the other mappings migth be paged out and the only reference to them would be in the page count. Since we should never try to NUMA-balance a page that we can't move anyway due to other references, just fix the code to use 'page_count()'. Oded confirms that that fixes his issue. Now, this does imply that something in NUMA balancing ends up changing page protections (other than the obvious one of making the page inaccessible to get the NUMA faulting information). Otherwise the COW simplification wouldn't matter - since doing the GUP on the page would make sure it's writable. The cause of that permission change would be good to figure out too, since it clearly results in spurious COW events - but fixing the nonsensical test that just happened to work before is obviously the CorrectThing(tm) to do regardless.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/254090925e16abd914c87b4ad1b489440d89c4c3
- https://git.kernel.org/stable/c/80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6
- https://git.kernel.org/stable/c/b3dc4b9d3ca68b370c4aeab5355007eedf948849
- https://git.kernel.org/stable/c/d187eeb02d18446e5e54ed6bcbf8b47e6551daea
- https://git.kernel.org/stable/c/254090925e16abd914c87b4ad1b489440d89c4c3
- https://git.kernel.org/stable/c/80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6
- https://git.kernel.org/stable/c/b3dc4b9d3ca68b370c4aeab5355007eedf948849
- https://git.kernel.org/stable/c/d187eeb02d18446e5e54ed6bcbf8b47e6551daea
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: s390/cio: verify the driver availability for path_event call If no driver is attached to a device or the driver does not provide the path_event function, an FCES path-event on this device could end up in a kernel-panic. Verify the driver availability before the path_event function call.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/a0619027f11590b2070624297530c34dc7f91bcd
- https://git.kernel.org/stable/c/dd9cb842fa9d90653a9b48aba52f89c069f3bc50
- https://git.kernel.org/stable/c/fe990b7bf6ac93f1d850d076b8f0e758268aa4ab
- https://git.kernel.org/stable/c/a0619027f11590b2070624297530c34dc7f91bcd
- https://git.kernel.org/stable/c/dd9cb842fa9d90653a9b48aba52f89c069f3bc50
- https://git.kernel.org/stable/c/fe990b7bf6ac93f1d850d076b8f0e758268aa4ab
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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm: vmscan: remove deadlock due to throttling failing to make progress A soft lockup bug in kcompactd was reported in a private bugzilla with the following visible in dmesg; watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479] The machine had 256G of RAM with no swap and an earlier failed allocation indicated that node 0 where kcompactd was run was potentially unreclaimable; Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes Vlastimil Babka investigated a crash dump and found that a task migrating pages was trying to drain PCP lists; PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: "kworker/u128:3" Call Trace: __schedule schedule schedule_timeout wait_for_completion __flush_work __drain_all_pages __alloc_pages_slowpath.constprop.114 __alloc_pages alloc_migration_target migrate_pages migrate_to_node do_migrate_pages cpuset_migrate_mm_workfn process_one_work worker_thread kthread ret_from_fork This failure is specific to CONFIG_PREEMPT=n builds. The root of the problem is that kcompact0 is not rescheduling on a CPU while a task that has isolated a large number of the pages from the LRU is waiting on kcompact0 to reschedule so the pages can be released. While shrink_inactive_list() only loops once around too_many_isolated, reclaim can continue without rescheduling if sc->skipped_deactivate == 1 which could happen if there was no file LRU and the inactive anon list was not low.
CVSS 3.xСРЕДНЯЯ 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: iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL If we fail to copy the just created file descriptor to userland, we try to clean up by putting back 'fd' and freeing 'ib'. The code uses put_unused_fd() for the former which is wrong, as the file descriptor was already published by fd_install() which gets called internally by anon_inode_getfd(). This makes the error handling code leaving a half cleaned up file descriptor table around and a partially destructed 'file' object, allowing userland to play use-after-free tricks on us, by abusing the still usable fd and making the code operate on a dangling 'file->private_data' pointer. Instead of leaving the kernel in a partially corrupted state, don't attempt to explicitly clean up and leave this to the process exit path that'll release any still valid fds, including the one created by the previous call to anon_inode_getfd(). Simply return -EFAULT to indicate the error.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/202071d2518537866d291aa7cf26af54e674f4d4
- https://git.kernel.org/stable/c/b7f54894aa7517d2b6c797a499b9f491e9db9083
- https://git.kernel.org/stable/c/c72ea20503610a4a7ba26c769357d31602769c01
- https://git.kernel.org/stable/c/202071d2518537866d291aa7cf26af54e674f4d4
- https://git.kernel.org/stable/c/b7f54894aa7517d2b6c797a499b9f491e9db9083
- https://git.kernel.org/stable/c/c72ea20503610a4a7ba26c769357d31602769c01
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fs/proc: task_mmu.c: don't read mapcount for migration entry The syzbot reported the below BUG: kernel BUG at include/linux/page-flags.h:785! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline] RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744 Call Trace: page_mapcount include/linux/mm.h:837 [inline] smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466 smaps_pte_entry fs/proc/task_mmu.c:538 [inline] smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601 walk_pmd_range mm/pagewalk.c:128 [inline] walk_pud_range mm/pagewalk.c:205 [inline] walk_p4d_range mm/pagewalk.c:240 [inline] walk_pgd_range mm/pagewalk.c:277 [inline] __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379 walk_page_vma+0x277/0x350 mm/pagewalk.c:530 smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768 smap_gather_stats fs/proc/task_mmu.c:741 [inline] show_smap+0xc6/0x440 fs/proc/task_mmu.c:822 seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272 seq_read+0x3e0/0x5b0 fs/seq_file.c:162 vfs_read+0x1b5/0x600 fs/read_write.c:479 ksys_read+0x12d/0x250 fs/read_write.c:619 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 The reproducer was trying to read /proc/$PID/smaps when calling MADV_FREE at the mean time. MADV_FREE may split THPs if it is called for partial THP. It may trigger the below race: CPU A CPU B ----- ----- smaps walk: MADV_FREE: page_mapcount() PageCompound() split_huge_page() page = compound_head(page) PageDoubleMap(page) When calling PageDoubleMap() this page is not a tail page of THP anymore so the BUG is triggered. This could be fixed by elevated refcount of the page before calling mapcount, but that would prevent it from counting migration entries, and it seems overkilling because the race just could happen when PMD is split so all PTE entries of tail pages are actually migration entries, and smaps_account() does treat migration entries as mapcount == 1 as Kirill pointed out. Add a new parameter for smaps_account() to tell this entry is migration entry then skip calling page_mapcount(). Don't skip getting mapcount for device private entries since they do track references with mapcount. Pagemap also has the similar issue although it was not reported. Fixed it as well. [shy828301@gmail.com: v4] [nathan@kernel.org: avoid unused variable warning in pagemap_pmd_range()]
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/05d3f8045efa59457b323caf00bdb9273b7962fa
- https://git.kernel.org/stable/c/24d7275ce2791829953ed4e72f68277ceb2571c6
- https://git.kernel.org/stable/c/a8dd0cfa37792863b6c4bf9542975212a6715d49
- https://git.kernel.org/stable/c/db3f3636e4aed2cba3e4e7897a053323f7a62249
- https://git.kernel.org/stable/c/05d3f8045efa59457b323caf00bdb9273b7962fa
- https://git.kernel.org/stable/c/24d7275ce2791829953ed4e72f68277ceb2571c6
- https://git.kernel.org/stable/c/a8dd0cfa37792863b6c4bf9542975212a6715d49
- https://git.kernel.org/stable/c/db3f3636e4aed2cba3e4e7897a053323f7a62249
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: phy: ti: Fix missing sentinel for clk_div_table _get_table_maxdiv() tries to access "clk_div_table" array out of bound defined in phy-j721e-wiz.c. Add a sentinel entry to prevent the following global-out-of-bounds error reported by enabling KASAN. [ 9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148 [ 9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38 [ 9.565926] [ 9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360 [ 9.576242] Hardware name: Texas Instruments J721e EVM (DT) [ 9.581832] Workqueue: events_unbound deferred_probe_work_func [ 9.587708] Call trace: [ 9.590174] dump_backtrace+0x20c/0x218 [ 9.594038] show_stack+0x18/0x68 [ 9.597375] dump_stack_lvl+0x9c/0xd8 [ 9.601062] print_address_description.constprop.0+0x78/0x334 [ 9.606830] kasan_report+0x1f0/0x260 [ 9.610517] __asan_load4+0x9c/0xd8 [ 9.614030] _get_maxdiv+0xc0/0x148 [ 9.617540] divider_determine_rate+0x88/0x488 [ 9.622005] divider_round_rate_parent+0xc8/0x124 [ 9.626729] wiz_clk_div_round_rate+0x54/0x68 [ 9.631113] clk_core_determine_round_nolock+0x124/0x158 [ 9.636448] clk_core_round_rate_nolock+0x68/0x138 [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8 [ 9.645987] clk_set_rate+0x50/0xa8 [ 9.649499] cdns_sierra_phy_init+0x88/0x248 [ 9.653794] phy_init+0x98/0x108 [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170 [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0 [ 9.665546] j721e_pcie_probe+0x4b8/0x798 [ 9.669579] platform_probe+0x8c/0x108 [ 9.673350] really_probe+0x114/0x630 [ 9.677037] __driver_probe_device+0x18c/0x220 [ 9.681505] driver_probe_device+0xac/0x150 [ 9.685712] __device_attach_driver+0xec/0x170 [ 9.690178] bus_for_each_drv+0xf0/0x158 [ 9.694124] __device_attach+0x184/0x210 [ 9.698070] device_initial_probe+0x14/0x20 [ 9.702277] bus_probe_device+0xec/0x100 [ 9.706223] deferred_probe_work_func+0x124/0x180 [ 9.710951] process_one_work+0x4b0/0xbc0 [ 9.714983] worker_thread+0x74/0x5d0 [ 9.718668] kthread+0x214/0x230 [ 9.721919] ret_from_fork+0x10/0x20 [ 9.725520] [ 9.727032] The buggy address belongs to the variable: [ 9.732183] clk_div_table+0x24/0x440
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3c75d1017cb362b6a4e0935746ef5da28250919f
- https://git.kernel.org/stable/c/5b0c9569135a37348c1267c81e8b0274b21a86ed
- https://git.kernel.org/stable/c/6d1e6bcb31663ee83aaea1f171f3dbfe95dd4a69
- https://git.kernel.org/stable/c/7a360e546ad9e7c3fd53d6bb60348c660cd28f54
- https://git.kernel.org/stable/c/3c75d1017cb362b6a4e0935746ef5da28250919f
- https://git.kernel.org/stable/c/5b0c9569135a37348c1267c81e8b0274b21a86ed
- https://git.kernel.org/stable/c/6d1e6bcb31663ee83aaea1f171f3dbfe95dd4a69
- https://git.kernel.org/stable/c/7a360e546ad9e7c3fd53d6bb60348c660cd28f54
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/170325aba4608bde3e7d21c9c19b7bc266ac0885
- https://git.kernel.org/stable/c/2a45a6bd1e6d651770aafff57ab3e1d3bb0b42e0
- https://git.kernel.org/stable/c/61cc70d9e8ef5b042d4ed87994d20100ec8896d9
- https://git.kernel.org/stable/c/6550bdf52846f85a2a3726a5aa0c7c4399f2fc02
- https://git.kernel.org/stable/c/778302ca09498b448620edd372dc908bebf80bdf
- https://git.kernel.org/stable/c/830c5aa302ec16b4ee641aec769462c37f802c90
- https://git.kernel.org/stable/c/ae3d57411562260ee3f4fd5e875f410002341104
- https://git.kernel.org/stable/c/ffe54289b02e9c732d6f04c8ebbe3b2d90d32118
- https://git.kernel.org/stable/c/170325aba4608bde3e7d21c9c19b7bc266ac0885
- https://git.kernel.org/stable/c/2a45a6bd1e6d651770aafff57ab3e1d3bb0b42e0
- https://git.kernel.org/stable/c/61cc70d9e8ef5b042d4ed87994d20100ec8896d9
- https://git.kernel.org/stable/c/6550bdf52846f85a2a3726a5aa0c7c4399f2fc02
- https://git.kernel.org/stable/c/778302ca09498b448620edd372dc908bebf80bdf
- https://git.kernel.org/stable/c/830c5aa302ec16b4ee641aec769462c37f802c90
- https://git.kernel.org/stable/c/ae3d57411562260ee3f4fd5e875f410002341104
- https://git.kernel.org/stable/c/ffe54289b02e9c732d6f04c8ebbe3b2d90d32118
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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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: eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX Commit effa453168a7 ("i2c: i801: Don't silently correct invalid transfer size") revealed that ee1004_eeprom_read() did not properly limit how many bytes to read at once. In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the length to read as an u8. If count == 256 after taking into account the offset and page boundary, the cast to u8 overflows. And this is common when user space tries to read the entire EEPROM at once. To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3937c35493ee2847aaefcfa5460e94b7443eef49
- https://git.kernel.org/stable/c/9443ddeb3754e9e382a396b50adc1961301713ce
- https://git.kernel.org/stable/c/9a5f471ae380f9fcb9756d453c12ca1f8595a93c
- https://git.kernel.org/stable/c/a37960df7eac3cc8094bd1ab84864e9e32c91345
- https://git.kernel.org/stable/c/c0689e46be23160d925dca95dfc411f1a0462708
- https://git.kernel.org/stable/c/3937c35493ee2847aaefcfa5460e94b7443eef49
- https://git.kernel.org/stable/c/9443ddeb3754e9e382a396b50adc1961301713ce
- https://git.kernel.org/stable/c/9a5f471ae380f9fcb9756d453c12ca1f8595a93c
- https://git.kernel.org/stable/c/a37960df7eac3cc8094bd1ab84864e9e32c91345
- https://git.kernel.org/stable/c/c0689e46be23160d925dca95dfc411f1a0462708
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler Currently, the same handler is called for both a NETDEV_BONDING_INFO LAG unlink notification as for a NETDEV_UNREGISTER call. This is causing a problem though, since the netdev_notifier_info passed has a different structure depending on which event is passed. The problem manifests as a call trace from a BUG: KASAN stack-out-of-bounds error. Fix this by creating a handler specific to NETDEV_UNREGISTER that only is passed valid elements in the netdev_notifier_info struct for the NETDEV_UNREGISTER event. Also included is the removal of an unbalanced dev_put on the peer_netdev and related braces.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/bea1898f65b9b7096cb4e73e97c83b94718f1fa1
- https://git.kernel.org/stable/c/f9daedc3ab8f673e3a9374b91a89fbf1174df469
- https://git.kernel.org/stable/c/faa9bcf700ca1a0d09f92502a6b65d3ce313fb46
- https://git.kernel.org/stable/c/bea1898f65b9b7096cb4e73e97c83b94718f1fa1
- https://git.kernel.org/stable/c/f9daedc3ab8f673e3a9374b91a89fbf1174df469
- https://git.kernel.org/stable/c/faa9bcf700ca1a0d09f92502a6b65d3ce313fb46
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix panic when DSA master device unbinds on shutdown Rafael reports that on a system with LX2160A and Marvell DSA switches, if a reboot occurs while the DSA master (dpaa2-eth) is up, the following panic can be seen: systemd-shutdown[1]: Rebooting. Unable to handle kernel paging request at virtual address 00a0000800000041 [00a0000800000041] address between user and kernel address ranges Internal error: Oops: 96000004 [#1] PREEMPT SMP CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32 pc : dsa_slave_netdevice_event+0x130/0x3e4 lr : raw_notifier_call_chain+0x50/0x6c Call trace: dsa_slave_netdevice_event+0x130/0x3e4 raw_notifier_call_chain+0x50/0x6c call_netdevice_notifiers_info+0x54/0xa0 __dev_close_many+0x50/0x130 dev_close_many+0x84/0x120 unregister_netdevice_many+0x130/0x710 unregister_netdevice_queue+0x8c/0xd0 unregister_netdev+0x20/0x30 dpaa2_eth_remove+0x68/0x190 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 __do_sys_reboot+0x1cc/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c It can be seen from the stack trace that the problem is that the deregistration of the master causes a dev_close(), which gets notified as NETDEV_GOING_DOWN to dsa_slave_netdevice_event(). But dsa_switch_shutdown() has already run, and this has unregistered the DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to call dev_close_many() on those slave interfaces, leading to the problem. The previous attempt to avoid the NETDEV_GOING_DOWN on the master after dsa_switch_shutdown() was called seems improper. Unregistering the slave interfaces is unnecessary and unhelpful. Instead, after the slaves have stopped being uppers of the DSA master, we can now reset to NULL the master->dsa_ptr pointer, which will make DSA start ignoring all future notifier events on the master.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7
- https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae
- https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5
- https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7
- https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae
- https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5
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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: don't release napi in __ibmvnic_open()
If __ibmvnic_open() encounters an error such as when setting link state,
it calls release_resources() which frees the napi structures needlessly.
Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.
disable napi and irqs) and leave the rest to the callers.
If caller of __ibmvnic_open() is ibmvnic_open(), it should release the
resources immediately. If the caller is do_reset() or do_hard_reset(),
they will release the resources on the next reset.
This fixes following crash that occurred when running the drmgr command
several times to add/remove a vnic interface:
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
[102056] ibmvnic 30000003 env3: Replenished 8 pools
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc000000000a3c840
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
...
CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
Workqueue: events_long __ibmvnic_reset [ibmvnic]
NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)
MSR: 8000000000009033 CR: 28248484 XER: 00000004
CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
...
NIP [c000000000a3c840] napi_enable+0x20/0xc0
LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
Call Trace:
[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
38a0fff6 e92d1100 f9210028 39200000 f9010020 60420000 e9210020
---[ end trace 5f8033b08fd27706 ]---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/61772b0908c640d0309c40f7d41d062ca4e979fa
- https://git.kernel.org/stable/c/960dfaf3b578dd23af012590e809ae2d58ba1827
- https://git.kernel.org/stable/c/e08cb9056fb2564d1f6bad789bdf79ab09bf2f81
- https://git.kernel.org/stable/c/61772b0908c640d0309c40f7d41d062ca4e979fa
- https://git.kernel.org/stable/c/960dfaf3b578dd23af012590e809ae2d58ba1827
- https://git.kernel.org/stable/c/e08cb9056fb2564d1f6bad789bdf79ab09bf2f81
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The GSWIP switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the GSWIP switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The gswip driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0d120dfb5d67edc5bcd1804e167dba2b30809afd
- https://git.kernel.org/stable/c/2443ba2fe396bdde187a2fdfa6a57375643ae93c
- https://git.kernel.org/stable/c/b5652bc50dde7b84e93dfb25479b64b817e377c1
- https://git.kernel.org/stable/c/e177d2e85ebcd3008c4b2abc293f4118e04eedef
- https://git.kernel.org/stable/c/0d120dfb5d67edc5bcd1804e167dba2b30809afd
- https://git.kernel.org/stable/c/2443ba2fe396bdde187a2fdfa6a57375643ae93c
- https://git.kernel.org/stable/c/b5652bc50dde7b84e93dfb25479b64b817e377c1
- https://git.kernel.org/stable/c/e177d2e85ebcd3008c4b2abc293f4118e04eedef
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Felix VSC9959 switch is a PCI device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the felix switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The felix driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc_size() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/209bdb7ec6a28c7cdf580a0a98afbc9fc3b98932
- https://git.kernel.org/stable/c/8cda7577a0b4018572f31e0caadfabd305ea2786
- https://git.kernel.org/stable/c/95e5402f9430b3c7d885dd3ec4c8c02c17936923
- https://git.kernel.org/stable/c/9db6f056efd089e80d81c774c01b639adf30c097
- https://git.kernel.org/stable/c/209bdb7ec6a28c7cdf580a0a98afbc9fc3b98932
- https://git.kernel.org/stable/c/8cda7577a0b4018572f31e0caadfabd305ea2786
- https://git.kernel.org/stable/c/95e5402f9430b3c7d885dd3ec4c8c02c17936923
- https://git.kernel.org/stable/c/9db6f056efd089e80d81c774c01b639adf30c097
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: seville: register the mdiobus under devres As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Seville VSC9959 switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the seville switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The seville driver has a code structure that could accommodate both the mdiobus_unregister and mdiobus_free calls, but it has an external dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls devm_mdiobus_alloc_size() on its behalf. So rather than restructuring that, and exporting yet one more symbol mscc_miim_teardown(), let's work with devres and replace of_mdiobus_register with the devres variant. When we use all-devres, we can ensure that devres doesn't free a still-registered bus (it either runs both callbacks, or none).
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0e816362d823cd46c666e64d8bffe329ee22f4cc
- https://git.kernel.org/stable/c/1d13e7221035947c62800c9d3d99b4ed570e27e7
- https://git.kernel.org/stable/c/bd488afc3b39e045ba71aab472233f2a78726e7b
- https://git.kernel.org/stable/c/0e816362d823cd46c666e64d8bffe329ee22f4cc
- https://git.kernel.org/stable/c/1d13e7221035947c62800c9d3d99b4ed570e27e7
- https://git.kernel.org/stable/c/bd488afc3b39e045ba71aab472233f2a78726e7b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/08e1a3554e99a1a5bd2835907381e2383ee85cae
- https://git.kernel.org/stable/c/08f1a20822349004bb9cc1b153ecb516e9f2889d
- https://git.kernel.org/stable/c/2770b795294ed312375c11ef1d0b810499c66b83
- https://git.kernel.org/stable/c/caabb5f64f5c32fceed93356bb688ef1ec6c5783
- https://git.kernel.org/stable/c/08e1a3554e99a1a5bd2835907381e2383ee85cae
- https://git.kernel.org/stable/c/08f1a20822349004bb9cc1b153ecb516e9f2889d
- https://git.kernel.org/stable/c/2770b795294ed312375c11ef1d0b810499c66b83
- https://git.kernel.org/stable/c/caabb5f64f5c32fceed93356bb688ef1ec6c5783
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: lock against ->sock changing during sysfs read ->sock can be set to NULL asynchronously unless ->recv_mutex is held. So it is important to hold that mutex. Otherwise a sysfs read can trigger an oops. Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before handling sysfs reads") appears to attempt to fix this problem, but it only narrows the race window.
CVSS 3.xСРЕДНЯЯ 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: ar9331: register the mdiobus under devres As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The ar9331 is an MDIO device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the ar9331 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The ar9331 driver doesn't have a complex code structure for mdiobus removal, so just replace of_mdiobus_register with the devres variant in order to be all-devres and ensure that we don't free a still-registered bus.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/475ce5dcf2d88fd4f3c213a0ac944e3e40702970
- https://git.kernel.org/stable/c/50facd86e9fbc4b93fe02e5fe05776047f45dbfb
- https://git.kernel.org/stable/c/aae1c6a1d3d696fc33b609fb12fe744a556d1dc5
- https://git.kernel.org/stable/c/f1842a8cb71de4d7eb75a86f76e88c7ee739218c
- https://git.kernel.org/stable/c/475ce5dcf2d88fd4f3c213a0ac944e3e40702970
- https://git.kernel.org/stable/c/50facd86e9fbc4b93fe02e5fe05776047f45dbfb
- https://git.kernel.org/stable/c/aae1c6a1d3d696fc33b609fb12fe744a556d1dc5
- https://git.kernel.org/stable/c/f1842a8cb71de4d7eb75a86f76e88c7ee739218c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The mv88e6xxx is an MDIO device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the Marvell switch driver on shutdown. systemd-shutdown[1]: Powering off. mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down fsl-mc dpbp.9: Removing from iommu group 7 fsl-mc dpbp.8: Removing from iommu group 7 ------------[ cut here ]------------ kernel BUG at drivers/net/phy/mdio_bus.c:677! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15 pc : mdiobus_free+0x44/0x50 lr : devm_mdiobus_free+0x10/0x20 Call trace: mdiobus_free+0x44/0x50 devm_mdiobus_free+0x10/0x20 devres_release_all+0xa0/0x100 __device_release_driver+0x190/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x4c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 kernel_power_off+0x34/0x6c __do_sys_reboot+0x15c/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The Marvell driver already has a good structure for mdiobus removal, so just plug in mdiobus_free and get rid of devres.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1b451c3994a2d322f8e55032c62c8b47b7d95900
- https://git.kernel.org/stable/c/8b626d45127d6f5ada7d815b83cfdc09e8cb1394
- https://git.kernel.org/stable/c/8ccebe77df6e0d88c72ba5e69cf1835927e53b6c
- https://git.kernel.org/stable/c/f53a2ce893b2c7884ef94471f170839170a4eba0
- https://git.kernel.org/stable/c/1b451c3994a2d322f8e55032c62c8b47b7d95900
- https://git.kernel.org/stable/c/8b626d45127d6f5ada7d815b83cfdc09e8cb1394
- https://git.kernel.org/stable/c/8ccebe77df6e0d88c72ba5e69cf1835927e53b6c
- https://git.kernel.org/stable/c/f53a2ce893b2c7884ef94471f170839170a4eba0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY) calls over the same TCP socket would again trigger the infamous warning in inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); While Talal took into account a mix of regular copied data and MSG_ZEROCOPY one in the same skb, the sendpage() path has been forgotten. We want the charging to happen for sendpage(), because pages could be coming from a pipe. What is missing is the downgrading of pure zerocopy status to make sure sk_forward_alloc will stay synced. Add tcp_downgrade_zcopy_pure() helper so that we can use it from the two callers.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable() This error path needs to decrement "usbphyc->n_pll_cons.counter" before returning.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0ad1a88fa3eb0ded7798f52b79bc33f75fc9a6d2
- https://git.kernel.org/stable/c/94b16ca86ab688ed6fad4548f70137f93cf1f0a9
- https://git.kernel.org/stable/c/cfc826c88a79e22ba5d8001556eb2c7efd8a01b6
- https://git.kernel.org/stable/c/0ad1a88fa3eb0ded7798f52b79bc33f75fc9a6d2
- https://git.kernel.org/stable/c/94b16ca86ab688ed6fad4548f70137f93cf1f0a9
- https://git.kernel.org/stable/c/cfc826c88a79e22ba5d8001556eb2c7efd8a01b6
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: avoid double fput() on failed usercopy If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact, dma_buf_fd() called fd_install() before, i.e. "consumed" one reference, leaving us with none. Calling dma_buf_put() will therefore put a reference we no longer own, leading to a valid file descritor table entry for an already released 'file' object which is a straight use-after-free. Simply avoid calling dma_buf_put() and rely on the process exit code to do the necessary cleanup, if needed, i.e. if the file descriptor is still valid.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/46963e2e0629cb31c96b1d47ddd89dc3d8990b34
- https://git.kernel.org/stable/c/4e6fd2b5fcf8e7119305a6042bd92e7f2b9ed215
- https://git.kernel.org/stable/c/76f85c307ef9f10aa2cef1b1d5ee654c1f3345fc
- https://git.kernel.org/stable/c/a5ce7ee5fcc07583159f54ab4af5164de00148f5
- https://git.kernel.org/stable/c/e4382d0a39f9a1e260d62fdc079ddae5293c037d
- https://git.kernel.org/stable/c/46963e2e0629cb31c96b1d47ddd89dc3d8990b34
- https://git.kernel.org/stable/c/4e6fd2b5fcf8e7119305a6042bd92e7f2b9ed215
- https://git.kernel.org/stable/c/76f85c307ef9f10aa2cef1b1d5ee654c1f3345fc
- https://git.kernel.org/stable/c/a5ce7ee5fcc07583159f54ab4af5164de00148f5
- https://git.kernel.org/stable/c/e4382d0a39f9a1e260d62fdc079ddae5293c037d
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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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: scsi: qedf: Fix refcount issue when LOGO is received during TMF Hung task call trace was seen during LOGO processing. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: rport 016900: Received LOGO request while in state Ready [ 974.309627] host1: rport 016900: Delete port [ 974.309642] host1: rport 016900: work event 3 [ 974.309644] host1: rport 016900: lld callback ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success... [ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds. [ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Call Trace: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [ 984.031233] ? bit_wait_timeout+0x90/0x90 [ 984.031235] schedule+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] __wait_on_bit+0x6c/0x80 [ 984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? finish_wait+0x80/0x80 [ 984.031291] ? commit_timeout+0x10/0x10 [jbd2] [ 984.031294] kthread+0x116/0x130 [ 984.031300] ? kthread_flush_work_fn+0x10/0x10 [ 984.031305] ret_from_fork+0x1f/0x40 There was a ref count issue when LOGO is received during TMF. This leads to one of the I/Os hanging with the driver. Fix the ref count.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/5239ab63f17cee643bd4bf6addfedebaa7d4f41e
- https://git.kernel.org/stable/c/6be8eaad75ca73131e2a697f0270dc8ee73814a8
- https://git.kernel.org/stable/c/7cc32ff0cd6c44a3c26de5faecfe8b5546198fad
- https://git.kernel.org/stable/c/7fcbed38503bb34c6e6538b6a9482d1c6bead1e8
- https://git.kernel.org/stable/c/87f187e5265bc8e3b38faef8b9db864cdd61dde7
- https://git.kernel.org/stable/c/5239ab63f17cee643bd4bf6addfedebaa7d4f41e
- https://git.kernel.org/stable/c/6be8eaad75ca73131e2a697f0270dc8ee73814a8
- https://git.kernel.org/stable/c/7cc32ff0cd6c44a3c26de5faecfe8b5546198fad
- https://git.kernel.org/stable/c/7fcbed38503bb34c6e6538b6a9482d1c6bead1e8
- https://git.kernel.org/stable/c/87f187e5265bc8e3b38faef8b9db864cdd61dde7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: myrs: Fix crash in error case In myrs_detect(), cs->disable_intr is NULL when privdata->hw_init() fails with non-zero. In this case, myrs_cleanup(cs) will call a NULL ptr and crash the kernel. [ 1.105606] myrs 0000:00:03.0: Unknown Initialization Error 5A [ 1.105872] myrs 0000:00:03.0: Failed to initialize Controller [ 1.106082] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.110774] Call Trace: [ 1.110950] myrs_cleanup+0xe4/0x150 [myrs] [ 1.111135] myrs_probe.cold+0x91/0x56a [myrs] [ 1.111302] ? DAC960_GEM_intr_handler+0x1f0/0x1f0 [myrs] [ 1.111500] local_pci_probe+0x48/0x90
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0e42c4a3d732517edc3766dd45a14e60d29dd929
- https://git.kernel.org/stable/c/1d6cd26605b4d662063a83c15c776b5299a1cb23
- https://git.kernel.org/stable/c/4db09593af0b0b4d7d4805ebb3273df51d7cc30d
- https://git.kernel.org/stable/c/5c5ceea00c8c9df150708e66cb9f2891192c1162
- https://git.kernel.org/stable/c/6207f35c213f6cb2fc3f13b5e77f08c710e1de19
- https://git.kernel.org/stable/c/0e42c4a3d732517edc3766dd45a14e60d29dd929
- https://git.kernel.org/stable/c/1d6cd26605b4d662063a83c15c776b5299a1cb23
- https://git.kernel.org/stable/c/4db09593af0b0b4d7d4805ebb3273df51d7cc30d
- https://git.kernel.org/stable/c/5c5ceea00c8c9df150708e66cb9f2891192c1162
- https://git.kernel.org/stable/c/6207f35c213f6cb2fc3f13b5e77f08c710e1de19
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Add stag_work to all the vports Call trace seen when creating NPIV ports, only 32 out of 64 show online. stag work was not initialized for vport, hence initialize the stag work. WARNING: CPU: 8 PID: 645 at kernel/workqueue.c:1635 __queue_delayed_work+0x68/0x80 CPU: 8 PID: 645 Comm: kworker/8:1 Kdump: loaded Tainted: G IOE --------- -- 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge MX740c/0177V9, BIOS 2.12.2 07/09/2021 Workqueue: events fc_lport_timeout [libfc] RIP: 0010:__queue_delayed_work+0x68/0x80 Code: 89 b2 88 00 00 00 44 89 82 90 00 00 00 48 01 c8 48 89 42 50 41 81 f8 00 20 00 00 75 1d e9 60 24 07 00 44 89 c7 e9 98 f6 ff ff <0f> 0b eb c5 0f 0b eb a1 0f 0b eb a7 0f 0b eb ac 44 89 c6 e9 40 23 RSP: 0018:ffffae514bc3be40 EFLAGS: 00010006 RAX: ffff8d25d6143750 RBX: 0000000000000202 RCX: 0000000000000002 RDX: ffff8d2e31383748 RSI: ffff8d25c000d600 RDI: ffff8d2e31383788 RBP: ffff8d2e31380de0 R08: 0000000000002000 R09: ffff8d2e31383750 R10: ffffffffc0c957e0 R11: ffff8d2624800000 R12: ffff8d2e31380a58 R13: ffff8d2d915eb000 R14: ffff8d25c499b5c0 R15: ffff8d2e31380e18 FS: 0000000000000000(0000) GS:ffff8d2d1fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fd0484b8b8 CR3: 00000008ffc10006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: queue_delayed_work_on+0x36/0x40 qedf_elsct_send+0x57/0x60 [qedf] fc_lport_enter_flogi+0x90/0xc0 [libfc] fc_lport_timeout+0xb7/0x140 [libfc] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 008f00f722f2c2ff ]-- Initialize stag work for all the vports.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0be556512cd0dfcf5ec1a140d9f42d88221a5d4e
- https://git.kernel.org/stable/c/1f53bbf27a876f7e61262bd74c18680ac11d4c31
- https://git.kernel.org/stable/c/aa7352aa155e19815b41f09f114fe9f110fde4d8
- https://git.kernel.org/stable/c/b70a99fd13282d7885f69bf1372e28b7506a1613
- https://git.kernel.org/stable/c/0be556512cd0dfcf5ec1a140d9f42d88221a5d4e
- https://git.kernel.org/stable/c/1f53bbf27a876f7e61262bd74c18680ac11d4c31
- https://git.kernel.org/stable/c/aa7352aa155e19815b41f09f114fe9f110fde4d8
- https://git.kernel.org/stable/c/b70a99fd13282d7885f69bf1372e28b7506a1613
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix deadlock on DSI device attach error DSI device attach to DSI host will be done with host device's lock held. Un-registering host in "device attach" error path (ex: probe retry) will result in deadlock with below call trace and non operational DSI display. Startup Call trace: [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [ 35.043048] mutex_lock_nested+0x7c/0xc8 [ 35.043060] device_del+0x4c/0x3e8 [ 35.043075] device_unregister+0x20/0x40 [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [ 35.043093] device_for_each_child+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28/0x38 [ 35.043234] really_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] __device_attach_driver+0x98/0xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] device_initial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] deferred_probe_work_func+0xa0/0xe0 [ 35.043318] process_one_work+0x254/0x700 [ 35.043330] worker_thread+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348] ret_from_fork+0x10/0x20 Shutdown Call trace: [ 365.565417] Call trace: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] schedule+0x48/0x110 [ 365.565479] schedule_timeout+0x3b0/0x448 [ 365.565496] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] device_shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart+0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0a3d12ab5097b1d045e693412e6b366b7e82031b
- https://git.kernel.org/stable/c/770d1ba9a8201ce9bee0946eb03746449b6f3b80
- https://git.kernel.org/stable/c/dddd832f35096fbc5004e3a7e58fb4d2cefb8deb
- https://git.kernel.org/stable/c/0a3d12ab5097b1d045e693412e6b366b7e82031b
- https://git.kernel.org/stable/c/770d1ba9a8201ce9bee0946eb03746449b6f3b80
- https://git.kernel.org/stable/c/dddd832f35096fbc5004e3a7e58fb4d2cefb8deb
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix the behavior of READ near OFFSET_MAX Dan Aloni reports: > Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to > the RPC read layers") on the client, a read of 0xfff is aligned up > to server rsize of 0x1000. > > As a result, in a test where the server has a file of size > 0x7fffffffffffffff, and the client tries to read from the offset > 0x7ffffffffffff000, the read causes loff_t overflow in the server > and it returns an NFS code of EINVAL to the client. The client as > a result indefinitely retries the request. The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ. Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers. Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb->s_maxbytes do not work properly.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0cb4d23ae08c48f6bf3c29a8e5c4a74b8388b960
- https://git.kernel.org/stable/c/1726a39b0879acfb490b22dca643f26f4f907da9
- https://git.kernel.org/stable/c/44502aca8e02ab32d6b0eb52e006a5ec9402719b
- https://git.kernel.org/stable/c/c6eff5c4277146a78b4fb8c9b668dd64542c41b0
- https://git.kernel.org/stable/c/0cb4d23ae08c48f6bf3c29a8e5c4a74b8388b960
- https://git.kernel.org/stable/c/1726a39b0879acfb490b22dca643f26f4f907da9
- https://git.kernel.org/stable/c/44502aca8e02ab32d6b0eb52e006a5ec9402719b
- https://git.kernel.org/stable/c/c6eff5c4277146a78b4fb8c9b668dd64542c41b0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix ia_size underflow iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and NFSv4 both define file size as an unsigned 64-bit type. Thus there is a range of valid file size values an NFS client can send that is already larger than Linux can handle. Currently decode_fattr4() dumps a full u64 value into ia_size. If that value happens to be larger than S64_MAX, then ia_size underflows. I'm about to fix up the NFSv3 behavior as well, so let's catch the underflow in the common code path: nfsd_setattr().
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/38d02ba22e43b6fc7d291cf724bc6e3b7be6626b
- https://git.kernel.org/stable/c/8e0ecaf7a7e57b30284d6b3289cc436100fadc48
- https://git.kernel.org/stable/c/d2211e6e34d0755f35e2f8c22d81999fa81cfc71
- https://git.kernel.org/stable/c/da22ca1ad548429d7822011c54cfe210718e0aa7
- https://git.kernel.org/stable/c/e6faac3f58c7c4176b66f63def17a34232a17b0e
- https://git.kernel.org/stable/c/38d02ba22e43b6fc7d291cf724bc6e3b7be6626b
- https://git.kernel.org/stable/c/8e0ecaf7a7e57b30284d6b3289cc436100fadc48
- https://git.kernel.org/stable/c/da22ca1ad548429d7822011c54cfe210718e0aa7
- https://git.kernel.org/stable/c/e6faac3f58c7c4176b66f63def17a34232a17b0e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes iattr::ia_size is a loff_t, so these NFSv3 procedures must be careful to deal with incoming client size values that are larger than s64_max without corrupting the value. Silently capping the value results in storing a different value than the client passed in which is unexpected behavior, so remove the min_t() check in decode_sattr3(). Note that RFC 1813 permits only the WRITE procedure to return NFS3ERR_FBIG. We believe that NFSv3 reference implementations also return NFS3ERR_FBIG when ia_size is too large.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/37f2d2cd8eadddbbd9c7bda327a9393399b2f89b
- https://git.kernel.org/stable/c/72c14aed6838b5d90b4dd926b6a339b34bb02e08
- https://git.kernel.org/stable/c/a231ae6bb50e7c0a9e9efd7b0d10687f1d71b3a3
- https://git.kernel.org/stable/c/a648fdeb7c0e17177a2280344d015dba3fbe3314
- https://git.kernel.org/stable/c/aa9051ddb4b378bd22e72a67bc77b9fc1482c5f0
- https://git.kernel.org/stable/c/37f2d2cd8eadddbbd9c7bda327a9393399b2f89b
- https://git.kernel.org/stable/c/a231ae6bb50e7c0a9e9efd7b0d10687f1d71b3a3
- https://git.kernel.org/stable/c/a648fdeb7c0e17177a2280344d015dba3fbe3314
- https://git.kernel.org/stable/c/aa9051ddb4b378bd22e72a67bc77b9fc1482c5f0
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: fix potential CAN frame reception race in isotp_rcv()
When receiving a CAN frame the current code logic does not consider
concurrently receiving processes which do not show up in real world
usage.
Ziyang Xuan writes:
The following syz problem is one of the scenarios. so->rx.len is
changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals
0 before alloc_skb() and equals 4096 after alloc_skb(). That will
trigger skb_over_panic() in skb_put().
=======================================================
CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0
RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113
Call Trace:
skb_over_panic net/core/skbuff.c:118 [inline]
skb_put.cold+0x24/0x24 net/core/skbuff.c:1990
isotp_rcv_cf net/can/isotp.c:570 [inline]
isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668
deliver net/can/af_can.c:574 [inline]
can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635
can_receive+0x31d/0x580 net/can/af_can.c:665
can_rcv+0x120/0x1c0 net/can/af_can.c:696
__netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465
__netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579
Therefore we make sure the state changes and data structures stay
consistent at CAN frame reception time by adding a spin_lock in
isotp_rcv(). This fixes the issue reported by syzkaller but does not
affect real world operation.
CVSS 3.xСРЕДНЯЯ 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/5b068f33bc8acfcfd5ea7992a2dafb30d89bad30
- https://git.kernel.org/stable/c/7b53d2204ce79b27a878074a77d64f40ec21dbca
- https://git.kernel.org/stable/c/7c759040c1dd03954f650f147ae7175476d51314
- https://git.kernel.org/stable/c/f90cc68f9f4b5d8585ad5d0a206a9d37ac299ef3
- https://git.kernel.org/stable/c/5b068f33bc8acfcfd5ea7992a2dafb30d89bad30
- https://git.kernel.org/stable/c/7b53d2204ce79b27a878074a77d64f40ec21dbca
- https://git.kernel.org/stable/c/7c759040c1dd03954f650f147ae7175476d51314
- https://git.kernel.org/stable/c/f90cc68f9f4b5d8585ad5d0a206a9d37ac299ef3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ima: fix reference leak in asymmetric_verify() Don't leak a reference to the key if its algorithm is unknown.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0838d6d68182f0b28a5434bc6d50727c4757e35b
- https://git.kernel.org/stable/c/89f586d3398f4cc0432ed870949dffb702940754
- https://git.kernel.org/stable/c/926fd9f23b27ca6587492c3f58f4c7f4cd01dad5
- https://git.kernel.org/stable/c/0838d6d68182f0b28a5434bc6d50727c4757e35b
- https://git.kernel.org/stable/c/89f586d3398f4cc0432ed870949dffb702940754
- https://git.kernel.org/stable/c/926fd9f23b27ca6587492c3f58f4c7f4cd01dad5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: audit: don't deref the syscall args when checking the openat2 open_how::flags As reported by Jeff, dereferencing the openat2 syscall argument in audit_match_perm() to obtain the open_how::flags can result in an oops/page-fault. This patch fixes this by using the open_how struct that we store in the audit_context with audit_openat2_how(). Independent of this patch, Richard Guy Briggs posted a similar patch to the audit mailing list roughly 40 minutes after this patch was posted.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H