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СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
ALT-PU-2022-1540-2Обновление пакета kernel-image-rpi-un в ветке p10
Серьёзность:
Закрытые проблемы (319)
HIGH7.8
Уязвимость функции cgroup_release_agent_write (kernel/cgroup/cgroup-v1.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии в системе или вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:C/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
Уязвимость функции nft_fwd_dup_netdev_offload() подсистемы netfilter ядра операционных систем 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
Уязвимость функций 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:CHIGH8.4
Уязвимость функции legacy_parse_param ядра операционной системы Linux, связанная с целочисленным переполнением, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
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Ссылки
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СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.5
Уязвимость реализации сетевого протокола ICMPv6 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0ВЫСОКАЯ 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CСсылки
HIGH8.8
Уязвимость реализации сетевого протокола TIPC операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/AV:N/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Ссылки
MEDIUM5.5
Уязвимость функции в drivers/bluetooth/virtio_bt.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.8
Уязвимость драйвера USB-устройства Xilinx (drivers/usb/gadget/udc/udc-xilinx.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0КРИТИЧЕСКАЯ 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции rtrs_clt_dev_release (drivers/infiniband/ulp/rtrs/rtrs-clt.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Ссылки
HIGH7.8
Уязвимость реализации функции copy_info_records_to_user() ядра операционных систем 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Ссылки
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Ссылки
LOW3.3
Уязвимость функции ib_copy_ah_attr_to_user() менеджера соединений RDMA ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
CVSS 3.xНИЗКАЯ 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:NCVSS 2.0НИЗКАЯ 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:NСсылки
HIGH7.8
Уязвимость функции moxart_remove компонента moxart ядра операционной системы 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
Уязвимость функции psi_trigger_poll() в модуле kernel/sched/psi.c реализации системы учета ресурсов PSI ядра операционной системы 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
Уязвимость функции 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Ссылки
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Ссылки
HIGH7.8
Уязвимость функции __nf_register_net_hook() в компоненте netfilter ядра операционной системы 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
Уязвимость компонента blktrace ядра операционной системы 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
Уязвимость компонента core ядра операционной системы 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.8
Уязвимость компонента cifs ядра операционной системы 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
Уязвимость компонента int340x ядра операционной системы 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.8
Уязвимость компонента RDMA/cma ядра операционной системы 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
Уязвимость компонента rndis ядра операционной системы 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
Уязвимость компонента tsc2046 ядра операционной системы 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
Уязвимость компонента men_z188_adc ядра операционной системы 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
Уязвимость компонента RDMA ядра операционной системы 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
Уязвимость компонента configfs ядра операционной системы 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
Уязвимость компонента netfilter ядра операционной системы 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
Уязвимость компонента flower ядра операционной системы 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
Уязвимость компонента netfilter ядра операционной системы 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Ссылки
LOW3.3
Уязвимость функции kmalloc() в компоненте io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xНИЗКАЯ 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:LCVSS 2.0НИЗКАЯ 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:PСсылки
MEDIUM5.5
Уязвимость компонента CDC-NCM ядра операционной системы 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Ссылки
LOW3.3
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xНИЗКАЯ 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:LCVSS 2.0НИЗКАЯ 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:PСсылки
MEDIUM5.5
Уязвимость компонента bpf ядра операционной системы 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
Уязвимость компонента ice ядра операционной системы 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
Уязвимость компонента hwmon ядра операционной системы 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.8
Уязвимость компонента mmu ядра операционной системы 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
Уязвимость компонента mvm ядра операционной системы 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.8
Уязвимость компонента nouveau ядра операционной системы 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
Уязвимость компонентов arch/x86/kvm/x86.c, lapic_shutdown подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы 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
Уязвимость функции smc_setsockopt ядра операционной системы 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
Уязвимость функции QueryVariableInfo компонента efi ядра операционной системы 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.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость функции test_bpf компонента powerpc64 ядра операционной системы 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.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость функции fixup_guest_exit компонента arm64 подсистемы виртуализации KVM ядра операционной системы 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.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.4
Уязвимость функции bnx2fc_recv_frame компонента 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.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM4.1
Уязвимость функции vmx_enter_smm файла arch/x86/kvm/vmx/vmx.c подсистемы виртуализации KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:HCVSS 2.0НИЗКАЯ 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.1
Уязвимость функции array_index_nospec драйвера dma-buf ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.1
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:LCVSS 2.0СРЕДНЯЯ 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:PСсылки
MEDIUM5.5
Уязвимость функции rpmsg_ctrldev_release_device компонента lib/debugobjects.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Ссылки
LOW2.3
Уязвимость функции bnx2fc_interface_put компонента fs/sysfs/group.c ядра операционной системы Linux, позволяющая нарушителю оказать влияние на доступность защищаемой информации
CVSS 3.xНИЗКАЯ 2.3
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:LCVSS 2.0НИЗКАЯ 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:PСсылки
MEDIUM5.5
Уязвимость компонента spi ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
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
Уязвимость функций btrfs_maybe_wake_unfinished_drop() и btrfs_add_dead_root() компонента btrfs ядра операционной системы 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
Уязвимость компонента btrfs ядра операционной системы 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
Уязвимость компонента btrfs ядра операционной системы 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
Уязвимость компонента iommu ядра операционной системы 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Ссылки
MEDIUM5.5
Уязвимость компонента lcd2s ядра операционной системы 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
Уязвимость компонента lcd2s ядра операционной системы 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
Уязвимость компонента com20020 ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
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
Уязвимость компонента 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Ссылки
MEDIUM5.5
Уязвимость компонента 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.5
Уязвимость компонента netfilter ядра операционной системы 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
Уязвимость компонента iommu ядра операционной системы 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
Уязвимость компонента btrfs ядра операционной системы 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
Уязвимость функции reweight_entity () компонента sched ядра операционной системы 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.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость компонента riscv ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
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
Уязвимость компонента btrfs ядра операционной системы 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
Уязвимость функции sched_fork() ядра операционной системы 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
Уязвимость функции 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.8
Уязвимость функции create_snapshot() (fs/btrfs/ioctl.c) файловой системы btrfs ядра операционной системы 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
Уязвимость функции __rtnl_newlink() (net/core/rtnetlink.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Ссылки
HIGH7.8
Уязвимость функции create_mute_led_cdev() (sound/pci/hda/hda_generic.c) звуковой подсистемы ALSA ядра операционной системы 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
Уязвимость функции cond_list_destroy() (security/selinux/ss/conditional.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Ссылки
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:CHIGH7.8
Уязвимость функции ucma_cleanup_multicast() драйвера InfiniBand ядра операционной системы 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Ссылки
CRITICAL9.8
Уязвимость функций wcd938x_set_swr_port() и wcd938x_get_swr_port() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0КРИТИЧЕСКАЯ 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:CСсылки
HIGH8.8
Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/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
Уязвимость компонента bpf ядра операционной системы 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
Уязвимость компонента ceph ядра операционной системы 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
Уязвимость компонента xhci-plat ядра операционной системы 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
Уязвимость компонента core ядра операционной системы 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
Уязвимость компонента 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Ссылки
HIGH8.8
Уязвимость компонента phylib ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/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
Уязвимость компонента bridge ядра операционной системы 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
Уязвимость компонента block ядра операционной системы 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
Уязвимость компонентов net/mlx5e ядра операционной системы 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Ссылки
HIGH8.8
Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/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
Уязвимость компонента hdmi-codec ядра операционной системы 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
Уязвимость компонента ops ядра операционной системы 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
Уязвимость компонентов mm/kmemleak ядра операционной системы 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
Уязвимость компонентов IB/hfi1 ядра операционной системы 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
Уязвимость компонентов RDMA/siw ядра операционной системы 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
Уязвимость компонентов iommu/vt-d ядра операционной системы 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
Уязвимость компонента uniphier ядра операционной системы 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
Уязвимость компонента ca8210 ядра операционной системы 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
Уязвимость компонентов 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Ссылки
MEDIUM5.5
Уязвимость компонента macsec ядра операционной системы 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
Уязвимость компонента mxsfb ядра операционной системы 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
Уязвимость компонента max9759 ядра операционной системы 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
Уязвимость компонента bpf ядра операционной системы 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/x86/intel/pt ядра операционной системы 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
Уязвимость компонента ext4 ядра операционной системы 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
Уязвимость компонента tipc ядра операционной системы 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
Уязвимость компонента Bluetooth ядра операционной системы 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
Уязвимость компонента i40e ядра операционной системы 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
Уязвимость компонента ARM ядра операционной системы 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
Уязвимость компонента pciehp ядра операционной системы 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
Уязвимость компонента 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Ссылки
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
Уязвимость компонента 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
Уязвимость функции 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
Уязвимость функции trace_action_create() модуля kernel/trace/trace_events_hist.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
Уязвимость функции msm_dsi_phy_driver_unregister() модуля drivers/gpu/drm/msm/dsi/phy/dsi_phy.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
Уязвимость функции xgbe_rx_poll() модуля drivers/net/ethernet/amd/xgbe/xgbe-drv.c - драйвера поддержки сетевых адаптеров Ethernet AMD ядра операционной системы 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
Уязвимость функции btrfs_quota_disable() модуля fs/btrfs/qgroup.c поддержки файловой системы btrfs ядра операционной системы 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
Уязвимость функции ovl_copy_fileattr() модуля fs/overlayfs/copy_up.c поддержки файловой системы Overlayfs ядра операционной системы 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
Уязвимость функции dpu_setup_dspp_pcc() модуля drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.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
Уязвимость функции 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Ссылки
CRITICAL9.8
A flaw in netfilter could allow a network-connected attacker to infer openvpn connection endpoint information for further use in traditional network attacks.
CVSS 2.0ВЫСОКАЯ 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:PCVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://bugzilla.redhat.com/show_bug.cgi?id=2004949
- https://citizenlab.ca/2024/07/vulnerabilities-in-vpns-paper-presented-at-the-privacy-enhancing-technologies-symposium-2024/
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2004949
- https://citizenlab.ca/2024/07/vulnerabilities-in-vpns-paper-presented-at-the-privacy-enhancing-technologies-symposium-2024/
- https://security.netapp.com/advisory/ntap-20250328-0004/
- https://www.oracle.com/security-alerts/cpujul2022.html
LOW2.3
A flaw was found in the Linux kernel's implementation of RDMA over infiniband. An attacker with a privileged local account can leak kernel stack information when issuing commands to the /dev/infiniband/rdma_cm device node. While this access is unlikely to leak sensitive user information, it can be further used to defeat existing kernel protection mechanisms.
CVSS 3.xНИЗКАЯ 2.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:NHIGH7.8
An unprivileged write to the file handler flaw in the Linux kernel's control groups and namespaces subsystem was found in the way users have access to some less privileged process that are controlled by cgroups and have higher privileged parent process. It is actually both for cgroup2 and cgroup1 versions of control groups. A local user could use this flaw to crash the system or escalate their privileges on the system.
CVSS 2.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=2035652
- https://lore.kernel.org/lkml/20211209214707.805617-1-tj%40kernel.org/T/
- https://security.netapp.com/advisory/ntap-20220602-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2035652
- https://lore.kernel.org/lkml/20211209214707.805617-1-tj%40kernel.org/T/
- https://security.netapp.com/advisory/ntap-20220602-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynq-qspi: Fix a NULL pointer dereference in zynq_qspi_exec_mem_op() In zynq_qspi_exec_mem_op(), kzalloc() is directly used in memset(), which could lead to a NULL pointer dereference on failure of kzalloc(). Fix this bug by adding a check of tmpbuf. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_SPI_ZYNQ_QSPI=m show no new warnings, and our static analyzer no longer warns about this code.
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/2efece1368aeee2d2552c7ec36aeb676c4d4c95f
- https://git.kernel.org/stable/c/3c32405d6474a21f7d742828e73c13e326dcae82
- https://git.kernel.org/stable/c/ab3824427b848da10e9fe2727f035bbeecae6ff4
- https://git.kernel.org/stable/c/b9dd08cbebe0c593c49bf86d2012a431494e54cb
- https://git.kernel.org/stable/c/df14d2bed8e2455878e046e67123d9ecb2e79056
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler.
CVSS 3.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/1db58c6584a72102e98af2e600ea184ddaf2b8af
- https://git.kernel.org/stable/c/23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12
- https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9
- https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d
- https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9ed24dd5
- https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a
- https://git.kernel.org/stable/c/1db58c6584a72102e98af2e600ea184ddaf2b8af
- https://git.kernel.org/stable/c/23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12
- https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9
- https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d
- https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9ed24dd5
- https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9170/1: fix panic when kasan and kprobe are enabled
arm32 uses software to simulate the instruction replaced
by kprobe. some instructions may be simulated by constructing
assembly functions. therefore, before executing instruction
simulation, it is necessary to construct assembly function
execution environment in C language through binding registers.
after kasan is enabled, the register binding relationship will
be destroyed, resulting in instruction simulation errors and
causing kernel panic.
the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable
KASAN when compiling these files.
for example, use kprobe insert on cap_capable+20 after kasan
enabled, the cap_capable assembly code is as follows:
:
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000 mov r5, r0
e280006c add r0, r0, #108 ; 0x6c
e1a04001 mov r4, r1
e1a06002 mov r6, r2
e59fa090 ldr sl, [pc, #144] ;
ebfc7bf8 bl c03aa4b4 <__asan_load4>
e595706c ldr r7, [r5, #108] ; 0x6c
e2859014 add r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 :
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e282803c add r8, r2, #60 ; 0x3c
e1a05000 mov r5, r0
e7e37855 ubfx r7, r5, #16, #4
e1a00008 mov r0, r8
e1a09001 mov r9, r1
e1a04002 mov r4, r2
ebf35462 bl c03c6530 <__asan_load4>
e357000f cmp r7, #15
e7e36655 ubfx r6, r5, #12, #4
e205a00f and sl, r5, #15
0a000001 beq c06f13bc
e0840107 add r0, r4, r7, lsl #2
ebf3545c bl c03c6530 <__asan_load4>
e084010a add r0, r4, sl, lsl #2
ebf3545a bl c03c6530 <__asan_load4>
e2890010 add r0, r9, #16
ebf35458 bl c03c6530 <__asan_load4>
e5990010 ldr r0, [r9, #16]
e12fff30 blx r0
e356000f cm r6, #15
1a000014 bne c06f1430
e1a06000 mov r6, r0
e2840040 add r0, r4, #64 ; 0x40
......
when running in emulate_ldr to simulate the ldr instruction, panic
occurred, and the log is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0
psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c
r10: 00000000 r9 : c30897f4 r8 : ecd63cd4
r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98
r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 32c5387d Table: 2d546400 DAC: 55555555
Process bash (pid: 1643, stack limit = 0xecd60190)
(cap_capable) from (kprobe_handler+0x218/0x340)
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
(__und_svc_finish) from (cap_capable+0x18/0xb0)
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
(cap_vm_enough_memory) from
(security_vm_enough_memory_mm+0x48/0x6c)
(security_vm_enough_memory_mm) from
(copy_process.constprop.5+0x16b4/0x25c8)
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
(_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)
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/1515e72aae803fc6b466adf918e71c4e4c9d5b3d
- https://git.kernel.org/stable/c/8b59b0a53c840921b625378f137e88adfa87647e
- https://git.kernel.org/stable/c/ba1863be105b06e10d0e2f6b1b8a0570801cfc71
- https://git.kernel.org/stable/c/1515e72aae803fc6b466adf918e71c4e4c9d5b3d
- https://git.kernel.org/stable/c/8b59b0a53c840921b625378f137e88adfa87647e
- https://git.kernel.org/stable/c/ba1863be105b06e10d0e2f6b1b8a0570801cfc71
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix queues reservation for XDP When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI.
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/00eddb0e4ea115154581d1049507a996acfc2d3e
- https://git.kernel.org/stable/c/4b3aa858268b7b9aeef02e5f9c4cd8f8fac101c8
- https://git.kernel.org/stable/c/768eb705e6381f0c70ca29d4e66f19790d5d19a1
- https://git.kernel.org/stable/c/92947844b8beee988c0ce17082b705c2f75f0742
- https://git.kernel.org/stable/c/be6998f232b8e4ca8225029e305b8329d89bfd59
- https://git.kernel.org/stable/c/d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b
- https://git.kernel.org/stable/c/00eddb0e4ea115154581d1049507a996acfc2d3e
- https://git.kernel.org/stable/c/4b3aa858268b7b9aeef02e5f9c4cd8f8fac101c8
- https://git.kernel.org/stable/c/768eb705e6381f0c70ca29d4e66f19790d5d19a1
- https://git.kernel.org/stable/c/92947844b8beee988c0ce17082b705c2f75f0742
- https://git.kernel.org/stable/c/be6998f232b8e4ca8225029e305b8329d89bfd59
- https://git.kernel.org/stable/c/d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: refactor malicious adv data check Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:NСсылки
- https://git.kernel.org/stable/c/305e92f525450f3e1b5f5c9dc7eadb152d66a082
- https://git.kernel.org/stable/c/5a539c08d743d9910631448da78af5e961664c0e
- https://git.kernel.org/stable/c/5c968affa804ba98c3c603f37ffea6fba618025e
- https://git.kernel.org/stable/c/7889b38a7f21ed19314f83194622b195d328465c
- https://git.kernel.org/stable/c/835d3706852537bf92eb23eb8635b8dee0c0aa67
- https://git.kernel.org/stable/c/83d5196b65d1b29e27d7dd16a3b9b439fb1d2dba
- https://git.kernel.org/stable/c/8819f93cd4a443dfe547aa622b21f723757df3fb
- https://git.kernel.org/stable/c/899663be5e75dc0174dc8bda0b5e6826edf0b29a
- https://git.kernel.org/stable/c/bcea886771c3f22a590c8c8b9139a107bd7f1e1c
- https://git.kernel.org/stable/c/305e92f525450f3e1b5f5c9dc7eadb152d66a082
- https://git.kernel.org/stable/c/5a539c08d743d9910631448da78af5e961664c0e
- https://git.kernel.org/stable/c/5c968affa804ba98c3c603f37ffea6fba618025e
- https://git.kernel.org/stable/c/7889b38a7f21ed19314f83194622b195d328465c
- https://git.kernel.org/stable/c/835d3706852537bf92eb23eb8635b8dee0c0aa67
- https://git.kernel.org/stable/c/83d5196b65d1b29e27d7dd16a3b9b439fb1d2dba
- https://git.kernel.org/stable/c/8819f93cd4a443dfe547aa622b21f723757df3fb
- https://git.kernel.org/stable/c/899663be5e75dc0174dc8bda0b5e6826edf0b29a
- https://git.kernel.org/stable/c/bcea886771c3f22a590c8c8b9139a107bd7f1e1c
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
HIGH8.4
A heap-based buffer overflow flaw was found in the way the legacy_parse_param function in the Filesystem Context functionality of the Linux kernel verified the supplied parameters length. An unprivileged (in case of unprivileged user namespaces enabled, otherwise needs namespaced CAP_SYS_ADMIN privilege) local user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to legacy handling) could use this flaw to 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ВЫСОКАЯ 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2
- https://github.com/Crusaders-of-Rust/CVE-2022-0185
- https://security.netapp.com/advisory/ntap-20220225-0003/
- https://www.openwall.com/lists/oss-security/2022/01/18/7
- https://www.willsroot.io/2022/01/cve-2022-0185.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2
- https://github.com/Crusaders-of-Rust/CVE-2022-0185
- https://security.netapp.com/advisory/ntap-20220225-0003/
- https://www.openwall.com/lists/oss-security/2022/01/18/7
- https://www.willsroot.io/2022/01/cve-2022-0185.html
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-0185
HIGH8.8
A stack overflow flaw was found in the Linux kernel's TIPC protocol functionality in the way a user sends a packet with malicious content where the number of domain member nodes is higher than the 64 allowed. This flaw allows a remote user to crash the system or possibly escalate their privileges if they have access to the TIPC network.
CVSS 2.0КРИТИЧЕСКАЯ 9.0
CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:CCVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://bugzilla.redhat.com/show_bug.cgi?id=2048738
- https://security.netapp.com/advisory/ntap-20220602-0001/
- https://www.openwall.com/lists/oss-security/2022/02/10/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2048738
- https://security.netapp.com/advisory/ntap-20220602-0001/
- https://www.openwall.com/lists/oss-security/2022/02/10/1
HIGH7.8
A vulnerability was found in the Linux kernel’s cgroup_release_agent_write in the kernel/cgroup/cgroup-v1.c function. This flaw, under certain circumstances, allows the use of the cgroups v1 release_agent feature to escalate privileges and bypass the namespace isolation unexpectedly.
CVSS 2.0СРЕДНЯЯ 6.9
CVSS:2.0/AV:L/AC:M/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/166444/Kernel-Live-Patch-Security-Notice-LSN-0085-1.html
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- http://packetstormsecurity.com/files/176099/Docker-cgroups-Container-Escape.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2051505
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://security.netapp.com/advisory/ntap-20220419-0002/
- https://www.debian.org/security/2022/dsa-5095
- https://www.debian.org/security/2022/dsa-5096
- http://packetstormsecurity.com/files/166444/Kernel-Live-Patch-Security-Notice-LSN-0085-1.html
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- http://packetstormsecurity.com/files/176099/Docker-cgroups-Container-Escape.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2051505
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://security.netapp.com/advisory/ntap-20220419-0002/
- https://www.debian.org/security/2022/dsa-5095
- https://www.debian.org/security/2022/dsa-5096
HIGH7.5
Memory leak in icmp6 implementation in Linux Kernel 5.13+ allows a remote attacker to DoS a host by making it go out-of-memory via icmp6 packets of type 130 or 131. We recommend upgrading past commit 2d3916f3189172d5c69d33065c3c21119fe539fc.
CVSS 2.0ВЫСОКАЯ 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CCVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d3916f3189172d5c69d33065c3c21119fe539fc
- https://security.netapp.com/advisory/ntap-20220425-0001/
- https://www.openwall.com/lists/oss-security/2022/03/15/3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d3916f3189172d5c69d33065c3c21119fe539fc
- https://security.netapp.com/advisory/ntap-20220425-0001/
- https://www.openwall.com/lists/oss-security/2022/03/15/3
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
A use after free in the Linux kernel File System notify functionality was found in the way user triggers copy_info_records_to_user() call to fail in copy_event_to_user(). A local user could use this flaw to crash the system or potentially 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/notify/fanotify/fanotify_user.c?h=v5.17&id=ee12595147ac1fbfb5bcb23837e26dd58d94b15d
- https://seclists.org/oss-sec/2022/q1/99
- https://security.netapp.com/advisory/ntap-20220707-0009/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/notify/fanotify/fanotify_user.c?h=v5.17&id=ee12595147ac1fbfb5bcb23837e26dd58d94b15d
- https://seclists.org/oss-sec/2022/q1/99
- https://security.netapp.com/advisory/ntap-20220707-0009/
HIGH7.8
kernel/ucount.c in the Linux kernel 5.14 through 5.16.4, when unprivileged user namespaces are enabled, allows a use-after-free and privilege escalation because a ucounts object can outlive its namespace.
CVSS 2.0СРЕДНЯЯ 6.9
CVSS:2.0/AV:L/AC:M/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://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9d87929d451d3e649699d0f1d74f71f77ad38f5
- https://github.com/torvalds/linux/commit/f9d87929d451d3e649699d0f1d74f71f77ad38f5
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/HSR3AI2IQGRKZCHNKF6S25JGDKUEAWWL/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VVSZKUJAZ2VN6LJ35J2B6YD6BOPQTU3B/
- https://security.netapp.com/advisory/ntap-20220221-0001/
- https://www.openwall.com/lists/oss-security/2022/01/29/1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9d87929d451d3e649699d0f1d74f71f77ad38f5
- https://github.com/torvalds/linux/commit/f9d87929d451d3e649699d0f1d74f71f77ad38f5
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/HSR3AI2IQGRKZCHNKF6S25JGDKUEAWWL/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VVSZKUJAZ2VN6LJ35J2B6YD6BOPQTU3B/
- https://security.netapp.com/advisory/ntap-20220221-0001/
- https://www.openwall.com/lists/oss-security/2022/01/29/1
HIGH7.8
net/netfilter/nf_dup_netdev.c in the Linux kernel 5.4 through 5.6.10 allows local users to gain privileges because of a heap out-of-bounds write. This is related to nf_tables_offload.
CVSS 2.0СРЕДНЯЯ 6.9
CVSS:2.0/AV:L/AC:M/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/166444/Kernel-Live-Patch-Security-Notice-LSN-0085-1.html
- http://www.openwall.com/lists/oss-security/2022/02/22/1
- https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git/commit/?id=b1a5983f56e371046dcf164f90bfaf704d2b89f6
- https://github.com/Bonfee/CVE-2022-25636
- https://nickgregory.me/linux/security/2022/03/12/cve-2022-25636/
- https://security.netapp.com/advisory/ntap-20220325-0002/
- https://www.debian.org/security/2022/dsa-5095
- https://www.openwall.com/lists/oss-security/2022/02/21/2
- https://www.oracle.com/security-alerts/cpujul2022.html
- http://packetstormsecurity.com/files/166444/Kernel-Live-Patch-Security-Notice-LSN-0085-1.html
- http://www.openwall.com/lists/oss-security/2022/02/22/1
- https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git/commit/?id=b1a5983f56e371046dcf164f90bfaf704d2b89f6
- https://github.com/Bonfee/CVE-2022-25636
- https://nickgregory.me/linux/security/2022/03/12/cve-2022-25636/
- https://security.netapp.com/advisory/ntap-20220325-0002/
- https://www.debian.org/security/2022/dsa-5095
- https://www.openwall.com/lists/oss-security/2022/02/21/2
- https://www.oracle.com/security-alerts/cpujul2022.html
MEDIUM5.5
drivers/bluetooth/virtio_bt.c in the Linux kernel before 5.16.3 has a memory leak (socket buffers have memory allocated but not freed).
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Ссылки
- http://www.openwall.com/lists/oss-security/2022/03/11/1
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.17
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d0688421449718c6c5f46e458a378c9b530ba18
- https://lore.kernel.org/linux-bluetooth/1A203F5E-FB5E-430C-BEA3-86B191D69D58%40holtmann.org/
- http://www.openwall.com/lists/oss-security/2022/03/11/1
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.17
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d0688421449718c6c5f46e458a378c9b530ba18
- https://lore.kernel.org/linux-bluetooth/1A203F5E-FB5E-430C-BEA3-86B191D69D58%40holtmann.org/
HIGH8.8
In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.
CVSS 2.0СРЕДНЯЯ 6.5
CVSS:2.0/AV:N/AC:L/Au:S/C:P/I:P/A:PCVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12
- https://github.com/torvalds/linux/commit/7f14c7227f342d9932f9b918893c8814f86d2a0d
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220419-0001/
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12
- https://github.com/torvalds/linux/commit/7f14c7227f342d9932f9b918893c8814f86d2a0d
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220419-0001/
HIGH7.8
drivers/infiniband/ulp/rtrs/rtrs-clt.c in the Linux kernel before 5.16.12 has a double free related to rtrs_clt_dev_release.
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://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12
- https://github.com/torvalds/linux/commit/8700af2cc18c919b2a83e74e0479038fd113c15d
- https://security.netapp.com/advisory/ntap-20220602-0002/
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12
- https://github.com/torvalds/linux/commit/8700af2cc18c919b2a83e74e0479038fd113c15d
- https://security.netapp.com/advisory/ntap-20220602-0002/
HIGH7.8
A flaw was found in the Linux kernel's implementation of Pressure Stall Information. While the feature is disabled by default, it could allow an attacker to crash the system or have other memory-corruption side effects.
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/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a06247c6804f1a7c86a2e5398a4c1f1db1471848
- https://security.netapp.com/advisory/ntap-20221223-0002/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a06247c6804f1a7c86a2e5398a4c1f1db1471848
- https://security.netapp.com/advisory/ntap-20221223-0002/
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:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: moxart: fix potential use-after-free on remove path It was reported that the mmc host structure could be accessed after it was freed in moxart_remove(), so fix this by saving the base register of the device and using it instead of the pointer dereference.
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/3a0a7ec5574b510b067cfc734b8bdb6564b31d4e
- https://git.kernel.org/stable/c/7f901d53f120d1921f84f7b9b118e87e94b403c5
- https://git.kernel.org/stable/c/9c25d5ff1856b91bd4365e813f566cb59aaa9552
- https://git.kernel.org/stable/c/af0e6c49438b1596e4be8a267d218a0c88a42323
- https://git.kernel.org/stable/c/bd2db32e7c3e35bd4d9b8bbff689434a50893546
- https://git.kernel.org/stable/c/be93028d306dac9f5b59ebebd9ec7abcfc69c156
- https://git.kernel.org/stable/c/e6f580d0b3349646d4ee1ce0057eb273e8fb7e2e
- https://git.kernel.org/stable/c/f5dc193167591e88797262ec78515a0cbe79ff5f
- https://git.kernel.org/stable/c/3a0a7ec5574b510b067cfc734b8bdb6564b31d4e
- https://git.kernel.org/stable/c/7f901d53f120d1921f84f7b9b118e87e94b403c5
- https://git.kernel.org/stable/c/9c25d5ff1856b91bd4365e813f566cb59aaa9552
- https://git.kernel.org/stable/c/af0e6c49438b1596e4be8a267d218a0c88a42323
- https://git.kernel.org/stable/c/bd2db32e7c3e35bd4d9b8bbff689434a50893546
- https://git.kernel.org/stable/c/be93028d306dac9f5b59ebebd9ec7abcfc69c156
- https://git.kernel.org/stable/c/e6f580d0b3349646d4ee1ce0057eb273e8fb7e2e
- https://git.kernel.org/stable/c/f5dc193167591e88797262ec78515a0cbe79ff5f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tipc: improve size validations for received domain records The function tipc_mon_rcv() allows a node to receive and process domain_record structs from peer nodes to track their views of the network topology. This patch verifies that the number of members in a received domain record does not exceed the limit defined by MAX_MON_DOMAIN, something that may otherwise lead to a stack overflow. tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where we are reading a 32 bit message data length field into a uint16. To avert any risk of bit overflow, we add an extra sanity check for this in that function. We cannot see that happen with the current code, but future designers being unaware of this risk, may introduce it by allowing delivery of very large (> 64k) sk buffers from the bearer layer. This potential problem was identified by Eric Dumazet. This fixes CVE-2022-0435
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/175db196e45d6f0e6047eccd09c8ba55465eb131
- https://git.kernel.org/stable/c/1f1788616157b0222b0c2153828b475d95e374a7
- https://git.kernel.org/stable/c/3c7e5943553594f68bbc070683db6bb6f6e9e78e
- https://git.kernel.org/stable/c/59ff7514f8c56f166aadca49bcecfa028e0ad50f
- https://git.kernel.org/stable/c/9aa422ad326634b76309e8ff342c246800621216
- https://git.kernel.org/stable/c/d692e3406e052dbf9f6d9da0cba36cb763272529
- https://git.kernel.org/stable/c/f1af11edd08dd8376f7a84487cbb0ea8203e3a1d
- https://git.kernel.org/stable/c/fde4ddeadd099bf9fbb9ccbee8e1b5c20d530a2d
- https://git.kernel.org/stable/c/175db196e45d6f0e6047eccd09c8ba55465eb131
- https://git.kernel.org/stable/c/1f1788616157b0222b0c2153828b475d95e374a7
- https://git.kernel.org/stable/c/3c7e5943553594f68bbc070683db6bb6f6e9e78e
- https://git.kernel.org/stable/c/59ff7514f8c56f166aadca49bcecfa028e0ad50f
- https://git.kernel.org/stable/c/9aa422ad326634b76309e8ff342c246800621216
- https://git.kernel.org/stable/c/d692e3406e052dbf9f6d9da0cba36cb763272529
- https://git.kernel.org/stable/c/f1af11edd08dd8376f7a84487cbb0ea8203e3a1d
- https://git.kernel.org/stable/c/fde4ddeadd099bf9fbb9ccbee8e1b5c20d530a2d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ext4: fix error handling in ext4_fc_record_modified_inode() Current code does not fully takes care of krealloc() error case, which could lead to silent memory corruption or a kernel bug. This patch fixes that. Also it cleans up some duplicated error handling logic from various functions in fast_commit.c file.
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/14aa3f49c7fc6424763f4323bfbc3a807b0727dc
- https://git.kernel.org/stable/c/1b6762ecdf3cf12113772427c904aa3c420a1802
- https://git.kernel.org/stable/c/62e46e0ffc02daa8fcfc02f7a932cc8a19601b19
- https://git.kernel.org/stable/c/cdce59a1549190b66f8e3fe465c2b2f714b98a94
- https://git.kernel.org/stable/c/14aa3f49c7fc6424763f4323bfbc3a807b0727dc
- https://git.kernel.org/stable/c/1b6762ecdf3cf12113772427c904aa3c420a1802
- https://git.kernel.org/stable/c/62e46e0ffc02daa8fcfc02f7a932cc8a19601b19
- https://git.kernel.org/stable/c/cdce59a1549190b66f8e3fe465c2b2f714b98a94
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix crash with stop filters in single-range mode Add a check for !buf->single before calling pt_buffer_region_size in a place where a missing check can cause a kernel crash. Fixes a bug introduced by commit 670638477aed ("perf/x86/intel/pt: Opportunistically use single range output mode"), which added a support for PT single-range output mode. Since that commit if a PT stop filter range is hit while tracing, the kernel will crash because of a null pointer dereference in pt_handle_status due to calling pt_buffer_region_size without a ToPA configured. The commit which introduced single-range mode guarded almost all uses of the ToPA buffer variables with checks of the buf->single variable, but missed the case where tracing was stopped by the PT hardware, which happens when execution hits a configured stop filter. Tested that hitting a stop filter while PT recording successfully records a trace with this patch but crashes without this patch.
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/1d9093457b243061a9bba23543c38726e864a643
- https://git.kernel.org/stable/c/456f041e035913fcedb275aff6f8a71dfebcd394
- https://git.kernel.org/stable/c/e83d941fd3445f660d2f43647c580a320cc384f6
- https://git.kernel.org/stable/c/feffb6ae2c80b9a8206450cdef90f5943baced99
- https://git.kernel.org/stable/c/1d9093457b243061a9bba23543c38726e864a643
- https://git.kernel.org/stable/c/456f041e035913fcedb275aff6f8a71dfebcd394
- https://git.kernel.org/stable/c/e83d941fd3445f660d2f43647c580a320cc384f6
- https://git.kernel.org/stable/c/feffb6ae2c80b9a8206450cdef90f5943baced99
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages after mapping"), non-VM_ALLOC mappings will be marked as accessible in __get_vm_area_node() when KASAN is enabled. But now the flag for ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access after vmap() returns. Because the ringbuf area is created by mapping allocated pages, so use VM_MAP instead. After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user to [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
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/5e457aeab52a5947619e1f18047f4d2f3212b3eb
- https://git.kernel.org/stable/c/6304a613a97d6dcd49b93fbad31e9f39d1e138d6
- https://git.kernel.org/stable/c/b293dcc473d22a62dc6d78de2b15e4f49515db56
- https://git.kernel.org/stable/c/d578933f6226d5419af9306746efa1c693cbaf9c
- https://git.kernel.org/stable/c/5e457aeab52a5947619e1f18047f4d2f3212b3eb
- https://git.kernel.org/stable/c/6304a613a97d6dcd49b93fbad31e9f39d1e138d6
- https://git.kernel.org/stable/c/b293dcc473d22a62dc6d78de2b15e4f49515db56
- https://git.kernel.org/stable/c/d578933f6226d5419af9306746efa1c693cbaf9c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe Running tests with a debug kernel shows that bnx2fc_recv_frame() is modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot a debug kernel and run the bnx2fc driver with the hardware enabled. [ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_ [ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 1391.699183] Call Trace: [ 1391.699188] dump_stack_lvl+0x57/0x7d [ 1391.699198] check_preemption_disabled+0xc8/0xd0 [ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180 [ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc] [ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc] [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc] [ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc] [ 1391.699258] kthread+0x364/0x420 [ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50 [ 1391.699268] ? set_kthread_struct+0x100/0x100 [ 1391.699273] ret_from_fork+0x22/0x30 Restore the old get_cpu/put_cpu code with some modifications to reduce the size of the critical section.
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/003bcee66a8f0e76157eb3af369c173151901d97
- https://git.kernel.org/stable/c/2d24336c7214b281b51860e54783dfc65f1248df
- https://git.kernel.org/stable/c/2f5a1ac68bdf2899ce822ab845081922ea8c588e
- https://git.kernel.org/stable/c/3a345198a7c2d1db2526dc60b77052f75de019d3
- https://git.kernel.org/stable/c/471085571f926a1fe6b1bed095638994dbf23990
- https://git.kernel.org/stable/c/53e4f71763c61a557283eb43301efd671922d1e8
- https://git.kernel.org/stable/c/936bd03405fc83ba039d42bc93ffd4b88418f1d3
- https://git.kernel.org/stable/c/ec4334152dae175dbd8fd5bde1d2139bbe7b42d0
- https://git.kernel.org/stable/c/003bcee66a8f0e76157eb3af369c173151901d97
- https://git.kernel.org/stable/c/2d24336c7214b281b51860e54783dfc65f1248df
- https://git.kernel.org/stable/c/2f5a1ac68bdf2899ce822ab845081922ea8c588e
- https://git.kernel.org/stable/c/3a345198a7c2d1db2526dc60b77052f75de019d3
- https://git.kernel.org/stable/c/471085571f926a1fe6b1bed095638994dbf23990
- https://git.kernel.org/stable/c/53e4f71763c61a557283eb43301efd671922d1e8
- https://git.kernel.org/stable/c/936bd03405fc83ba039d42bc93ffd4b88418f1d3
- https://git.kernel.org/stable/c/ec4334152dae175dbd8fd5bde1d2139bbe7b42d0
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd938x: fix incorrect used of portid Mixer controls have the channel id in mixer->reg, which is not same as port id. port id should be derived from chan_info array. So fix this. Without this, its possible that we could corrupt struct wcd938x_sdw_priv by accessing port_map array out of range with channel id instead of port id.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/9167f2712dc8c24964840a4d1e2ebf130e846b95
- https://git.kernel.org/stable/c/aa7152f9f117b3e66b3c0d4158ca4c6d46ab229f
- https://git.kernel.org/stable/c/c5c1546a654f613e291a7c5d6f3660fc1eb6d0c7
- https://git.kernel.org/stable/c/9167f2712dc8c24964840a4d1e2ebf130e846b95
- https://git.kernel.org/stable/c/aa7152f9f117b3e66b3c0d4158ca4c6d46ab229f
- https://git.kernel.org/stable/c/c5c1546a654f613e291a7c5d6f3660fc1eb6d0c7
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ASoC: max9759: fix underflow in speaker_gain_control_put() Check for negative values of "priv->gain" to prevent an out of bounds access. The concern is that these might come from the user via: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put()
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/4c907bcd9dcd233da6707059d777ab389dcbd964
- https://git.kernel.org/stable/c/5a45448ac95b715173edb1cd090ff24b6586d921
- https://git.kernel.org/stable/c/71e60c170105d153e34d01766c1e4db26a4b24cc
- https://git.kernel.org/stable/c/a0f49d12547d45ea8b0f356a96632dd503941c1e
- https://git.kernel.org/stable/c/baead410e5db49e962a67fffc17ac30e44b50b7c
- https://git.kernel.org/stable/c/f114fd6165dfb52520755cc4d1c1dfbd447b88b6
- https://git.kernel.org/stable/c/4c907bcd9dcd233da6707059d777ab389dcbd964
- https://git.kernel.org/stable/c/5a45448ac95b715173edb1cd090ff24b6586d921
- https://git.kernel.org/stable/c/71e60c170105d153e34d01766c1e4db26a4b24cc
- https://git.kernel.org/stable/c/a0f49d12547d45ea8b0f356a96632dd503941c1e
- https://git.kernel.org/stable/c/baead410e5db49e962a67fffc17ac30e44b50b7c
- https://git.kernel.org/stable/c/f114fd6165dfb52520755cc4d1c1dfbd447b88b6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm: mxsfb: Fix NULL pointer dereference mxsfb should not ever dereference the NULL pointer which drm_atomic_get_new_bridge_state is allowed to return. Assume a fixed format instead.
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/622c9a3a7868e1eeca39c55305ca3ebec4742b64
- https://git.kernel.org/stable/c/6f9267e01cca749137349d8ffb0d0ebbadf567f4
- https://git.kernel.org/stable/c/86a337bb803040e4401b87c974a7fb92efe3d0e1
- https://git.kernel.org/stable/c/622c9a3a7868e1eeca39c55305ca3ebec4742b64
- https://git.kernel.org/stable/c/6f9267e01cca749137349d8ffb0d0ebbadf567f4
- https://git.kernel.org/stable/c/86a337bb803040e4401b87c974a7fb92efe3d0e1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: macsec: Fix offload support for NETDEV_UNREGISTER event Current macsec netdev notify handler handles NETDEV_UNREGISTER event by releasing relevant SW resources only, this causes resources leak in case of macsec HW offload, as the underlay driver was not notified to clean it's macsec offload resources. Fix by calling the underlay driver to clean it's relevant resources by moving offload handling from macsec_dellink() to macsec_common_dellink() when handling NETDEV_UNREGISTER event.
CVSS 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Ссылки
- https://git.kernel.org/stable/c/2e7f5b6ee1a7a2c628253a95b0a95b582901ef1b
- https://git.kernel.org/stable/c/8299be160aad8548071d080518712dec0df92bd5
- https://git.kernel.org/stable/c/9cef24c8b76c1f6effe499d2f131807c90f7ce9a
- https://git.kernel.org/stable/c/e7a0b3a0806dae3cc81931f0e83055ca2ac6f455
- https://git.kernel.org/stable/c/2e7f5b6ee1a7a2c628253a95b0a95b582901ef1b
- https://git.kernel.org/stable/c/8299be160aad8548071d080518712dec0df92bd5
- https://git.kernel.org/stable/c/9cef24c8b76c1f6effe499d2f131807c90f7ce9a
- https://git.kernel.org/stable/c/e7a0b3a0806dae3cc81931f0e83055ca2ac6f455
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace TCP with SMC and a fallback occurs, there may be
some socket waitqueue entries remaining in smc socket->wq, such
as eppoll_entries inserted by userspace applications.
After the fallback, data flows over TCP/IP and only clcsocket->wq
will be woken up. Applications can't be notified by the entries
which were inserted in smc socket->wq before fallback. So we need
a mechanism to wake up smc socket->wq at the same time if some
entries remaining in it.
The current workaround is to transfer the entries from smc socket->wq
to clcsock->wq during the fallback. But this may cause a crash
like this:
general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107
RIP: 0010:__wake_up_common+0x65/0x170
Call Trace:
__wake_up_common_lock+0x7a/0xc0
sock_def_readable+0x3c/0x70
tcp_data_queue+0x4a7/0xc40
tcp_rcv_established+0x32f/0x660
? sk_filter_trim_cap+0xcb/0x2e0
tcp_v4_do_rcv+0x10b/0x260
tcp_v4_rcv+0xd2a/0xde0
ip_protocol_deliver_rcu+0x3b/0x1d0
ip_local_deliver_finish+0x54/0x60
ip_local_deliver+0x6a/0x110
? tcp_v4_early_demux+0xa2/0x140
? tcp_v4_early_demux+0x10d/0x140
ip_sublist_rcv_finish+0x49/0x60
ip_sublist_rcv+0x19d/0x230
ip_list_rcv+0x13e/0x170
__netif_receive_skb_list_core+0x1c2/0x240
netif_receive_skb_list_internal+0x1e6/0x320
napi_complete_done+0x11d/0x190
mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]
__napi_poll+0x3c/0x1b0
net_rx_action+0x27c/0x300
__do_softirq+0x114/0x2d2
irq_exit_rcu+0xb4/0xe0
common_interrupt+0xba/0xe0
The crash is caused by privately transferring waitqueue entries from
smc socket->wq to clcsock->wq. The owners of these entries, such as
epoll, have no idea that the entries have been transferred to a
different socket wait queue and still use original waitqueue spinlock
(smc socket->wq.wait.lock) to make the entries operation exclusive,
but it doesn't work. The operations to the entries, such as removing
from the waitqueue (now is clcsock->wq after fallback), may cause a
crash when clcsock waitqueue is being iterated over at the moment.
This patch tries to fix this by no longer transferring wait queue
entries privately, but introducing own implementations of clcsock's
callback functions in fallback situation. The callback functions will
forward the wakeup to smc socket->wq if clcsock->wq is actually woken
up and smc socket->wq has remaining entries.
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/0ef6049f664941bc0f75828b3a61877635048b27
- https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39
- https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa
- https://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a61877635048b27
- https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39
- https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: ca8210: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. We then leak the skb structure. Free the skb structure upon error before returning.
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/21feb6df3967541931242c427fe0958276af81cc
- https://git.kernel.org/stable/c/621b24b09eb61c63f262da0c9c5f0e93348897e5
- https://git.kernel.org/stable/c/6f38d3a6ec11c2733b1c641a46a2a2ecec57be08
- https://git.kernel.org/stable/c/78b3f20c17cbcb7645bfa63f2ca0e11b53c09d56
- https://git.kernel.org/stable/c/94cd597e20ed4acedb8f15f029d92998b011cb1a
- https://git.kernel.org/stable/c/a1c277b0ed2a13e7de923b5f03bc23586eceb851
- https://git.kernel.org/stable/c/d6a44feb2f28d71a7e725f72d09c97c81561cd9a
- https://git.kernel.org/stable/c/21feb6df3967541931242c427fe0958276af81cc
- https://git.kernel.org/stable/c/621b24b09eb61c63f262da0c9c5f0e93348897e5
- https://git.kernel.org/stable/c/6f38d3a6ec11c2733b1c641a46a2a2ecec57be08
- https://git.kernel.org/stable/c/78b3f20c17cbcb7645bfa63f2ca0e11b53c09d56
- https://git.kernel.org/stable/c/94cd597e20ed4acedb8f15f029d92998b011cb1a
- https://git.kernel.org/stable/c/a1c277b0ed2a13e7de923b5f03bc23586eceb851
- https://git.kernel.org/stable/c/d6a44feb2f28d71a7e725f72d09c97c81561cd9a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: fix reference count leak in uniphier_spi_probe() The issue happens in several error paths in uniphier_spi_probe(). When either dma_get_slave_caps() or devm_spi_register_master() returns an error code, the function forgets to decrease the refcount of both `dma_rx` and `dma_tx` objects, which may lead to refcount leaks. Fix it by decrementing the reference count of specific objects in those error paths.
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/37c2c83ca4f1ef4b6908181ac98e18360af89b42
- https://git.kernel.org/stable/c/447c3d4046d7b54052d07d8b27e15e6edea5662c
- https://git.kernel.org/stable/c/dd00b4f8f768d81c3788a8ac88fdb3d745e55ea3
- https://git.kernel.org/stable/c/e895e067d73e154b1ebc84a124e00831e311d9b0
- https://git.kernel.org/stable/c/37c2c83ca4f1ef4b6908181ac98e18360af89b42
- https://git.kernel.org/stable/c/447c3d4046d7b54052d07d8b27e15e6edea5662c
- https://git.kernel.org/stable/c/dd00b4f8f768d81c3788a8ac88fdb3d745e55ea3
- https://git.kernel.org/stable/c/e895e067d73e154b1ebc84a124e00831e311d9b0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated"). For tear down scenario, fn is only freed after fail to allocate ir_domain, though it also should be freed in case dmar_enable_qi returns error. Besides free fn, irq_domain and ir_msi_domain need to be removed as well if intel_setup_irq_remapping fails to enable queued invalidation. Improve the rewinding path by add out_free_ir_domain and out_free_fwnode lables per Baolu's suggestion.
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/336d096b62bdc673e852b6b80d5072d7888ce85d
- https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d29ee2d1
- https://git.kernel.org/stable/c/99e675d473eb8cf2deac1376a0f840222fc1adcf
- https://git.kernel.org/stable/c/9d9995b0371e4e8c18d4f955479e5d47efe7b2d4
- https://git.kernel.org/stable/c/a0c685ba99961b1dd894b2e470e692a539770f6d
- https://git.kernel.org/stable/c/a31cb1f0fb6caf46ffe88c41252b6b7a4ee062d9
- https://git.kernel.org/stable/c/b62eceb5f8f08815fe3f945fc55bbf997c344ecd
- https://git.kernel.org/stable/c/336d096b62bdc673e852b6b80d5072d7888ce85d
- https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d29ee2d1
- https://git.kernel.org/stable/c/99e675d473eb8cf2deac1376a0f840222fc1adcf
- https://git.kernel.org/stable/c/9d9995b0371e4e8c18d4f955479e5d47efe7b2d4
- https://git.kernel.org/stable/c/a0c685ba99961b1dd894b2e470e692a539770f6d
- https://git.kernel.org/stable/c/a31cb1f0fb6caf46ffe88c41252b6b7a4ee062d9
- https://git.kernel.org/stable/c/b62eceb5f8f08815fe3f945fc55bbf997c344ecd
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix refcounting leak in siw_create_qp() The atomic_inc() needs to be paired with an atomic_dec() on the error path.
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/2989ba9532babac66e79997ccff73c015b69700c
- https://git.kernel.org/stable/c/a75badebfdc0b3823054bedf112edb54d6357c75
- https://git.kernel.org/stable/c/fa3b844a50845c817660146c27c0fc29b08d3116
- https://git.kernel.org/stable/c/2989ba9532babac66e79997ccff73c015b69700c
- https://git.kernel.org/stable/c/a75badebfdc0b3823054bedf112edb54d6357c75
- https://git.kernel.org/stable/c/fa3b844a50845c817660146c27c0fc29b08d3116
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Protect mc during concurrent multicast leaves Partially revert the commit mentioned in the Fixes line to make sure that allocation and erasing multicast struct are locked. BUG: KASAN: use-after-free in ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline] BUG: KASAN: use-after-free in ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579 Read of size 8 at addr ffff88801bb74b00 by task syz-executor.1/25529 CPU: 0 PID: 25529 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline] ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579 ucma_destroy_id+0x1e6/0x280 drivers/infiniband/core/ucma.c:614 ucma_write+0x25c/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xae0 fs/read_write.c:588 ksys_write+0x1ee/0x250 fs/read_write.c:643 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 Currently the xarray search can touch a concurrently freeing mc as the xa_for_each() is not surrounded by any lock. Rather than hold the lock for a full scan hold it only for the effected items, which is usually an empty list.
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/2923948ffe0835f7114e948b35bcc42bc9b3baa1
- https://git.kernel.org/stable/c/36e8169ec973359f671f9ec7213547059cae972e
- https://git.kernel.org/stable/c/75c610212b9f1756b9384911d3a2c347eee8031c
- https://git.kernel.org/stable/c/ee2477e8ccd3d978eeac0dc5a981b286d9bb7b0a
- https://git.kernel.org/stable/c/2923948ffe0835f7114e948b35bcc42bc9b3baa1
- https://git.kernel.org/stable/c/36e8169ec973359f671f9ec7213547059cae972e
- https://git.kernel.org/stable/c/75c610212b9f1756b9384911d3a2c347eee8031c
- https://git.kernel.org/stable/c/ee2477e8ccd3d978eeac0dc5a981b286d9bb7b0a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Avoid consuming a stale esr value when SError occur When any exception other than an IRQ occurs, the CPU updates the ESR_EL2 register with the exception syndrome. An SError may also become pending, and will be synchronised by KVM. KVM notes the exception type, and whether an SError was synchronised in exit_code. When an exception other than an IRQ occurs, fixup_guest_exit() updates vcpu->arch.fault.esr_el2 from the hardware register. When an SError was synchronised, the vcpu esr value is used to determine if the exception was due to an HVC. If so, ELR_EL2 is moved back one instruction. This is so that KVM can process the SError first, and re-execute the HVC if the guest survives the SError. But if an IRQ synchronises an SError, the vcpu's esr value is stale. If the previous non-IRQ exception was an HVC, KVM will corrupt ELR_EL2, causing an unrelated guest instruction to be executed twice. Check ARM_EXCEPTION_CODE() before messing with ELR_EL2, IRQs don't update this register so don't need to check.
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/1c71dbc8a179d99dd9bb7e7fc1888db613cf85de
- https://git.kernel.org/stable/c/57e2986c3b25092691a6e3d6ee9168caf8978932
- https://git.kernel.org/stable/c/e1e852746997500f1873f60b954da5f02cc2dba3
- https://git.kernel.org/stable/c/1c71dbc8a179d99dd9bb7e7fc1888db613cf85de
- https://git.kernel.org/stable/c/57e2986c3b25092691a6e3d6ee9168caf8978932
- https://git.kernel.org/stable/c/e1e852746997500f1873f60b954da5f02cc2dba3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix AIP early init panic
An early failure in hfi1_ipoib_setup_rn() can lead to the following panic:
BUG: unable to handle kernel NULL pointer dereference at 00000000000001b0
PGD 0 P4D 0
Oops: 0002 [#1] SMP NOPTI
Workqueue: events work_for_cpu_fn
RIP: 0010:try_to_grab_pending+0x2b/0x140
Code: 1f 44 00 00 41 55 41 54 55 48 89 d5 53 48 89 fb 9c 58 0f 1f 44 00 00 48 89 c2 fa 66 0f 1f 44 00 00 48 89 55 00 40 84 f6 75 77 48 0f ba 2b 00 72 09 31 c0 5b 5d 41 5c 41 5d c3 48 89 df e8 6c
RSP: 0018:ffffb6b3cf7cfa48 EFLAGS: 00010046
RAX: 0000000000000246 RBX: 00000000000001b0 RCX: 0000000000000000
RDX: 0000000000000246 RSI: 0000000000000000 RDI: 00000000000001b0
RBP: ffffb6b3cf7cfa70 R08: 0000000000000f09 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffb6b3cf7cfa90 R14: ffffffff9b2fbfc0 R15: ffff8a4fdf244690
FS: 0000000000000000(0000) GS:ffff8a527f400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000001b0 CR3: 00000017e2410003 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
__cancel_work_timer+0x42/0x190
? dev_printk_emit+0x4e/0x70
iowait_cancel_work+0x15/0x30 [hfi1]
hfi1_ipoib_txreq_deinit+0x5a/0x220 [hfi1]
? dev_err+0x6c/0x90
hfi1_ipoib_netdev_dtor+0x15/0x30 [hfi1]
hfi1_ipoib_setup_rn+0x10e/0x150 [hfi1]
rdma_init_netdev+0x5a/0x80 [ib_core]
? hfi1_ipoib_free_rdma_netdev+0x20/0x20 [hfi1]
ipoib_intf_init+0x6c/0x350 [ib_ipoib]
ipoib_intf_alloc+0x5c/0xc0 [ib_ipoib]
ipoib_add_one+0xbe/0x300 [ib_ipoib]
add_client_context+0x12c/0x1a0 [ib_core]
enable_device_and_get+0xdc/0x1d0 [ib_core]
ib_register_device+0x572/0x6b0 [ib_core]
rvt_register_device+0x11b/0x220 [rdmavt]
hfi1_register_ib_device+0x6b4/0x770 [hfi1]
do_init_one.isra.20+0x3e3/0x680 [hfi1]
local_pci_probe+0x41/0x90
work_for_cpu_fn+0x16/0x20
process_one_work+0x1a7/0x360
? create_worker+0x1a0/0x1a0
worker_thread+0x1cf/0x390
? create_worker+0x1a0/0x1a0
kthread+0x116/0x130
? kthread_flush_work_fn+0x10/0x10
ret_from_fork+0x1f/0x40
The panic happens in hfi1_ipoib_txreq_deinit() because there is a NULL
deref when hfi1_ipoib_netdev_dtor() is called in this error case.
hfi1_ipoib_txreq_init() and hfi1_ipoib_rxq_init() are self unwinding so
fix by adjusting the error paths accordingly.
Other changes:
- hfi1_ipoib_free_rdma_netdev() is deleted including the free_netdev()
since the netdev core code deletes calls free_netdev()
- The switch to the accelerated entrances is moved to the success path.
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/1899c3cad265c4583658aed5293d02e8af84276b
- https://git.kernel.org/stable/c/4a9bd1e6780fc59f81466ec3489d5ad535a37190
- https://git.kernel.org/stable/c/5f8f55b92edd621f056bdf09e572092849fabd83
- https://git.kernel.org/stable/c/a3dd4d2682f2a796121609e5f3bbeb1243198c53
- https://git.kernel.org/stable/c/1899c3cad265c4583658aed5293d02e8af84276b
- https://git.kernel.org/stable/c/4a9bd1e6780fc59f81466ec3489d5ad535a37190
- https://git.kernel.org/stable/c/5f8f55b92edd621f056bdf09e572092849fabd83
- https://git.kernel.org/stable/c/a3dd4d2682f2a796121609e5f3bbeb1243198c53
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix potential spectre v1 gadget It appears like nr could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec. [sumits: added fixes and cc: stable tags]
CVSS 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Ссылки
- https://git.kernel.org/stable/c/24f8e12d965b24f8aea762589e0e9fe2025c005e
- https://git.kernel.org/stable/c/5d40f1bdad3dd1a177f21a90ad4353c1ed40ba3a
- https://git.kernel.org/stable/c/92c4cfaee6872038563c5b6f2e8e613f9d84d47d
- https://git.kernel.org/stable/c/cc8f7940d9c2d45f67b3d1a2f2b7a829ca561bed
- https://git.kernel.org/stable/c/24f8e12d965b24f8aea762589e0e9fe2025c005e
- https://git.kernel.org/stable/c/5d40f1bdad3dd1a177f21a90ad4353c1ed40ba3a
- https://git.kernel.org/stable/c/92c4cfaee6872038563c5b6f2e8e613f9d84d47d
- https://git.kernel.org/stable/c/cc8f7940d9c2d45f67b3d1a2f2b7a829ca561bed
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid scanning potential huge holes When using devm_request_free_mem_region() and devm_memremap_pages() to add ZONE_DEVICE memory, if requested free mem region's end pfn were huge(e.g., 0x400000000), the node_end_pfn() will be also huge (see move_pfn_range_to_zone()). Thus it creates a huge hole between node_start_pfn() and node_end_pfn(). We found on some AMD APUs, amdkfd requested such a free mem region and created a huge hole. In such a case, following code snippet was just doing busy test_bit() looping on the huge hole. for (pfn = start_pfn; pfn < end_pfn; pfn++) { struct page *page = pfn_to_online_page(pfn); if (!page) continue; ... } So we got a soft lockup: watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221] CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Call Trace: ? kmemleak_scan+0x16a/0x440 kmemleak_write+0x306/0x3a0 ? common_file_perm+0x72/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae I did some tests with the patch. (1) amdgpu module unloaded before the patch: real 0m0.976s user 0m0.000s sys 0m0.968s after the patch: real 0m0.981s user 0m0.000s sys 0m0.973s (2) amdgpu module loaded before the patch: real 0m35.365s user 0m0.000s sys 0m35.354s after the patch: real 0m1.049s user 0m0.000s sys 0m1.042s
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/352715593e81b917ce1b321e794549815b850134
- https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e
- https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db
- https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529
- https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a
- https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134
- https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e
- https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db
- https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529
- https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix off by one in BIOS boundary checking Bounds checking when parsing init scripts embedded in the BIOS reject access to the last byte. This causes driver initialization to fail on Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working console. This is probably only seen on OpenFirmware machines like PowerPC Macs because the BIOS image provided by OF is only the used parts of the ROM, not a power-of-two blocks read from PCI directly so PCs always have empty bytes at the end that are never accessed.
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/1b777d4d9e383d2744fc9b3a09af6ec1893c8b1a
- https://git.kernel.org/stable/c/909d3ec1bf9f0ec534bfc081b77c0836fea7b0e2
- https://git.kernel.org/stable/c/acc887ba88333f5fec49631f12d8cc7ebd95781c
- https://git.kernel.org/stable/c/b2a21669ee98aafc41c6d42ef15af4dab9e6e882
- https://git.kernel.org/stable/c/d4b746e60fd8eaa8016e144223abe91158edcdad
- https://git.kernel.org/stable/c/d877e814a62b7de9069aeff8bc1d979dfc996e06
- https://git.kernel.org/stable/c/e7c36fa8a1e63b08312162179c78a0c7795ea369
- https://git.kernel.org/stable/c/f071d9fa857582d7bd77f4906691f73d3edeab73
- https://git.kernel.org/stable/c/1b777d4d9e383d2744fc9b3a09af6ec1893c8b1a
- https://git.kernel.org/stable/c/909d3ec1bf9f0ec534bfc081b77c0836fea7b0e2
- https://git.kernel.org/stable/c/acc887ba88333f5fec49631f12d8cc7ebd95781c
- https://git.kernel.org/stable/c/b2a21669ee98aafc41c6d42ef15af4dab9e6e882
- https://git.kernel.org/stable/c/d4b746e60fd8eaa8016e144223abe91158edcdad
- https://git.kernel.org/stable/c/d877e814a62b7de9069aeff8bc1d979dfc996e06
- https://git.kernel.org/stable/c/e7c36fa8a1e63b08312162179c78a0c7795ea369
- https://git.kernel.org/stable/c/f071d9fa857582d7bd77f4906691f73d3edeab73
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free after failure to create a snapshot At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore.
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/28b21c558a3753171097193b6f6602a94169093a
- https://git.kernel.org/stable/c/7e4c72dbaf62f8978af8321a24dbd35566d3a78a
- https://git.kernel.org/stable/c/9372fa1d73da5f1673921e365d0cd2c27ec7adc2
- https://git.kernel.org/stable/c/a7b717fa15165d3d9245614680bebc48a52ac05d
- https://git.kernel.org/stable/c/28b21c558a3753171097193b6f6602a94169093a
- https://git.kernel.org/stable/c/9372fa1d73da5f1673921e365d0cd2c27ec7adc2
- https://git.kernel.org/stable/c/a7b717fa15165d3d9245614680bebc48a52ac05d
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock between quota disable and qgroup rescan worker
Quota disable ioctl starts a transaction before waiting for the qgroup
rescan worker completes. However, this wait can be infinite and results
in deadlock because of circular dependency among the quota disable
ioctl, the qgroup rescan worker and the other task with transaction such
as block group relocation task.
The deadlock happens with the steps following:
1) Task A calls ioctl to disable quota. It starts a transaction and
waits for qgroup rescan worker completes.
2) Task B such as block group relocation task starts a transaction and
joins to the transaction that task A started. Then task B commits to
the transaction. In this commit, task B waits for a commit by task A.
3) Task C as the qgroup rescan worker starts its job and starts a
transaction. In this transaction start, task C waits for completion
of the transaction that task A started and task B committed.
This deadlock was found with fstests test case btrfs/115 and a zoned
null_blk device. The test case enables and disables quota, and the
block group reclaim was triggered during the quota disable by chance.
The deadlock was also observed by running quota enable and disable in
parallel with 'btrfs balance' command on regular null_blk devices.
An example report of the deadlock:
[372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds.
[372.479944] Not tainted 5.16.0-rc8 #7
[372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000
[372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs]
[372.510782] Call Trace:
[372.514092]
[372.521684] __schedule+0xb56/0x4850
[372.530104] ? io_schedule_timeout+0x190/0x190
[372.538842] ? lockdep_hardirqs_on+0x7e/0x100
[372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60
[372.555591] schedule+0xe0/0x270
[372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs]
[372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs]
[372.578875] ? free_unref_page+0x3f2/0x650
[372.585484] ? finish_wait+0x270/0x270
[372.591594] ? release_extent_buffer+0x224/0x420 [btrfs]
[372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs]
[372.607157] ? lock_release+0x3a9/0x6d0
[372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs]
[372.620960] ? do_raw_spin_lock+0x11e/0x250
[372.627137] ? rwlock_bug.part.0+0x90/0x90
[372.633215] ? lock_is_held_type+0xe4/0x140
[372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs]
[372.646268] process_one_work+0x7e9/0x1320
[372.652321] ? lock_release+0x6d0/0x6d0
[372.658081] ? pwq_dec_nr_in_flight+0x230/0x230
[372.664513] ? rwlock_bug.part.0+0x90/0x90
[372.670529] worker_thread+0x59e/0xf90
[372.676172] ? process_one_work+0x1320/0x1320
[372.682440] kthread+0x3b9/0x490
[372.687550] ? _raw_spin_unlock_irq+0x24/0x50
[372.693811] ? set_kthread_struct+0x100/0x100
[372.700052] ret_from_fork+0x22/0x30
[372.705517]
[372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds.
[372.729827] Not tainted 5.16.0-rc8 #7
[372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000
[372.787776] Call Trace:
[372.801652]
[372.812961] __schedule+0xb56/0x4850
[372.830011] ? io_schedule_timeout+0x190/0x190
[372.852547] ? lockdep_hardirqs_on+0x7e/0x100
[372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60
[372.886792] schedule+0xe0/0x270
[372.901685] wait_current_trans+0x22c/0x310 [btrfs]
[372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs]
[372.938923] ? finish_wait+0x270/0x270
[372.959085] ? join_transaction+0xc7
---truncated---
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/26b3901d20bf9da2c6a00cb1fb48932166f80a45
- https://git.kernel.org/stable/c/31198e58c09e21d4f65c49d2361f76b87aca4c3f
- https://git.kernel.org/stable/c/32747e01436aac8ef93fe85b5b523b4f3b52f040
- https://git.kernel.org/stable/c/89d4cca583fc9594ee7d1a0bc986886d6fb587e6
- https://git.kernel.org/stable/c/e804861bd4e69cc5fe1053eedcb024982dde8e48
- https://git.kernel.org/stable/c/26b3901d20bf9da2c6a00cb1fb48932166f80a45
- https://git.kernel.org/stable/c/31198e58c09e21d4f65c49d2361f76b87aca4c3f
- https://git.kernel.org/stable/c/32747e01436aac8ef93fe85b5b523b4f3b52f040
- https://git.kernel.org/stable/c/89d4cca583fc9594ee7d1a0bc986886d6fb587e6
- https://git.kernel.org/stable/c/e804861bd4e69cc5fe1053eedcb024982dde8e48
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix UAF of leds class devs at unbinding The LED class devices that are created by HD-audio codec drivers are registered via devm_led_classdev_register() and associated with the HD-audio codec device. Unfortunately, it turned out that the devres release doesn't work for this case; namely, since the codec resource release happens before the devm call chain, it triggers a NULL dereference or a UAF for a stale set_brightness_delay callback. For fixing the bug, this patch changes the LED class device register and unregister in a manual manner without devres, keeping the instances in hda_gen_spec.
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/0e629052f013eeb61494d4df2f1f647c2a9aef47
- https://git.kernel.org/stable/c/549f8ffc7b2f7561bea7f90930b6c5104318e87b
- https://git.kernel.org/stable/c/813e9f3e06d22e29872d4fd51b54992d89cf66c8
- https://git.kernel.org/stable/c/a7de1002135cf94367748ffc695a29812d7633b5
- https://git.kernel.org/stable/c/0e629052f013eeb61494d4df2f1f647c2a9aef47
- https://git.kernel.org/stable/c/549f8ffc7b2f7561bea7f90930b6c5104318e87b
- https://git.kernel.org/stable/c/813e9f3e06d22e29872d4fd51b54992d89cf66c8
- https://git.kernel.org/stable/c/a7de1002135cf94367748ffc695a29812d7633b5
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Reject out of bounds values in snd_soc_put_volsw() We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.
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/40f598698129b5ceaf31012f9501b775c7b6e57d
- https://git.kernel.org/stable/c/586ef863c94354a7e00e5ae5ef01443d1dc99bc7
- https://git.kernel.org/stable/c/65a61b1f56f5386486757930069fbdce94af08bf
- https://git.kernel.org/stable/c/68fd718724284788fc5f379e0b7cac541429ece7
- https://git.kernel.org/stable/c/817f7c9335ec01e0f5e8caffc4f1dcd5e458a4c0
- https://git.kernel.org/stable/c/9e8895f1b3d4433f6d78aa6578e9db61ca6e6830
- https://git.kernel.org/stable/c/a9394f21fba027147bf275b083c77955864c366a
- https://git.kernel.org/stable/c/bb72d2dda85564c66d909108ea6903937a41679d
- https://git.kernel.org/stable/c/40f598698129b5ceaf31012f9501b775c7b6e57d
- https://git.kernel.org/stable/c/586ef863c94354a7e00e5ae5ef01443d1dc99bc7
- https://git.kernel.org/stable/c/65a61b1f56f5386486757930069fbdce94af08bf
- https://git.kernel.org/stable/c/68fd718724284788fc5f379e0b7cac541429ece7
- https://git.kernel.org/stable/c/817f7c9335ec01e0f5e8caffc4f1dcd5e458a4c0
- https://git.kernel.org/stable/c/9e8895f1b3d4433f6d78aa6578e9db61ca6e6830
- https://git.kernel.org/stable/c/a9394f21fba027147bf275b083c77955864c366a
- https://git.kernel.org/stable/c/bb72d2dda85564c66d909108ea6903937a41679d
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ASoC: hdmi-codec: Fix OOB memory accesses Correct size of iec_status array by changing it to the size of status array of the struct snd_aes_iec958. This fixes out-of-bounds slab read accesses made by memcpy() of the hdmi-codec driver. This problem is reported by KASAN.
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/06feec6005c9d9500cd286ec440aabf8b2ddd94d
- https://git.kernel.org/stable/c/10007bd96b6c4c3cfaea9e76c311b06a07a5e260
- https://git.kernel.org/stable/c/1552e66be325a21d7eff49f46013fb402165a0ac
- https://git.kernel.org/stable/c/06feec6005c9d9500cd286ec440aabf8b2ddd94d
- https://git.kernel.org/stable/c/10007bd96b6c4c3cfaea9e76c311b06a07a5e260
- https://git.kernel.org/stable/c/1552e66be325a21d7eff49f46013fb402165a0ac
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: selinux: fix double free of cond_list on error paths On error path from cond_read_list() and duplicate_policydb_cond_list() the cond_list_destroy() gets called a second time in caller functions, resulting in NULL pointer deref. Fix this by resetting the cond_list_len to 0 in cond_list_destroy(), making subsequent calls a noop. Also consistently reset the cond_list pointer to NULL after freeing. [PM: fix line lengths in the description]
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/186edf7e368c40d06cf727a1ad14698ea67b74ad
- https://git.kernel.org/stable/c/70caa32e6d81f45f0702070c0e4dfe945e92fbd7
- https://git.kernel.org/stable/c/7ed9cbf7ac0d4ed86b356e1b944304ae9ee450d4
- https://git.kernel.org/stable/c/f446089a268c8fc6908488e991d28a9b936293db
- https://git.kernel.org/stable/c/186edf7e368c40d06cf727a1ad14698ea67b74ad
- https://git.kernel.org/stable/c/70caa32e6d81f45f0702070c0e4dfe945e92fbd7
- https://git.kernel.org/stable/c/7ed9cbf7ac0d4ed86b356e1b944304ae9ee450d4
- https://git.kernel.org/stable/c/f446089a268c8fc6908488e991d28a9b936293db
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ovl: fix NULL pointer dereference in copy up warning This patch is fixing a NULL pointer dereference to get a recently introduced warning message working.
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/4ee7e4a6c9b298da44029ed9ec8ed23ae49cc209
- https://git.kernel.org/stable/c/9c7f8a35c5a83740c0e3ea540b6ad145c50d79aa
- https://git.kernel.org/stable/c/e6b678c1a3673de6a5d2f4e22bb725a086a0701a
- https://git.kernel.org/stable/c/4ee7e4a6c9b298da44029ed9ec8ed23ae49cc209
- https://git.kernel.org/stable/c/9c7f8a35c5a83740c0e3ea540b6ad145c50d79aa
- https://git.kernel.org/stable/c/e6b678c1a3673de6a5d2f4e22bb725a086a0701a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free. It is better to clear master_dev and m_ops inside the loop, in case we have to replay it.
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/2cf180360d66bd657e606c1217e0e668e6faa303
- https://git.kernel.org/stable/c/36a9a0aee881940476b254e0352581401b23f210
- https://git.kernel.org/stable/c/3bbe2019dd12b8d13671ee6cda055d49637b4c39
- https://git.kernel.org/stable/c/7d9211678c0f0624f74cdff36117ab8316697bb8
- https://git.kernel.org/stable/c/a01e60a1ec6bef9be471fb7182a33c6d6f124e93
- https://git.kernel.org/stable/c/bd43771ee9759dd9dfae946bff190e2c5a120de5
- https://git.kernel.org/stable/c/c6f6f2444bdbe0079e41914a35081530d0409963
- https://git.kernel.org/stable/c/def5e7070079b2a214b3b1a2fbec623e6fbfe34a
- https://git.kernel.org/stable/c/2cf180360d66bd657e606c1217e0e668e6faa303
- https://git.kernel.org/stable/c/36a9a0aee881940476b254e0352581401b23f210
- https://git.kernel.org/stable/c/3bbe2019dd12b8d13671ee6cda055d49637b4c39
- https://git.kernel.org/stable/c/7d9211678c0f0624f74cdff36117ab8316697bb8
- https://git.kernel.org/stable/c/a01e60a1ec6bef9be471fb7182a33c6d6f124e93
- https://git.kernel.org/stable/c/bd43771ee9759dd9dfae946bff190e2c5a120de5
- https://git.kernel.org/stable/c/c6f6f2444bdbe0079e41914a35081530d0409963
- https://git.kernel.org/stable/c/def5e7070079b2a214b3b1a2fbec623e6fbfe34a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors.
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/34aeb4da20f93ac80a6291a2dbe7b9c6460e9b26
- https://git.kernel.org/stable/c/4d3fcfe8464838b3920bc2b939d888e0b792934e
- https://git.kernel.org/stable/c/5aac9108a180fc06e28d4e7fb00247ce603b72ee
- https://git.kernel.org/stable/c/617f9934bb37993b9813832516f318ba874bcb7d
- https://git.kernel.org/stable/c/9892742f035f7aa7dcd2bb0750effa486db89576
- https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e
- https://git.kernel.org/stable/c/db6fd92316a254be2097556f01bccecf560e53ce
- https://git.kernel.org/stable/c/e8f73f620fee5f52653ed2da360121e4446575c5
- https://git.kernel.org/stable/c/34aeb4da20f93ac80a6291a2dbe7b9c6460e9b26
- https://git.kernel.org/stable/c/4d3fcfe8464838b3920bc2b939d888e0b792934e
- https://git.kernel.org/stable/c/5aac9108a180fc06e28d4e7fb00247ce603b72ee
- https://git.kernel.org/stable/c/617f9934bb37993b9813832516f318ba874bcb7d
- https://git.kernel.org/stable/c/9892742f035f7aa7dcd2bb0750effa486db89576
- https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e
- https://git.kernel.org/stable/c/db6fd92316a254be2097556f01bccecf560e53ce
- https://git.kernel.org/stable/c/e8f73f620fee5f52653ed2da360121e4446575c5
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Use del_timer_sync in fw reset flow of halting poll
Substitute del_timer() with del_timer_sync() in fw reset polling
deactivation flow, in order to prevent a race condition which occurs
when del_timer() is called and timer is deactivated while another
process is handling the timer interrupt. A situation that led to
the following call trace:
RIP: 0010:run_timer_softirq+0x137/0x420
recalibrate_cpu_khz+0x10/0x10
ktime_get+0x3e/0xa0
? sched_clock_cpu+0xb/0xc0
__do_softirq+0xf5/0x2ea
irq_exit_rcu+0xc1/0xf0
sysvec_apic_timer_interrupt+0x9e/0xc0
asm_sysvec_apic_timer_interrupt+0x12/0x20
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/2a038dd1d942f8fbc495c58fa592ff24af05f1c2
- https://git.kernel.org/stable/c/3c5193a87b0fea090aa3f769d020337662d87b5e
- https://git.kernel.org/stable/c/502c37b033fab7cde3e95a570af4f073306be45e
- https://git.kernel.org/stable/c/f895ebeb44d09d02674cfdd0cfc2bf687603918c
- https://git.kernel.org/stable/c/2a038dd1d942f8fbc495c58fa592ff24af05f1c2
- https://git.kernel.org/stable/c/3c5193a87b0fea090aa3f769d020337662d87b5e
- https://git.kernel.org/stable/c/502c37b033fab7cde3e95a570af4f073306be45e
- https://git.kernel.org/stable/c/f895ebeb44d09d02674cfdd0cfc2bf687603918c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix handling of wrong devices during bond netevent Current implementation of bond netevent handler only check if the handled netdev is VF representor and it missing a check if the VF representor is on the same phys device of the bond handling the netevent. Fix by adding the missing check and optimizing the check if the netdev is VF representor so it will not access uninitialized private data and crashes. BUG: kernel NULL pointer dereference, address: 000000000000036c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Workqueue: eth3bond0 bond_mii_monitor [bonding] RIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core] RSP: 0018:ffff88812d69fd60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000 RDX: ffff88812d69fe10 RSI: 000000000000001b RDI: ffff8881cf800880 RBP: ffff8881cf800000 R08: 00000445cabccf2b R09: 0000000000000008 R10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10 R13: 00000000fffffffe R14: ffff88820c0f9000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88846fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036c CR3: 0000000103d80006 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core] mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core] mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core] raw_notifier_call_chain+0x41/0x60 call_netdevice_notifiers_info+0x34/0x80 netdev_lower_state_changed+0x4e/0xa0 bond_mii_monitor+0x56b/0x640 [bonding] process_one_work+0x1b9/0x390 worker_thread+0x4d/0x3d0 ? rescuer_thread+0x350/0x350 kthread+0x124/0x150 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30
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/4fad499d7fece448e7230d5e5b92f6d8a073e0bb
- https://git.kernel.org/stable/c/a01ee1b8165f4161459b5ec4e728bc7130fe8cd4
- https://git.kernel.org/stable/c/ec41332e02bd0acf1f24206867bb6a02f5877a62
- https://git.kernel.org/stable/c/fe70126da6063c29ca161cdec7ad1dae9af836b3
- https://git.kernel.org/stable/c/4fad499d7fece448e7230d5e5b92f6d8a073e0bb
- https://git.kernel.org/stable/c/a01ee1b8165f4161459b5ec4e728bc7130fe8cd4
- https://git.kernel.org/stable/c/ec41332e02bd0acf1f24206867bb6a02f5877a62
- https://git.kernel.org/stable/c/fe70126da6063c29ca161cdec7ad1dae9af836b3
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: block: Fix wrong offset in bio_truncate() bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NСсылки
- https://git.kernel.org/stable/c/3ee859e384d453d6ac68bfd5971f630d9fa46ad3
- https://git.kernel.org/stable/c/4633a79ff8bc82770486a063a08b55e5162521d8
- https://git.kernel.org/stable/c/6cbf4c731d7812518cd857c2cfc3da9fd120f6ae
- https://git.kernel.org/stable/c/941d5180c430ce5b0f7a3622ef9b76077bfa3d82
- https://git.kernel.org/stable/c/b63e120189fd92aff00096d11e2fc5253f60248b
- https://git.kernel.org/stable/c/3ee859e384d453d6ac68bfd5971f630d9fa46ad3
- https://git.kernel.org/stable/c/4633a79ff8bc82770486a063a08b55e5162521d8
- https://git.kernel.org/stable/c/6cbf4c731d7812518cd857c2cfc3da9fd120f6ae
- https://git.kernel.org/stable/c/941d5180c430ce5b0f7a3622ef9b76077bfa3d82
- https://git.kernel.org/stable/c/b63e120189fd92aff00096d11e2fc5253f60248b
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net: bridge: vlan: fix memory leak in __allowed_ingress When using per-vlan state, if vlan snooping and stats are disabled, untagged or priority-tagged ingress frame will go to check pvid state. If the port state is forwarding and the pvid state is not learning/forwarding, untagged or priority-tagged frame will be dropped but skb memory is not freed. Should free skb when __allowed_ingress returns false.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/14be8d448fca6fe7b2a413831eedd55aef6c6511
- https://git.kernel.org/stable/c/446ff1fc37c74093e81db40811a07b5a19f1d797
- https://git.kernel.org/stable/c/c5e216e880fa6f2cd9d4a6541269377657163098
- https://git.kernel.org/stable/c/fd20d9738395cf8e27d0a17eba34169699fccdff
- https://git.kernel.org/stable/c/14be8d448fca6fe7b2a413831eedd55aef6c6511
- https://git.kernel.org/stable/c/446ff1fc37c74093e81db40811a07b5a19f1d797
- https://git.kernel.org/stable/c/c5e216e880fa6f2cd9d4a6541269377657163098
- https://git.kernel.org/stable/c/fd20d9738395cf8e27d0a17eba34169699fccdff
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pcc The function performs a check on the "ctx" input parameter, however, it is used before the check. Initialize the "base" variable after the sanity check to avoid a possible NULL pointer dereference. Addresses-Coverity-ID: 1493866 ("Null pointer dereference")
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/170b22234d5495f5e0844246e23f004639ee89ba
- https://git.kernel.org/stable/c/1ebc18836d5df09061657f8c548e594cbb519476
- https://git.kernel.org/stable/c/8f069f6dde518dfebe86e848508c07e497bd9298
- https://git.kernel.org/stable/c/93a6e920d8ccb4df846c03b6e72f7e08843d294c
- https://git.kernel.org/stable/c/170b22234d5495f5e0844246e23f004639ee89ba
- https://git.kernel.org/stable/c/1ebc18836d5df09061657f8c548e594cbb519476
- https://git.kernel.org/stable/c/8f069f6dde518dfebe86e848508c07e497bd9298
- https://git.kernel.org/stable/c/93a6e920d8ccb4df846c03b6e72f7e08843d294c
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Transitional solution for clcsock race issue
We encountered a crash in smc_setsockopt() and it is caused by
accessing smc->clcsock after clcsock was released.
BUG: kernel NULL pointer dereference, address: 0000000000000020
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E 5.16.0-rc4+ #53
RIP: 0010:smc_setsockopt+0x59/0x280 [smc]
Call Trace:
__sys_setsockopt+0xfc/0x190
__x64_sys_setsockopt+0x20/0x30
do_syscall_64+0x34/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f16ba83918e
This patch tries to fix it by holding clcsock_release_lock and
checking whether clcsock has already been released before access.
In case that a crash of the same reason happens in smc_getsockopt()
or smc_switch_to_fallback(), this patch also checkes smc->clcsock
in them too. And the caller of smc_switch_to_fallback() will identify
whether fallback succeeds according to the return value.
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/38f0bdd548fd2ef5d481b88d8a2bfef968452e34
- https://git.kernel.org/stable/c/4284225cd8001e134f5cf533a7cd244bbb654d0f
- https://git.kernel.org/stable/c/c0bf3d8a943b6f2e912b7c1de03e2ef28e76f760
- https://git.kernel.org/stable/c/38f0bdd548fd2ef5d481b88d8a2bfef968452e34
- https://git.kernel.org/stable/c/4284225cd8001e134f5cf533a7cd244bbb654d0f
- https://git.kernel.org/stable/c/c0bf3d8a943b6f2e912b7c1de03e2ef28e76f760
HIGH8.4
In the Linux kernel, the following vulnerability has been resolved: phylib: fix potential use-after-free Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phy_device_reset(phydev) after the put_device() call in phy_detach(). The comment before the put_device() call says that the phydev might go away with put_device(). Fix potential use-after-free by calling phy_device_reset() before put_device().
CVSS 3.xВЫСОКАЯ 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/67d271760b037ce0806d687ee6057edc8afd4205
- https://git.kernel.org/stable/c/aefaccd19379d6c4620269a162bfb88ff687f289
- https://git.kernel.org/stable/c/bd024e36f68174b1793906c39ca16cee0c9295c2
- https://git.kernel.org/stable/c/cb2fab10fc5e7a3aa1bb0a68a3abdcf3e37852af
- https://git.kernel.org/stable/c/cbda1b16687580d5beee38273f6241ae3725960c
- https://git.kernel.org/stable/c/f39027cbada43b33566c312e6be3db654ca3ad17
- https://git.kernel.org/stable/c/67d271760b037ce0806d687ee6057edc8afd4205
- https://git.kernel.org/stable/c/aefaccd19379d6c4620269a162bfb88ff687f289
- https://git.kernel.org/stable/c/bd024e36f68174b1793906c39ca16cee0c9295c2
- https://git.kernel.org/stable/c/cb2fab10fc5e7a3aa1bb0a68a3abdcf3e37852af
- https://git.kernel.org/stable/c/cbda1b16687580d5beee38273f6241ae3725960c
- https://git.kernel.org/stable/c/f39027cbada43b33566c312e6be3db654ca3ad17
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06
Johan reported the below crash with test_bpf on ppc64 e5500:
test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1
Oops: Exception in kernel mode, sig: 4 [#1]
BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
Modules linked in: test_bpf(+)
CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1
NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18
REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty)
MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK: 0
<...>
NIP [8000000000061c3c] 0x8000000000061c3c
LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]
Call Trace:
.__run_one+0x60/0x17c [test_bpf] (unreliable)
.test_bpf_init+0x6a8/0xdc8 [test_bpf]
.do_one_initcall+0x6c/0x28c
.do_init_module+0x68/0x28c
.load_module+0x2460/0x2abc
.__do_sys_init_module+0x120/0x18c
.system_call_exception+0x110/0x1b8
system_call_common+0xf0/0x210
--- interrupt: c00 at 0x101d0acc
<...>
---[ end trace 47b2bf19090bb3d0 ]---
Illegal instruction
The illegal instruction turned out to be 'ldbrx' emitted for
BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of
the same and implement an alternative approach for older processors.
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/129c71829d7f46423d95c19e8d87ce956d4c6e1c
- https://git.kernel.org/stable/c/3bfbc00587dc883eaed383558ae512a351c2cd09
- https://git.kernel.org/stable/c/3f5f766d5f7f95a69a630da3544a1a0cee1cdddf
- https://git.kernel.org/stable/c/aaccfeeee1630b155e8ff0d6c449d3de1ef86e73
- https://git.kernel.org/stable/c/129c71829d7f46423d95c19e8d87ce956d4c6e1c
- https://git.kernel.org/stable/c/3bfbc00587dc883eaed383558ae512a351c2cd09
- https://git.kernel.org/stable/c/3f5f766d5f7f95a69a630da3544a1a0cee1cdddf
- https://git.kernel.org/stable/c/aaccfeeee1630b155e8ff0d6c449d3de1ef86e73
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Addresses-Coverity-ID: 1493860 ("Null pointer dereference")
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/2b7e7df1eacd280e561ede3e977853606871c951
- https://git.kernel.org/stable/c/56480fb10b976581a363fd168dc2e4fbee87a1a7
- https://git.kernel.org/stable/c/581317b1f001b7509041544d7019b75571daa100
- https://git.kernel.org/stable/c/5e761a2287234bc402ba7ef07129f5103bcd775c
- https://git.kernel.org/stable/c/6d9f8ba28f3747ca0f910a363e46f1114856dbbe
- https://git.kernel.org/stable/c/79c0b5287ded74f4eacde4dfd8aa0a76cbd853b5
- https://git.kernel.org/stable/c/ca63eeb70fcb53c42e1fe54e1735a54d8e7759fd
- https://git.kernel.org/stable/c/2b7e7df1eacd280e561ede3e977853606871c951
- https://git.kernel.org/stable/c/56480fb10b976581a363fd168dc2e4fbee87a1a7
- https://git.kernel.org/stable/c/581317b1f001b7509041544d7019b75571daa100
- https://git.kernel.org/stable/c/5e761a2287234bc402ba7ef07129f5103bcd775c
- https://git.kernel.org/stable/c/6d9f8ba28f3747ca0f910a363e46f1114856dbbe
- https://git.kernel.org/stable/c/79c0b5287ded74f4eacde4dfd8aa0a76cbd853b5
- https://git.kernel.org/stable/c/ca63eeb70fcb53c42e1fe54e1735a54d8e7759fd
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: net: fix information leakage in /proc/net/ptype In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new `packet_type` added by this packet socket by reading `/proc/net/ptype` file. This is minor information leakage as packet socket is namespace aware. Add a net pointer in `packet_type` to keep the net namespace of of corresponding packet socket. In `ptype_seq_show`, this net pointer must be checked when it is not NULL.
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/47934e06b65637c88a762d9c98329ae6e3238888
- https://git.kernel.org/stable/c/839ec7039513a4f84bfbaff953a9393471176bee
- https://git.kernel.org/stable/c/8f88c78d24f6f346919007cd459fd7e51a8c7779
- https://git.kernel.org/stable/c/b67ad6170c0ea87391bb253f35d1f78857736e54
- https://git.kernel.org/stable/c/be1ca30331c7923c6f376610c1bd6059be9b1908
- https://git.kernel.org/stable/c/c38023032a598ec6263e008d62c7f02def72d5c7
- https://git.kernel.org/stable/c/db044d97460ea792110eb8b971e82569ded536c6
- https://git.kernel.org/stable/c/e372ecd455b6ebc7720f52bf4b5f5d44d02f2092
- https://git.kernel.org/stable/c/e43669c77cb3a742b7d84ecdc7c68c4167a7709b
- https://git.kernel.org/stable/c/47934e06b65637c88a762d9c98329ae6e3238888
- https://git.kernel.org/stable/c/839ec7039513a4f84bfbaff953a9393471176bee
- https://git.kernel.org/stable/c/8f88c78d24f6f346919007cd459fd7e51a8c7779
- https://git.kernel.org/stable/c/b67ad6170c0ea87391bb253f35d1f78857736e54
- https://git.kernel.org/stable/c/be1ca30331c7923c6f376610c1bd6059be9b1908
- https://git.kernel.org/stable/c/c38023032a598ec6263e008d62c7f02def72d5c7
- https://git.kernel.org/stable/c/db044d97460ea792110eb8b971e82569ded536c6
- https://git.kernel.org/stable/c/e372ecd455b6ebc7720f52bf4b5f5d44d02f2092
- https://git.kernel.org/stable/c/e43669c77cb3a742b7d84ecdc7c68c4167a7709b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put() The bnx2fc_destroy() functions are removing the interface before calling destroy_work. This results multiple WARNings from sysfs_remove_group() as the controller rport device attributes are removed too early. Replace the fcoe_port's destroy_work queue. It's not needed. The problem is easily reproducible with the following steps. Example: $ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80 [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc] [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0 [ 584.454888] Call Trace: [ 584.466108] device_del+0xb2/0x3e0 [ 584.481701] device_unregister+0x13/0x60 [ 584.501306] bsg_unregister_queue+0x5b/0x80 [ 584.522029] bsg_remove_queue+0x1c/0x40 [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc] [ 584.573823] process_one_work+0x1e3/0x3b0 [ 584.592396] worker_thread+0x50/0x3b0 [ 584.609256] ? rescuer_thread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? set_kthread_struct+0x40/0x40 [ 584.662909] ret_from_fork+0x22/0x30 [ 584.680002] ---[ end trace 53575ecefa942ece ]---
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/00849de10f798a9538242824a51b1756e7110754
- https://git.kernel.org/stable/c/262550f29c750f7876b6ed1244281e72b64ebffb
- https://git.kernel.org/stable/c/2a12fe8248a38437b95b942bbe85aced72e6e2eb
- https://git.kernel.org/stable/c/847f9ea4c5186fdb7b84297e3eeed9e340e83fce
- https://git.kernel.org/stable/c/ace7b6ef41251c5fe47f629a9a922382fb7b0a6b
- https://git.kernel.org/stable/c/b11e34f7bab21df36f02a5e54fb69e858c09a65d
- https://git.kernel.org/stable/c/bf2bd892a0cb14dd2d21f2c658f4b747813be311
- https://git.kernel.org/stable/c/c93a290c862ccfa404e42d7420565730d67cbff9
- https://git.kernel.org/stable/c/de6336b17a1376db1c0f7a528cce8783db0881c0
- https://git.kernel.org/stable/c/00849de10f798a9538242824a51b1756e7110754
- https://git.kernel.org/stable/c/262550f29c750f7876b6ed1244281e72b64ebffb
- https://git.kernel.org/stable/c/2a12fe8248a38437b95b942bbe85aced72e6e2eb
- https://git.kernel.org/stable/c/847f9ea4c5186fdb7b84297e3eeed9e340e83fce
- https://git.kernel.org/stable/c/ace7b6ef41251c5fe47f629a9a922382fb7b0a6b
- https://git.kernel.org/stable/c/b11e34f7bab21df36f02a5e54fb69e858c09a65d
- https://git.kernel.org/stable/c/bf2bd892a0cb14dd2d21f2c658f4b747813be311
- https://git.kernel.org/stable/c/c93a290c862ccfa404e42d7420565730d67cbff9
- https://git.kernel.org/stable/c/de6336b17a1376db1c0f7a528cce8783db0881c0
HIGH7.0
In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev struct rpmsg_ctrldev contains a struct cdev. The current code frees the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_ctrldev could be freed before the cdev is entirely released, as in the backtrace below. [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0 [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26 [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 93.730055] Workqueue: events kobject_delayed_cleanup [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [ 93.740216] pc : debug_print_object+0x13c/0x1b0 [ 93.744890] lr : debug_print_object+0x13c/0x1b0 [ 93.749555] sp : ffffffacf5bc7940 [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000 [ 93.802244] x11: 0000000000000001 x10: 0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000 [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000 [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001 [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061 [ 93.835104] Call trace: [ 93.837644] debug_print_object+0x13c/0x1b0 [ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0 [ 93.846987] debug_check_no_obj_freed+0x18/0x20 [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8 [ 93.864445] device_release+0x84/0x168 [ 93.868310] kobject_cleanup+0x12c/0x298 [ 93.872356] kobject_delayed_cleanup+0x10/0x18 [ 93.876948] process_one_work+0x578/0x92c [ 93.881086] worker_thread+0x804/0xcf8 [ 93.884963] kthread+0x2a8/0x314 [ 93.888303] ret_from_fork+0x10/0x18 The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del().
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/1dbb206730f3e5ce90014ad569ddf8167ec4124a
- https://git.kernel.org/stable/c/70cb4295ec806b663665e1d2ed15caab6159880e
- https://git.kernel.org/stable/c/74d85e9fbc7022a4011102c7474a9c7aeb704a35
- https://git.kernel.org/stable/c/85aba11a8ea92a8eef2de95ebbe063086fd62d9c
- https://git.kernel.org/stable/c/b7fb2dad571d1e21173c06cef0bced77b323990a
- https://git.kernel.org/stable/c/d6cdc6ae542845d4d0ac8b6d99362bde7042a3c7
- https://git.kernel.org/stable/c/da27b834c1e0222e149e06caddf7718478086d1b
- https://git.kernel.org/stable/c/1dbb206730f3e5ce90014ad569ddf8167ec4124a
- https://git.kernel.org/stable/c/70cb4295ec806b663665e1d2ed15caab6159880e
- https://git.kernel.org/stable/c/74d85e9fbc7022a4011102c7474a9c7aeb704a35
- https://git.kernel.org/stable/c/85aba11a8ea92a8eef2de95ebbe063086fd62d9c
- https://git.kernel.org/stable/c/b7fb2dad571d1e21173c06cef0bced77b323990a
- https://git.kernel.org/stable/c/d6cdc6ae542845d4d0ac8b6d99362bde7042a3c7
- https://git.kernel.org/stable/c/da27b834c1e0222e149e06caddf7718478086d1b
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix hang in usb_kill_urb by adding memory barriers The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers.
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/26fbe9772b8c459687930511444ce443011f86bf
- https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3
- https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
- https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427
- https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26
- https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6
- https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
- https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0
- https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193
- https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf
- https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3
- https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
- https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427
- https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26
- https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6
- https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
- https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0
- https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193
MEDIUM5.3
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci-plat: fix crash when suspend if remote wake enable
Crashed at i.mx8qm platform when suspend if enable remote wakeup
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
Hardware name: Freescale i.MX8QM MEK (DT)
Workqueue: events_unbound async_run_entry_fn
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8
sp : ffff80001394bbf0
x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578
x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000
x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001
x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0
x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453
x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c
x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620
Call trace:
xhci_disable_hub_port_wake.isra.62+0x60/0xf8
xhci_suspend+0x58/0x510
xhci_plat_suspend+0x50/0x78
platform_pm_suspend+0x2c/0x78
dpm_run_callback.isra.25+0x50/0xe8
__device_suspend+0x108/0x3c0
The basic flow:
1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend
3. xhci_suspend call xhci_disable_hub_port_wake, which access register,
but clock already gated by run time suspend.
This problem was hidden by power domain driver, which call run time resume before it.
But the below commit remove it and make this issue happen.
commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")
This patch call run time resume before suspend to make sure clock is on
before access register.
Testeb-by: Abel Vesa
CVSS 3.xСРЕДНЯЯ 5.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:LСсылки
- https://git.kernel.org/stable/c/20c51a4c52208f98e27308c456a1951778f41fa5
- https://git.kernel.org/stable/c/8b05ad29acb972850ad795fa850e814b2e758b83
- https://git.kernel.org/stable/c/9df478463d9feb90dae24f183383961cf123a0ec
- https://git.kernel.org/stable/c/d5755832a1e47f5d8773f0776e211ecd4e02da72
- https://git.kernel.org/stable/c/20c51a4c52208f98e27308c456a1951778f41fa5
- https://git.kernel.org/stable/c/8b05ad29acb972850ad795fa850e814b2e758b83
- https://git.kernel.org/stable/c/9df478463d9feb90dae24f183383961cf123a0ec
- https://git.kernel.org/stable/c/d5755832a1e47f5d8773f0776e211ecd4e02da72
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Forcibly leave nested virt when SMM state is toggled
Forcibly leave nested virtualization operation if userspace toggles SMM
state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace
forces the vCPU out of SMM while it's post-VMXON and then injects an SMI,
vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both
vmxon=false and smm.vmxon=false, but all other nVMX state allocated.
Don't attempt to gracefully handle the transition as (a) most transitions
are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't
sufficient information to handle all transitions, e.g. SVM wants access
to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede
KVM_SET_NESTED_STATE during state restore as the latter disallows putting
the vCPU into L2 if SMM is active, and disallows tagging the vCPU as
being post-VMXON in SMM if SMM is not active.
Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX
due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond
just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU
in an architecturally impossible state.
WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
Modules linked in:
CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00
Call Trace:
kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123
kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]
kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460
kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]
kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676
kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]
kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250
kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273
__fput+0x286/0x9f0 fs/file_table.c:311
task_work_run+0xdd/0x1a0 kernel/task_work.c:164
exit_task_work include/linux/task_work.h:32 [inline]
do_exit+0xb29/0x2a30 kernel/exit.c:806
do_group_exit+0xd2/0x2f0 kernel/exit.c:935
get_signal+0x4b0/0x28c0 kernel/signal.c:2862
arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868
handle_signal_work kernel/entry/common.c:148 [inline]
exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207
__syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x44/0xae
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/080dbe7e9b86a0392d8dffc00d9971792afc121f
- https://git.kernel.org/stable/c/b4c0d89c92e957ecccce12e66b63875d0cc7af7e
- https://git.kernel.org/stable/c/e302786233e6bc512986d007c96458ccf5ca21c7
- https://git.kernel.org/stable/c/f7e570780efc5cec9b2ed1e0472a7da14e864fdb
- https://git.kernel.org/stable/c/080dbe7e9b86a0392d8dffc00d9971792afc121f
- https://git.kernel.org/stable/c/b4c0d89c92e957ecccce12e66b63875d0cc7af7e
- https://git.kernel.org/stable/c/e302786233e6bc512986d007c96458ccf5ca21c7
- https://git.kernel.org/stable/c/f7e570780efc5cec9b2ed1e0472a7da14e864fdb
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
The below warning is splatting during guest reboot.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
Call Trace:
kvm_vcpu_ioctl+0x279/0x710 [kvm]
__x64_sys_ioctl+0x83/0xb0
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fd39797350b
This can be triggered by not exposing tsc-deadline mode and doing a reboot in
the guest. The lapic_shutdown() function which is called in sys_reboot path
will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
switch between tsc-deadline and oneshot/periodic, which can result in preemption
timer be cancelled in apic_update_lvtt(). However, We can't depend on this when
not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
timer. Qemu will synchronise states around reset, let's cancel preemption timer
under KVM_SET_LAPIC.
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/35fe7cfbab2e81f1afb23fc4212210b1de6d9633
- https://git.kernel.org/stable/c/54b3439c8e70e0bcfea59aeef9dd98908cbbf655
- https://git.kernel.org/stable/c/ce55f63f6cea4cab8ae9212f73285648a5baa30d
- https://git.kernel.org/stable/c/35fe7cfbab2e81f1afb23fc4212210b1de6d9633
- https://git.kernel.org/stable/c/54b3439c8e70e0bcfea59aeef9dd98908cbbf655
- https://git.kernel.org/stable/c/ce55f63f6cea4cab8ae9212f73285648a5baa30d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ceph: properly put ceph_string reference after async create attempt The reference acquired by try_prep_async_create is currently leaked. Ensure we put it.
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/36d433ae3242aa714176378850e6d1a5a3e78f18
- https://git.kernel.org/stable/c/932a9b5870d38b87ba0a9923c804b1af7d3605b9
- https://git.kernel.org/stable/c/a0c22e970cd78b81c94691e6cb09713e8074d580
- https://git.kernel.org/stable/c/e7be12ca7d3947765b0d7c1c7e0537e748da993a
- https://git.kernel.org/stable/c/36d433ae3242aa714176378850e6d1a5a3e78f18
- https://git.kernel.org/stable/c/932a9b5870d38b87ba0a9923c804b1af7d3605b9
- https://git.kernel.org/stable/c/a0c22e970cd78b81c94691e6cb09713e8074d580
- https://git.kernel.org/stable/c/e7be12ca7d3947765b0d7c1c7e0537e748da993a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tracing/histogram: Fix a potential memory leak for kstrdup() kfree() is missing on an error path to free the memory allocated by kstrdup(): p = param = kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p).
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/8a8878ebb596281f50fc0b9a6e1f23f0d7f154e8
- https://git.kernel.org/stable/c/d71b06aa995007eafd247626d0669b9364c42ad7
- https://git.kernel.org/stable/c/df86e2fe808c3536a9dba353cc2bebdfea00d0cf
- https://git.kernel.org/stable/c/e33fa4a46ee22de88a700e2e3d033da8214a5175
- https://git.kernel.org/stable/c/e629e7b525a179e29d53463d992bdee759c950fb
- https://git.kernel.org/stable/c/8a8878ebb596281f50fc0b9a6e1f23f0d7f154e8
- https://git.kernel.org/stable/c/d71b06aa995007eafd247626d0669b9364c42ad7
- https://git.kernel.org/stable/c/df86e2fe808c3536a9dba353cc2bebdfea00d0cf
- https://git.kernel.org/stable/c/e33fa4a46ee22de88a700e2e3d033da8214a5175
- https://git.kernel.org/stable/c/e629e7b525a179e29d53463d992bdee759c950fb
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00. The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space. Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/
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/3df52448978802ae15dcebf66beba1029df957b4
- https://git.kernel.org/stable/c/a4085859411c825c321c9b55b8a9dc5a128a6684
- https://git.kernel.org/stable/c/b0f1cc093bc2493ac259c53766fd2b800e085807
- https://git.kernel.org/stable/c/f5390cd0b43c2e54c7cf5506c7da4a37c5cef746
- https://git.kernel.org/stable/c/3df52448978802ae15dcebf66beba1029df957b4
- https://git.kernel.org/stable/c/a4085859411c825c321c9b55b8a9dc5a128a6684
- https://git.kernel.org/stable/c/b0f1cc093bc2493ac259c53766fd2b800e085807
- https://git.kernel.org/stable/c/f5390cd0b43c2e54c7cf5506c7da4a37c5cef746
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack() task_pt_regs() can return NULL on powerpc for kernel threads. This is then used in __bpf_get_stack() to check for user mode, resulting in a kernel oops. Guard against this by checking return value of task_pt_regs() before trying to obtain the call chain.
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/0bcd484587b3b3092e448d27dc369e347e1810c3
- https://git.kernel.org/stable/c/b82ef4985a6d05e80f604624332430351df7b79a
- https://git.kernel.org/stable/c/b992f01e66150fc5e90be4a96f5eb8e634c8249e
- https://git.kernel.org/stable/c/ff6bdc205fd0a83bd365405d4e31fb5905826996
- https://git.kernel.org/stable/c/0bcd484587b3b3092e448d27dc369e347e1810c3
- https://git.kernel.org/stable/c/b82ef4985a6d05e80f604624332430351df7b79a
- https://git.kernel.org/stable/c/b992f01e66150fc5e90be4a96f5eb8e634c8249e
- https://git.kernel.org/stable/c/ff6bdc205fd0a83bd365405d4e31fb5905826996
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix stale file descriptors on failed usercopy A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded.
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/0008a0c78fc33a84e2212a7c04e6b21a36ca6f4d
- https://git.kernel.org/stable/c/1d833b27fb708d6fdf5de9f6b3a8be4bd4321565
- https://git.kernel.org/stable/c/6066977961fc6f437bc064f628cf9b0e4571c56c
- https://git.kernel.org/stable/c/84b1259fe36ae0915f3d6ddcea6377779de48b82
- https://git.kernel.org/stable/c/a0f90c8815706981c483a652a6aefca51a5e191c
- https://git.kernel.org/stable/c/ae2b20f27732fe92055d9e7b350abc5cdf3e2414
- https://git.kernel.org/stable/c/e8d092a62449dcfc73517ca43963d2b8f44d0516
- https://git.kernel.org/stable/c/0008a0c78fc33a84e2212a7c04e6b21a36ca6f4d
- https://git.kernel.org/stable/c/1d833b27fb708d6fdf5de9f6b3a8be4bd4321565
- https://git.kernel.org/stable/c/6066977961fc6f437bc064f628cf9b0e4571c56c
- https://git.kernel.org/stable/c/84b1259fe36ae0915f3d6ddcea6377779de48b82
- https://git.kernel.org/stable/c/a0f90c8815706981c483a652a6aefca51a5e191c
- https://git.kernel.org/stable/c/ae2b20f27732fe92055d9e7b350abc5cdf3e2414
- https://git.kernel.org/stable/c/e8d092a62449dcfc73517ca43963d2b8f44d0516
MEDIUM5.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
MEDIUM4.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: 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
HIGH7.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: 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: 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
MEDIUM5.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
HIGH7.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:
btrfs: do not start relocation until in progress drops are done
We hit a bug with a recovering relocation on mount for one of our file
systems in production. I reproduced this locally by injecting errors
into snapshot delete with balance running at the same time. This
presented as an error while looking up an extent item
WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680
CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8
RIP: 0010:lookup_inline_extent_backref+0x647/0x680
RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000
RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001
R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000
R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000
FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0
Call Trace:
insert_inline_extent_backref+0x46/0xd0
__btrfs_inc_extent_ref.isra.0+0x5f/0x200
? btrfs_merge_delayed_refs+0x164/0x190
__btrfs_run_delayed_refs+0x561/0xfa0
? btrfs_search_slot+0x7b4/0xb30
? btrfs_update_root+0x1a9/0x2c0
btrfs_run_delayed_refs+0x73/0x1f0
? btrfs_update_root+0x1a9/0x2c0
btrfs_commit_transaction+0x50/0xa50
? btrfs_update_reloc_root+0x122/0x220
prepare_to_merge+0x29f/0x320
relocate_block_group+0x2b8/0x550
btrfs_relocate_block_group+0x1a6/0x350
btrfs_relocate_chunk+0x27/0xe0
btrfs_balance+0x777/0xe60
balance_kthread+0x35/0x50
? btrfs_balance+0xe60/0xe60
kthread+0x16b/0x190
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
Normally snapshot deletion and relocation are excluded from running at
the same time by the fs_info->cleaner_mutex. However if we had a
pending balance waiting to get the ->cleaner_mutex, and a snapshot
deletion was running, and then the box crashed, we would come up in a
state where we have a half deleted snapshot.
Again, in the normal case the snapshot deletion needs to complete before
relocation can start, but in this case relocation could very well start
before the snapshot deletion completes, as we simply add the root to the
dead roots list and wait for the next time the cleaner runs to clean up
the snapshot.
Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that
had a pending drop_progress key. If they do then we know we were in the
middle of the drop operation and set a flag on the fs_info. Then
balance can wait until this flag is cleared to start up again.
If there are DEAD_ROOT's that don't have a drop_progress set then we're
safe to start balance right away as we'll be properly protected by the
cleaner_mutex.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not WARN_ON() if we have PageError set Whenever we do any extent buffer operations we call assert_eb_page_uptodate() to complain loudly if we're operating on an non-uptodate page. Our overnight tests caught this warning earlier this week WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it"), however all that fix did was keep us from finding extent buffers after a failed writeout. It didn't keep us from continuing to use a buffer that we already had found. In this case we're searching the commit root to cache the block group, so we can start committing the transaction and switch the commit root and then start writing. After the switch we can look up an extent buffer that hasn't been written yet and start processing that block group. Then we fail to write that block out and clear Uptodate on the page, and then we start spewing these errors. Normally we're protected by the tree lock to a certain degree here. If we read a block we have that block read locked, and we block the writer from locking the block before we submit it for the write. However this isn't necessarily fool proof because the read could happen before we do the submit_bio and after we locked and unlocked the extent buffer. Also in this particular case we have path->skip_locking set, so that won't save us here. We'll simply get a block that was valid when we read it, but became invalid while we were using it. What we really want is to catch the case where we've "read" a block but it's not marked Uptodate. On read we ClearPageError(), so if we're !Uptodate and !Error we know we didn't do the right thing for reading the page. Fix this by checking !Uptodate && !Error, this way we will not complain if our buffer gets invalidated while we're using it, and we'll maintain the spirit of the check which is to make sure we have a fully in-cache block while we're messing with it.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix relocation crash due to premature return from btrfs_commit_transaction()
We are seeing crashes similar to the following trace:
[38.969182] WARNING: CPU: 20 PID: 2105 at fs/btrfs/relocation.c:4070 btrfs_relocate_block_group+0x2dc/0x340 [btrfs]
[38.973556] CPU: 20 PID: 2105 Comm: btrfs Not tainted 5.17.0-rc4 #54
[38.974580] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs]
[38.980336] RSP: 0000:ffffb0dd42e03c20 EFLAGS: 00010206
[38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14
[38.982560] RDX: 0000000000000000 RSI: 4cfd109a0bcb5d7f RDI: ffff96cfc3ce0360
[38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000
[38.984678] R10: ffff96cec0000001 R11: ffffe84c80000000 R12: ffff96cfc4ede800
[38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360
[38.987146] FS: 00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) knlGS:0000000000000000
[38.988662] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0
[38.990279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[38.991219] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[38.992528] Call Trace:
[38.992854]
[38.993148] btrfs_relocate_chunk+0x27/0xe0 [btrfs]
[38.993941] btrfs_balance+0x78e/0xea0 [btrfs]
[38.994801] ? vsnprintf+0x33c/0x520
[38.995368] ? __kmalloc_track_caller+0x351/0x440
[38.996198] btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs]
[38.997084] btrfs_ioctl+0x11b0/0x2da0 [btrfs]
[38.997867] ? mod_objcg_state+0xee/0x340
[38.998552] ? seq_release+0x24/0x30
[38.999184] ? proc_nr_files+0x30/0x30
[38.999654] ? call_rcu+0xc8/0x2f0
[39.000228] ? __x64_sys_ioctl+0x84/0xc0
[39.000872] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[39.001973] __x64_sys_ioctl+0x84/0xc0
[39.002566] do_syscall_64+0x3a/0x80
[39.003011] entry_SYSCALL_64_after_hwframe+0x44/0xae
[39.003735] RIP: 0033:0x7f11c166959b
[39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b
[39.009833] RDX: 00007fff2543ea40 RSI: 00000000c4009420 RDI: 0000000000000003
[39.011270] RBP: 0000000000000003 R08: 0000000000000013 R09: 00007f11c16f94e0
[39.012581] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff25440df3
[39.014046] R13: 0000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001
[39.015040]
[39.015418] ---[ end trace 0000000000000000 ]---
[43.131559] ------------[ cut here ]------------
[43.132234] kernel BUG at fs/btrfs/extent-tree.c:2717!
[43.133031] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: G W 5.17.0-rc4 #54
[43.134863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs]
[43.139913] RSP: 0000:ffffb0dd4216bc70 EFLAGS: 00010246
[43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001
[43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 RDI: 00000000ffffffff
[43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50
[43.143669] R10: ffff96cfc46e8a00 R11: fffffffffffec000 R12: 0000000041d00000
[43.144657] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000
[43.145686] FS: 00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) knlGS:0000000000000000
[43.146808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[43.147584] CR2: 00007f7fe81bf5b0 CR3: 00000001093ee004 CR4: 0000000000370ee0
[43.148589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[43.149581] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000
---truncated---
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix I/O page table memory leak The current logic updates the I/O page table mode for the domain before calling the logic to free memory used for the page table. This results in IOMMU page table memory leak, and can be observed when launching VM w/ pass-through devices. Fix by freeing the memory used for page table before updating the mode.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: free reset-work-item when flushing Fix a tiny memory leak when flushing the reset work queue.
CVSS 3.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/39738a2346b270e8f72f88d8856de2c167bd2899
- https://git.kernel.org/stable/c/4c26745e4576cec224092e6cc12e37829333b183
- https://git.kernel.org/stable/c/58b07100c20e95c78b8cb4d6d28ca53eb9ef81f2
- https://git.kernel.org/stable/c/6acbc8875282d3ca8a73fa93cd7a9b166de5019c
- https://git.kernel.org/stable/c/786576c03b313a9ff6585458aa0dfd039d897f51
- https://git.kernel.org/stable/c/8d0657f39f487d904fca713e0bc39c2707382553
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
mptcp: Correctly set DATA_FIN timeout when number of retransmits is large
Syzkaller with UBSAN uncovered a scenario where a large number of
DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN
timeout calculation:
================================================================================
UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: events mptcp_worker
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
ubsan_epilogue+0xb/0x5a lib/ubsan.c:151
__ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330
mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline]
__mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445
mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528
process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307
worker_thread+0x95/0xe10 kernel/workqueue.c:2454
kthread+0x2f4/0x3b0 kernel/kthread.c:377
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
================================================================================
This change limits the maximum timeout by limiting the size of the
shift, which keeps all intermediate values in-bounds.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: auxdisplay: lcd2s: Fix memory leak in ->remove() Once allocated the struct lcd2s_data is never freed. Fix the memory leak by switching to devm_kzalloc().
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe() During driver initialization, the pointer of card info, i.e. the variable 'ci' is required. However, the definition of 'com20020pci_id_table' reveals that this field is empty for some devices, which will cause null pointer dereference when initializing these devices. The following log reveals it: [ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci] [ 3.975181] Call Trace: [ 3.976208] local_pci_probe+0x13f/0x210 [ 3.977248] pci_device_probe+0x34c/0x6d0 [ 3.977255] ? pci_uevent+0x470/0x470 [ 3.978265] really_probe+0x24c/0x8d0 [ 3.978273] __driver_probe_device+0x1b3/0x280 [ 3.979288] driver_probe_device+0x50/0x370 Fix this by checking whether the 'ci' is a null pointer first.
CVSS 3.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/5f394102ee27dbf051a4e283390cd8d1759dacea
- https://git.kernel.org/stable/c/8e3bc7c5bbf87e86e9cd652ca2a9166942d86206
- https://git.kernel.org/stable/c/b1ee6b9340a38bdb9e5c90f0eac5b22b122c3049
- https://git.kernel.org/stable/c/b838add93e1dd98210482dc433768daaf752bdef
- https://git.kernel.org/stable/c/bd6f1fd5d33dfe5d1b4f2502d3694a7cc13f166d
- https://git.kernel.org/stable/c/ca0bdff4249a644f2ca7a49d410d95b8dacf1f72
- https://git.kernel.org/stable/c/e50c589678e50f8d574612e473ca60ef45190896
- https://git.kernel.org/stable/c/ea372aab54903310756217d81610901a8e66cb7d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix connection leak There's a potential leak issue under following execution sequence : smc_release smc_connect_work if (sk->sk_state == SMC_INIT) send_clc_confirim tcp_abort(); ... sk.sk_state = SMC_ACTIVE smc_close_active switch(sk->sk_state) { ... case SMC_ACTIVE: smc_close_final() // then wait peer closed Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are still in the tcp send buffer, in which case our connection token cannot be delivered to the server side, which means that we cannot get a passive close message at all. Therefore, it is impossible for the to be disconnected at all. This patch tries a very simple way to avoid this issue, once the state has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the smc connection, considering that the state is SMC_INIT before tcp_abort(), abandoning the complete disconnection process should not cause too much problem. In fact, this problem may exist as long as the CLC CONFIRM message is not received by the server. Whether a timer should be added after smc_close_final() needs to be discussed in the future. But even so, this patch provides a faster release for connection in above case, it should also be valuable.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ensure we call ipv6_mc_down() at most once There are two reasons for addrconf_notify() to be called with NETDEV_DOWN: either the network device is actually going down, or IPv6 was disabled on the interface. If either of them stays down while the other is toggled, we repeatedly call the code for NETDEV_DOWN, including ipv6_mc_down(), while never calling the corresponding ipv6_mc_up() in between. This will cause a new entry in idev->mc_tomb to be allocated for each multicast group the interface is subscribed to, which in turn leaks one struct ifmcaddr6 per nontrivial multicast group the interface is subscribed to. The following reproducer will leak at least $n objects: ip addr add ff2e::4242/32 dev eth0 autojoin sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 for i in $(seq 1 $n); do ip link set up eth0; ip link set down eth0 done Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2) can also be used to create a nontrivial idev->mc_list, which will the leak objects with the right up-down-sequence. Based on both sources for NETDEV_DOWN events the interface IPv6 state should be considered: - not ready if the network interface is not ready OR IPv6 is disabled for it - ready if the network interface is ready AND IPv6 is enabled for it The functions ipv6_mc_up() and ipv6_down() should only be run when this state changes. Implement this by remembering when the IPv6 state is ready, and only run ipv6_mc_down() if it actually changed from ready to not ready. The other direction (not ready -> ready) already works correctly, as: - the interface notification triggered codepath for NETDEV_UP / NETDEV_CHANGE returns early if ipv6 is disabled, and - the disable_ipv6=0 triggered codepath skips fully initializing the interface as long as addrconf_link_ready(dev) returns false - calling ipv6_mc_up() repeatedly does not leak anything
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/24888915364cfa410de62d8abb5df95c3b67455d
- https://git.kernel.org/stable/c/72124e65a70b84e6303a5cd21b0ac1f27d7d61a4
- https://git.kernel.org/stable/c/9588ac2eddc2f223ebcebf6e9f5caed84d32922b
- https://git.kernel.org/stable/c/9995b408f17ff8c7f11bc725c8aa225ba3a63b1c
- https://git.kernel.org/stable/c/9a8736b2da28b24f01707f592ff059b9f90a058c
- https://git.kernel.org/stable/c/b11781515208dd31fbcd0b664078dce5dc44523f
- https://git.kernel.org/stable/c/c71bf3229f9e9dd60ba02f5a5be02066edf57012
- https://git.kernel.org/stable/c/f4c63b24dea9cc2043ff845dcca9aaf8109ea38a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: fix possible use-after-free Eric Dumazet says: The sock_hold() side seems suspect, because there is no guarantee that sk_refcnt is not already 0. On failure, we cannot queue the packet and need to indicate an error. The packet will be dropped by the caller. v2: split skb prefetch hunk into separate change
CVSS 3.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/21b27b2baa27423286e9b8d3f0b194d587083d95
- https://git.kernel.org/stable/c/34dc4a6a7f261736ef7183868a5bddad31c7f9e3
- https://git.kernel.org/stable/c/43c25da41e3091b31a906651a43e80a2719aa1ff
- https://git.kernel.org/stable/c/4d05239203fa38ea8a6f31e228460da4cb17a71a
- https://git.kernel.org/stable/c/c3873070247d9e3c7a6b0cf9bf9b45e8018427b1
- https://git.kernel.org/stable/c/dcc3cb920bf7ba66ac5e9272293a9ba5f80917ee
- https://git.kernel.org/stable/c/dd648bd1b33a828f62befa696b206c688da0ec43
- https://git.kernel.org/stable/c/ef97921ccdc243170fcef857ba2a17cf697aece5
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
netfilter: fix use-after-free in __nf_register_net_hook()
We must not dereference @new_hooks after nf_hook_mutex has been released,
because other threads might have freed our allocated hooks already.
BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline]
BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430
CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
hooks_validate net/netfilter/core.c:171 [inline]
__nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571
nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587
nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218
synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81
xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038
check_target net/ipv6/netfilter/ip6_tables.c:530 [inline]
find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573
translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735
do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline]
do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639
nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101
ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024
rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084
__sys_setsockopt+0x2db/0x610 net/socket.c:2180
__do_sys_setsockopt net/socket.c:2191 [inline]
__se_sys_setsockopt net/socket.c:2188 [inline]
__x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f65a1ace7d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9
RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003
RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130
R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000
The buggy address belongs to the page:
page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993
prep_new_page mm/page_alloc.c:2434 [inline]
get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389
__alloc_pages_node include/linux/gfp.h:572 [inline]
alloc_pages_node include/linux/gfp.h:595 [inline]
kmalloc_large_node+0x62/0x130 mm/slub.c:4438
__kmalloc_node+0x35a/0x4a0 mm/slub.
---truncated---
CVSS 3.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/05f7927b25d2635e87267ff6c79db79fb46cf313
- https://git.kernel.org/stable/c/49c24579cec41e32f13d57b337fd28fb208d4a5b
- https://git.kernel.org/stable/c/56763f12b0f02706576a088e85ef856deacc98a0
- https://git.kernel.org/stable/c/5a8076e98dde17224dd47283b894a8b1dbe1bc72
- https://git.kernel.org/stable/c/8b0142c4143c1ca297dcf2c0cdd045d65dae2344
- https://git.kernel.org/stable/c/bd61f192a339b1095dfd6d56073a5265934c2979
- https://git.kernel.org/stable/c/bdd8fc1b826e6f23963f5bef3f7431c6188ec954
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
blktrace: fix use after free for struct blk_trace
When tracing the whole disk, 'dropped' and 'msg' will be created
under 'q->debugfs_dir' and 'bt->dir' is NULL, thus blk_trace_free()
won't remove those files. What's worse, the following UAF can be
triggered because of accessing stale 'dropped' and 'msg':
==================================================================
BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100
Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188
CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4
Call Trace:
dump_stack_lvl+0x34/0x44
print_address_description.constprop.0.cold+0xab/0x381
? blk_dropped_read+0x89/0x100
? blk_dropped_read+0x89/0x100
kasan_report.cold+0x83/0xdf
? blk_dropped_read+0x89/0x100
kasan_check_range+0x140/0x1b0
blk_dropped_read+0x89/0x100
? blk_create_buf_file_callback+0x20/0x20
? kmem_cache_free+0xa1/0x500
? do_sys_openat2+0x258/0x460
full_proxy_read+0x8f/0xc0
vfs_read+0xc6/0x260
ksys_read+0xb9/0x150
? vfs_write+0x3d0/0x3d0
? fpregs_assert_state_consistent+0x55/0x60
? exit_to_user_mode_prepare+0x39/0x1e0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fbc080d92fd
Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1
RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd
RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045
RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd
R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0
R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8
Allocated by task 1050:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
do_blk_trace_setup+0xcb/0x410
__blk_trace_setup+0xac/0x130
blk_trace_ioctl+0xe9/0x1c0
blkdev_ioctl+0xf1/0x390
__x64_sys_ioctl+0xa5/0xe0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 1050:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x103/0x180
kfree+0x9a/0x4c0
__blk_trace_remove+0x53/0x70
blk_trace_ioctl+0x199/0x1c0
blkdev_common_ioctl+0x5e9/0xb30
blkdev_ioctl+0x1a5/0x390
__x64_sys_ioctl+0xa5/0xe0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88816912f380
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 88 bytes inside of
96-byte region [ffff88816912f380, ffff88816912f3e0)
The buggy address belongs to the page:
page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f
flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
>ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
==================================================================
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: thermal: core: Fix TZ_GET_TRIP NULL pointer dereference Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if the thermal zone does not define one.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
When enabling VMD and IOMMU scalable mode, the following kernel panic
call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids
CPU) during booting:
pci 0000:59:00.5: Adding to iommu group 42
...
vmd 0000:59:00.5: PCI host bridge to bus 10000:80
pci 10000:80:01.0: [8086:352a] type 01 class 0x060400
pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
pci 10000:80:01.0: enabling Extended Tags
pci 10000:80:01.0: PME# supported from D0 D3hot D3cold
pci 10000:80:01.0: DMAR: Setup RID2PASID failed
pci 10000:80:01.0: Failed to add to iommu group 42: -16
pci 10000:80:03.0: [8086:352b] type 01 class 0x060400
pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
pci 10000:80:03.0: enabling Extended Tags
pci 10000:80:03.0: PME# supported from D0 D3hot D3cold
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:29!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7
Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022
Workqueue: events work_for_cpu_fn
RIP: 0010:__list_add_valid.cold+0x26/0x3f
Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f
0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1
fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9
9e e8 8b b1 fe
RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246
RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8
RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20
RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888
R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0
R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70
FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
intel_pasid_alloc_table+0x9c/0x1d0
dmar_insert_one_dev_info+0x423/0x540
? device_to_iommu+0x12d/0x2f0
intel_iommu_attach_device+0x116/0x290
__iommu_attach_device+0x1a/0x90
iommu_group_add_device+0x190/0x2c0
__iommu_probe_device+0x13e/0x250
iommu_probe_device+0x24/0x150
iommu_bus_notifier+0x69/0x90
blocking_notifier_call_chain+0x5a/0x80
device_add+0x3db/0x7b0
? arch_memremap_can_ram_remap+0x19/0x50
? memremap+0x75/0x140
pci_device_add+0x193/0x1d0
pci_scan_single_device+0xb9/0xf0
pci_scan_slot+0x4c/0x110
pci_scan_child_bus_extend+0x3a/0x290
vmd_enable_domain.constprop.0+0x63e/0x820
vmd_probe+0x163/0x190
local_pci_probe+0x42/0x80
work_for_cpu_fn+0x13/0x20
process_one_work+0x1e2/0x3b0
worker_thread+0x1c4/0x3a0
? rescuer_thread+0x370/0x370
kthread+0xc7/0xf0
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
Modules linked in:
---[ end trace 0000000000000000 ]---
...
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---
The following 'lspci' output shows devices '10000:80:*' are subdevices of
the VMD device 0000:59:00.5:
$ lspci
...
0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)
...
10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)
10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)
10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)
10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)
10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]
10000:82:00
---truncated---
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
iwlwifi: mvm: check debugfs_dir ptr before use
When "debugfs=off" is used on the kernel command line, iwiwifi's
mvm module uses an invalid/unchecked debugfs_dir pointer and causes
a BUG:
BUG: kernel NULL pointer dereference, address: 000000000000004f
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7
Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021
RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm]
Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c <48> 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73
RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246
RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328
RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c
RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620
R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000
R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320
FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0
PKRU: 55555554
Call Trace:
? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm]
iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm]
iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm]
_iwl_op_mode_start+0x6f/0xd0 [iwlwifi]
iwl_opmode_register+0x6a/0xe0 [iwlwifi]
? 0xffffffffa0231000
iwl_mvm_init+0x35/0x1000 [iwlmvm]
? 0xffffffffa0231000
do_one_initcall+0x5a/0x1b0
? kmem_cache_alloc+0x1e5/0x2f0
? do_init_module+0x1e/0x220
do_init_module+0x48/0x220
load_module+0x2602/0x2bc0
? __kernel_read+0x145/0x2e0
? kernel_read_file+0x229/0x290
__do_sys_finit_module+0xc5/0x130
? __do_sys_finit_module+0xc5/0x130
__x64_sys_finit_module+0x13/0x20
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f64dda564dd
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48
RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd
RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001
RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002
R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2
R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018
Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev
CR2: 000000000000004f
---[ end trace 0000000000000000 ]---
Check the debugfs_dir pointer for an error before using it.
[change to make both conditional]
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:
cifs: fix double free race when mount fails in cifs_get_root()
When cifs_get_root() fails during cifs_smb3_do_mount() we call
deactivate_locked_super() which eventually will call delayed_free() which
will free the context.
In this situation we should not proceed to enter the out: section in
cifs_smb3_do_mount() and free the same resources a second time.
[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0
[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4
[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[Thu Feb 10 12:59:06 2022] Call Trace:
[Thu Feb 10 12:59:06 2022]
[Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78
[Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0
[Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0
[Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0
[Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20
[Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140
[Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10
[Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b
[Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150
[Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30
[Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0
...
[Thu Feb 10 12:59:07 2022] Freed by task 58179:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30
[Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40
[Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170
[Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20
[Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0
[Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
[Thu Feb 10 12:59:07 2022] Last potentially related work creation:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0
[Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10
[Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0
[Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS 3.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:
btrfs: get rid of warning on transaction commit when using flushoncommit
When using the flushoncommit mount option, during almost every transaction
commit we trigger a warning from __writeback_inodes_sb_nr():
$ cat fs/fs-writeback.c:
(...)
static void __writeback_inodes_sb_nr(struct super_block *sb, ...
{
(...)
WARN_ON(!rwsem_is_locked(&sb->s_umount));
(...)
}
(...)
The trace produced in dmesg looks like the following:
[947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3
[947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif
[947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186
[947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3
[947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)
[947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246
[947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000
[947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50
[947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000
[947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488
[947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460
[947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000
[947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0
[947.571072] Call Trace:
[947.572354]
[947.573266] btrfs_commit_transaction+0x1f1/0x998
[947.576785] ? start_transaction+0x3ab/0x44e
[947.579867] ? schedule_timeout+0x8a/0xdd
[947.582716] transaction_kthread+0xe9/0x156
[947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407
[947.590104] kthread+0x131/0x139
[947.592168] ? set_kthread_struct+0x32/0x32
[947.595174] ret_from_fork+0x22/0x30
[947.597561]
[947.598553] ---[ end trace 644721052755541c ]---
This is because we started using writeback_inodes_sb() to flush delalloc
when committing a transaction (when using -o flushoncommit), in order to
avoid deadlocks with filesystem freeze operations. This change was made
by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots
in flushoncommit"). After that change we started producing that warning,
and every now and then a user reports this since the warning happens too
often, it spams dmesg/syslog, and a user is unsure if this reflects any
problem that might compromise the filesystem's reliability.
We can not just lock the sb->s_umount semaphore before calling
writeback_inodes_sb(), because that would at least deadlock with
filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()
is called while we are holding that semaphore in write mode, and that can
trigger a transaction commit, resulting in a deadlock. It would also
trigger the same type of deadlock in the unmount path. Possibly, it could
also introduce some other locking dependencies that lockdep would report.
To fix this call try_to_writeback_inodes_sb() instead of
writeback_inodes_sb(), because that will try to read lock sb->s_umount
and then will only call writeback_inodes_sb() if it was able to lock it.
This is fine because the cases where it can't read lock sb->s_umount
are during a filesystem unmount or during a filesystem freeze - in those
cases sb->s_umount is write locked and sync_filesystem() is called, which
calls writeback_inodes_sb(). In other words, in all cases where we can't
take a read lock on sb->s_umount, writeback is already being triggered
elsewhere.
An alternative would be to call btrfs_start_delalloc_roots() with a
number of pages different from LONG_MAX, for example matching the number
of delalloc bytes we currently have, in
---truncated---
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:HMEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix fault in reweight_entity Syzbot found a GPF in reweight_entity. This has been bisected to commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") There is a race between sched_post_fork() and setpriority(PRIO_PGRP) within a thread group that causes a null-ptr-deref in reweight_entity() in CFS. The scenario is that the main process spawns number of new threads, which then call setpriority(PRIO_PGRP, 0, -20), wait, and exit. For each of the new threads the copy_process() gets invoked, which adds the new task_struct and calls sched_post_fork() for it. In the above scenario there is a possibility that setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread in the group that is just being created by copy_process(), and for which the sched_post_fork() has not been executed yet. This will trigger a null pointer dereference in reweight_entity(), as it will try to access the run queue pointer, which hasn't been set. Before the mentioned change the cfs_rq pointer for the task has been set in sched_fork(), which is called much earlier in copy_process(), before the new task is added to the thread_group. Now it is done in the sched_post_fork(), which is called after that. To fix the issue the remove the update_load param from the update_load param() function and call reweight_task() only if the task flag doesn't have the TASK_NEW flag set.
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:
riscv: fix oops caused by irqsoff latency tracer
The trace_hardirqs_{on,off}() require the caller to setup frame pointer
properly. This because these two functions use macro 'CALLER_ADDR1' (aka.
__builtin_return_address(1)) to acquire caller info. If the $fp is used
for other purpose, the code generated this macro (as below) could trigger
memory access fault.
0xffffffff8011510e <+80>: ld a1,-16(s0)
0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault here
The oops message during booting if compiled with 'irqoff' tracer enabled:
[ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8
[ 0.041925][ T0] Oops [#1]
[ 0.042063][ T0] Modules linked in:
[ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29
[ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT)
[ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2
[ 0.044601][ T0] ra : restore_all+0x12/0x6e
[ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0
[ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020
[ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0
[ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100
[ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
[ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45
[ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50
[ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8
[ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000
[ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000
[ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368
[ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d
[ 0.046402][ T0] [] restore_all+0x12/0x6e
This because the $fp(aka. $s0) register is not used as frame pointer in the
assembly entry code.
resume_kernel:
REG_L s0, TASK_TI_PREEMPT_COUNT(tp)
bnez s0, restore_all
REG_L s0, TASK_TI_FLAGS(tp)
andi s0, s0, _TIF_NEED_RESCHED
beqz s0, restore_all
call preempt_schedule_irq
j restore_all
To fix above issue, here we add one extra level wrapper for function
trace_hardirqs_{on,off}() so they can be safely called by low level entry
code.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: prevent copying too big compressed lzo segment
Compressed length can be corrupted to be a lot larger than memory
we have allocated for buffer.
This will cause memcpy in copy_compressed_segment to write outside
of allocated memory.
This mostly results in stuck read syscall but sometimes when using
btrfs send can get #GP
kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI
kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P OE 5.17.0-rc2-1 #12
kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs]
kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs
Code starting with the faulting instruction
===========================================
0:* 48 8b 06 mov (%rsi),%rax <-- trapping instruction
3: 48 8d 79 08 lea 0x8(%rcx),%rdi
7: 48 83 e7 f8 and $0xfffffffffffffff8,%rdi
b: 48 89 01 mov %rax,(%rcx)
e: 44 89 f0 mov %r14d,%eax
11: 48 8b 54 06 f8 mov -0x8(%rsi,%rax,1),%rdx
kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212
kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8
kernel: RDX: 0000000000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d
kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000
kernel: R13: 0000000000000008 R14: 0000000000001000 R15: 000841551d5c1000
kernel: FS: 0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0
kernel: Call Trace:
kernel:
kernel: end_compressed_bio_read (fs/btrfs/compression.c:104 fs/btrfs/compression.c:1363 fs/btrfs/compression.c:323) btrfs
kernel: end_workqueue_fn (fs/btrfs/disk-io.c:1923) btrfs
kernel: btrfs_work_helper (fs/btrfs/async-thread.c:326) btrfs
kernel: process_one_work (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312)
kernel: worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2455)
kernel: ? process_one_work (kernel/workqueue.c:2397)
kernel: kthread (kernel/kthread.c:377)
kernel: ? kthread_complete_and_exit (kernel/kthread.c:332)
kernel: ret_from_fork (arch/x86/entry/entry_64.S:301)
kernel:
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: fix memory leak in int3400_notify()
It is easy to hit the below memory leaks in my TigerLake platform:
unreferenced object 0xffff927c8b91dbc0 (size 32):
comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
hex dump (first 32 bytes):
4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The
72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.
backtrace:
[] __kmalloc_track_caller+0x2fe/0x4a0
[] kvasprintf+0x65/0xd0
[] kasprintf+0x4e/0x70
[] int3400_notify+0x82/0x120 [int3400_thermal]
[] acpi_ev_notify_dispatch+0x54/0x71
[] acpi_os_execute_deferred+0x17/0x30
[] process_one_work+0x21a/0x3f0
[] worker_thread+0x4a/0x3b0
[] kthread+0xfd/0x130
[] ret_from_fork+0x1f/0x30
Fix it by calling kfree() accordingly.
CVSS 3.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/2e798814e01827871938ff172d2b2ccf1e74b355
- https://git.kernel.org/stable/c/33c73a4d7e7b19313a6b417152f5365016926418
- https://git.kernel.org/stable/c/3abea10e6a8f0e7804ed4c124bea2d15aca977c8
- https://git.kernel.org/stable/c/ba9efbbf6745750d34c1e87c9539ce9db645ca0a
- https://git.kernel.org/stable/c/c3fa6d1937a8d0828131a04ae2cd2c30d0668693
- https://git.kernel.org/stable/c/e098933866f9e1dd3ef4eebbe2e3d504f970f599
- https://git.kernel.org/stable/c/f0ddc5184b0127038d05008e2a69f89d1e13f980
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Do not change route.addr.src_addr outside state checks If the state is not idle then resolve_prepare_src() should immediately fail and no change to global state should happen. However, it unconditionally overwrites the src_addr trying to build a temporary any address. For instance if the state is already RDMA_CM_LISTEN then this will corrupt the src_addr and would cause the test in cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) Which would manifest as this trace from syzkaller: BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [inline] list_add_tail include/linux/list.h:100 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae This is indicating that an rdma_id_private was destroyed without doing cma_cancel_listens(). Instead of trying to re-use the src_addr memory to indirectly create an any address derived from the dst build one explicitly on the stack and bind to that as any other normal flow would do. rdma_bind_addr() will copy it over the src_addr once it knows the state is valid. This is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not change route.addr.src_addr.ss_family")
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:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: add spinlock for rndis response list There's no lock for rndis response list. It could cause list corruption if there're two different list_add at the same time like below. It's better to add in rndis_add_response / rndis_free_response / rndis_get_next_response to prevent any race condition on response list. [ 361.894299] [1: irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0). [ 361.904380] [1: irq/191-dwc3:16979] Call trace: [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4 [ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec [ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c
CVSS 3.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/33222d1571d7ce8c1c75f6b488f38968fa93d2d9
- https://git.kernel.org/stable/c/4ce247af3f30078d5b97554f1ae6200a0222c15a
- https://git.kernel.org/stable/c/669c2b178956718407af5631ccbc61c24413f038
- https://git.kernel.org/stable/c/9ab652d41deab49848673c3dadb57ad338485376
- https://git.kernel.org/stable/c/9f5d8ba538ef81cd86ea587ca3f8c77e26bea405
- https://git.kernel.org/stable/c/9f688aadede6b862a0a898792b1a35421c93636f
- https://git.kernel.org/stable/c/aaaba1c86d04dac8e49bf508b492f81506257da3
- https://git.kernel.org/stable/c/da514063440b53a27309a4528b726f92c3cfe56f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: iio: adc: tsc2046: fix memory corruption by preventing array overflow On one side we have indio_dev->num_channels includes all physical channels + timestamp channel. On other side we have an array allocated only for physical channels. So, fix memory corruption by ARRAY_SIZE() instead of num_channels variable. Note the first case is a cleanup rather than a fix as the software timestamp channel bit in active_scanmask is never set by the IIO core.
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: iio: adc: men_z188_adc: Fix a resource leak in an error handling path If iio_device_register() fails, a previous ioremap() is left unbalanced. Update the error handling path and add the missing iounmap() call, as already done in the remove function.
CVSS 3.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/0f88722313645a903f4d420ba61ddc690ec2481d
- https://git.kernel.org/stable/c/1aa12ecfdcbafebc218910ec47acf6262e600cf5
- https://git.kernel.org/stable/c/53d43a9c8dd224e66559fe86af1e473802c7130e
- https://git.kernel.org/stable/c/c5723b422f564af15f2e3bc0592fd6376a0a6c45
- https://git.kernel.org/stable/c/ce1076b33e299dc8d270e4450a420a18bfb3e190
- https://git.kernel.org/stable/c/d6ed5426a7fad36cf928c244483ba24e72359638
- https://git.kernel.org/stable/c/e0a2e37f303828d030a83f33ffe14b36cb88d563
- https://git.kernel.org/stable/c/fe73477802981bd0d0d70f2b22f109bcca801bdb
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/ib_srp: Fix a deadlock Remove the flush_workqueue(system_long_wq) call since flushing system_long_wq is deadlock-prone and since that call is redundant with a preceding cancel_work_sync()
CVSS 3.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/081bdc9fe05bb23248f5effb6f811da3da4b8252
- https://git.kernel.org/stable/c/4752fafb461821f8c8581090c923ababba68c5bd
- https://git.kernel.org/stable/c/8cc342508f9e7fdccd2e9758ae9d52aff72dab7f
- https://git.kernel.org/stable/c/901206f71e6ad2b2e7accefc5199a438d173c25f
- https://git.kernel.org/stable/c/98d056603ce55ceb90631b3927151c190dfb1b27
- https://git.kernel.org/stable/c/99eb8d694174c777558dc902d575d1997d5ca650
- https://git.kernel.org/stable/c/c8b56e51aa91b8e7df3a98388dce3fdabd15c1d4
- https://git.kernel.org/stable/c/d7997d19dfa7001ca41e971cd9efd091bb195b51
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex.
CVSS 3.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/3aadfd46858b1f64d4d6a0654b863e21aabff975
- https://git.kernel.org/stable/c/40805099af11f68c5ca7dbcfacf455da8f99f622
- https://git.kernel.org/stable/c/84ec758fb2daa236026506868c8796b0500c047d
- https://git.kernel.org/stable/c/a37024f7757c25550accdebf49e497ad6ae239fe
- https://git.kernel.org/stable/c/a7ab53d3c27dfe83bb594456b9f38a37796ec39b
- https://git.kernel.org/stable/c/b7e2b91fcb5c78c414e33dc8d50642e307ca0c5a
- https://git.kernel.org/stable/c/d1654de19d42f513b6cfe955cc77e7f427e05a77
- https://git.kernel.org/stable/c/e7a66dd2687758718eddd79b542a95cf3aa488cc
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memory leak during stateful obj update stateful objects can be updated from the control plane. The transaction logic allocates a temporary object for this purpose. The ->init function was called for this object, so plain kfree() leaks resources. We must call ->destroy function of the object. nft_obj_destroy does this, but it also decrements the module refcount, but the update path doesn't increment it. To avoid special-casing the update object release, do module_get for the update case too and release it via nft_obj_destroy().
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/34bb90e407e3288f610558beaae54ecaa32b11c4
- https://git.kernel.org/stable/c/53026346a94c43f35c32b18804041bc483271d87
- https://git.kernel.org/stable/c/7e9880e81d3fd6a43c202f205717485290432826
- https://git.kernel.org/stable/c/dad3bdeef45f81a6e90204bcc85360bb76eccec7
- https://git.kernel.org/stable/c/e96e204ee6fa46702f6c94c3c69a09e69e0eac52
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac() ida_simple_get() returns an id between min (0) and max (NFP_MAX_MAC_INDEX) inclusive. So NFP_MAX_MAC_INDEX (0xff) is a valid id. In order for the error handling path to work correctly, the 'invalid' value for 'ida_idx' should not be in the 0..NFP_MAX_MAC_INDEX range, inclusive. So set it to -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/3a14d0888eb4b0045884126acc69abfb7b87814d
- https://git.kernel.org/stable/c/4086d2433576baf85f0e538511df97c8101e0a10
- https://git.kernel.org/stable/c/5ad5886f85b6bd893e3ed19013765fb0c243c069
- https://git.kernel.org/stable/c/9d8097caa73200710d52b9f4d9f430548f46a900
- https://git.kernel.org/stable/c/af4bc921d39dffdb83076e0a7eed1321242b7d87
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: unregister flowtable hooks on netns exit
Unregister flowtable hooks before they are releases via
nf_tables_flowtable_destroy() otherwise hook core reports UAF.
BUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142
Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666
CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
__dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106
dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106
print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247
__kasan_report mm/kasan/report.c:433 [inline]
__kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450
kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450
nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142
__nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429
nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571
nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232
nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430
nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline]
nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]
nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652
nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652
nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652
__nft_release_hook() calls nft_unregister_flowtable_net_hooks() which
only unregisters the hooks, then after RCU grace period, it is
guaranteed that no packets add new entries to the flowtable (no flow
offload rules and flowtable hooks are reachable from packet path), so it
is safe to call nf_flow_table_free() which cleans up the remaining
entries from the flowtable (both software and hardware) and it unbinds
the flow_block.
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:HLOW3.3
In the Linux kernel, the following vulnerability has been resolved:
io_uring: add a schedule point in io_add_buffers()
Looping ~65535 times doing kmalloc() calls can trigger soft lockups,
especially with DEBUG features (like KASAN).
[ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]
[ 253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)
[ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801
[ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)
[ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb <48> c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40
[ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246
[ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001
[ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a
[ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004
[ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380
[ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0
[ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000
[ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0
[ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 253.544494] Call Trace:
[ 253.544496]
[ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143)
[ 253.544505] __kernel_text_address (kernel/extable.c:78)
[ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)
[ 253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)
[ 253.544517] ? io_queue_sqe (fs/io_uring.c:7143)
[ 253.544521] stack_trace_save (kernel/stacktrace.c:123)
[ 253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
[ 253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
[ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)
[ 253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
[ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[ 253.544544] ? __io_queue_sqe (fs/io_uring.c:?)
[ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524)
[ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
[ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[ 253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
[ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
[ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)
[ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)
[ 253.544578] ? io_submit_sqes (fs/io_uring.c:7441)
[ 253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)
[ 253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)
[ 253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[ 253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)
[ 253.544596] __io_queue_sqe (fs/io_uring.c:?)
[ 253.544600] io_queue_sqe (fs/io_uring.c:7143)
[ 253.544603] io_submit_sqe (fs/io_uring.c:?)
[ 253.544608] io_submit_sqes (fs/io_uring.c:?)
[ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri
---truncated---
CVSS 3.xНИЗКАЯ 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:LMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: CDC-NCM: avoid overflow in sanity checking A broken device may give an extreme offset like 0xFFF0 and a reasonable length for a fragment. In the sanity check as formulated now, this will create an integer overflow, defeating the sanity check. Both offset and offset + len need to be checked in such a manner that no overflow can occur. And those quantities should be unsigned.
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/49909c9f8458cacb5b241106cba65aba5a6d8f4c
- https://git.kernel.org/stable/c/69560efa001397ebb8dc1c3e6a3ce00302bb9f7f
- https://git.kernel.org/stable/c/7b737e47b87589031f0d4657f6d7b0b770474925
- https://git.kernel.org/stable/c/8d2b1a1ec9f559d30b724877da4ce592edc41fdc
- https://git.kernel.org/stable/c/9957fbf34f52a4d8945d1bf39aae400ef9a11246
- https://git.kernel.org/stable/c/a612395c7631918e0e10ea48b9ce5ab4340f26a6
LOW3.3
In the Linux kernel, the following vulnerability has been resolved: bpf: Add schedule points in batch ops syzbot reported various soft lockups caused by bpf batch operations. INFO: task kworker/1:1:27 blocked for more than 140 seconds. INFO: task hung in rcu_barrier Nothing prevents batch ops to process huge amount of data, we need to add schedule points in them. Note that maybe_wait_bpf_programs(map) calls from generic_map_delete_batch() can be factorized by moving the call after the loop. This will be done later in -next tree once we get this fix merged, unless there is strong opinion doing this optimization sooner.
CVSS 3.xНИЗКАЯ 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:LMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix crash due to incorrect copy_map_value
When both bpf_spin_lock and bpf_timer are present in a BPF map value,
copy_map_value needs to skirt both objects when copying a value into and
out of the map. However, the current code does not set both s_off and
t_off in copy_map_value, which leads to a crash when e.g. bpf_spin_lock
is placed in map value with bpf_timer, as bpf_map_update_elem call will
be able to overwrite the other timer object.
When the issue is not fixed, an overwriting can produce the following
splat:
[root@(none) bpf]# ./test_progs -t timer_crash
[ 15.930339] bpf_testmod: loading out-of-tree module taints kernel.
[ 16.037849] ==================================================================
[ 16.038458] BUG: KASAN: user-memory-access in __pv_queued_spin_lock_slowpath+0x32b/0x520
[ 16.038944] Write of size 8 at addr 0000000000043ec0 by task test_progs/325
[ 16.039399]
[ 16.039514] CPU: 0 PID: 325 Comm: test_progs Tainted: G OE 5.16.0+ #278
[ 16.039983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0-1 04/01/2014
[ 16.040485] Call Trace:
[ 16.040645]
[ 16.040805] dump_stack_lvl+0x59/0x73
[ 16.041069] ? __pv_queued_spin_lock_slowpath+0x32b/0x520
[ 16.041427] kasan_report.cold+0x116/0x11b
[ 16.041673] ? __pv_queued_spin_lock_slowpath+0x32b/0x520
[ 16.042040] __pv_queued_spin_lock_slowpath+0x32b/0x520
[ 16.042328] ? memcpy+0x39/0x60
[ 16.042552] ? pv_hash+0xd0/0xd0
[ 16.042785] ? lockdep_hardirqs_off+0x95/0xd0
[ 16.043079] __bpf_spin_lock_irqsave+0xdf/0xf0
[ 16.043366] ? bpf_get_current_comm+0x50/0x50
[ 16.043608] ? jhash+0x11a/0x270
[ 16.043848] bpf_timer_cancel+0x34/0xe0
[ 16.044119] bpf_prog_c4ea1c0f7449940d_sys_enter+0x7c/0x81
[ 16.044500] bpf_trampoline_6442477838_0+0x36/0x1000
[ 16.044836] __x64_sys_nanosleep+0x5/0x140
[ 16.045119] do_syscall_64+0x59/0x80
[ 16.045377] ? lock_is_held_type+0xe4/0x140
[ 16.045670] ? irqentry_exit_to_user_mode+0xa/0x40
[ 16.046001] ? mark_held_locks+0x24/0x90
[ 16.046287] ? asm_exc_page_fault+0x1e/0x30
[ 16.046569] ? asm_exc_page_fault+0x8/0x30
[ 16.046851] ? lockdep_hardirqs_on+0x7e/0x100
[ 16.047137] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 16.047405] RIP: 0033:0x7f9e4831718d
[ 16.047602] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48
[ 16.048764] RSP: 002b:00007fff488086b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000023
[ 16.049275] RAX: ffffffffffffffda RBX: 00007f9e48683740 RCX: 00007f9e4831718d
[ 16.049747] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fff488086d0
[ 16.050225] RBP: 00007fff488086f0 R08: 00007fff488085d7 R09: 00007f9e4cb594a0
[ 16.050648] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f9e484cde30
[ 16.051124] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 16.051608]
[ 16.051762] ==================================================================
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:HMEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: ice: fix concurrent reset and removal of VFs Commit c503e63200c6 ("ice: Stop processing VF messages during teardown") introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is intended to prevent some issues with concurrently handling messages from VFs while tearing down the VFs. This change was motivated by crashes caused while tearing down and bringing up VFs in rapid succession. It turns out that the fix actually introduces issues with the VF driver caused because the PF no longer responds to any messages sent by the VF during its .remove routine. This results in the VF potentially removing its DMA memory before the PF has shut down the device queues. Additionally, the fix doesn't actually resolve concurrency issues within the ice driver. It is possible for a VF to initiate a reset just prior to the ice driver removing VFs. This can result in the remove task concurrently operating while the VF is being reset. This results in similar memory corruption and panics purportedly fixed by that commit. Fix this concurrency at its root by protecting both the reset and removal flows using the existing VF cfg_lock. This ensures that we cannot remove the VF while any outstanding critical tasks such as a virtchnl message or a reset are occurring. This locking change also fixes the root cause originally fixed by commit c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we can simply revert it. Note that I kept these two changes together because simply reverting the original commit alone would leave the driver vulnerable to worse race conditions.
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: hwmon: Handle failure to register sensor with thermal zone correctly If an attempt is made to a sensor with a thermal zone and it fails, the call to devm_thermal_zone_of_sensor_register() may return -ENODEV. This may result in crashes similar to the following. Unable to handle kernel NULL pointer dereference at virtual address 00000000000003cd ... Internal error: Oops: 96000021 [#1] PREEMPT SMP ... pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mutex_lock+0x18/0x60 lr : thermal_zone_device_update+0x40/0x2e0 sp : ffff800014c4fc60 x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790 x26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000 x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd x20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000 x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040 x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd x2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd Call trace: mutex_lock+0x18/0x60 hwmon_notify_event+0xfc/0x110 0xffffdde1cb7a0a90 0xffffdde1cb7a0b7c irq_thread_fn+0x2c/0xa0 irq_thread+0x134/0x240 kthread+0x178/0x190 ret_from_fork+0x10/0x20 Code: d503201f d503201f d2800001 aa0103e4 (c8e47c02) Jon Hunter reports that the exact call sequence is: hwmon_notify_event() --> hwmon_thermal_notify() --> thermal_zone_device_update() --> update_temperature() --> mutex_lock() The hwmon core needs to handle all errors returned from calls to devm_thermal_zone_of_sensor_register(). If the call fails with -ENODEV, report that the sensor was not attached to a thermal zone but continue to register the hwmon device.
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: KVM: x86/mmu: make apf token non-zero to fix bug In current async pagefault logic, when a page is ready, KVM relies on kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event. This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000
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: sched: Fix yet more sched_fork() races Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") fixed a fork race vs cgroup, it opened up a race vs syscalls by not placing the task on the runqueue before it gets exposed through the pidhash. Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is trying to fix a single instance of this, instead fix the whole class of issues, effectively reverting this commit.
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