All errata/sisyphus/ALT-PU-2021-1920-2
ALT-PU-2021-1920-2

Package update kernel-image-std-kvm in branch sisyphus

Version5.10.42-alt1
Task#273546
Published2026-02-04
Max severityHIGH
Severity:

Closed issues (337)

BDU:2021-02663
LOW3.5

Уязвимость набора стандартов связи для коммуникации IEEE 802.11 операционной системы Windows, позволяющая нарушителю внедрить произвольные сетевые пакеты

Published: 2021-05-24Modified: 2024-09-16
CVSS 3.xLOW 3.5
CVSS:3.x/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
CVSS 2.0LOW 2.9
CVSS:2.0/AV:A/AC:M/Au:N/C:N/I:P/A:N
References
BDU:2021-03088
LOW2.6

Уязвимость реализации алгоритмов WPA, WPA2 и WPA3 набора стандартов связи для коммуникации IEEE 802.11, позволяющая нарушителю оказать воздействие на целостность защищаемой информации

Published: 2021-06-18Modified: 2024-09-16
CVSS 3.xLOW 2.6
CVSS:3.x/AV:A/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.8
CVSS:2.0/AV:A/AC:H/Au:N/C:P/I:N/A:N
References
BDU:2021-03095
LOW3.5

Уязвимость реализации алгоритмов WEP, WPA, WPA2 и WPA3 набора стандартов связи для коммуникации IEEE 802.11, позволяющая нарушителю внедрить произвольные сетевые пакеты и/или оказать воздействие на целостность защищаемой информации

Published: 2021-06-18Modified: 2024-09-16
CVSS 3.xLOW 3.5
CVSS:3.x/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
CVSS 2.0LOW 2.9
CVSS:2.0/AV:A/AC:M/Au:N/C:P/I:N/A:N
References
BDU:2021-03177
MEDIUM5.4

Уязвимость реализации алгоритмов WEP, WPA, WPA2 и WPA3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации

Published: 2021-06-23Modified: 2024-09-16
CVSS 3.xMEDIUM 5.4
CVSS:3.x/AV:A/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N
CVSS 2.0LOW 3.2
CVSS:2.0/AV:A/AC:H/Au:N/C:P/I:P/A:N
References
BDU:2021-04825
HIGH7.8

Уязвимость функции bpf_ringbuf_reserve() ядра операционной системы Linux , связанная с записью за границами буфера в памяти, позволяющая нарушителю выполнить произвольный код в контексте ядра

Published: 2021-09-30Modified: 2024-06-03
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2021-04830
HIGH7.0

Уязвимость ядра операционной системы Linux , позволяющая нарушителю выполнить произвольный код в контексте ядра

Published: 2021-09-30Modified: 2024-06-04
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:M/Au:S/C:C/I:C/A:C
References
BDU:2021-04842
HIGH7.8

Уязвимость подсистемы eBPF ядра операционной системы Linux , связанная с чтением за границами буфера в памяти, позволяющая нарушителю выполнить произвольный код в контексте ядра

Published: 2021-10-05Modified: 2024-09-13
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2021-04843
HIGH8.8

Уязвимость подсистемы io_uring ядра операционной системы Linux, связанная с записью за границами буфера в памяти, позволяющая нарушителю выполнить произвольный код

Published: 2021-10-05Modified: 2024-12-04
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2021-05947
HIGH7.5

Уязвимость модуля CMTP (kernel/net/bluetooth/cmtp) ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии или выполнить произвольный код

Published: 2021-12-09Modified: 2024-11-07
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:H/Au:M/C:C/I:C/A:C
References
BDU:2022-04604
HIGH8.0

Уязвимость функции decode_nfs_fh() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии и вызвать аварийное завершение системы

Published: 2022-07-22Modified: 2026-01-20
CVSS 3.xHIGH 8.0
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.4
CVSS:2.0/AV:A/AC:M/Au:S/C:C/I:C/A:C
References
BDU:2024-01683
MEDIUM4.6

Уязвимость функции io_provide_buffers_prep() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных

Published: 2024-03-04Modified: 2024-12-05
CVSS 3.xMEDIUM 4.6
CVSS:3.x/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0MEDIUM 4.0
CVSS:2.0/AV:A/AC:H/Au:S/C:P/I:P/A:P
References
BDU:2024-01723
MEDIUM5.5

Уязвимость функции hso_serial_tty_unregister драйвера USB HSO (High Speed Options) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-04Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01749
HIGH8.4

Уязвимость функции drm_connector_cleanup() подсистемы Direct Rendering Manager (DRM) ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-03-05Modified: 2026-01-20
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-01755
LOW3.5

Уязвимость драйвера криптографического аппаратного ускорителя sun8i-ss (drivers/crypto/allwinner/sun8i-ss) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-05Modified: 2024-06-18
CVSS 3.xLOW 3.5
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 2.7
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2024-01757
LOW2.3

Уязвимость функции mt76_dma_tx_queue_skb_raw() компонента mt76 ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации

Published: 2024-03-05Modified: 2024-06-18
CVSS 3.xLOW 2.3
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:N/A:N
References
BDU:2024-01763
MEDIUM5.5

Уязвимость функция hci_conn_get_phy драйвера Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-05Modified: 2024-12-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01799
HIGH7.8

Уязвимость подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-06Modified: 2024-06-18
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01800
MEDIUM5.5

Уязвимость функции kvm_io_bus_unregister_dev() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-06Modified: 2024-06-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01812
HIGH7.1

Уязвимость функций llcp_sock_connect() и llcp_sock_bind() подсистемы NFC (Near Field Communication) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или раскрыть защищаемую информацию

Published: 2024-03-06Modified: 2024-05-13
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-01826
MEDIUM4.4

Уязвимость функции rtw_get_tx_power_params() службы UBSAN (Undefined Behaviour Sanity Checker) ядра операционных систем Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2024-03-07Modified: 2024-06-18
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:N/A:N
References
BDU:2024-01827
LOW2.3

Уязвимость функции DVFS (Dynamic Voltage and Frequency Scaling) драйвера встраиваемых плат Tegra 30 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-07Modified: 2024-06-18
CVSS 3.xLOW 2.3
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.4
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:P
References
BDU:2024-01828
LOW3.4

Уязвимость функции regmap_debugfs_exit() ядра операционных систем Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании

Published: 2024-03-07Modified: 2024-06-18
CVSS 3.xLOW 3.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:L
CVSS 2.0LOW 2.9
CVSS:2.0/AV:L/AC:L/Au:M/C:P/I:N/A:P
References
BDU:2024-01830
LOW3.4

Уязвимость функции sii902x_init ядра операционных систем Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании

Published: 2024-03-07Modified: 2024-06-18
CVSS 3.xLOW 3.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:L
CVSS 2.0LOW 2.9
CVSS:2.0/AV:L/AC:L/Au:M/C:P/I:N/A:P
References
BDU:2024-03688
HIGH7.8

Уязвимость функциях dm_mq_init_request_queue() и dm_mq_cleanup_mapped_device() в модуле drivers/md/dm-rq.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2024-09-16
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03689
HIGH7.8

Уязвимость функции imgu_fmt() в модуле drivers/staging/media/ipu3/ipu3-v4l2.c драйвера Intel ipu3-imgu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-01-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03690
HIGH7.8

Уязвимость функции raid1_end_write_request() в модуле drivers/md/raid1.c драйвера raid1 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03693
HIGH7.1

Уязвимость функции nfs23_parse_monolithic() в модуле fs/nfs/fs_context.c сервера файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-05-15
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-00795
MEDIUM5.5

Уязвимость компонента spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00796
MEDIUM5.5

Уязвимость компонента gve_main.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00799
MEDIUM5.5

Уязвимость функции qedf_update_link_speed() компонента drivers/scsi/qedf/qedf_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00800
MEDIUM5.5

Уязвимость компонента drivers/uio/uio_hv_generic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00801
MEDIUM5.5

Уязвимость функции lpspi_prepare_xfer_hardware() компонента drivers/spi/spi-fsl-lpspi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00802
HIGH7.8

Уязвимость функции __vmbus_open() компонента drivers/hv/channel.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00803
MEDIUM5.5

Уязвимость компонента drivers/nvme/target/tcp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00804
MEDIUM4.4

Уязвимость функции radix__set_pte_at() компонента arch/powerpc/include/asm/book3s/64/radix.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-00806
MEDIUM5.5

Уязвимость компонента net/vmw_vsock/virtio_transport_common.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00807
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с неправильным освобождением памяти перед удалением последней ссылки, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00808
HIGH7.8

Уязвимость функции siw_alloc_mr() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00809
HIGH7.8

Уязвимость функции tcp_set_default_congestion_control() компонента net/ipv4/tcp_cong.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00810
HIGH7.8

Уязвимость функции enic_hard_start_xmit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00811
HIGH7.8

Уязвимость функции i40e_client_subtask() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00812
MEDIUM5.5

Уязвимость функции hfsplus_file_truncate() компонента fs/hfsplus/extents.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00813
HIGH7.8

Уязвимость ядра операционной системы Linux, связанная с непроверенным индексированием массива, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00814
MEDIUM5.5

Уязвимость функции nbd_disconnect_and_put() компонента /drivers/block/nbd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00818
HIGH7.8

Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00821
MEDIUM5.5

Уязвимость компонента drivers/irqchip/irq-gic-v3.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00822
MEDIUM5.5

Уязвимость компонента fs/cifs/smb2ops.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00823
MEDIUM5.5

Уязвимость компонента fs/fuse/virtio_fs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00824
HIGH7.1

Уязвимость компонента net/openvswitch/actions.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28Modified: 2026-04-09
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-00827
MEDIUM6.7

Уязвимость компонента drivers/acpi/arm64/gtdt.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.5
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:C/A:C
References
BDU:2025-00828
MEDIUM5.5

Уязвимость функции imgu_fmt() компонента drivers/staging/media/ipu3/ipu3-v4l2.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00829
MEDIUM5.5

Уязвимость компонента drivers/usb/dwc3/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00830
MEDIUM5.5

Уязвимость функции queued_write_lock_slowpath() компонента locking/qrwlock.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2025-00833
MEDIUM5.5

Уязвимость компонента drivers/media/platform/aspeed-video.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00835
MEDIUM5.5

Уязвимость компонента drivers/i2c/busses/i2c-img-scb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00836
MEDIUM5.5

Уязвимость компонента drivers/i2c/busses/i2c-imx-lpi2c.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02847
HIGH8.4

Уязвимость функции qcom_mhi_qrtr_send() модуля net/qrtr/mhi.c поддержки маршрутизатора Qualcomm IPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-18
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2025-02848
HIGH7.8

Уязвимость функции atomisp_alloc_css_stat_bufs() модуля drivers/staging/media/atomisp/pci/atomisp_ioctl.c - драйвера поддержки устройств линейки Intel Atom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-02851
HIGH7.8

Уязвимость функции devm_spi_alloc_master() модуля drivers/spi/spi.c - драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-18
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-02853
HIGH7.8

Уязвимость функции nested_get_evmcs_page() модуля arch/x86/kvm/vmx/nested.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-18
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-02854
HIGH7.1

Уязвимость функции bt1_rom_map_copy_from() модуля drivers/mtd/maps/physmap-bt1-rom.c - драйвера поддержки доступа к устройствам памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность.

Published: 2025-03-18
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-02855
HIGH7.1

Уязвимость функции ucsi_unregister_altmodes() модуля drivers/usb/typec/ucsi/ucsi.c - драйвера поддержки интерфейса системного программного обеспечения разъема USB Type- C ( UCSI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-02856
MEDIUM5.5

Уязвимость функции cpu_power_to_freq() модуля drivers/thermal/cpufreq_cooling.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02857
MEDIUM5.5

Уязвимость функции dvb_media_device_free() модуля drivers/media/dvb-core/dvbdev.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02858
MEDIUM5.5

Уязвимость функции xiic_xfer() модуля drivers/i2c/busses/i2c-xiic.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02859
MEDIUM5.5

Уязвимость функции stm32f7_i2c_xfer() модуля drivers/i2c/busses/i2c-stm32f7.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02860
MEDIUM5.5

Уязвимость функции i2c_imx_xfer() модуля drivers/i2c/busses/i2c-imx.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02861
MEDIUM5.5

Уязвимость функции cdns_i2c_master_xfer() модуля drivers/i2c/busses/i2c-cadence.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02862
MEDIUM5.5

Уязвимость функции lm3554_probe() модуля drivers/staging/media/atomisp/i2c/atomisp-lm3554.c - драйвера поддержки устройств линейки Intel Atom ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02865
MEDIUM5.5

Уязвимость функции tpm2_seal_trusted() модуля security/keys/trusted-keys/trusted_tpm2.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02866
MEDIUM5.5

Уязвимость функции trace_clock_global() модуля kernel/trace/trace_clock.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02867
MEDIUM5.5

Уязвимость функции idx_to_offset() модуля tools/power/x86/turbostat/turbostat.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02871
MEDIUM5.5

Уязвимость функции efx_farch_handle_tx_event() модуля drivers/net/ethernet/sfc/farch.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02872
MEDIUM5.5

Уязвимость функции efx_farch_handle_tx_flush_done() модуля drivers/net/ethernet/sfc/farch.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02873
MEDIUM5.5

Уязвимость функции tpm_read_log_efi() модуля drivers/char/tpm/eventlog/efi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02985
MEDIUM5.5

Уязвимость функции uniphier_sd_remove() модуля drivers/mmc/host/uniphier-sd.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.

Published: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2025-02987
MEDIUM5.5

Уязвимость функции qla2xxx_mqueuecommand() модуля drivers/scsi/qla2xxx/qla_os.c - драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02990
MEDIUM5.5

Уязвимость функции vhost_vdpa_mmap() модуля drivers/vhost/vdpa.c - драйвера общей реализации IOTLB для vhost и vringh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02991
MEDIUM5.5

Уязвимость функции zcrypt_card_unregister() модуля drivers/s390/crypto/zcrypt_card.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03589
MEDIUM5.5

Уязвимость функции ovl_lookup() модуля fs/overlayfs/namei.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.

Published: 2025-04-01Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03654
MEDIUM5.5

Уязвимость функции rp2_remove_ports() модуля drivers/tty/serial/rp2.c - драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03845
MEDIUM5.5

Уязвимость функции fixup_bpf_calls() модуля kernel/bpf/verifier.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03846
MEDIUM5.5

Уязвимость функции auto_active() модуля drivers/gpu/drm/i915/i915_active.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-07Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03848
MEDIUM5.5

Уязвимость функции kvm_pv_send_ipi() модуля arch/x86/include/asm/kvm_host.h на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04376
LOW3.3

Уязвимость функции __do_sys_perf_event_open() модуля kernel/events/core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации

Published: 2025-04-14
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:N
References
BDU:2025-04392
MEDIUM5.5

Уязвимость функции meson_probe_remote() модуля drivers/gpu/drm/meson/meson_drv.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05164
MEDIUM5.5

Уязвимость функции mcp251x_stop() модуля drivers/net/can/spi/mcp251x.c - драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-05-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05173
MEDIUM5.5

Уязвимость функции init_dell_smbios_wmi() модуля drivers/platform/x86/dell-smbios-wmi.c - драйвера поддержки устройств X86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05303
MEDIUM5.5

Уязвимость функции nvmet_rdma_send_done() модуля drivers/nvme/target/rdma.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05304
MEDIUM4.7

Уязвимость функции sprd_i2c_master_xfer() модуля drivers/i2c/busses/i2c-sprd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05305
MEDIUM4.7

Уязвимость функции cleanup_transaction() модуля fs/btrfs/transaction.c поддержки файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05306
MEDIUM4.7

Уязвимость функции f2fs_unlock_rpages() модуля fs/f2fs/compress.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-05307
HIGH8.2

Уязвимость функции prestera_port_handle_event() модуля drivers/net/ethernet/marvell/prestera/prestera_main.c - драйвера поддержки сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю, действующему удаленно, оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xHIGH 8.2
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0HIGH 8.5
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:P/A:C
References
BDU:2025-05308
HIGH7.8

Уязвимость функции sctp_sf_do_dupcook_a() модуля net/sctp/sm_statefuns.c реализации протокола SCTP (Stream Control Transmission Protocol) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-05309
HIGH7.8

Уязвимость функции emac_mac_tx_buf_send() модуля drivers/net/ethernet/qualcomm/emac/emac-mac.c - драйвера поддержки сетевых адаптеров Ethernet Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-05-09Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-05311
HIGH7.8

Уязвимость функции ath10k_htc_send_bundle() модуля drivers/net/wireless/ath/ath10k/htc.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-05-09Modified: 2026-02-17
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-05313
HIGH7.8

Уязвимость функции rtrs_clt_remove_path_from_sysfs() модуля drivers/infiniband/ulp/rtrs/rtrs-clt.c - драйвера поддержки сервера и клиента RTRS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-05314
HIGH7.8

Уязвимость структуры hdcp_cmd_is_read{} модуля drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-05315
HIGH7.8

Уязвимость функции zynqmp_qspi_exec_op() модуля drivers/spi/spi-zynqmp-gqspi.c - драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-05317
HIGH7.7

Уязвимость функции detach_tasks() модуля kernel/sched/fair.c поддержки системы учета ресурсов ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2025-05-09
CVSS 3.xHIGH 7.7
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.6
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:N/A:C
References
BDU:2025-05318
HIGH7.1

Уязвимость функции nft_rhash_destroy() модуля net/netfilter/nft_set_hash.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-05319
HIGH7.1

Уязвимость функции f2fs_get_unusable_blocks() модуля fs/f2fs/f2fs.h поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:C/A:C
References
BDU:2025-05320
HIGH7.0

Уязвимость функции __pipelined_op() модуля ipc/mqueue.c подсистемы межпроцессного взаимодействия IPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-09Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2025-05321
HIGH7.1

Уязвимость функции uclamp_bucket_id() модуля kernel/sched/core.c поддержки системы учета ресурсов ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-05-09
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-05322
MEDIUM5.5

Уязвимость функции acpi_device_add() модуля drivers/acpi/scan.c - драйвера поддержки ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-05-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06525
MEDIUM5.5

Уязвимость функции dwc3_gadget_exit() модуля drivers/usb/dwc3/gadget.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06527
MEDIUM5.5

Уязвимость функции shmem_mfill_atomic_pte() модуля mm/shmem.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06528
MEDIUM5.5

Уязвимость функции do_uaccess_flush_fixups() модуля arch/powerpc/lib/feature-fixups.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06530
MEDIUM5.5

Уязвимость функции nf_tables_newobj() модуля net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06531
MEDIUM5.5

Уязвимость функции local_daif_inherit() модуля arch/arm64/include/asm/daifflags.h поддержки платформы ARM 64-бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06533
MEDIUM5.5

Уязвимость функции idxd_cmd_exec() модуля drivers/dma/idxd/device.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06534
MEDIUM5.5

Уязвимость функции pci_epf_test_bind() модуля drivers/pci/endpoint/functions/pci-epf-test.c - драйвера поддержки утройств PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06535
MEDIUM5.5

Уязвимость функции breakpoint_handler() модуля arch/arm/kernel/hw_breakpoint.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06536
MEDIUM5.5

Уязвимость функции f2fs_resize_fs() модуля fs/f2fs/gc.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06539
MEDIUM5.5

Уязвимость функции tpm_seal() модуля security/keys/trusted-keys/trusted_tpm1.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06540
MEDIUM5.5

Уязвимость функции drain_obj_stock() модуля mm/memcontrol.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06541
MEDIUM5.5

Уязвимость функции bnxt_rx_pkt() модуля drivers/net/ethernet/broadcom/bnxt/bnxt.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06542
MEDIUM5.5

Уязвимость функции mvme147_timer_int() модуля arch/m68k/mvme147/config.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06544
MEDIUM5.5

Уязвимость функции __set_fixmap() модуля arch/powerpc/include/asm/book3s/64/pgtable.h поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06547
MEDIUM5.5

Уязвимость функции mt7615_unregister_device() модуля drivers/net/wireless/mediatek/mt76/mt7615/pci_init.c - драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07252
MEDIUM5.5

Уязвимость функции mt7915_txp_skb_unmap() модуля drivers/net/wireless/mediatek/mt76/mt7915/mac.c - драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07253
MEDIUM5.5

Уязвимость функции mt7615_txp_skb_unmap_fw() модуля drivers/net/wireless/mediatek/mt76/mt7615/mac.c - драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07254
MEDIUM5.5

Уязвимость функции __domain_mapping() модуля drivers/iommu/intel/iommu.c - драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и конфиденциальность защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-07256
MEDIUM5.5

Уязвимость функции venus_probe() модуля drivers/media/platform/qcom/venus/core.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2025-07258
MEDIUM5.5

Уязвимость функции zynqmp_qspi_irq() модуля drivers/spi/spi-zynqmp-gqspi.c - драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07259
MEDIUM5.5

Уязвимость функции rpcif_sw_init() модуля drivers/memory/renesas-rpc-if.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07260
MEDIUM5.5

Уязвимость функции sa_run() модуля drivers/crypto/sa2ul.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07261
MEDIUM5.5

Уязвимость функции sun8i_ss_hash_run() модуля drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07262
MEDIUM5.5

Уязвимость функции qcom_ebi2_probe() модуля drivers/bus/qcom-ebi2.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07263
MEDIUM5.5

Уязвимость функции mtdchar_ioctl() модуля drivers/mtd/mtdchar.c - драйвера поддержки устройств памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07264
MEDIUM5.5

Уязвимость функции adf_probe() модуля drivers/crypto/qat/qat_c3xxxvf/adf_drv.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07265
MEDIUM5.5

Уязвимость функции sun8i_ss_prng_generate() модуля drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07266
MEDIUM5.5

Уязвимость функции nvme_loop_create_ctrl() модуля drivers/nvme/target/loop.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07268
MEDIUM5.5

Уязвимость функции ib_uverbs_handler_5() модуля drivers/infiniband/core/uverbs_std_types_device.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07272
MEDIUM5.3

Уязвимость функции nvmet_alloc_ctrl() модуля drivers/nvme/target/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23Modified: 2025-06-25
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:P
References
BDU:2025-07274
MEDIUM5.3

Уязвимость функции rxe_qp_init_req() модуля drivers/infiniband/sw/rxe/rxe_qp.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:P
References
BDU:2025-07276
MEDIUM4.7

Уязвимость функции rpcrdma_reply_handler() модуля net/sunrpc/xprtrdma/rpc_rdma.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-07313
HIGH7.8

Уязвимость функции xrx200_alloc_skb() модуля drivers/net/ethernet/lantiq_xrx200.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-23
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07352
MEDIUM6.0

Уязвимость функции i801_check_post() модуля drivers/i2c/busses/i2c-i801.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-07354
MEDIUM5.5

Уязвимость функции amdgpu_ttm_tt_unpopulate() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07356
MEDIUM5.5

Уязвимость функции link_to_fixup_dir() модуля fs/btrfs/tree-log.c поддержки файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07357
MEDIUM5.5

Уязвимость функции mld_newpack() модуля net/ipv6/mcast.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07358
MEDIUM5.5

Уязвимость функции fmvj18x_get_hwinfo() модуля drivers/net/ethernet/fujitsu/fmvj18x_cs.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07360
MEDIUM5.5

Уязвимость функции fec_enet_init() модуля drivers/net/ethernet/freescale/fec_main.c - драйвера поддержки сетевых адаптеров Ethernet Freescale ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07361
MEDIUM5.5

Уязвимость функции of_bcm_voter_get() модуля drivers/interconnect/qcom/bcm-voter.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07362
MEDIUM5.5

Уязвимость функции sja1105_setup() модуля drivers/net/dsa/sja1105/sja1105_main.c - драйвера поддержки коммутаторов семейства NXP SJA1105 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07363
MEDIUM5.5

Уязвимость функции mlx5e_rep_changelowerstate_event() модуля drivers/net/ethernet/mellanox/mlx5/core/en/rep/bond.c - драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07364
MEDIUM5.5

Уязвимость функции smsc75xx_bind() модуля drivers/net/usb/smsc75xx.c - драйвера поддержки сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07365
MEDIUM5.5

Уязвимость функции ad7124_of_parse_channel_config() модуля drivers/iio/adc/ad7124.c - драйвера поддержки различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07366
MEDIUM5.5

Уязвимость функции uss720_probe() модуля drivers/usb/misc/uss720.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07368
MEDIUM5.5

Уязвимость функции nci_core_conn_create() модуля include/net/nfc/nci_core.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13605
LOW3.3

Уязвимость функции __fh_to_dentry() модуля fs/ceph/export.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-10-31
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-13697
MEDIUM6.0

Уязвимость функции clear_all_filters() модуля drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:N/A:C
References
BDU:2025-13698
MEDIUM5.5

Уязвимость функции smcd_register_dev() модуля net/smc/smc_ism.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13699
MEDIUM5.5

Уязвимость функции mptcp_skb_can_collapse_to() модуля net/mptcp/protocol.c реализации протокола MTCP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13700
MEDIUM4.7

Уязвимость функции hns3_client_init() модуля drivers/net/ethernet/hisilicon/hns3/hns3_enet.c драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-05Modified: 2025-11-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-13701
MEDIUM4.4

Уязвимость функции mlx5e_rep_tc_update_skb() модуля drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c - драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-13702
MEDIUM6.0

Уязвимость функции mt7530_port_set_vlan_aware() модуля drivers/net/dsa/mt7530.c - драйвера поддержки DSA ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:N/A:C
References
BDU:2025-13703
MEDIUM5.5

Уязвимость функции dsa_master_get_strings() модуля net/dsa/master.c поддержки коммутаторов с распределенной архитектурой ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-05Modified: 2025-11-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13704
MEDIUM5.5

Уязвимость функции tipc_buf_append() модуля net/tipc/msg.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-05Modified: 2025-11-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13705
MEDIUM5.5

Уязвимость функции tipc_exit_net() модуля net/tipc/core.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-05Modified: 2025-11-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13706
MEDIUM5.5

Уязвимость функции nfs_pageio_doio() модуля fs/nfs/pagelist.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-05Modified: 2025-11-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13707
MEDIUM5.5

Уязвимость функции nfs_pageio_do_add_request() модуля fs/nfs/pagelist.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-05Modified: 2025-11-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13708
MEDIUM5.5

Уязвимость функции filelayout_decode_layout() модуля fs/nfs/filelayout/filelayout.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13709
MEDIUM4.4

Уязвимость функции proc_bulk() модуля drivers/usb/core/devio.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-13710
HIGH7.1

Уязвимость функции fq_pie_qdisc_enqueue() модуля net/sched/sch_fq_pie.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-13711
MEDIUM5.5

Уязвимость функции pipapo_refill() модуля net/netfilter/nft_set_pipapo.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13713
MEDIUM4.4

Уязвимость функции alloc_iommu() модуля drivers/iommu/dmar.c - драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-11-05
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
CVE-2020-24586
LOW3.5

The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that received fragments be cleared from memory after (re)connecting to a network. Under the right circumstances, when another device sends fragmented frames encrypted using WEP, CCMP, or GCMP, this can be abused to inject arbitrary network packets and/or exfiltrate user data.

Published: 2021-05-11Modified: 2024-11-21
CVSS 2.0LOW 2.9
CVSS:2.0/AV:A/AC:M/Au:N/C:P/I:N/A:N
CVSS 3.xLOW 3.5
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
References
CVE-2020-24587
LOW2.6

The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that all fragments of a frame are encrypted under the same key. An adversary can abuse this to decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed.

Published: 2021-05-11Modified: 2024-11-21
CVSS 2.0LOW 1.8
CVSS:2.0/AV:A/AC:H/Au:N/C:P/I:N/A:N
CVSS 3.xLOW 2.6
CVSS:3.x/CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
References
CVE-2020-24588
LOW3.5

The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that the A-MSDU flag in the plaintext QoS header field is authenticated. Against devices that support receiving non-SSP A-MSDU frames (which is mandatory as part of 802.11n), an adversary can abuse this to inject arbitrary network packets.

Published: 2021-05-11Modified: 2026-04-14
CVSS 2.0LOW 2.9
CVSS:2.0/AV:A/AC:M/Au:N/C:N/I:P/A:N
CVSS 3.xLOW 3.5
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
References
CVE-2020-26147
MEDIUM5.4

An issue was discovered in the Linux kernel 5.8.9. The WEP, WPA, WPA2, and WPA3 implementations reassemble fragments even though some of them were sent in plaintext. This vulnerability can be abused to inject packets and/or exfiltrate selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP data-confidentiality protocol is used.

Published: 2021-05-11Modified: 2026-04-14
CVSS 2.0LOW 3.2
CVSS:2.0/AV:A/AC:H/Au:N/C:P/I:P/A:N
CVSS 3.xMEDIUM 5.4
CVSS:3.x/CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N
References
CVE-2020-36776
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/cpufreq_cooling: Fix slab OOB issue Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index. Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue. Backtrace: [] die+0x104/0x5ac [] bug_handler+0x64/0xd0 [] brk_handler+0x160/0x258 [] do_debug_exception+0x248/0x3f0 [] el1_dbg+0x14/0xbc [] __kasan_report+0x1dc/0x1e0 [] kasan_report+0x10/0x20 [] __asan_report_load8_noabort+0x18/0x28 [] cpufreq_power2state+0x180/0x43c [] power_actor_set_power+0x114/0x1d4 [] allocate_power+0xaec/0xde0 [] power_allocator_throttle+0x3ec/0x5a4 [] handle_thermal_trip+0x160/0x294 [] thermal_zone_device_check+0xe4/0x154 [] process_one_work+0x5e4/0xe28 [] worker_thread+0xa4c/0xfac [] kthread+0x33c/0x358 [] ret_from_fork+0xc/0x18

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36777
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: Fix memory leak in dvb_media_device_free() dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn` before setting it to NULL, as documented in include/media/media-device.h: "The media_entity instance itself must be freed explicitly by the driver if required."

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36778
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: xiic: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in xiic_xfer and xiic_i2c_remove. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36779
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in these stm32f7_i2c_xx serious functions. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36780
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: i2c: sprd: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in sprd_i2c_master_xfer() and sprd_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2025-03-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36781
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix reference leak when pm_runtime_get_sync fails In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count is not expected to be incremented on return. However, pm_runtime_get_sync will increment pm reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36782
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36783
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: img-scb: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36784
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: cadence: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36785
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: atomisp: Fix use after free in atomisp_alloc_css_stat_bufs() The "s3a_buf" is freed along with all the other items on the "asd->s3a_stats" list. It leads to a double free and a use after free.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2020-36786
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: [next] staging: media: atomisp: fix memory leak of object flash In the case where the call to lm3554_platform_data_func returns an error there is a memory leak on the error return path of object flash. Fix this by adding an error return path that will free flash and rename labels fail2 to fail3 and fail1 to fail2.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2020-36787
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: aspeed: fix clock handling logic Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below. Enable eclk De-assert Video Engine reset 10ms delay Enable vclk It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot. To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails. clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting.

Published: 2024-02-28Modified: 2024-12-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-31440
HIGH7.0

This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel 5.11.15. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of eBPF programs. The issue results from the lack of proper validation of user-supplied eBPF programs prior to executing them. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel. Was ZDI-CAN-13661.

Published: 2021-05-21Modified: 2024-11-21
CVSS 2.0MEDIUM 6.9
CVSS:2.0/AV:L/AC:M/Au:N/C:C/I:C/A:C
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-3489
HIGH7.8

The eBPF RINGBUF bpf_ringbuf_reserve() function in the Linux kernel did not check that the allocated size was smaller than the ringbuf size, allowing an attacker to perform out-of-bounds writes within the kernel and therefore, arbitrary code execution. This issue was fixed via commit 4b81ccebaeee ("bpf, ringbuf: Deny reserve of buffers larger than ringbuf") (v5.13-rc4) and backported to the stable kernels in v5.12.4, v5.11.21, and v5.10.37. It was introduced via 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") (v5.8-rc1).

Published: 2021-06-04Modified: 2024-11-21
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-3490
HIGH7.8

The eBPF ALU32 bounds tracking for bitwise ops (AND, OR and XOR) in the Linux kernel did not properly update 32-bit bounds, which could be turned into out of bounds reads and writes in the Linux kernel and therefore, arbitrary code execution. This issue was fixed via commit 049c4e13714e ("bpf: Fix alu32 const subreg bound tracking on bitwise operations") (v5.13-rc4) and backported to the stable kernels in v5.12.4, v5.11.21, and v5.10.37. The AND/OR issues were introduced by commit 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") (5.7-rc1) and the XOR variant was introduced by 2921c90d4718 ("bpf:Fix a verifier failure with xor") ( 5.10-rc1).

Published: 2021-06-04Modified: 2024-11-21
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-3491
HIGH8.8

The io_uring subsystem in the Linux kernel allowed the MAX_RW_COUNT limit to be bypassed in the PROVIDE_BUFFERS operation, which led to negative values being usedin mem_rw when reading /proc//mem. This could be used to create a heap overflow leading to arbitrary code execution in the kernel. It was addressed via commit d1f82808877b ("io_uring: truncate lengths larger than MAX_RW_COUNT on provide buffers") (v5.13-rc1) and backported to the stable kernels in v5.12.4, v5.11.21, and v5.10.37. It was introduced in ddf0322db79c ("io_uring: add IORING_OP_PROVIDE_BUFFERS") (v5.7-rc1).

Published: 2021-06-04Modified: 2024-11-21
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
References
CVE-2021-34981
MEDIUM6.7

Linux Kernel Bluetooth CMTP Module Double Free Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the CMTP module. The issue results from the lack of validating the existence of an object prior to performing further free operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the kernel. Was ZDI-CAN-11977.

Published: 2024-05-07Modified: 2025-08-14
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-4157
HIGH8.0

An out of memory bounds write flaw (1 or 2 bytes of memory) in the Linux kernel NFS subsystem was found in the way users use mirroring (replication of files with NFS). A user, having access to the NFS mount, could potentially use this flaw to crash the system or escalate privileges on the system.

Published: 2022-03-25Modified: 2024-11-21
CVSS 2.0HIGH 7.4
CVSS:2.0/AV:A/AC:M/Au:S/C:C/I:C/A:C
CVSS 3.xHIGH 8.0
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-4460
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix UBSAN shift-out-of-bounds warning If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up doing a shift operation where the number of bits shifted equals number of bits in the operand. This behaviour is undefined. Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the count is >= number of bits in the operand. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472

Published: 2025-10-01Modified: 2026-01-14
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-46905
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect regression Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration") fixed the racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor has been released by hso_serial_tty_unregister().

Published: 2024-02-26Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46921
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: locking/qrwlock: Fix ordering in queued_write_lock_slowpath() While this code is executed with the wait_lock held, a reader can acquire the lock without holding wait_lock. The writer side loops checking the value with the atomic_cond_read_acquire(), but only truly acquires the lock when the compare-and-exchange is completed successfully which isn’t ordered. This exposes the window between the acquire and the cmpxchg to an A-B-A problem which allows reads following the lock acquisition to observe values speculatively before the write lock is truly acquired. We've seen a problem in epoll where the reader does a xchg while holding the read lock, but the writer can see a value change out from under it. Writer | Reader -------------------------------------------------------------------------------- ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->lock, flags); --> (observes value before unlock) | chain_epi_lockless() | | epi->next = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->lock, flags); | | | atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep->ovflist); | A core can order the read of the ovflist ahead of the atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire semantics addresses this issue at which point the atomic_cond_read can be switched to use relaxed semantics. [peterz: use try_cmpxchg()]

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2021-46922
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM reservation for seal/unseal The original patch 8c657a0590de ("KEYS: trusted: Reserve TPM for seal and unseal operations") was correct on the mailing list: https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ But somehow got rebased so that the tpm_try_get_ops() in tpm2_seal_trusted() got lost. This causes an imbalanced put of the TPM ops and causes oopses on TIS based hardware. This fix puts back the lost tpm_try_get_ops()

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46938
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46939
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

Published: 2024-02-27Modified: 2025-04-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46940
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tools/power turbostat: Fix offset overflow issue in index converting The idx_to_offset() function returns type int (32-bit signed), but MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number. The end result is that it hits the if (offset < 0) check in update_msr_sum() which prevents the timer callback from updating the stat in the background when long durations are used. The similar issue exists in offset_to_idx() and update_msr_sum(). Fix this issue by converting the 'int' to 'off_t' accordingly.

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46941
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Do core softreset when switch mode According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46943
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix set_fmt error handling If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46944
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix memory leak in imu_fmt We are losing the reference to an allocated memory if try. Change the order of the check to avoid that.

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46948
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics).

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46949
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX flush done handling We're starting from a TXQ instance number ('qid'), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics).

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46950
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: md/raid1: properly indicate failure when ending a failed write request This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared. Since we are in the failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).

Published: 2024-02-27Modified: 2025-04-22
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46951
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tpm: efi: Use local variable for calculating final log size When tpm_read_log_efi is called multiple times, which happens when one loads and unloads a TPM2 driver multiple times, then the global variable efi_tpm_final_log_size will at some point become a negative number due to the subtraction of final_events_preboot_size occurring each time. Use a local variable to avoid this integer underflow. The following issue is now resolved: Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20 Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073 Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000 Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 Mar 8 15:35:12 hibinst kernel: Call Trace: Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7 Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260 Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370 Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0 Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46952
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller. If the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift value for a 64-bit long integer, so 'retrans' cannot be >= 64. If it is >= 64, fail the mount and return an error.

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-46953
MEDIUM6.7

In the Linux kernel, the following vulnerability has been resolved: ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure When failing the driver probe because of invalid firmware properties, the GTDT driver unmaps the interrupt that it mapped earlier. However, it never checks whether the mapping of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks (as reported by Dann Frazier). Rework the driver to have a slightly saner behaviour and actually check whether the interrupt has been mapped before unmapping things.

Published: 2024-02-27Modified: 2024-11-21
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46955
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix stack OOB read while fragmenting IPv4 packets running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below.

Published: 2024-02-27Modified: 2024-12-06
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-46956
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix memory leak in virtio_fs_probe() When accidentally passing twice the same tag to qemu, kmemleak ended up reporting a memory leak in virtiofs. Also, looking at the log I saw the following error (that's when I realised the duplicated tag): virtiofs: probe of virtio5 failed with error -17 Here's the kmemleak log for reference: unreferenced object 0xffff888103d47800 (size 1024): comm "systemd-udevd", pid 118, jiffies 4294893780 (age 18.340s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ................ backtrace: [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs] [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210 [<000000004d6baf3c>] really_probe+0xea/0x430 [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0 [<00000000196f47a7>] __driver_attach+0x98/0x140 [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0 [<00000000399c7b7f>] bus_add_driver+0x11b/0x1f0 [<0000000032b09ba7>] driver_register+0x8f/0xe0 [<00000000cdd55998>] 0xffffffffa002c013 [<000000000ea196a2>] do_one_initcall+0x64/0x2e0 [<0000000008f727ce>] do_init_module+0x5c/0x260 [<000000003cdedab6>] __do_sys_finit_module+0xb5/0x120 [<00000000ad2f48c6>] do_syscall_64+0x33/0x40 [<00000000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae

Published: 2024-02-27Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46958
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between transaction aborts and fsyncs leading to use-after-free There is a race between a task aborting a transaction during a commit, a task doing an fsync and the transaction kthread, which leads to an use-after-free of the log root tree. When this happens, it results in a stack trace like the following: BTRFS info (device dm-0): forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x139/0xa40 Code: c0 74 19 (...) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __btrfs_handle_fs_error+0xde/0x146 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_file+0x40c/0x580 [btrfs] do_fsync+0x38/0x70 __x64_sys_fsync+0x10/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (...) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...) ---[ end trace ee2f1b19327d791d ]--- The steps that lead to this crash are the following: 1) We are at transaction N; 2) We have two tasks with a transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync; 3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree into a local variable named 'log_root_tree' at the top of btrfs_sync_log(). Task B is about to call write_all_supers(), but before that... 4) Task A calls btrfs_commit_transaction(), and after it sets the transaction state to TRANS_STATE_COMMIT_START, an error happens before it w ---truncated---

Published: 2024-02-27Modified: 2024-12-11
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46959
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: spi: Fix use-after-free with devm_spi_alloc_* We can't rely on the contents of the devres list during spi_unregister_controller(), as the list is already torn down at the time we perform devres_find() for devm_spi_release_controller. This causes devices registered with devm_spi_alloc_{master,slave}() to be mistakenly identified as legacy, non-devm managed devices and have their reference counters decremented below 0. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [] (refcount_warn_saturate) from [] (kobject_put+0x90/0x98) [] (kobject_put) from [] (put_device+0x20/0x24) r4:b6700140 [] (put_device) from [] (devm_spi_release_controller+0x3c/0x40) [] (devm_spi_release_controller) from [] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [] (release_nodes) from [] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [] (devres_release_all) from [] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [] (__device_release_driver) from [] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [] (device_driver_detach) from [] (unbind_store+0xe4/0xf8) Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup.

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46960
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cifs: Return correct error code from smb2_get_enc_key Avoid a warning if the error percolates back up: [440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key [440700.386947] ------------[ cut here ]------------ [440700.386948] err = 1 [440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70 ... [440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu ... [440700.397334] Call Trace: [440700.397346] __filemap_set_wb_err+0x1a/0x70 [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs] [440700.397426] do_writepages+0x4b/0xe0 [440700.397444] __filemap_fdatawrite_range+0xcb/0x100 [440700.397455] filemap_write_and_wait+0x42/0xa0 [440700.397486] cifs_setattr+0x68b/0xf30 [cifs] [440700.397493] notify_change+0x358/0x4a0 [440700.397500] utimes_common+0xe9/0x1c0 [440700.397510] do_utimes+0xc5/0x150 [440700.397520] __x64_sys_utimensat+0x88/0xd0

Published: 2024-02-27Modified: 2024-12-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46961
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Do not enable irqs when handling spurious interrups We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ------------[ cut here ]------------ [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a 'BUG_ON(in_nmi())' in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. [maz: rewrote commit message, corrected Fixes: tag]

Published: 2024-02-27Modified: 2025-04-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46962
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mmc: uniphier-sd: Fix a resource leak in the remove function A 'tmio_mmc_host_free()' call is missing in the remove function, in order to balance a 'tmio_mmc_host_alloc()' call in the probe. This is done in the error handling path of the probe, but not in the remove function. Add the missing call.

Published: 2024-02-27Modified: 2024-12-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2021-46963
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand() RIP: 0010:kmem_cache_free+0xfa/0x1b0 Call Trace: qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_directly+0x128/0x1d0 blk_mq_request_issue_directly+0x4e/0xb0 Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free.

Published: 2024-02-27Modified: 2024-12-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46965
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: mtd: physmap: physmap-bt1-rom: Fix unintentional stack access Cast &data to (char *) in order to avoid unintentionally accessing the stack. Notice that data is of type u32, so any increment to &data will be in the order of 4-byte chunks, and this piece of code is actually intended to be a byte offset. Addresses-Coverity-ID: 1497765 ("Out-of-bounds access")

Published: 2024-02-27Modified: 2025-01-08
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-46966
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function.

Published: 2024-02-27Modified: 2024-12-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46967
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: fix vm_flags for virtqueue doorbell mapping The virtqueue doorbell is usually implemented via registeres but we don't provide the necessary vma->flags like VM_PFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vm_flags. With this patch, try to map doorbell via IOTLB will fail with bad address.

Published: 2024-02-27Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46968
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix zcard and zqueue hot-unplug memleak Tests with kvm and a kmemdebug kernel showed, that on hot unplug the zcard and zqueue structs for the unplugged card or queue are not properly freed because of a mismatch with get/put for the embedded kref counter. This fix now adjusts the handling of the kref counters. With init the kref counter starts with 1. This initial value needs to drop to zero with the unregister of the card or queue to trigger the release and free the object.

Published: 2024-02-27Modified: 2025-01-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46971
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task's type has the corresponding "lockdown" class permission ("integrity" or "confidentiality") allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when its result would be honored.

Published: 2024-02-27Modified: 2025-01-08
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
References
CVE-2021-46972
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ovl: fix leaked dentry Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a metacopy error, which leads to dentry leaks when shutting down the related superblock: overlayfs: refusing to follow metacopy origin for (/file0) ... BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] ... WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 ... RIP: 0010:umount_check.cold+0x107/0x14d ... Call Trace: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0 ? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820 ? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160 ? lock_release+0x1b6/0x660 ? mm_update_next_owner+0xa20/0xa20 ? reacquire_held_locks+0x3f0/0x3f0 ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae ... VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day... This fix has been tested with a syzkaller reproducer.

Published: 2024-02-27Modified: 2025-01-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46973
HIGH8.4

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Avoid potential use after free in MHI send It is possible that the MHI ul_callback will be invoked immediately following the queueing of the skb for transmission, leading to the callback decrementing the refcount of the associated sk and freeing the skb. As such the dereference of skb and the increment of the sk refcount must happen before the skb is queued, to avoid the skb to be used after free and potentially the sk to drop its last refcount..

Published: 2024-02-27Modified: 2025-03-14
CVSS 3.xHIGH 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46974
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix masking negation logic upon negative dst register The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation.

Published: 2024-02-27Modified: 2025-01-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46976
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix crash in auto_retire The retire logic uses the 2 lower bits of the pointer to the retire function to store flags. However, the auto_retire function is not guaranteed to be aligned to a multiple of 4, which causes crashes as we jump to the wrong address, for example like this: 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros ---truncated---

Published: 2024-02-28Modified: 2025-01-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46977
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Disable preemption when probing user return MSRs Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host's value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU. Opportunistically land the helper in common x86, SVM will use the helper in a future commit.

Published: 2024-02-28Modified: 2025-01-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46978
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state().

Published: 2024-02-28Modified: 2025-03-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46980
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command.

Published: 2024-02-28Modified: 2024-12-31
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-46981
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nbd: Fix NULL pointer in flush_workqueue Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750] ____sys_sendmsg+0x1da/0x320 [ 656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put().

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46982
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix race condition of overwrite vs truncate pos_fsstress testcase complains a panic as belew: ------------[ cut here ]------------ kernel BUG at fs/f2fs/compress.c:1082! invalid opcode: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G OE 5.12.0-rc1-custom #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: writeback wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Call Trace: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x290 wb_workfn+0x309/0x500 process_one_work+0x220/0x3c0 worker_thread+0x53/0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 The root cause is truncate() may race with overwrite as below, so that one reference count left in page can not guarantee the page attaching in mapping tree all the time, after truncation, later find_lock_page() may return NULL pointer. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Fix this by avoiding referencing updated page.

Published: 2024-02-28Modified: 2024-12-31
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46983
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: Fix NULL deref when SEND is completed with error When running some traffic and taking down the link on peer, a retry counter exceeded error is received. This leads to nvmet_rdma_error_comp which tried accessing the cq_context to obtain the queue. The cq_context is no longer valid after the fix to use shared CQ mechanism and should be obtained similar to how it is obtained in other functions from the wc->qp. [ 905.786331] nvmet_rdma: SEND for CQE 0x00000000e3337f90 failed with status transport retry counter exceeded (12). [ 905.832048] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 905.839919] PGD 0 P4D 0 [ 905.842464] Oops: 0000 1 SMP NOPTI [ 905.846144] CPU: 13 PID: 1557 Comm: kworker/13:1H Kdump: loaded Tainted: G OE --------- - - 4.18.0-304.el8.x86_64 #1 [ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma] [ 905.878259] Code: 19 4f c0 e8 89 b3 a5 f6 e9 5b e0 ff ff 0f b7 75 14 4c 89 ea 48 c7 c7 08 1a 4f c0 e8 71 b3 a5 f6 e9 4b e0 ff ff 0f 1f 44 00 00 <48> 8b 47 48 48 85 c0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff [ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246 [ 905.902387] RAX: 0000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000 [ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 0000000000000000 [ 905.916731] RBP: ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074 [ 905.923903] R10: 0000000000000000 R11: ffffab601c45fcc0 R12: 0000000000000010 [ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400 [ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72df940000(0000) knlGS:0000000000000000 [ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 905.950067] nvmet_rdma: SEND for CQE 0x00000000c7356cca failed with status transport retry counter exceeded (12). [ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0 [ 905.961855] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 905.961857] PKRU: 55555554 [ 906.010315] Call Trace: [ 906.012778] __ib_process_cq+0x89/0x170 [ib_core] [ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core] [ 906.022152] process_one_work+0x1a7/0x360 [ 906.026182] ? create_worker+0x1a0/0x1a0 [ 906.030123] worker_thread+0x30/0x390 [ 906.033802] ? create_worker+0x1a0/0x1a0 [ 906.037744] kthread+0x116/0x130 [ 906.040988] ? kthread_flush_work_fn+0x10/0x10 [ 906.045456] ret_from_fork+0x1f/0x40

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46984
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46985
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: Fix a memory leak in an error handling path If 'acpi_device_set_name()' fails, we must free 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46986
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Free gadget structure only after freeing endpoints As part of commit e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the device's removal when usb_del_gadget_udc() is called in dwc3_gadget_exit(). However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del(). This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf5492 ("usb: dwc3: core: Add shutdown callback for dwc3") also exposes this as a panic during shutdown. There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain. Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate "del" and "put" components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget().

Published: 2024-02-28Modified: 2024-12-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46988
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page. This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned. To fix this, detect if we have such a "dangling" page when accounting fails, and if so, release it before returning.

Published: 2024-02-28Modified: 2024-12-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46989
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: hfsplus: prevent corruption in shrinking truncate I believe there are some issues introduced by commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file. In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more. Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally. To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data. Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data. Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check.

Published: 2024-02-28Modified: 2025-03-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46990
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix crashes when toggling entry flush barrier The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity.

Published: 2024-02-28Modified: 2024-12-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46991
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: i40e: Fix use-after-free in i40e_client_subtask() Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: ("Read from pointer after free")

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46992
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: avoid overflows in nft_hash_buckets() Number of buckets being stored in 32bit variables, we have to ensure that no overflows occur in nft_hash_buckets() syzbot injected a size == 0x40000000 and reported: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.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:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [inline] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline] nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46

Published: 2024-02-28Modified: 2024-12-24
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-46993
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: sched: Fix out-of-bound access in uclamp Util-clamp places tasks in different buckets based on their clamp values for performance reasons. However, the size of buckets is currently computed using a rounding division, which can lead to an off-by-one error in some configurations. For instance, with 20 buckets, the bucket size will be 1024/20=51. A task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, correct indexes are in range [0,19], hence leading to an out of bound memory access. Clamp the bucket id to fix the issue.

Published: 2024-02-28Modified: 2024-12-24
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-46994
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix resume from sleep before interface was brought up Since 8ce8c0abcba3 the driver queues work via priv->restart_work when resuming after suspend, even when the interface was not previously enabled. This causes a null dereference error as the workqueue is only allocated and initialized in mcp251x_open(). To fix this we move the workqueue init to mcp251x_can_probe() as there is no reason to do it later and repeat it whenever mcp251x_open() is called. [mkl: fix error handling in mcp251x_stop()]

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46996
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: Fix a memleak from userdata error path in new objects Release object name if userdata allocation fails.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46997
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18

Published: 2024-02-28Modified: 2024-12-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-46998
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961.

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-46999
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: sctp: do asoc update earlier in sctp_sf_do_dupcook_a There's a panic that occurs in a few of envs, the call trace is as below: [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc's shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire(). Thanks Alexander and Jere for helping dig into this issue. To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this.

Published: 2024-02-28Modified: 2025-01-08
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47000
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode leak on getattr error in __fh_to_dentry

Published: 2024-02-28Modified: 2025-03-14
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
References
CVE-2021-47001
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().

Published: 2024-02-28Modified: 2025-04-11
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47003
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix potential null dereference on pointer status There are calls to idxd_cmd_exec that pass a null status pointer however a recent commit has added an assignment to *status that can end up with a null pointer dereference. The function expects a null status pointer sometimes as there is a later assignment to *status where status is first null checked. Fix the issue by null checking status before making the assignment. Addresses-Coverity: ("Explicit null dereferenced")

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47004
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid touching checkpointed data in get_victim() In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR mode to select victim: 1. LFS is set to find source section during GC, the victim should have no checkpointed data, since after GC, section could not be set free for reuse. Previously, we only check valid chpt blocks in current segment rather than section, fix it. 2. SSR | AT_SSR are set to find target segment for writes which can be fully filled by checkpointed and newly written blocks, we should never select such segment, otherwise it can cause panic or data corruption during allocation, potential case is described as below: a) target segment has 'n' (n < 512) ckpt valid blocks b) GC migrates 'n' valid blocks to other segment (segment is still in dirty list) c) GC migrates '512 - n' blocks to target segment (segment has 'n' cp_vblocks and '512 - n' vblocks) d) If GC selects target segment via {AT,}SSR allocator, however there is no free space in targe segment.

Published: 2024-02-28Modified: 2025-01-08
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2021-47005
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix NULL pointer dereference for ->get_features() get_features ops of pci_epc_ops may return NULL, causing NULL pointer dereference in pci_epf_test_alloc_space function. Let us add a check for pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid any such NULL pointer dereference and return -ENOTSUPP in case pci_epc_feature is not found. When the patch is not applied and EPC features is not implemented in the platform driver, we see the following dump due to kernel NULL pointer dereference. Call trace: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys_symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70/0x88 el0_svc+0x8/0x640 Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ end trace a438e3c5a24f9df0 ]---

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47006
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook The commit 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") set a default event->overflow_handler in perf_event_alloc(), and replace the check event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/

Published: 2024-02-28Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47007
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix panic during f2fs_resize_fs() f2fs_resize_fs() hangs in below callstack with testcase: - mkfs 16GB image & mount image - dd 8GB fileA - dd 8GB fileB - sync - rm fileA - sync - resize filesystem to 8GB kernel BUG at segment.c:2484! Call Trace: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page+0x392/0x850 [f2fs] move_data_page+0x233/0x320 [f2fs] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioctl+0x8e/0xd0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The root cause is we forgot to check that whether we have enough space in resized filesystem to store all valid blocks in before-resizing filesystem, then allocator will run out-of-space during block migration in free_segment_range().

Published: 2024-02-28Modified: 2025-01-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47009
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak on object td Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc]

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47010
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: Only allow init netns to set default tcp cong to a restricted algo tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future. This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify

Published: 2024-02-28Modified: 2025-03-19
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47011
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm: memcontrol: slab: fix obtain a reference to a freeing memcg Patch series "Use obj_cgroup APIs to charge kmem pages", v5. Since Roman's series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which still hold a reference to the memory cgroup. E.g. We know that the kernel stack is charged as kmem pages because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x86_64 or arm64). If we create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see this scenario by using the following script. We can see that the system has added 500 dying cgroups (This is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which can pin the memory cgroup in the memory). #!/bin/bash cat /proc/cgroups | grep memory cd /sys/fs/cgroup/memory echo 1 > memory.move_charge_at_immigrate for i in range{1..500} do mkdir kmem_test echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` > cgroup.procs rmdir kmem_test done cat /proc/cgroups | grep memory This patchset aims to make those kmem pages to drop the reference to memory cgroup by using the APIs of obj_cgroup. Finally, we can see that the number of the dying cgroups will not increase if we run the above test script. This patch (of 7): The rcu_read_lock/unlock only can guarantee that the memcg will not be freed, but it cannot guarantee the success of css_get (which is in the refill_stock when cached memcg changed) to memcg. rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg) // css_get can change the ref counter from 0 back to 1. css_get(&memcg->css) rcu_read_unlock() This fix is very like the commit: eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge") Fix this by holding a reference to the memcg which is passed to the __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().

Published: 2024-02-28Modified: 2025-01-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47012
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix a use after free in siw_alloc_mr Our code analyzer reported a UAF. In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the err_out branch of siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr). My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {} section, to avoid the uaf.

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47013
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47015
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RX consumer index logic in the error path. In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

Published: 2024-02-28Modified: 2025-01-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47016
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: m68k: mvme147,mvme16x: Don't wipe PCC timer config bits Don't clear the timer 1 configuration bits when clearing the interrupt flag and counter overflow. As Michael reported, "This results in no timer interrupts being delivered after the first. Initialization then hangs in calibrate_delay as the jiffies counter is not updated." On mvme16x, enable the timer after requesting the irq, consistent with mvme147.

Published: 2024-02-29Modified: 2025-01-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47017
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix a use after free in ath10k_htc_send_bundle In ath10k_htc_send_bundle, the bundle_skb could be freed by dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later by bundle_skb->len. As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to skb_len after the bundle_skb was freed.

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47018
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough.

Published: 2024-02-28Modified: 2025-01-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47020
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soundwire: stream: fix memory leak in stream config error path When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak.

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47022
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: fix memleak when mt7615_unregister_device() mt7615_tx_token_put() should get call before mt76_free_pending_txwi().

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47023
HIGH8.2

In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix port event handling on init For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state. The crash points to cancel_delayed_work() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port's state was up & runnig. The following is the crash which can be triggered: [ 28.311104] Unable to handle kernel paging request at virtual address 000071775f776600 [ 28.319097] Mem abort info: [ 28.321914] ESR = 0x96000004 [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Data abort info: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=0000000000000000, p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 28.365310] Modules linked in: prestera_pci(+) prestera uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted 5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn [prestera_pci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : get_work_pool+0x48/0x60 [ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0 [ 28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.420089] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0 [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 000000000000000c [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030 [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758 [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60 [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060 [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8 [ 28.489791] Call trace: [ 28.492259] get_work_pool+0x48/0x60 [ 28.495874] cancel_delayed_work+0x38/0xb0 [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera] [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera] [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci] [ 28.516660] process_one_work+0x1e8/0x360 [ 28.520710] worker_thread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] ret_from_fork+0x10/0x38 [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020) [ 28.537429] ---[ end trace 5eced933df3a080b ]---

Published: 2024-02-28Modified: 2025-03-19
CVSS 3.xHIGH 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
References
CVE-2021-47024
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47026
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: destroy sysfs after removing session from active list A session can be removed dynamically by sysfs interface "remove_path" that eventually calls rtrs_clt_remove_path_from_sysfs function. The current rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and frees sess->stats object. Second it removes the session from the active list. Therefore some functions could access non-connected session and access the freed sess->stats object even-if they check the session status before accessing the session. For instance rtrs_clt_request and get_next_path_min_inflight check the session status and try to send IO to the session. The session status could be changed when they are trying to send IO but they could not catch the change and update the statistics information in sess->stats object, and generate use-after-free problem. (see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats") This patch changes the rtrs_clt_remove_path_from_sysfs to remove the session from the active session list and then destroy the sysfs interfaces. Each function still should check the session status because closing or error recovery paths can change the status.

Published: 2024-02-28Modified: 2025-01-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47032
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix tx skb dma unmap The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries

Published: 2024-02-28Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47033
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: fix tx skb dma unmap The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries

Published: 2024-02-28Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47034
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix pte update for kernel memory on radix When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call T ---truncated---

Published: 2024-02-28Modified: 2025-04-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47035
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.

Published: 2024-02-28Modified: 2025-01-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47038
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: avoid deadlock between hci_dev->lock and socket lock Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a dependency between socket lock and hci_dev->lock that could lead to deadlock. It turns out that hci_conn_get_phy() is not in any way relying on hdev being immutable during the runtime of this function, neither does it even look at any of the members of hdev, and as such there is no need to hold that lock. This fixes the lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc1-00026-g73d464503354 #10 Not tainted ------------------------------------------------------ bluetoothd/1118 is trying to acquire lock: ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth] but task is already holding lock: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] process_one_work+0x244/0x5f0 worker_thread+0x3c/0x380 kthread+0x13e/0x160 ret_from_fork+0x22/0x30 -> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x322/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks+0x49/0x70 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x ---truncated---

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47040
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: io_uring: fix overflows checks in provide buffers Colin reported before possible overflow and sign extension problems in io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension"). Do that with help of check__overflow helpers. And fix struct io_provide_buf::len type, as it doesn't make much sense to keep it signed.

Published: 2024-02-28Modified: 2025-01-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47041
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated---

Published: 2024-02-28Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47043
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: venus: core: Fix some resource leaks in the error path of 'venus_probe()' If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls.

Published: 2024-02-28Modified: 2025-01-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2021-47044
HIGH7.7

In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Possible UB shift here") The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine.

Published: 2024-02-28Modified: 2025-03-19
CVSS 3.xHIGH 7.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-47046
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix off by one in hdmi_14_process_transaction() The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code.

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47047
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [ 123.792536] Mem abort info: [ 123.795313] ESR = 0x96000145 [ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Data abort info: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1, WnR = 1 [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP

Published: 2024-02-28Modified: 2025-01-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47048
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op When handling op->addr, it is using the buffer "tmpbuf" which has been freed. This will trigger a use-after-free KASAN warning. Let's use temporary variables to store op->addr.val and op->cmd.opcode to fix this issue.

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47049
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it.

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47050
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: memory: renesas-rpc-if: fix possible NULL pointer dereference of resource The platform_get_resource_byname() can return NULL which would be immediately dereferenced by resource_size(). Instead dereference it after validating the resource. Addresses-Coverity: Dereference null return value

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47051
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced.

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47052
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - Fix memory leak of rxd There are two error return paths that are not freeing rxd and causing memory leaks. Fix these. Addresses-Coverity: ("Resource leak")

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47053
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Fix memory leak of pad It appears there are several failure return paths that don't seem to be free'ing pad. Fix these. Addresses-Coverity: ("Resource leak")

Published: 2024-02-28Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47054
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bus: qcom: Put child node before return Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and should be decremented manually if the loop is broken in loop body.

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47055
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mtd: require write permissions for locking and badblock ioctls MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table.

Published: 2024-02-29Modified: 2025-01-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47056
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [ 7.180345] Call Trace: [ 7.182576] mutex_lock+0xc9/0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf]

Published: 2024-02-29Modified: 2025-01-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47057
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Fix memory leak of object d when dma_iv fails to map In the case where the dma_iv mapping fails, the return error path leaks the memory allocated to object d. Fix this by adding a new error return label and jumping to this to ensure d is free'd before the return. Addresses-Coverity: ("Resource leak")

Published: 2024-02-29Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47058
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: regmap: set debugfs_name to NULL after it is freed There is a upstream commit cffa4b2122f5("regmap:debugfs: Fix a memory leak when calling regmap_attach_dev") that adds a if condition when create name for debugfs_name. With below function invoking logical, debugfs_name is freed in regmap_debugfs_exit(), but it is not created again because of the if condition introduced by above commit. regmap_reinit_cache() regmap_debugfs_exit() ... regmap_debugfs_init() So, set debugfs_name to NULL after it is freed.

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47059
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - fix result memory leak on error path This patch fixes a memory leak on an error path.

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47060
MEDIUM6.0

In the Linux kernel, the following vulnerability has been resolved: KVM: Stop looking for coalesced MMIO zones if the bus is destroyed Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails to allocate memory for the new instance of the bus. If it can't instantiate a new bus, unregister_dev() destroys all devices _except_ the target device. But, it doesn't tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO case, this can result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones after future entries (in the walk) have been deleted. Opportunistically add curly braces to the for-loop, which encompasses many lines but sneaks by without braces due to the guts being a single if statement.

Published: 2024-02-29Modified: 2025-04-08
CVSS 3.xMEDIUM 6.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-47061
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid.

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47063
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm: bridge/panel: Cleanup connector on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47064
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: mt76: fix potential DMA mapping leak With buf uninitialized in mt76_dma_tx_queue_skb_raw, its field skip_unmap could potentially inherit a non-zero value from stack garbage. If this happens, it will cause DMA mappings for MCU command frames to not be unmapped after completion

Published: 2024-02-29Modified: 2025-04-08
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2021-47065
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: rtw88: Fix array overrun in rtw_get_tx_power_params() Using a kernel with the Undefined Behaviour Sanity Checker (UBSAN) enabled, the following array overrun is logged: ================================================================================ UBSAN: array-index-out-of-bounds in /home/finger/wireless-drivers-next/drivers/net/wireless/realtek/rtw88/phy.c:1789:34 index 5 is out of range for type 'u8 [5]' CPU: 2 PID: 84 Comm: kworker/u16:3 Tainted: G O 5.12.0-rc5-00086-gd88bba47038e-dirty #651 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50 09/29/2014 Workqueue: phy0 ieee80211_scan_work [mac80211] Call Trace: dump_stack+0x64/0x7c ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold+0x43/0x48 rtw_get_tx_power_params+0x83a/drivers/net/wireless/realtek/rtw88/0xad0 [rtw_core] ? rtw_pci_read16+0x20/0x20 [rtw_pci] ? check_hw_ready+0x50/0x90 [rtw_core] rtw_phy_get_tx_power_index+0x4d/0xd0 [rtw_core] rtw_phy_set_tx_power_level+0xee/0x1b0 [rtw_core] rtw_set_channel+0xab/0x110 [rtw_core] rtw_ops_config+0x87/0xc0 [rtw_core] ieee80211_hw_config+0x9d/0x130 [mac80211] ieee80211_scan_state_set_channel+0x81/0x170 [mac80211] ieee80211_scan_work+0x19f/0x2a0 [mac80211] process_one_work+0x1dd/0x3a0 worker_thread+0x49/0x330 ? rescuer_thread+0x3a0/0x3a0 kthread+0x134/0x150 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x30 ================================================================================ The statement where an array is being overrun is shown in the following snippet: if (rate <= DESC_RATE11M) tx_power = pwr_idx_2g->cck_base[group]; else ====> tx_power = pwr_idx_2g->bw40_base[group]; The associated arrays are defined in main.h as follows: struct rtw_2g_txpwr_idx { u8 cck_base[6]; u8 bw40_base[5]; struct rtw_2g_1s_pwr_idx_diff ht_1s_diff; struct rtw_2g_ns_pwr_idx_diff ht_2s_diff; struct rtw_2g_ns_pwr_idx_diff ht_3s_diff; struct rtw_2g_ns_pwr_idx_diff ht_4s_diff; }; The problem arises because the value of group is 5 for channel 14. The trivial increase in the dimension of bw40_base fails as this struct must match the layout of efuse. The fix is to add the rate as an argument to rtw_get_channel_group() and set the group for channel 14 to 4 if rate <= DESC_RATE11M. This patch fixes commit fa6dfe6bff24 ("rtw88: resolve order of tx power setting routines")

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47066
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: async_xor: increase src_offs when dropping destination page Now we support sharing one page if PAGE_SIZE is not equal stripe size. To support this, it needs to support calculating xor value with different offsets for each r5dev. One offset array is used to record those offsets. In RMW mode, parity page is used as a source page. It sets ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5. So it needs to add src_list and src_offs at the same time. Now it only needs src_list. So the xor value which is calculated is wrong. It can cause data corruption problem. I can reproduce this problem 100% on a POWER8 machine. The steps are: mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G mkfs.xfs /dev/md0 mount /dev/md0 /mnt/test mount: /mnt/test: mount(2) system call failed: Structure needs cleaning.

Published: 2024-02-29Modified: 2025-01-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47067
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soc/tegra: regulators: Fix locking up when voltage-spread is out of range Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree.

Published: 2024-02-29Modified: 2024-12-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47068
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/nfc: fix use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134.

Published: 2024-02-29Modified: 2025-04-22
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47069
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send. This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash: RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343 The race occurs as: 1. do_mq_timedreceive calls wq_sleep with the address of `struct ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it holds a valid `struct ext_wait_queue *` as long as the stack has not been overwritten. 2. `ewq_addr` gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op. 3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (`this` is `ewq_addr`.) 4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see `state == STATE_READY` and break. 5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive's stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.) 6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a `struct ext_wait_queue *`, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwritten `ewq_addr` yet, `ewq_addr->task` is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver's task_struct causing the crash. do_mq_timedsend::__pipelined_op() should not dereference `this` after setting STATE_READY, as the receiver counterpart is now free to return. Change __pipelined_op to call wake_q_add_safe on the receiver's task_struct returned by get_task_struct, instead of dereferencing `this` which sits on the receiver's stack. As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way.

Published: 2024-03-01Modified: 2025-01-09
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47071
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix a memory leak in error handling paths If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and 'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer. In such a case, we need to free the buffer explicitly.

Published: 2024-03-01Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47073
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the same condition the register happens to fix this.

Published: 2024-03-01Modified: 2025-01-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47074
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nvme-loop: fix memory leak in nvme_loop_create_ctrl() When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the "out" label.

Published: 2024-03-01Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47075
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: nvmet: fix memory leak in nvmet_alloc_ctrl() When creating ctrl in nvmet_alloc_ctrl(), if the cntlid_min is larger than cntlid_max of the subsystem, and jumps to the "out_free_changed_ns_list" label, but the ctrl->sqs lack of be freed. Fix this by jumping to the "out_free_sqs" label.

Published: 2024-03-01Modified: 2025-03-19
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2021-47077
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Add pointer checks in qedf_update_link_speed() The following trace was observed: [ 14.042059] Call Trace: [ 14.042061] [ 14.042068] qedf_link_update+0x144/0x1f0 [qedf] [ 14.042117] qed_link_update+0x5c/0x80 [qed] [ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed] [ 14.042155] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042170] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042186] ? qed_rd+0x13/0x40 [qed] [ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed] [ 14.042221] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed] [ 14.042245] tasklet_action_common.isra.14+0x5a/0x100 [ 14.042250] __do_softirq+0xe4/0x2f8 [ 14.042253] irq_exit+0xf7/0x100 [ 14.042255] do_IRQ+0x7f/0xd0 [ 14.042257] common_interrupt+0xf/0xf [ 14.042259] API qedf_link_update() is getting called from QED but by that time shost_data is not initialised. This results in a NULL pointer dereference when we try to dereference shost_data while updating supported_speeds. Add a NULL pointer check before dereferencing shost_data.

Published: 2024-03-01Modified: 2024-12-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47078
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Clear all QP fields if creation failed rxe_qp_do_cleanup() relies on valid pointer values in QP for the properly created ones, but in case rxe_qp_from_init() failed it was filled with garbage and caused tot the following error. refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800 R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put include/linux/kref.h:64 [inline] rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805 execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327 rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391 kref_put include/linux/kref.h:65 [inline] rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425 _ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline] ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231 ib_create_qp include/rdma/ib_verbs.h:3644 [inline] create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline] ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717 enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ib_register_device drivers/infiniband/core/device.c:1413 [inline] ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365 rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0 ---truncated---

Published: 2024-03-01Modified: 2025-03-19
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
References
CVE-2021-47080
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Prevent divide-by-zero error triggered by the user The user_entry_size is supplied by the user and later used as a denominator to calculate number of entries. The zero supplied by the user will trigger the following divide-by-zero error: divide error: 0000 [#1] SMP KASAN PTI CPU: 4 PID: 497 Comm: c_repro Not tainted 5.13.0-rc1+ #281 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ib_uverbs_handler_UVERBS_METHOD_QUERY_GID_TABLE+0x1b1/0x510 Code: 87 59 03 00 00 e8 9f ab 1e ff 48 8d bd a8 00 00 00 e8 d3 70 41 ff 44 0f b7 b5 a8 00 00 00 e8 86 ab 1e ff 31 d2 4c 89 f0 31 ff <49> f7 f5 48 89 d6 48 89 54 24 10 48 89 04 24 e8 1b ad 1e ff 48 8b RSP: 0018:ffff88810416f828 EFLAGS: 00010246 RAX: 0000000000000008 RBX: 1ffff1102082df09 RCX: ffffffff82183f3d RDX: 0000000000000000 RSI: ffff888105f2da00 RDI: 0000000000000000 RBP: ffff88810416fa98 R08: 0000000000000001 R09: ffffed102082df5f R10: ffff88810416faf7 R11: ffffed102082df5e R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000008 R15: ffff88810416faf0 FS: 00007f5715efa740(0000) GS:ffff88811a700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000840 CR3: 000000010c2e0001 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ib_uverbs_handler_UVERBS_METHOD_INFO_HANDLES+0x4b0/0x4b0 ib_uverbs_cmd_verbs+0x1546/0x1940 ib_uverbs_ioctl+0x186/0x240 __x64_sys_ioctl+0x38a/0x1220 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae

Published: 2024-03-01Modified: 2024-12-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47136
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: zero-initialize tc skb extension on allocation Function skb_ext_add() doesn't initialize created skb extension with any value and leaves it up to the user. However, since extension of type TC_SKB_EXT originally contained only single value tc_skb_ext->chain its users used to just assign the chain value without setting whole extension memory to zero first. This assumption changed when TC_SKB_EXT extension was extended with additional fields but not all users were updated to initialize the new fields which leads to use of uninitialized memory afterwards. UBSAN log: [ 778.299821] UBSAN: invalid-load in net/openvswitch/flow.c:899:28 [ 778.301495] load of value 107 is not a valid value for type '_Bool' [ 778.303215] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7+ #2 [ 778.304933] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 778.307901] Call Trace: [ 778.308680] [ 778.309358] dump_stack+0xbb/0x107 [ 778.310307] ubsan_epilogue+0x5/0x40 [ 778.311167] __ubsan_handle_load_invalid_value.cold+0x43/0x48 [ 778.312454] ? memset+0x20/0x40 [ 778.313230] ovs_flow_key_extract.cold+0xf/0x14 [openvswitch] [ 778.314532] ovs_vport_receive+0x19e/0x2e0 [openvswitch] [ 778.315749] ? ovs_vport_find_upcall_portid+0x330/0x330 [openvswitch] [ 778.317188] ? create_prof_cpu_mask+0x20/0x20 [ 778.318220] ? arch_stack_walk+0x82/0xf0 [ 778.319153] ? secondary_startup_64_no_verify+0xb0/0xbb [ 778.320399] ? stack_trace_save+0x91/0xc0 [ 778.321362] ? stack_trace_consume_entry+0x160/0x160 [ 778.322517] ? lock_release+0x52e/0x760 [ 778.323444] netdev_frame_hook+0x323/0x610 [openvswitch] [ 778.324668] ? ovs_netdev_get_vport+0xe0/0xe0 [openvswitch] [ 778.325950] __netif_receive_skb_core+0x771/0x2db0 [ 778.327067] ? lock_downgrade+0x6e0/0x6f0 [ 778.328021] ? lock_acquire+0x565/0x720 [ 778.328940] ? generic_xdp_tx+0x4f0/0x4f0 [ 778.329902] ? inet_gro_receive+0x2a7/0x10a0 [ 778.330914] ? lock_downgrade+0x6f0/0x6f0 [ 778.331867] ? udp4_gro_receive+0x4c4/0x13e0 [ 778.332876] ? lock_release+0x52e/0x760 [ 778.333808] ? dev_gro_receive+0xcc8/0x2380 [ 778.334810] ? lock_downgrade+0x6f0/0x6f0 [ 778.335769] __netif_receive_skb_list_core+0x295/0x820 [ 778.336955] ? process_backlog+0x780/0x780 [ 778.337941] ? mlx5e_rep_tc_netdevice_event_unregister+0x20/0x20 [mlx5_core] [ 778.339613] ? seqcount_lockdep_reader_access.constprop.0+0xa7/0xc0 [ 778.341033] ? kvm_clock_get_cycles+0x14/0x20 [ 778.342072] netif_receive_skb_list_internal+0x5f5/0xcb0 [ 778.343288] ? __kasan_kmalloc+0x7a/0x90 [ 778.344234] ? mlx5e_handle_rx_cqe_mpwrq+0x9e0/0x9e0 [mlx5_core] [ 778.345676] ? mlx5e_xmit_xdp_frame_mpwqe+0x14d0/0x14d0 [mlx5_core] [ 778.347140] ? __netif_receive_skb_list_core+0x820/0x820 [ 778.348351] ? mlx5e_post_rx_mpwqes+0xa6/0x25d0 [mlx5_core] [ 778.349688] ? napi_gro_flush+0x26c/0x3c0 [ 778.350641] napi_complete_done+0x188/0x6b0 [ 778.351627] mlx5e_napi_poll+0x373/0x1b80 [mlx5_core] [ 778.352853] __napi_poll+0x9f/0x510 [ 778.353704] ? mlx5_flow_namespace_set_mode+0x260/0x260 [mlx5_core] [ 778.355158] net_rx_action+0x34c/0xa40 [ 778.356060] ? napi_threaded_poll+0x3d0/0x3d0 [ 778.357083] ? sched_clock_cpu+0x18/0x190 [ 778.358041] ? __common_interrupt+0x8e/0x1a0 [ 778.359045] __do_softirq+0x1ce/0x984 [ 778.359938] __irq_exit_rcu+0x137/0x1d0 [ 778.360865] irq_exit_rcu+0xa/0x20 [ 778.361708] common_interrupt+0x80/0xa0 [ 778.362640] [ 778.363212] asm_common_interrupt+0x1e/0x40 [ 778.364204] RIP: 0010:native_safe_halt+0xe/0x10 [ 778.365273] Code: 4f ff ff ff 4c 89 e7 e8 50 3f 40 fe e9 dc fe ff ff 48 89 df e8 43 3f 40 fe eb 90 cc e9 07 00 00 00 0f 00 2d 74 05 62 00 fb f4 90 e9 07 00 00 00 0f 00 2d 64 05 62 00 f4 c3 cc cc 0f 1f 44 00 [ 778.369355] RSP: 0018:ffffffff84407e48 EFLAGS: 00000246 [ 778.370570] RAX ---truncated---

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47137
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: lantiq: fix memory corruption in RX ring In a situation where memory allocation or dma mapping fails, an invalid address is programmed into the descriptor. This can lead to memory corruption. If the memory allocation fails, DMA should reuse the previous skb and mapping and drop the packet. This patch also increments rx drop counter.

Published: 2024-03-25Modified: 2025-03-19
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2021-47138
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: cxgb4: avoid accessing registers when clearing filters Hardware register having the server TID base can contain invalid values when adapter is in bad state (for example, due to AER fatal error). Reading these invalid values in the register can lead to out-of-bound memory access. So, fix by using the saved server TID base when clearing filters.

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-47139
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hns3: put off calling register_netdev() until client initialize complete Currently, the netdevice is registered before client initializing complete. So there is a timewindow between netdevice available and usable. In this case, if user try to change the channel number or ring param, it may cause the hns3_set_rx_cpu_rmap() being called twice, and report bug. [47199.416502] hns3 0000:35:00.0 eth1: set channels: tqp_num=1, rxfh=0 [47199.430340] hns3 0000:35:00.0 eth1: already uninitialized [47199.438554] hns3 0000:35:00.0: rss changes from 4 to 1 [47199.511854] hns3 0000:35:00.0: Channels changed, rss_size from 4 to 1, tqps from 4 to 1 [47200.163524] ------------[ cut here ]------------ [47200.171674] kernel BUG at lib/cpu_rmap.c:142! [47200.177847] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [47200.185259] Modules linked in: hclge(+) hns3(-) hns3_cae(O) hns_roce_hw_v2 hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [last unloaded: hclge] [47200.205912] CPU: 1 PID: 8260 Comm: ethtool Tainted: G O 5.11.0-rc3+ #1 [47200.215601] Hardware name: , xxxxxx 02/04/2021 [47200.223052] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [47200.230188] pc : cpu_rmap_add+0x38/0x40 [47200.237472] lr : irq_cpu_rmap_add+0x84/0x140 [47200.243291] sp : ffff800010e93a30 [47200.247295] x29: ffff800010e93a30 x28: ffff082100584880 [47200.254155] x27: 0000000000000000 x26: 0000000000000000 [47200.260712] x25: 0000000000000000 x24: 0000000000000004 [47200.267241] x23: ffff08209ba03000 x22: ffff08209ba038c0 [47200.273789] x21: 000000000000003f x20: ffff0820e2bc1680 [47200.280400] x19: ffff0820c970ec80 x18: 00000000000000c0 [47200.286944] x17: 0000000000000000 x16: ffffb43debe4a0d0 [47200.293456] x15: fffffc2082990600 x14: dead000000000122 [47200.300059] x13: ffffffffffffffff x12: 000000000000003e [47200.306606] x11: ffff0820815b8080 x10: ffff53e411988000 [47200.313171] x9 : 0000000000000000 x8 : ffff0820e2bc1700 [47200.319682] x7 : 0000000000000000 x6 : 000000000000003f [47200.326170] x5 : 0000000000000040 x4 : ffff800010e93a20 [47200.332656] x3 : 0000000000000004 x2 : ffff0820c970ec80 [47200.339168] x1 : ffff0820e2bc1680 x0 : 0000000000000004 [47200.346058] Call trace: [47200.349324] cpu_rmap_add+0x38/0x40 [47200.354300] hns3_set_rx_cpu_rmap+0x6c/0xe0 [hns3] [47200.362294] hns3_reset_notify_init_enet+0x1cc/0x340 [hns3] [47200.370049] hns3_change_channels+0x40/0xb0 [hns3] [47200.376770] hns3_set_channels+0x12c/0x2a0 [hns3] [47200.383353] ethtool_set_channels+0x140/0x250 [47200.389772] dev_ethtool+0x714/0x23d0 [47200.394440] dev_ioctl+0x4cc/0x640 [47200.399277] sock_do_ioctl+0x100/0x2a0 [47200.404574] sock_ioctl+0x28c/0x470 [47200.409079] __arm64_sys_ioctl+0xb4/0x100 [47200.415217] el0_svc_common.constprop.0+0x84/0x210 [47200.422088] do_el0_svc+0x28/0x34 [47200.426387] el0_svc+0x28/0x70 [47200.431308] el0_sync_handler+0x1a4/0x1b0 [47200.436477] el0_sync+0x174/0x180 [47200.441562] Code: 11000405 79000c45 f8247861 d65f03c0 (d4210000) [47200.448869] ---[ end trace a01efe4ce42e5f34 ]--- The process is like below: excuting hns3_client_init | register_netdev() | hns3_set_channels() | | hns3_set_rx_cpu_rmap() hns3_reset_notify_uninit_enet() | | | quit without calling function | hns3_free_rx_cpu_rmap for flag | HNS3_NIC_STATE_INITED is unset. | | | hns3_reset_notify_init_enet() | | set HNS3_NIC_STATE_INITED call hns3_set_rx_cpu_rmap()-- crash Fix it by calling register_netdev() at the end of function hns3_client_init().

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47141
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: gve: Add NULL pointer checks when freeing irqs. When freeing notification blocks, we index priv->msix_vectors. If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors) this could lead to a NULL pointer dereference if the driver is unloaded.

Published: 2024-03-25Modified: 2024-12-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47142
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix a use-after-free looks like we forget to set ttm->sg to NULL. Hit panic below [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.989074] Call Trace: [ 1235.991751] sg_free_table+0x17/0x20 [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu]

Published: 2024-03-25Modified: 2024-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47143
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/smc: remove device from smcd_dev_list after failed device_add() If the device_add() for a smcd_dev fails, there's no cleanup step that rolls back the earlier list_add(). The device subsequently gets freed, and we end up with a corrupted list. Add some error handling that removes the device from the list.

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47145
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON in link_to_fixup_dir While doing error injection testing I got the following panic kernel BUG at fs/btrfs/tree-log.c:1862! invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:link_to_fixup_dir+0xd5/0xe0 RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216 RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0 RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000 RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001 R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800 R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065 FS: 00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0 Call Trace: replay_one_buffer+0x409/0x470 ? btree_read_extent_buffer_pages+0xd0/0x110 walk_up_log_tree+0x157/0x1e0 walk_log_tree+0xa6/0x1d0 btrfs_recover_log_trees+0x1da/0x360 ? replay_one_extent+0x7b0/0x7b0 open_ctree+0x1486/0x1720 btrfs_mount_root.cold+0x12/0xea ? __kmalloc_track_caller+0x12f/0x240 legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 ? vfs_parse_fs_string+0x4d/0x90 legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 path_mount+0x433/0xa10 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae We can get -EIO or any number of legitimate errors from btrfs_search_slot(), panicing here is not the appropriate response. The error path for this code handles errors properly, simply return the error.

Published: 2024-03-25Modified: 2024-12-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47146
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mld: fix panic in mld_newpack() mld_newpack() doesn't allow to allocate high order page, only order-0 allocation is allowed. If headroom size is too large, a kernel panic could occur in skb_put(). Test commands: ip netns del A ip netns del B ip netns add A ip netns add B ip link add veth0 type veth peer name veth1 ip link set veth0 netns A ip link set veth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set veth0 up ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0 ip netns exec B ip link set lo up ip netns exec B ip link set veth1 up ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1 for i in {1..99} do let A=$i-1 ip netns exec A ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100 ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i ip netns exec A ip link set ip6gre$i up ip netns exec B ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100 ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i ip netns exec B ip link set ip6gre$i up done Splat looks like: kernel BUG at net/core/skbuff.c:110! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x15d/0x15f Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83 41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20 RSP: 0018:ffff88810091f820 EFLAGS: 00010282 RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000 RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031 R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028 R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0 FS: 0000000000000000(0000) GS:ffff888117c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 skb_put.cold.104+0x22/0x22 ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? rcu_read_lock_sched_held+0x91/0xc0 mld_newpack+0x398/0x8f0 ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600 ? lock_contended+0xc40/0xc40 add_grhead.isra.33+0x280/0x380 add_grec+0x5ca/0xff0 ? mld_sendpack+0xf40/0xf40 ? lock_downgrade+0x690/0x690 mld_send_initial_cr.part.34+0xb9/0x180 ipv6_mc_dad_complete+0x15d/0x1b0 addrconf_dad_completed+0x8d2/0xbb0 ? lock_downgrade+0x690/0x690 ? addrconf_rs_timer+0x660/0x660 ? addrconf_dad_work+0x73c/0x10e0 addrconf_dad_work+0x73c/0x10e0 Allowing high order page allocation could fix this problem.

Published: 2024-03-25Modified: 2024-12-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47149
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: fujitsu: fix potential null-ptr-deref In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer deref. To fix this, check the return value of ioremap and return -1 to the caller in case of failure.

Published: 2024-03-25Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47150
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: fec: fix the potential memory leak in fec_enet_init() If the memory allocated for cbd_base is failed, it should free the memory allocated for the queues, otherwise it causes memory leak. And if the memory allocated for the queues is failed, it can return error directly.

Published: 2024-03-25Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47151
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: interconnect: qcom: bcm-voter: add a missing of_node_put() Add a missing of_node_put() in of_bcm_voter_get() to avoid the reference leak.

Published: 2024-03-25Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47152
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data stream corruption Maxim reported several issues when forcing a TCP transparent proxy to use the MPTCP protocol for the inbound connections. He also provided a clean reproducer. The problem boils down to 'mptcp_frag_can_collapse_to()' assuming that only MPTCP will use the given page_frag. If others - e.g. the plain TCP protocol - allocate page fragments, we can end-up re-using already allocated memory for mptcp_data_frag. Fix the issue ensuring that the to-be-expanded data fragment is located at the current page frag end. v1 -> v2: - added missing fixes tag (Mat)

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47153
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot: https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction.

Published: 2024-03-25Modified: 2025-09-16
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-47158
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: add error handling in sja1105_setup() If any of sja1105_static_config_load(), sja1105_clocking_setup() or sja1105_devlink_setup() fails, we can't just return in the middle of sja1105_setup() or memory will leak. Add a cleanup path.

Published: 2024-03-25Modified: 2024-12-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47159
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix a crash if ->get_sset_count() fails If ds->ops->get_sset_count() fails then it "count" is a negative error code such as -EOPNOTSUPP. Because "i" is an unsigned int, the negative error code is type promoted to a very high value and the loop will corrupt memory until the system crashes. Fix this by checking for error codes and changing the type of "i" to just int.

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47160
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: net: dsa: mt7530: fix VLAN traffic leaks PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but was not reset when it is disabled, which may cause traffic leaks: ip link add br0 type bridge vlan_filtering 1 ip link add br1 type bridge vlan_filtering 1 ip link set swp0 master br0 ip link set swp1 master br1 ip link set br0 type bridge vlan_filtering 0 ip link set br1 type bridge vlan_filtering 0 # traffic in br0 and br1 will start leaking to each other As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the PCR_MATRIX write from mt7530_port_set_vlan_aware.

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-47161
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix a resource leak in an error handling path 'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the error handling path of the probe function, as already done in the remove function

Published: 2024-03-25Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47162
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tipc: skb_linearize the head skb when reassembling msgs It's not a good idea to append the frag skb to a skb's frag_list if the frag_list already has skbs from elsewhere, such as this skb was created by pskb_copy() where the frag_list was cloned (all the skbs in it were skb_get'ed) and shared by multiple skbs. However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this appended frag skb are seen by multiple skbs but it only got skb_get called once. The same thing happens with a skb updated by pskb_may_pull() with a skb_cloned skb. Li Shuang has reported quite a few crashes caused by this when doing testing over macvlan devices: [] kernel BUG at net/core/skbuff.c:1970! [] Call Trace: [] skb_clone+0x4d/0xb0 [] macvlan_broadcast+0xd8/0x160 [macvlan] [] macvlan_process_broadcast+0x148/0x150 [macvlan] [] process_one_work+0x1a7/0x360 [] worker_thread+0x30/0x390 [] kernel BUG at mm/usercopy.c:102! [] Call Trace: [] __check_heap_object+0xd3/0x100 [] __check_object_size+0xff/0x16b [] simple_copy_to_iter+0x1c/0x30 [] __skb_datagram_iter+0x7d/0x310 [] __skb_datagram_iter+0x2a5/0x310 [] skb_copy_datagram_iter+0x3b/0x90 [] tipc_recvmsg+0x14a/0x3a0 [tipc] [] ____sys_recvmsg+0x91/0x150 [] ___sys_recvmsg+0x7b/0xc0 [] kernel BUG at mm/slub.c:305! [] Call Trace: [] [] kmem_cache_free+0x3ff/0x400 [] __netif_receive_skb_core+0x12c/0xc40 [] ? kmem_cache_alloc+0x12e/0x270 [] netif_receive_skb_internal+0x3d/0xb0 [] ? get_rx_page_info+0x8e/0xa0 [be2net] [] be_poll+0x6ef/0xd00 [be2net] [] ? irq_exit+0x4f/0x100 [] net_rx_action+0x149/0x3b0 ... This patch is to fix it by linearizing the head skb if it has frag_list set in tipc_buf_append(). Note that we choose to do this before calling skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can not just drop the frag_list either as the early time.

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47163
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tipc: wait and exit until all work queues are done On some host, a crash could be triggered simply by repeating these commands several times: # modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc [] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ? create_worker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? kthread_flush_work_fn+0x10/0x10 [] ? ret_from_fork+0x35/0x40 When removing the TIPC module, the UDP tunnel sock will be delayed to release in a work queue as sock_release() can't be done in rtnl_lock(). If the work queue is schedule to run after the TIPC module is removed, kernel will crash as the work queue function cleanup_beareri() code no longer exists when trying to invoke it. To fix it, this patch introduce a member wq_count in tipc_net to track the numbers of work queues in schedule, and wait and exit until all work queues are done in tipc_exit_net().

Published: 2024-03-25Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47164
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix null deref accessing lag dev It could be the lag dev is null so stop processing the event. In bond_enslave() the active/backup slave being set before setting the upper dev so first event is without an upper dev. After setting the upper dev with bond_master_upper_dev_link() there is a second event and in that event we have an upper dev.

Published: 2024-03-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47165
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix shutdown crash when component not probed When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... pc : meson_drv_shutdown+0x24/0x50 lr : platform_drv_shutdown+0x20/0x30 ... Call trace: meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x30 device_shutdown+0x158/0x360 kernel_restart_prepare+0x38/0x48 kernel_restart+0x18/0x68 __do_sys_reboot+0x224/0x250 __arm64_sys_reboot+0x24/0x30 ... Simply check if the priv struct has been allocated before using it.

Published: 2024-03-25Modified: 2025-03-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47166
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce() The value of mirror->pg_bytes_written should only be updated after a successful attempt to flush out the requests on the list.

Published: 2024-03-25Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47167
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: NFS: Fix an Oopsable condition in __nfs_pageio_add_request() Ensure that nfs_pageio_error_cleanup() resets the mirror array contents, so that the structure reflects the fact that it is now empty. Also change the test in nfs_pageio_do_add_request() to be more robust by checking whether or not the list is empty rather than relying on the value of pg_count.

Published: 2024-03-25Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47168
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: NFS: fix an incorrect limit in filelayout_decode_layout() The "sizeof(struct nfs_fh)" is two bytes too large and could lead to memory corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer. I reversed the size of the arguments to put the variable on the left.

Published: 2024-03-25Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47169
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait' In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the firmware don't exists, function just return without initializing ports of 'rp2_card'. But now the interrupt handler function has been registered, and when an interrupt comes, 'rp2_uart_interrupt' may access those ports then causing NULL pointer dereference or other bugs. Because the driver does some initialization work in 'rp2_fw_cb', in order to make the driver ready to handle interrupts, 'request_firmware' should be used instead of asynchronous 'request_firmware_nowait'. This report reveals it: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 assign_lock_key kernel/locking/lockdep.c:727 [inline] register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline] rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline] RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Co ---truncated---

Published: 2024-03-25Modified: 2025-03-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47170
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: USB: usbfs: Don't WARN about excessively large memory allocations Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers.

Published: 2024-03-25Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47171
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: usb: fix memory leak in smsc75xx_bind Syzbot reported memory leak in smsc75xx_bind(). The problem was is non-freed memory in case of errors after memory allocation. backtrace: [] kmalloc include/linux/slab.h:556 [inline] [] kzalloc include/linux/slab.h:686 [inline] [] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728

Published: 2024-03-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47172
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers Channel numbering must start at 0 and then not have any holes, or it is possible to overflow the available storage. Note this bug was introduced as part of a fix to ensure we didn't rely on the ordering of child nodes. So we need to support arbitrary ordering but they all need to be there somewhere. Note I hit this when using qemu to test the rest of this series. Arguably this isn't the best fix, but it is probably the most minimal option for backporting etc. Alexandru's sign-off is here because he carried this patch in a larger set that Jonathan then applied.

Published: 2024-03-25Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47173
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: misc/uss720: fix memory leak in uss720_probe uss720_probe forgets to decrease the refcount of usbdev in uss720_probe. Fix this by decreasing the refcount of usbdev by usb_put_dev. BUG: memory leak unreferenced object 0xffff888101113800 (size 2048): comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s) hex dump (first 32 bytes): ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1........... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................ backtrace: [] kmalloc include/linux/slab.h:554 [inline] [] kzalloc include/linux/slab.h:684 [inline] [] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582 [] hub_port_connect drivers/usb/core/hub.c:5129 [inline] [] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] [] port_event drivers/usb/core/hub.c:5509 [inline] [] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275 [] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421 [] kthread+0x178/0x1b0 kernel/kthread.c:292 [] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

Published: 2024-03-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47174
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: Add irq_fpu_usable() check, fallback to non-AVX2 version Arturo reported this backtrace: [709732.358791] WARNING: CPU: 3 PID: 456 at arch/x86/kernel/fpu/core.c:128 kernel_fpu_begin_mask+0xae/0xe0 [709732.358793] Modules linked in: binfmt_misc nft_nat nft_chain_nat nf_nat nft_counter nft_ct nf_tables nf_conntrack_netlink nfnetlink 8021q garp stp mrp llc vrf intel_rapl_msr intel_rapl_common skx_edac nfit libnvdimm ipmi_ssif x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul mgag200 ghash_clmulni_intel drm_kms_helper cec aesni_intel drm libaes crypto_simd cryptd glue_helper mei_me dell_smbios iTCO_wdt evdev intel_pmc_bxt iTCO_vendor_support dcdbas pcspkr rapl dell_wmi_descriptor wmi_bmof sg i2c_algo_bit watchdog mei acpi_ipmi ipmi_si button nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor sd_mod t10_pi crc_t10dif crct10dif_generic raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod ahci libahci tg3 libata xhci_pci libphy xhci_hcd ptp usbcore crct10dif_pclmul crct10dif_common bnxt_en crc32c_intel scsi_mod [709732.358941] pps_core i2c_i801 lpc_ich i2c_smbus wmi usb_common [709732.358957] CPU: 3 PID: 456 Comm: jbd2/dm-0-8 Not tainted 5.10.0-0.bpo.5-amd64 #1 Debian 5.10.24-1~bpo10+1 [709732.358959] Hardware name: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.9.3 09/23/2020 [709732.358964] RIP: 0010:kernel_fpu_begin_mask+0xae/0xe0 [709732.358969] Code: ae 54 24 04 83 e3 01 75 38 48 8b 44 24 08 65 48 33 04 25 28 00 00 00 75 33 48 83 c4 10 5b c3 65 8a 05 5e 21 5e 76 84 c0 74 92 <0f> 0b eb 8e f0 80 4f 01 40 48 81 c7 00 14 00 00 e8 dd fb ff ff eb [709732.358972] RSP: 0018:ffffbb9700304740 EFLAGS: 00010202 [709732.358976] RAX: 0000000000000001 RBX: 0000000000000003 RCX: 0000000000000001 [709732.358979] RDX: ffffbb9700304970 RSI: ffff922fe1952e00 RDI: 0000000000000003 [709732.358981] RBP: ffffbb9700304970 R08: ffff922fc868a600 R09: ffff922fc711e462 [709732.358984] R10: 000000000000005f R11: ffff922ff0b27180 R12: ffffbb9700304960 [709732.358987] R13: ffffbb9700304b08 R14: ffff922fc664b6c8 R15: ffff922fc664b660 [709732.358990] FS: 0000000000000000(0000) GS:ffff92371fec0000(0000) knlGS:0000000000000000 [709732.358993] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [709732.358996] CR2: 0000557a6655bdd0 CR3: 000000026020a001 CR4: 00000000007706e0 [709732.358999] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [709732.359001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [709732.359003] PKRU: 55555554 [709732.359005] Call Trace: [709732.359009] [709732.359035] nft_pipapo_avx2_lookup+0x4c/0x1cba [nf_tables] [709732.359046] ? sched_clock+0x5/0x10 [709732.359054] ? sched_clock_cpu+0xc/0xb0 [709732.359061] ? record_times+0x16/0x80 [709732.359068] ? plist_add+0xc1/0x100 [709732.359073] ? psi_group_change+0x47/0x230 [709732.359079] ? skb_clone+0x4d/0xb0 [709732.359085] ? enqueue_task_rt+0x22b/0x310 [709732.359098] ? bnxt_start_xmit+0x1e8/0xaf0 [bnxt_en] [709732.359102] ? packet_rcv+0x40/0x4a0 [709732.359121] nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359133] nft_do_chain+0x350/0x500 [nf_tables] [709732.359152] ? nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359163] ? nft_do_chain+0x364/0x500 [nf_tables] [709732.359172] ? fib4_rule_action+0x6d/0x80 [709732.359178] ? fib_rules_lookup+0x107/0x250 [709732.359184] nft_nat_do_chain+0x8a/0xf2 [nft_chain_nat] [709732.359193] nf_nat_inet_fn+0xea/0x210 [nf_nat] [709732.359202] nf_nat_ipv4_out+0x14/0xa0 [nf_nat] [709732.359207] nf_hook_slow+0x44/0xc0 [709732.359214] ip_output+0xd2/0x100 [709732.359221] ? __ip_finish_output+0x210/0x210 [709732.359226] ip_forward+0x37d/0x4a0 [709732.359232] ? ip4_key_hashfn+0xb0/0xb0 [709732.359238] ip_subli ---truncated---

Published: 2024-03-25Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47175
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: fix OOB access in the traffic path the following script: # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2 # tc qdisc add dev eth0 clsact # tc filter add dev eth0 egress matchall action skbedit priority 0x10002 # ping 192.0.2.2 -I eth0 -c2 -w1 -q produces the following splat: BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] Read of size 4 at addr ffff888171306924 by task ping/942 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ #441 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] __dev_queue_xmit+0x1034/0x2b10 ip_finish_output2+0xc62/0x2120 __ip_finish_output+0x553/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fe69735c3eb Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003 RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0 Allocated by task 917: kasan_save_stack+0x19/0x40 __kasan_kmalloc+0x7f/0xa0 __kmalloc_node+0x139/0x280 fq_pie_init+0x555/0x8e8 [sch_fq_pie] qdisc_create+0x407/0x11b0 tc_modify_qdisc+0x3c2/0x17e0 rtnetlink_rcv_msg+0x346/0x8e0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff888171306800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 36 bytes to the right of 256-byte region [ffff888171306800, ffff888171306900) The buggy address belongs to the page: page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306 head:00000000bcfb624e order:1 compound_mapcount:0 flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a valid flow: it's an address beyond the allocated memory.

Published: 2024-03-25Modified: 2025-03-17
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2021-47177
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix sysfs leak in alloc_iommu() iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent errors.

Published: 2024-03-25Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2021-47180
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: NFC: nci: fix memory leak in nci_allocate_device nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev. Fix this by freeing hci_dev in nci_free_device. BUG: memory leak unreferenced object 0xffff888111ea6800 (size 1024): comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline] [<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline] [<000000004bc25d43>] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784 [<00000000c59cff92>] nci_allocate_device net/nfc/nci/core.c:1170 [inline] [<00000000c59cff92>] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132 [<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153 [<000000004da1b57e>] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345 [<00000000d506aed9>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [<000000000ce658ca>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 [<000000007067d05f>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<00000000f8e13372>] __device_attach+0x122/0x250 drivers/base/dd.c:914 [<000000009cf68860>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<00000000359c965a>] device_add+0x5be/0xc30 drivers/base/core.c:3109 [<00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164 [<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<00000000d40d36f6>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554

Published: 2024-03-25Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References