ALT-PU-2021-1985-2
Package kernel-image-rt updated to version 5.10.41-alt1.rt42 for branch sisyphus in task 274368.
Closed vulnerabilities
Modified: 2024-06-03
BDU:2021-04825
Уязвимость функции bpf_ringbuf_reserve() ядра операционной системы Linux , связанная с записью за границами буфера в памяти, позволяющая нарушителю выполнить произвольный код в контексте ядра
Modified: 2024-06-03
BDU:2021-04827
Уязвимость компонент kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
Modified: 2024-06-04
BDU:2021-04830
Уязвимость ядра операционной системы Linux , позволяющая нарушителю выполнить произвольный код в контексте ядра
Modified: 2024-09-13
BDU:2021-04842
Уязвимость подсистемы eBPF ядра операционной системы Linux , связанная с чтением за границами буфера в памяти, позволяющая нарушителю выполнить произвольный код в контексте ядра
Modified: 2024-12-04
BDU:2021-04843
Уязвимость подсистемы io_uring ядра операционной системы Linux, связанная с записью за границами буфера в памяти, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2022-04604
Уязвимость функции decode_nfs_fh() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии и вызвать аварийное завершение системы
Modified: 2024-12-05
BDU:2024-01683
Уязвимость функции io_provide_buffers_prep() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных
Modified: 2026-01-20
BDU:2024-01749
Уязвимость функции drm_connector_cleanup() подсистемы Direct Rendering Manager (DRM) ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-06-18
BDU:2024-01755
Уязвимость драйвера криптографического аппаратного ускорителя sun8i-ss (drivers/crypto/allwinner/sun8i-ss) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-18
BDU:2024-01757
Уязвимость функции mt76_dma_tx_queue_skb_raw() компонента mt76 ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-12-05
BDU:2024-01763
Уязвимость функция hci_conn_get_phy драйвера Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-18
BDU:2024-01799
Уязвимость подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-18
BDU:2024-01800
Уязвимость функции kvm_io_bus_unregister_dev() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-05-13
BDU:2024-01812
Уязвимость функций llcp_sock_connect() и llcp_sock_bind() подсистемы NFC (Near Field Communication) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или раскрыть защищаемую информацию
Modified: 2024-06-18
BDU:2024-01826
Уязвимость функции rtw_get_tx_power_params() службы UBSAN (Undefined Behaviour Sanity Checker) ядра операционных систем Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-06-18
BDU:2024-01827
Уязвимость функции DVFS (Dynamic Voltage and Frequency Scaling) драйвера встраиваемых плат Tegra 30 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-18
BDU:2024-01828
Уязвимость функции regmap_debugfs_exit() ядра операционных систем Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2024-06-18
BDU:2024-01830
Уязвимость функции sii902x_init ядра операционных систем Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2024-09-16
BDU:2024-03688
Уязвимость функциях dm_mq_init_request_queue() и dm_mq_cleanup_mapped_device() в модуле drivers/md/dm-rq.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-03689
Уязвимость функции imgu_fmt() в модуле drivers/staging/media/ipu3/ipu3-v4l2.c драйвера Intel ipu3-imgu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-03690
Уязвимость функции raid1_end_write_request() в модуле drivers/md/raid1.c драйвера raid1 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-03693
Уязвимость функции nfs23_parse_monolithic() в модуле fs/nfs/fs_context.c сервера файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
BDU:2025-00799
Уязвимость функции qedf_update_link_speed() компонента drivers/scsi/qedf/qedf_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00800
Уязвимость компонента drivers/uio/uio_hv_generic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00801
Уязвимость функции lpspi_prepare_xfer_hardware() компонента drivers/spi/spi-fsl-lpspi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00802
Уязвимость функции __vmbus_open() компонента drivers/hv/channel.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00803
Уязвимость компонента drivers/nvme/target/tcp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00804
Уязвимость функции radix__set_pte_at() компонента arch/powerpc/include/asm/book3s/64/radix.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00806
Уязвимость компонента net/vmw_vsock/virtio_transport_common.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-00807
Уязвимость ядра операционной системы Linux, связанная с неправильным освобождением памяти перед удалением последней ссылки, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00808
Уязвимость функции siw_alloc_mr() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-00809
Уязвимость функции tcp_set_default_congestion_control() компонента net/ipv4/tcp_cong.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00810
Уязвимость функции enic_hard_start_xmit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00811
Уязвимость функции i40e_client_subtask() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00812
Уязвимость функции hfsplus_file_truncate() компонента fs/hfsplus/extents.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-00813
Уязвимость ядра операционной системы Linux, связанная с непроверенным индексированием массива, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00814
Уязвимость функции nbd_disconnect_and_put() компонента /drivers/block/nbd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00818
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00821
Уязвимость компонента drivers/irqchip/irq-gic-v3.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00822
Уязвимость компонента fs/cifs/smb2ops.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00823
Уязвимость компонента fs/fuse/virtio_fs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-09
BDU:2025-00824
Уязвимость компонента net/openvswitch/actions.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00827
Уязвимость компонента drivers/acpi/arm64/gtdt.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00828
Уязвимость функции imgu_fmt() компонента drivers/staging/media/ipu3/ipu3-v4l2.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00829
Уязвимость компонента drivers/usb/dwc3/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00833
Уязвимость компонента drivers/media/platform/aspeed-video.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00835
Уязвимость компонента drivers/i2c/busses/i2c-img-scb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-00836
Уязвимость компонента drivers/i2c/busses/i2c-imx-lpi2c.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-02847
Уязвимость функции qcom_mhi_qrtr_send() модуля net/qrtr/mhi.c поддержки маршрутизатора Qualcomm IPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-02848
Уязвимость функции atomisp_alloc_css_stat_bufs() модуля drivers/staging/media/atomisp/pci/atomisp_ioctl.c - драйвера поддержки устройств линейки Intel Atom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02851
Уязвимость функции devm_spi_alloc_master() модуля drivers/spi/spi.c - драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-02853
Уязвимость функции nested_get_evmcs_page() модуля arch/x86/kvm/vmx/nested.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-02854
Уязвимость функции bt1_rom_map_copy_from() модуля drivers/mtd/maps/physmap-bt1-rom.c - драйвера поддержки доступа к устройствам памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность.
BDU:2025-02855
Уязвимость функции ucsi_unregister_altmodes() модуля drivers/usb/typec/ucsi/ucsi.c - драйвера поддержки интерфейса системного программного обеспечения разъема USB Type- C ( UCSI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02856
Уязвимость функции cpu_power_to_freq() модуля drivers/thermal/cpufreq_cooling.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-02857
Уязвимость функции dvb_media_device_free() модуля drivers/media/dvb-core/dvbdev.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02858
Уязвимость функции xiic_xfer() модуля drivers/i2c/busses/i2c-xiic.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
BDU:2025-02859
Уязвимость функции stm32f7_i2c_xfer() модуля drivers/i2c/busses/i2c-stm32f7.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
BDU:2025-02860
Уязвимость функции i2c_imx_xfer() модуля drivers/i2c/busses/i2c-imx.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
BDU:2025-02861
Уязвимость функции cdns_i2c_master_xfer() модуля drivers/i2c/busses/i2c-cadence.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
BDU:2025-02862
Уязвимость функции lm3554_probe() модуля drivers/staging/media/atomisp/i2c/atomisp-lm3554.c - драйвера поддержки устройств линейки Intel Atom ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
Modified: 2026-02-17
BDU:2025-02866
Уязвимость функции trace_clock_global() модуля kernel/trace/trace_clock.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02867
Уязвимость функции idx_to_offset() модуля tools/power/x86/turbostat/turbostat.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-02871
Уязвимость функции efx_farch_handle_tx_event() модуля drivers/net/ethernet/sfc/farch.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02872
Уязвимость функции efx_farch_handle_tx_flush_done() модуля drivers/net/ethernet/sfc/farch.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02873
Уязвимость функции tpm_read_log_efi() модуля drivers/char/tpm/eventlog/efi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02985
Уязвимость функции uniphier_sd_remove() модуля drivers/mmc/host/uniphier-sd.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
BDU:2025-02987
Уязвимость функции qla2xxx_mqueuecommand() модуля drivers/scsi/qla2xxx/qla_os.c - драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02990
Уязвимость функции vhost_vdpa_mmap() модуля drivers/vhost/vdpa.c - драйвера общей реализации IOTLB для vhost и vringh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-02991
Уязвимость функции zcrypt_card_unregister() модуля drivers/s390/crypto/zcrypt_card.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-02-17
BDU:2025-03846
Уязвимость функции auto_active() модуля drivers/gpu/drm/i915/i915_active.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-03848
Уязвимость функции kvm_pv_send_ipi() модуля arch/x86/include/asm/kvm_host.h на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-05164
Уязвимость функции mcp251x_stop() модуля drivers/net/can/spi/mcp251x.c - драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-05173
Уязвимость функции init_dell_smbios_wmi() модуля drivers/platform/x86/dell-smbios-wmi.c - драйвера поддержки устройств X86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05303
Уязвимость функции nvmet_rdma_send_done() модуля drivers/nvme/target/rdma.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05304
Уязвимость функции sprd_i2c_master_xfer() модуля drivers/i2c/busses/i2c-sprd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05305
Уязвимость функции cleanup_transaction() модуля fs/btrfs/transaction.c поддержки файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05306
Уязвимость функции f2fs_unlock_rpages() модуля fs/f2fs/compress.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05307
Уязвимость функции prestera_port_handle_event() модуля drivers/net/ethernet/marvell/prestera/prestera_main.c - драйвера поддержки сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю, действующему удаленно, оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-05308
Уязвимость функции sctp_sf_do_dupcook_a() модуля net/sctp/sm_statefuns.c реализации протокола SCTP (Stream Control Transmission Protocol) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-05309
Уязвимость функции emac_mac_tx_buf_send() модуля drivers/net/ethernet/qualcomm/emac/emac-mac.c - драйвера поддержки сетевых адаптеров Ethernet Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-05311
Уязвимость функции ath10k_htc_send_bundle() модуля drivers/net/wireless/ath/ath10k/htc.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-05313
Уязвимость функции rtrs_clt_remove_path_from_sysfs() модуля drivers/infiniband/ulp/rtrs/rtrs-clt.c - драйвера поддержки сервера и клиента RTRS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05314
Уязвимость структуры hdcp_cmd_is_read{} модуля drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05315
Уязвимость функции zynqmp_qspi_exec_op() модуля drivers/spi/spi-zynqmp-gqspi.c - драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05317
Уязвимость функции detach_tasks() модуля kernel/sched/fair.c поддержки системы учета ресурсов ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
BDU:2025-05318
Уязвимость функции nft_rhash_destroy() модуля net/netfilter/nft_set_hash.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05319
Уязвимость функции f2fs_get_unusable_blocks() модуля fs/f2fs/f2fs.h поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-05320
Уязвимость функции __pipelined_op() модуля ipc/mqueue.c подсистемы межпроцессного взаимодействия IPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05321
Уязвимость функции uclamp_bucket_id() модуля kernel/sched/core.c поддержки системы учета ресурсов ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-05322
Уязвимость функции acpi_device_add() модуля drivers/acpi/scan.c - драйвера поддержки ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-06525
Уязвимость функции dwc3_gadget_exit() модуля drivers/usb/dwc3/gadget.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-06527
Уязвимость функции shmem_mfill_atomic_pte() модуля mm/shmem.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-06528
Уязвимость функции do_uaccess_flush_fixups() модуля arch/powerpc/lib/feature-fixups.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06530
Уязвимость функции nf_tables_newobj() модуля net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-06531
Уязвимость функции local_daif_inherit() модуля arch/arm64/include/asm/daifflags.h поддержки платформы ARM 64-бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06533
Уязвимость функции idxd_cmd_exec() модуля drivers/dma/idxd/device.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06534
Уязвимость функции pci_epf_test_bind() модуля drivers/pci/endpoint/functions/pci-epf-test.c - драйвера поддержки утройств PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06535
Уязвимость функции breakpoint_handler() модуля arch/arm/kernel/hw_breakpoint.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06536
Уязвимость функции f2fs_resize_fs() модуля fs/f2fs/gc.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06539
Уязвимость функции tpm_seal() модуля security/keys/trusted-keys/trusted_tpm1.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-06540
Уязвимость функции drain_obj_stock() модуля mm/memcontrol.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-06541
Уязвимость функции bnxt_rx_pkt() модуля drivers/net/ethernet/broadcom/bnxt/bnxt.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-06542
Уязвимость функции mvme147_timer_int() модуля arch/m68k/mvme147/config.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06544
Уязвимость функции __set_fixmap() модуля arch/powerpc/include/asm/book3s/64/pgtable.h поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06547
Уязвимость функции mt7615_unregister_device() модуля drivers/net/wireless/mediatek/mt76/mt7615/pci_init.c - драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-07252
Уязвимость функции mt7915_txp_skb_unmap() модуля drivers/net/wireless/mediatek/mt76/mt7915/mac.c - драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-07253
Уязвимость функции mt7615_txp_skb_unmap_fw() модуля drivers/net/wireless/mediatek/mt76/mt7615/mac.c - драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-07254
Уязвимость функции __domain_mapping() модуля drivers/iommu/intel/iommu.c - драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и конфиденциальность защищаемой информации
BDU:2025-07256
Уязвимость функции venus_probe() модуля drivers/media/platform/qcom/venus/core.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-07258
Уязвимость функции zynqmp_qspi_irq() модуля drivers/spi/spi-zynqmp-gqspi.c - драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-07259
Уязвимость функции rpcif_sw_init() модуля drivers/memory/renesas-rpc-if.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07260
Уязвимость функции sa_run() модуля drivers/crypto/sa2ul.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-07261
Уязвимость функции sun8i_ss_hash_run() модуля drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-07262
Уязвимость функции qcom_ebi2_probe() модуля drivers/bus/qcom-ebi2.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07263
Уязвимость функции mtdchar_ioctl() модуля drivers/mtd/mtdchar.c - драйвера поддержки устройств памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07264
Уязвимость функции adf_probe() модуля drivers/crypto/qat/qat_c3xxxvf/adf_drv.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07265
Уязвимость функции sun8i_ss_prng_generate() модуля drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07266
Уязвимость функции nvme_loop_create_ctrl() модуля drivers/nvme/target/loop.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-07268
Уязвимость функции ib_uverbs_handler_5() модуля drivers/infiniband/core/uverbs_std_types_device.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-25
BDU:2025-07272
Уязвимость функции nvmet_alloc_ctrl() модуля drivers/nvme/target/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07274
Уязвимость функции rxe_qp_init_req() модуля drivers/infiniband/sw/rxe/rxe_qp.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-07276
Уязвимость функции rpcrdma_reply_handler() модуля net/sunrpc/xprtrdma/rpc_rdma.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07368
Уязвимость функции nci_core_conn_create() модуля include/net/nfc/nci_core.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13605
Уязвимость функции __fh_to_dentry() модуля fs/ceph/export.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2024-11-21
CVE-2020-36776
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:
[
- https://git.kernel.org/stable/c/34ab17cc6c2c1ac93d7e5d53bb972df9a968f085
- https://git.kernel.org/stable/c/6bf443acf6ca4f666d0e4225614ba9993a3aa1a9
- https://git.kernel.org/stable/c/876a5f33e5d961d879c5436987c09b3d9ef70379
- https://git.kernel.org/stable/c/c24a20912eef00587416628149c438e885eb1304
- https://git.kernel.org/stable/c/34ab17cc6c2c1ac93d7e5d53bb972df9a968f085
- https://git.kernel.org/stable/c/6bf443acf6ca4f666d0e4225614ba9993a3aa1a9
- https://git.kernel.org/stable/c/876a5f33e5d961d879c5436987c09b3d9ef70379
- https://git.kernel.org/stable/c/c24a20912eef00587416628149c438e885eb1304
Modified: 2024-11-21
CVE-2020-36777
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."
- https://git.kernel.org/stable/c/06854b943e0571ccbd7ad0a529babed1a98ff275
- https://git.kernel.org/stable/c/32168ca1f123316848fffb85d059860adf3c409f
- https://git.kernel.org/stable/c/43263fd43083e412311fa764cd04a727b0c6a749
- https://git.kernel.org/stable/c/9185b3b1c143b8da409c19ac5a785aa18d67a81b
- https://git.kernel.org/stable/c/9ad15e214fcd73694ea51967d86055f47b802066
- https://git.kernel.org/stable/c/bf9a40ae8d722f281a2721779595d6df1c33a0bf
- https://git.kernel.org/stable/c/cd89f79be5d553c78202f686e8e4caa5fbe94e98
- https://git.kernel.org/stable/c/cede24d13be6c2a62be6d7ceea63c2719b0cfa82
- https://git.kernel.org/stable/c/06854b943e0571ccbd7ad0a529babed1a98ff275
- https://git.kernel.org/stable/c/32168ca1f123316848fffb85d059860adf3c409f
- https://git.kernel.org/stable/c/43263fd43083e412311fa764cd04a727b0c6a749
- https://git.kernel.org/stable/c/9185b3b1c143b8da409c19ac5a785aa18d67a81b
- https://git.kernel.org/stable/c/9ad15e214fcd73694ea51967d86055f47b802066
- https://git.kernel.org/stable/c/bf9a40ae8d722f281a2721779595d6df1c33a0bf
- https://git.kernel.org/stable/c/cd89f79be5d553c78202f686e8e4caa5fbe94e98
- https://git.kernel.org/stable/c/cede24d13be6c2a62be6d7ceea63c2719b0cfa82
Modified: 2024-12-06
CVE-2020-36778
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.
- https://git.kernel.org/stable/c/a42ac16e6573f19c78f556ea292f5b534fcc4514
- https://git.kernel.org/stable/c/a85c5c7a3aa8041777ff691400b4046e56149fd3
- https://git.kernel.org/stable/c/c977426db644ba476938125597947979e8aba725
- https://git.kernel.org/stable/c/e2ba996577eaea423694dc69ae43d56f1410a22b
- https://git.kernel.org/stable/c/a42ac16e6573f19c78f556ea292f5b534fcc4514
- https://git.kernel.org/stable/c/a85c5c7a3aa8041777ff691400b4046e56149fd3
- https://git.kernel.org/stable/c/c977426db644ba476938125597947979e8aba725
- https://git.kernel.org/stable/c/e2ba996577eaea423694dc69ae43d56f1410a22b
Modified: 2024-12-06
CVE-2020-36779
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.
- https://git.kernel.org/stable/c/2c662660ce2bd3b09dae21a9a9ac9395e1e6c00b
- https://git.kernel.org/stable/c/c323b270a52a26aa8038a4d1fd9a850904a41166
- https://git.kernel.org/stable/c/c7ea772c9fcf711ed566814b92eecaffc0e2bfd0
- https://git.kernel.org/stable/c/d791b90f5c5e5aa8ccf9e33386c16bd2b7e333a4
- https://git.kernel.org/stable/c/2c662660ce2bd3b09dae21a9a9ac9395e1e6c00b
- https://git.kernel.org/stable/c/c323b270a52a26aa8038a4d1fd9a850904a41166
- https://git.kernel.org/stable/c/c7ea772c9fcf711ed566814b92eecaffc0e2bfd0
- https://git.kernel.org/stable/c/d791b90f5c5e5aa8ccf9e33386c16bd2b7e333a4
Modified: 2025-03-19
CVE-2020-36780
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.
- https://git.kernel.org/stable/c/3a4f326463117cee3adcb72999ca34a9aaafda93
- https://git.kernel.org/stable/c/7e1764312440c5df9dfe6b436035a03673b0c1b9
- https://git.kernel.org/stable/c/9223505e938ba3db5907e058f4209770cff2f2a7
- https://git.kernel.org/stable/c/d3406ab52097328a3bc4cbe124bfd8f6d51fb86f
- https://git.kernel.org/stable/c/e547640cee7981fd751d2c9cde3a61bdb678b755
- https://git.kernel.org/stable/c/3a4f326463117cee3adcb72999ca34a9aaafda93
- https://git.kernel.org/stable/c/7e1764312440c5df9dfe6b436035a03673b0c1b9
- https://git.kernel.org/stable/c/9223505e938ba3db5907e058f4209770cff2f2a7
- https://git.kernel.org/stable/c/d3406ab52097328a3bc4cbe124bfd8f6d51fb86f
- https://git.kernel.org/stable/c/e547640cee7981fd751d2c9cde3a61bdb678b755
Modified: 2024-12-06
CVE-2020-36781
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.
- https://git.kernel.org/stable/c/1ecc0ebc2ebbad4a22a670a07d27a21fa0b59c77
- https://git.kernel.org/stable/c/3a0cdd336d92c429b51a79bf4f64b17eafa0325d
- https://git.kernel.org/stable/c/47ff617217ca6a13194fcb35c6c3a0c57c080693
- https://git.kernel.org/stable/c/ff406f6cd09c273337ab4854292e4aca48f8affd
- https://git.kernel.org/stable/c/1ecc0ebc2ebbad4a22a670a07d27a21fa0b59c77
- https://git.kernel.org/stable/c/3a0cdd336d92c429b51a79bf4f64b17eafa0325d
- https://git.kernel.org/stable/c/47ff617217ca6a13194fcb35c6c3a0c57c080693
- https://git.kernel.org/stable/c/ff406f6cd09c273337ab4854292e4aca48f8affd
Modified: 2024-12-06
CVE-2020-36782
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.
- https://git.kernel.org/stable/c/278e5bbdb9a94fa063c0f9bcde2479d0b8042462
- https://git.kernel.org/stable/c/815859cb1d2302e74f11bf6894bceace9ca9eb4a
- https://git.kernel.org/stable/c/b100650d80cd2292f6c152f5f2943b5944b3e8ce
- https://git.kernel.org/stable/c/bb300acc867e937edc2a6898e92b21f88e4e4e66
- https://git.kernel.org/stable/c/cc49d206414240483bb93ffa3d80243e6a776916
- https://git.kernel.org/stable/c/278e5bbdb9a94fa063c0f9bcde2479d0b8042462
- https://git.kernel.org/stable/c/815859cb1d2302e74f11bf6894bceace9ca9eb4a
- https://git.kernel.org/stable/c/b100650d80cd2292f6c152f5f2943b5944b3e8ce
- https://git.kernel.org/stable/c/bb300acc867e937edc2a6898e92b21f88e4e4e66
- https://git.kernel.org/stable/c/cc49d206414240483bb93ffa3d80243e6a776916
Modified: 2024-12-06
CVE-2020-36783
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.
- https://git.kernel.org/stable/c/223125e37af8a641ea4a09747a6a52172fc4b903
- https://git.kernel.org/stable/c/4734c4b1d9573c9d20bbc46cf37dde095ee011b8
- https://git.kernel.org/stable/c/7ee35cde1e810ad6ca589980b9ec2b7b62946a5b
- https://git.kernel.org/stable/c/96c4a03658d661666c360959aa80cdabfe2972ed
- https://git.kernel.org/stable/c/e80ae8bde41266d3b8bf012460b6593851766006
- https://git.kernel.org/stable/c/223125e37af8a641ea4a09747a6a52172fc4b903
- https://git.kernel.org/stable/c/4734c4b1d9573c9d20bbc46cf37dde095ee011b8
- https://git.kernel.org/stable/c/7ee35cde1e810ad6ca589980b9ec2b7b62946a5b
- https://git.kernel.org/stable/c/96c4a03658d661666c360959aa80cdabfe2972ed
- https://git.kernel.org/stable/c/e80ae8bde41266d3b8bf012460b6593851766006
Modified: 2024-12-06
CVE-2020-36784
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.
- https://git.kernel.org/stable/c/23ceb8462dc6f4b4decdb5536a7e5fc477cdf0b6
- https://git.kernel.org/stable/c/30410519328c94367e561fd878e5f0d3a0303585
- https://git.kernel.org/stable/c/a45fc41beed8e0fe31864619c34aa00797fb60c1
- https://git.kernel.org/stable/c/d57ff04e0ed6f3be1682ae861ead33f879225e07
- https://git.kernel.org/stable/c/23ceb8462dc6f4b4decdb5536a7e5fc477cdf0b6
- https://git.kernel.org/stable/c/30410519328c94367e561fd878e5f0d3a0303585
- https://git.kernel.org/stable/c/a45fc41beed8e0fe31864619c34aa00797fb60c1
- https://git.kernel.org/stable/c/d57ff04e0ed6f3be1682ae861ead33f879225e07
Modified: 2024-12-06
CVE-2020-36785
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.
- https://git.kernel.org/stable/c/801c1d505894008c888bc71d08d5cff5d87f8aba
- https://git.kernel.org/stable/c/8267ccd7b9df7ab682043507dd682fe0621cf045
- https://git.kernel.org/stable/c/ba11bbf303fafb33989e95473e409f6ab412b18d
- https://git.kernel.org/stable/c/d218c7a0284f6b92a7b82d2e19706e18663b4193
- https://git.kernel.org/stable/c/801c1d505894008c888bc71d08d5cff5d87f8aba
- https://git.kernel.org/stable/c/8267ccd7b9df7ab682043507dd682fe0621cf045
- https://git.kernel.org/stable/c/ba11bbf303fafb33989e95473e409f6ab412b18d
- https://git.kernel.org/stable/c/d218c7a0284f6b92a7b82d2e19706e18663b4193
Modified: 2024-12-06
CVE-2020-36786
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.
- https://git.kernel.org/stable/c/27d2eab69f7da8e94e4751ac5c6d22d809275484
- https://git.kernel.org/stable/c/4f0f37d03cde8f4341df8454f9b40a67fda94a33
- https://git.kernel.org/stable/c/6045b01dd0e3cd3759eafe7f290ed04c957500b1
- https://git.kernel.org/stable/c/cc4cc2fb5aaf9adb83c02211eb13b16cfcb7ba64
- https://git.kernel.org/stable/c/27d2eab69f7da8e94e4751ac5c6d22d809275484
- https://git.kernel.org/stable/c/4f0f37d03cde8f4341df8454f9b40a67fda94a33
- https://git.kernel.org/stable/c/6045b01dd0e3cd3759eafe7f290ed04c957500b1
- https://git.kernel.org/stable/c/cc4cc2fb5aaf9adb83c02211eb13b16cfcb7ba64
Modified: 2024-12-11
CVE-2020-36787
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.
- https://git.kernel.org/stable/c/1dc1d30ac101bb8335d9852de2107af60c2580e7
- https://git.kernel.org/stable/c/2964c37563e86cfdc439f217eb3c5a69adfdba6a
- https://git.kernel.org/stable/c/3536169f8531c2c5b153921dc7d1ac9fd570cda7
- https://git.kernel.org/stable/c/75321dc8aebe3f30eff226028fe6da340fe0bf02
- https://git.kernel.org/stable/c/a59d01384c80a8a4392665802df57c3df20055f5
- https://git.kernel.org/stable/c/1dc1d30ac101bb8335d9852de2107af60c2580e7
- https://git.kernel.org/stable/c/2964c37563e86cfdc439f217eb3c5a69adfdba6a
- https://git.kernel.org/stable/c/3536169f8531c2c5b153921dc7d1ac9fd570cda7
- https://git.kernel.org/stable/c/75321dc8aebe3f30eff226028fe6da340fe0bf02
- https://git.kernel.org/stable/c/a59d01384c80a8a4392665802df57c3df20055f5
Modified: 2024-11-21
CVE-2021-31440
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.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10bf4e83167cc68595b85fd73bb91e8f2c086e36
- https://security.netapp.com/advisory/ntap-20210706-0003/
- https://www.zerodayinitiative.com/advisories/ZDI-21-503/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10bf4e83167cc68595b85fd73bb91e8f2c086e36
- https://security.netapp.com/advisory/ntap-20210706-0003/
- https://www.zerodayinitiative.com/advisories/ZDI-21-503/
Modified: 2024-11-21
CVE-2021-33200
kernel/bpf/verifier.c in the Linux kernel through 5.12.7 enforces incorrect limits for pointer arithmetic operations, aka CID-bb01a1bba579. This can be abused to perform out-of-bounds reads and writes in kernel memory, leading to local privilege escalation to root. In particular, there is a corner case where the off reg causes a masking direction change, which then results in an incorrect final aux->alu_limit.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d0220f6861d713213b015b582e9f21e5b28d2e0
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a7036191277f9fa68d92f2071ddc38c09b1e5ee5
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb01a1bba579b4b1c5566af24d95f1767859771e
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7LR3OKKPHIBGOMHN476CMLW2T7UG53QX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JJCABL43FT3FKRX5DBPZG25FNKR6CEK4/
- https://security.netapp.com/advisory/ntap-20210706-0004/
- https://www.openwall.com/lists/oss-security/2021/05/27/1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d0220f6861d713213b015b582e9f21e5b28d2e0
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a7036191277f9fa68d92f2071ddc38c09b1e5ee5
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb01a1bba579b4b1c5566af24d95f1767859771e
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7LR3OKKPHIBGOMHN476CMLW2T7UG53QX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JJCABL43FT3FKRX5DBPZG25FNKR6CEK4/
- https://security.netapp.com/advisory/ntap-20210706-0004/
- https://www.openwall.com/lists/oss-security/2021/05/27/1
Modified: 2024-11-21
CVE-2021-3489
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).
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=4b81ccebaeee885ab1aa1438133f2991e3a2b6ea
- https://security.netapp.com/advisory/ntap-20210716-0004/
- https://ubuntu.com/security/notices/USN-4949-1
- https://ubuntu.com/security/notices/USN-4950-1
- https://www.openwall.com/lists/oss-security/2021/05/11/10
- https://www.zerodayinitiative.com/advisories/ZDI-21-590/
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=4b81ccebaeee885ab1aa1438133f2991e3a2b6ea
- https://security.netapp.com/advisory/ntap-20210716-0004/
- https://ubuntu.com/security/notices/USN-4949-1
- https://ubuntu.com/security/notices/USN-4950-1
- https://www.openwall.com/lists/oss-security/2021/05/11/10
- https://www.zerodayinitiative.com/advisories/ZDI-21-590/
Modified: 2024-11-21
CVE-2021-3490
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).
- http://packetstormsecurity.com/files/164015/Linux-eBPF-ALU32-32-bit-Invalid-Bounds-Tracking-Local-Privilege-Escalation.html
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=049c4e13714ecbca567b4d5f6d563f05d431c80e
- https://security.netapp.com/advisory/ntap-20210716-0004/
- https://ubuntu.com/security/notices/USN-4949-1
- https://ubuntu.com/security/notices/USN-4950-1
- https://www.openwall.com/lists/oss-security/2021/05/11/11
- https://www.zerodayinitiative.com/advisories/ZDI-21-606/
- http://packetstormsecurity.com/files/164015/Linux-eBPF-ALU32-32-bit-Invalid-Bounds-Tracking-Local-Privilege-Escalation.html
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=049c4e13714ecbca567b4d5f6d563f05d431c80e
- https://security.netapp.com/advisory/ntap-20210716-0004/
- https://ubuntu.com/security/notices/USN-4949-1
- https://ubuntu.com/security/notices/USN-4950-1
- https://www.openwall.com/lists/oss-security/2021/05/11/11
- https://www.zerodayinitiative.com/advisories/ZDI-21-606/
Modified: 2024-11-21
CVE-2021-3491
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/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1f82808877bb10d3deee7cf3374a4eb3fb582db
- https://security.netapp.com/advisory/ntap-20210716-0004/
- https://ubuntu.com/security/notices/USN-4949-1
- https://ubuntu.com/security/notices/USN-4950-1
- https://www.openwall.com/lists/oss-security/2021/05/11/13
- https://www.zerodayinitiative.com/advisories/ZDI-21-589/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1f82808877bb10d3deee7cf3374a4eb3fb582db
- https://security.netapp.com/advisory/ntap-20210716-0004/
- https://ubuntu.com/security/notices/USN-4949-1
- https://ubuntu.com/security/notices/USN-4950-1
- https://www.openwall.com/lists/oss-security/2021/05/11/13
- https://www.zerodayinitiative.com/advisories/ZDI-21-589/
Modified: 2024-11-21
CVE-2021-4157
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.
- https://bugzilla.redhat.com/show_bug.cgi?id=2034342
- https://lore.kernel.org/lkml/20210517140244.822185482%40linuxfoundation.org/
- https://security.netapp.com/advisory/ntap-20220602-0007/
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2034342
- https://lore.kernel.org/lkml/20210517140244.822185482%40linuxfoundation.org/
- https://security.netapp.com/advisory/ntap-20220602-0007/
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2026-01-14
CVE-2021-4460
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
- https://git.kernel.org/stable/c/0c0356ef2498c1a250fe3846f30293f828737309
- https://git.kernel.org/stable/c/1874b0ef1426b873de94c61861e38f29a8df714c
- https://git.kernel.org/stable/c/3fdc5182700910a685d23df57d65166e8556a266
- https://git.kernel.org/stable/c/50e2fc36e72d4ad672032ebf646cecb48656efe0
- https://git.kernel.org/stable/c/9069b1b542de8f3bbffef868aff41521b21485cf
Modified: 2024-11-21
CVE-2021-46938
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().
- https://git.kernel.org/stable/c/1cb02dc76f4c0a2749a02b26469512d6984252e9
- https://git.kernel.org/stable/c/6086f957416a6e87236c06079fcaba7a3998aeca
- https://git.kernel.org/stable/c/772b9f59657665af3b68d24d12b9d172d31f0dfb
- https://git.kernel.org/stable/c/8ae0185255eaf05bd66f4215c81e99bf01140fd9
- https://git.kernel.org/stable/c/8e947c8f4a5620df77e43c9c75310dc510250166
- https://git.kernel.org/stable/c/a992a283c0b77d0a7c2c348add0e6a21fb1dab67
- https://git.kernel.org/stable/c/b42c0a33dfdd451d9be62dd5de58c39f2750b6e3
- https://git.kernel.org/stable/c/d757bf4c69cda3c3ab7f775dfabbf5a80e2f6f9d
- https://git.kernel.org/stable/c/1cb02dc76f4c0a2749a02b26469512d6984252e9
- https://git.kernel.org/stable/c/6086f957416a6e87236c06079fcaba7a3998aeca
- https://git.kernel.org/stable/c/772b9f59657665af3b68d24d12b9d172d31f0dfb
- https://git.kernel.org/stable/c/8ae0185255eaf05bd66f4215c81e99bf01140fd9
- https://git.kernel.org/stable/c/8e947c8f4a5620df77e43c9c75310dc510250166
- https://git.kernel.org/stable/c/a992a283c0b77d0a7c2c348add0e6a21fb1dab67
- https://git.kernel.org/stable/c/b42c0a33dfdd451d9be62dd5de58c39f2750b6e3
- https://git.kernel.org/stable/c/d757bf4c69cda3c3ab7f775dfabbf5a80e2f6f9d
Modified: 2025-04-22
CVE-2021-46939
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
- https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545
- https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e
- https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff
- https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b
- https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4
- https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534
- https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc
- https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44
- https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c
- https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545
- https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e
- https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff
- https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b
- https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4
- https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534
- https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc
- https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44
- https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c
Modified: 2024-11-21
CVE-2021-46940
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.
- https://git.kernel.org/stable/c/13a779de4175df602366d129e41782ad7168cef0
- https://git.kernel.org/stable/c/337b1546cde87fb8588ddaedf0201b769baa572a
- https://git.kernel.org/stable/c/dbdf22fc825fdb1d97f23230064e0f9819471628
- https://git.kernel.org/stable/c/ea6803ff2cd1a2d7d880256bf562172b708a76ff
- https://git.kernel.org/stable/c/13a779de4175df602366d129e41782ad7168cef0
- https://git.kernel.org/stable/c/337b1546cde87fb8588ddaedf0201b769baa572a
- https://git.kernel.org/stable/c/dbdf22fc825fdb1d97f23230064e0f9819471628
- https://git.kernel.org/stable/c/ea6803ff2cd1a2d7d880256bf562172b708a76ff
Modified: 2024-11-21
CVE-2021-46941
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/
- https://git.kernel.org/stable/c/1c10fd60c8595ea7ff7e29d3cf1fa88069941da3
- https://git.kernel.org/stable/c/800f58217626c8b147aa40660e572ed8a0d56e3b
- https://git.kernel.org/stable/c/f88359e1588b85cf0e8209ab7d6620085f3441d9
- https://git.kernel.org/stable/c/fce7bbcd07d59ac30dba8ce225316b3b4c1c7b50
- https://git.kernel.org/stable/c/1c10fd60c8595ea7ff7e29d3cf1fa88069941da3
- https://git.kernel.org/stable/c/800f58217626c8b147aa40660e572ed8a0d56e3b
- https://git.kernel.org/stable/c/f88359e1588b85cf0e8209ab7d6620085f3441d9
- https://git.kernel.org/stable/c/fce7bbcd07d59ac30dba8ce225316b3b4c1c7b50
Modified: 2024-11-21
CVE-2021-46943
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
- https://git.kernel.org/stable/c/34892ea938387d83ffcfb7775ec55f0f80767916
- https://git.kernel.org/stable/c/6fb617e37a39db0a3eca4489431359d0bdf3b9bc
- https://git.kernel.org/stable/c/a03fb1e8a110658215a4cefc3e2ad53279e496a6
- https://git.kernel.org/stable/c/ad91849996f9dd79741a961fd03585a683b08356
- https://git.kernel.org/stable/c/c6b81b897f6f9445d57f8d47c4e060ec21556137
- https://git.kernel.org/stable/c/34892ea938387d83ffcfb7775ec55f0f80767916
- https://git.kernel.org/stable/c/6fb617e37a39db0a3eca4489431359d0bdf3b9bc
- https://git.kernel.org/stable/c/a03fb1e8a110658215a4cefc3e2ad53279e496a6
- https://git.kernel.org/stable/c/ad91849996f9dd79741a961fd03585a683b08356
- https://git.kernel.org/stable/c/c6b81b897f6f9445d57f8d47c4e060ec21556137
Modified: 2024-11-21
CVE-2021-46944
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.
- https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e
- https://git.kernel.org/stable/c/3630901933afba1d16c462b04d569b7576339223
- https://git.kernel.org/stable/c/517f6f570566a863c2422b843c8b7d099474f6a9
- https://git.kernel.org/stable/c/74ba0adb5e983503b18a96121d965cad34ac7ce3
- https://git.kernel.org/stable/c/ff792ae52005c85a2d829c153e08d99a356e007d
- https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e
- https://git.kernel.org/stable/c/3630901933afba1d16c462b04d569b7576339223
- https://git.kernel.org/stable/c/517f6f570566a863c2422b843c8b7d099474f6a9
- https://git.kernel.org/stable/c/74ba0adb5e983503b18a96121d965cad34ac7ce3
- https://git.kernel.org/stable/c/ff792ae52005c85a2d829c153e08d99a356e007d
Modified: 2024-11-21
CVE-2021-46948
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).
- https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052
- https://git.kernel.org/stable/c/83b09a1807415608b387c7bc748d329fefc5617e
- https://git.kernel.org/stable/c/bf2b941d0a6f2d3b9f5fa3c4c21bdd54f71ce253
- https://git.kernel.org/stable/c/e531db1ea6f98c9612cb2de093a107c7eadfb96c
- https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052
- https://git.kernel.org/stable/c/83b09a1807415608b387c7bc748d329fefc5617e
- https://git.kernel.org/stable/c/bf2b941d0a6f2d3b9f5fa3c4c21bdd54f71ce253
- https://git.kernel.org/stable/c/e531db1ea6f98c9612cb2de093a107c7eadfb96c
Modified: 2024-11-21
CVE-2021-46949
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).
- https://git.kernel.org/stable/c/5b1faa92289b53cad654123ed2bc8e10f6ddd4ac
- https://git.kernel.org/stable/c/98d91180748986bfb6dfb3e72765f3225719a647
- https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170
- https://git.kernel.org/stable/c/fb791572d6747ef385f628450f8d57cd132e6e5a
- https://git.kernel.org/stable/c/5b1faa92289b53cad654123ed2bc8e10f6ddd4ac
- https://git.kernel.org/stable/c/98d91180748986bfb6dfb3e72765f3225719a647
- https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170
- https://git.kernel.org/stable/c/fb791572d6747ef385f628450f8d57cd132e6e5a
Modified: 2025-04-22
CVE-2021-46950
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).
- https://git.kernel.org/stable/c/12216d0919b64ee2ea5dc7a50e455670f44383d5
- https://git.kernel.org/stable/c/2417b9869b81882ab90fd5ed1081a1cb2d4db1dd
- https://git.kernel.org/stable/c/538244fba59fde17186322776247cd9c05be86dd
- https://git.kernel.org/stable/c/59452e551784b7a57a45d971727e9db63b192515
- https://git.kernel.org/stable/c/661061a45e32d8b2cc0e306da9f169ad44011382
- https://git.kernel.org/stable/c/6920cef604fa57f9409e3960413e9cc11f5c5a40
- https://git.kernel.org/stable/c/a6e17cab00fc5bf85472434c52ac751426257c6f
- https://git.kernel.org/stable/c/12216d0919b64ee2ea5dc7a50e455670f44383d5
- https://git.kernel.org/stable/c/2417b9869b81882ab90fd5ed1081a1cb2d4db1dd
- https://git.kernel.org/stable/c/538244fba59fde17186322776247cd9c05be86dd
- https://git.kernel.org/stable/c/59452e551784b7a57a45d971727e9db63b192515
- https://git.kernel.org/stable/c/661061a45e32d8b2cc0e306da9f169ad44011382
- https://git.kernel.org/stable/c/6920cef604fa57f9409e3960413e9cc11f5c5a40
- https://git.kernel.org/stable/c/a6e17cab00fc5bf85472434c52ac751426257c6f
Modified: 2024-11-21
CVE-2021-46951
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
- https://git.kernel.org/stable/c/2f12258b5224cfaa808c54fd29345f3c1cbfca76
- https://git.kernel.org/stable/c/3818b753277f5ca0c170bf5b98e0a5a225542fcb
- https://git.kernel.org/stable/c/48cff270b037022e37835d93361646205ca25101
- https://git.kernel.org/stable/c/60a01ecc9f68067e4314a0b55148e39e5d58a51b
- https://git.kernel.org/stable/c/ac07c557ca12ec9276c0375517bac7ae5be4e50c
- https://git.kernel.org/stable/c/2f12258b5224cfaa808c54fd29345f3c1cbfca76
- https://git.kernel.org/stable/c/3818b753277f5ca0c170bf5b98e0a5a225542fcb
- https://git.kernel.org/stable/c/48cff270b037022e37835d93361646205ca25101
- https://git.kernel.org/stable/c/60a01ecc9f68067e4314a0b55148e39e5d58a51b
- https://git.kernel.org/stable/c/ac07c557ca12ec9276c0375517bac7ae5be4e50c
Modified: 2024-11-21
CVE-2021-46952
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.
- https://git.kernel.org/stable/c/2f3380121d49e829fb73ba86240c181bc32ad897
- https://git.kernel.org/stable/c/3d0163821c035040a46d816a42c0780f0f0a30a8
- https://git.kernel.org/stable/c/96fa26b74cdcf9f5c98996bf36bec9fb5b19ffe2
- https://git.kernel.org/stable/c/c09f11ef35955785f92369e25819bf0629df2e59
- https://git.kernel.org/stable/c/2f3380121d49e829fb73ba86240c181bc32ad897
- https://git.kernel.org/stable/c/3d0163821c035040a46d816a42c0780f0f0a30a8
- https://git.kernel.org/stable/c/96fa26b74cdcf9f5c98996bf36bec9fb5b19ffe2
- https://git.kernel.org/stable/c/c09f11ef35955785f92369e25819bf0629df2e59
Modified: 2024-11-21
CVE-2021-46953
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.
- https://git.kernel.org/stable/c/1ecd5b129252249b9bc03d7645a7bda512747277
- https://git.kernel.org/stable/c/42e69521ee1fa5abf21f478d147d06bbfe6bf6a8
- https://git.kernel.org/stable/c/504632a3577a049dd9bb7aabae5b4476f9c586b4
- https://git.kernel.org/stable/c/596e079c362ac17ed02aa1b99fdc444d62072a01
- https://git.kernel.org/stable/c/7b2162db1498c71962a4bb2f776fa4e76d4d305b
- https://git.kernel.org/stable/c/c3385a9122f8db15b453e07bfc88117fce7f3724
- https://git.kernel.org/stable/c/e0f2d86481eaa83df33b0793f75212919db7a19d
- https://git.kernel.org/stable/c/1ecd5b129252249b9bc03d7645a7bda512747277
- https://git.kernel.org/stable/c/42e69521ee1fa5abf21f478d147d06bbfe6bf6a8
- https://git.kernel.org/stable/c/504632a3577a049dd9bb7aabae5b4476f9c586b4
- https://git.kernel.org/stable/c/596e079c362ac17ed02aa1b99fdc444d62072a01
- https://git.kernel.org/stable/c/7b2162db1498c71962a4bb2f776fa4e76d4d305b
- https://git.kernel.org/stable/c/c3385a9122f8db15b453e07bfc88117fce7f3724
- https://git.kernel.org/stable/c/e0f2d86481eaa83df33b0793f75212919db7a19d
Modified: 2024-12-06
CVE-2021-46955
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.
- https://git.kernel.org/stable/c/23e17ec1a5eb53fe39cc34fa5592686d5acd0dac
- https://git.kernel.org/stable/c/490ad0a2390442d0a7b8c00972a83dbb09cab142
- https://git.kernel.org/stable/c/5a52fa8ad45b5a593ed416adf326538638454ff1
- https://git.kernel.org/stable/c/7c0ea5930c1c211931819d83cfb157bff1539a4c
- https://git.kernel.org/stable/c/a1478374b0bda89b4277a8afd39208271faad4be
- https://git.kernel.org/stable/c/b1d7280f9ba1bfdbc3af5bdb82e51f014854f26f
- https://git.kernel.org/stable/c/b3502b04e84ac5349be95fc033c17bd701d2787a
- https://git.kernel.org/stable/c/d841d3cf5297fde4ce6a41ff35451d0e82917f3e
- https://git.kernel.org/stable/c/df9e900de24637be41879e2c50afb713ec4e8b2e
- https://git.kernel.org/stable/c/23e17ec1a5eb53fe39cc34fa5592686d5acd0dac
- https://git.kernel.org/stable/c/490ad0a2390442d0a7b8c00972a83dbb09cab142
- https://git.kernel.org/stable/c/5a52fa8ad45b5a593ed416adf326538638454ff1
- https://git.kernel.org/stable/c/7c0ea5930c1c211931819d83cfb157bff1539a4c
- https://git.kernel.org/stable/c/a1478374b0bda89b4277a8afd39208271faad4be
- https://git.kernel.org/stable/c/b1d7280f9ba1bfdbc3af5bdb82e51f014854f26f
- https://git.kernel.org/stable/c/b3502b04e84ac5349be95fc033c17bd701d2787a
- https://git.kernel.org/stable/c/d841d3cf5297fde4ce6a41ff35451d0e82917f3e
- https://git.kernel.org/stable/c/df9e900de24637be41879e2c50afb713ec4e8b2e
Modified: 2024-12-06
CVE-2021-46956
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
- https://git.kernel.org/stable/c/310efc95c72c13faf855c692d19cd4d054d827c8
- https://git.kernel.org/stable/c/5116e79fc6e6725b8acdad8b7e928a83ab7b47e6
- https://git.kernel.org/stable/c/9b9d60c0eb8ada99cce2a9ab5c15dffc523b01ae
- https://git.kernel.org/stable/c/c79c5e0178922a9e092ec8fed026750f39dcaef4
- https://git.kernel.org/stable/c/d19555ff225d0896a33246a49279e6d578095f15
- https://git.kernel.org/stable/c/310efc95c72c13faf855c692d19cd4d054d827c8
- https://git.kernel.org/stable/c/5116e79fc6e6725b8acdad8b7e928a83ab7b47e6
- https://git.kernel.org/stable/c/9b9d60c0eb8ada99cce2a9ab5c15dffc523b01ae
- https://git.kernel.org/stable/c/c79c5e0178922a9e092ec8fed026750f39dcaef4
- https://git.kernel.org/stable/c/d19555ff225d0896a33246a49279e6d578095f15
Modified: 2024-12-11
CVE-2021-46958
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---
- https://git.kernel.org/stable/c/061dde8245356d8864d29e25207aa4daa0be4d3c
- https://git.kernel.org/stable/c/633f7f216663587f17601eaa1cf2ac3d5654874c
- https://git.kernel.org/stable/c/a4794be7b00b7eda4b45fffd283ab7d76df7e5d6
- https://git.kernel.org/stable/c/e2da98788369bfba1138bada72765c47989a4338
- https://git.kernel.org/stable/c/061dde8245356d8864d29e25207aa4daa0be4d3c
- https://git.kernel.org/stable/c/633f7f216663587f17601eaa1cf2ac3d5654874c
- https://git.kernel.org/stable/c/a4794be7b00b7eda4b45fffd283ab7d76df7e5d6
- https://git.kernel.org/stable/c/e2da98788369bfba1138bada72765c47989a4338
Modified: 2024-12-10
CVE-2021-46959
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
[
- https://git.kernel.org/stable/c/001c8e83646ad3b847b18f6ac55a54367d917d74
- https://git.kernel.org/stable/c/28a5529068c51cdf0295ab1e11a99a3a909a03e4
- https://git.kernel.org/stable/c/62bb2c7f2411a0045c24831f11ecacfc35610815
- https://git.kernel.org/stable/c/794aaf01444d4e765e2b067cba01cc69c1c68ed9
- https://git.kernel.org/stable/c/8735248ebb918d25427965f0db07939ed0473ec6
- https://git.kernel.org/stable/c/8bf96425c90f5c1dcf3b7b9df568019a1d4b8a0e
- https://git.kernel.org/stable/c/8e029707f50a82c53172359c686b2536ab54e58c
- https://git.kernel.org/stable/c/c7fabe372a9031acd00498bc718ce27c253abfd1
- https://git.kernel.org/stable/c/cee78aa24578edac8cf00513dca618c0acc17cd7
- https://git.kernel.org/stable/c/001c8e83646ad3b847b18f6ac55a54367d917d74
- https://git.kernel.org/stable/c/28a5529068c51cdf0295ab1e11a99a3a909a03e4
- https://git.kernel.org/stable/c/62bb2c7f2411a0045c24831f11ecacfc35610815
- https://git.kernel.org/stable/c/794aaf01444d4e765e2b067cba01cc69c1c68ed9
- https://git.kernel.org/stable/c/8735248ebb918d25427965f0db07939ed0473ec6
- https://git.kernel.org/stable/c/8bf96425c90f5c1dcf3b7b9df568019a1d4b8a0e
- https://git.kernel.org/stable/c/8e029707f50a82c53172359c686b2536ab54e58c
- https://git.kernel.org/stable/c/c7fabe372a9031acd00498bc718ce27c253abfd1
- https://git.kernel.org/stable/c/cee78aa24578edac8cf00513dca618c0acc17cd7
Modified: 2024-12-11
CVE-2021-46960
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
- https://git.kernel.org/stable/c/83728cbf366e334301091d5b808add468ab46b27
- https://git.kernel.org/stable/c/93f3339b22ba17e66f0808737467b70ba087eaec
- https://git.kernel.org/stable/c/aaa0faa5c28a91c362352d6b35dc3ed10df56fb0
- https://git.kernel.org/stable/c/b399c1a3ea0b9d10047ff266d65533df7f15532f
- https://git.kernel.org/stable/c/e486f8397f3f14a7cadc166138141fdb14379a54
- https://git.kernel.org/stable/c/e94851629c49c65b4fbb29a5725ddfd7988f8f20
- https://git.kernel.org/stable/c/f59a9242942fef0de7b926e438ba4eae65d4b4dd
- https://git.kernel.org/stable/c/83728cbf366e334301091d5b808add468ab46b27
- https://git.kernel.org/stable/c/93f3339b22ba17e66f0808737467b70ba087eaec
- https://git.kernel.org/stable/c/aaa0faa5c28a91c362352d6b35dc3ed10df56fb0
- https://git.kernel.org/stable/c/b399c1a3ea0b9d10047ff266d65533df7f15532f
- https://git.kernel.org/stable/c/e486f8397f3f14a7cadc166138141fdb14379a54
- https://git.kernel.org/stable/c/e94851629c49c65b4fbb29a5725ddfd7988f8f20
- https://git.kernel.org/stable/c/f59a9242942fef0de7b926e438ba4eae65d4b4dd
Modified: 2025-04-22
CVE-2021-46961
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]
- https://git.kernel.org/stable/c/3f72d3709f53af72835af7dc8b15ba61611a0e36
- https://git.kernel.org/stable/c/7be4db5c2b59fa77071c93ca4329876fb9777202
- https://git.kernel.org/stable/c/a97709f563a078e259bf0861cd259aa60332890a
- https://git.kernel.org/stable/c/e7ea8e46e3b777be26aa855fe07778c415f24926
- https://git.kernel.org/stable/c/ea817ac1014c04f47885532b55f5d0898deadfba
- https://git.kernel.org/stable/c/3f72d3709f53af72835af7dc8b15ba61611a0e36
- https://git.kernel.org/stable/c/7be4db5c2b59fa77071c93ca4329876fb9777202
- https://git.kernel.org/stable/c/a97709f563a078e259bf0861cd259aa60332890a
- https://git.kernel.org/stable/c/e7ea8e46e3b777be26aa855fe07778c415f24926
- https://git.kernel.org/stable/c/ea817ac1014c04f47885532b55f5d0898deadfba
Modified: 2024-12-11
CVE-2021-46962
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.
- https://git.kernel.org/stable/c/0d8941b9b2d3e7b3481fdf43b1a6189d162175b7
- https://git.kernel.org/stable/c/25ac6ce65f1ab458982d15ec1caf441acd37106a
- https://git.kernel.org/stable/c/d6e7fda496978f2763413b5523557b38dc2bf6c2
- https://git.kernel.org/stable/c/e29c84857e2d51aa017ce04284b962742fb97d9e
- https://git.kernel.org/stable/c/ebe0f12cf4c044f812c6d17011531582f9ac8bb3
- https://git.kernel.org/stable/c/0d8941b9b2d3e7b3481fdf43b1a6189d162175b7
- https://git.kernel.org/stable/c/25ac6ce65f1ab458982d15ec1caf441acd37106a
- https://git.kernel.org/stable/c/d6e7fda496978f2763413b5523557b38dc2bf6c2
- https://git.kernel.org/stable/c/e29c84857e2d51aa017ce04284b962742fb97d9e
- https://git.kernel.org/stable/c/ebe0f12cf4c044f812c6d17011531582f9ac8bb3
Modified: 2024-12-11
CVE-2021-46963
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.
- https://git.kernel.org/stable/c/6641df81ab799f28a5d564f860233dd26cca0d93
- https://git.kernel.org/stable/c/702cdaa2c6283c135ef16d52e0e4e3c1005aa538
- https://git.kernel.org/stable/c/77509a238547863040a42d57c72403f7d4c89a8f
- https://git.kernel.org/stable/c/80ef24175df2cba3860d0369d1c662b49ee2de56
- https://git.kernel.org/stable/c/a73208e3244127ef9f2cdf24e4adb947aaa32053
- https://git.kernel.org/stable/c/c5ab9b67d8b061de74e2ca51bf787ee599bd7f89
- https://git.kernel.org/stable/c/6641df81ab799f28a5d564f860233dd26cca0d93
- https://git.kernel.org/stable/c/702cdaa2c6283c135ef16d52e0e4e3c1005aa538
- https://git.kernel.org/stable/c/77509a238547863040a42d57c72403f7d4c89a8f
- https://git.kernel.org/stable/c/80ef24175df2cba3860d0369d1c662b49ee2de56
- https://git.kernel.org/stable/c/a73208e3244127ef9f2cdf24e4adb947aaa32053
- https://git.kernel.org/stable/c/c5ab9b67d8b061de74e2ca51bf787ee599bd7f89
Modified: 2025-01-08
CVE-2021-46965
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")
- https://git.kernel.org/stable/c/34ec706bf0b7c4ca249a729c1bcb91f706c7a7be
- https://git.kernel.org/stable/c/4d786870e3262ec098a3b4ed10b895176bc66ecb
- https://git.kernel.org/stable/c/4e4ebb827bf09311469ffd9d0c14ed40ed9747aa
- https://git.kernel.org/stable/c/683313993dbe1651c7aa00bb42a041d70e914925
- https://git.kernel.org/stable/c/34ec706bf0b7c4ca249a729c1bcb91f706c7a7be
- https://git.kernel.org/stable/c/4d786870e3262ec098a3b4ed10b895176bc66ecb
- https://git.kernel.org/stable/c/4e4ebb827bf09311469ffd9d0c14ed40ed9747aa
- https://git.kernel.org/stable/c/683313993dbe1651c7aa00bb42a041d70e914925
Modified: 2024-12-06
CVE-2021-46966
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.
- https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3bf7e394
- https://git.kernel.org/stable/c/62dc2440ebb552aa0d7f635e1697e077d9d21203
- https://git.kernel.org/stable/c/72814a94c38a33239793f7622cec6ace1e540c4b
- https://git.kernel.org/stable/c/8b04d57f30caf76649d0567551589af9a66ca9be
- https://git.kernel.org/stable/c/90575d1d9311b753cf1718f4ce9061ddda7dfd23
- https://git.kernel.org/stable/c/a5b26a2e362f572d87e9fd35435680e557052a17
- https://git.kernel.org/stable/c/b7a5baaae212a686ceb812c32fceed79c03c0234
- https://git.kernel.org/stable/c/e483bb9a991bdae29a0caa4b3a6d002c968f94aa
- https://git.kernel.org/stable/c/f16737caf41fc06cfe6e49048becb09657074d4b
- https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3bf7e394
- https://git.kernel.org/stable/c/62dc2440ebb552aa0d7f635e1697e077d9d21203
- https://git.kernel.org/stable/c/72814a94c38a33239793f7622cec6ace1e540c4b
- https://git.kernel.org/stable/c/8b04d57f30caf76649d0567551589af9a66ca9be
- https://git.kernel.org/stable/c/90575d1d9311b753cf1718f4ce9061ddda7dfd23
- https://git.kernel.org/stable/c/a5b26a2e362f572d87e9fd35435680e557052a17
- https://git.kernel.org/stable/c/b7a5baaae212a686ceb812c32fceed79c03c0234
- https://git.kernel.org/stable/c/e483bb9a991bdae29a0caa4b3a6d002c968f94aa
- https://git.kernel.org/stable/c/f16737caf41fc06cfe6e49048becb09657074d4b
Modified: 2024-12-06
CVE-2021-46967
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.
- https://git.kernel.org/stable/c/3a3e0fad16d40a2aa68ddf7eea4acdf48b22dd44
- https://git.kernel.org/stable/c/3b8b6399666a29daa30b0bb3f5c9e3fc81c5a6a6
- https://git.kernel.org/stable/c/93dbbf20e3ffad14f04227a0b7105f6e6f0387ce
- https://git.kernel.org/stable/c/940230a5c31e2714722aee04c521a21f484b4df7
- https://git.kernel.org/stable/c/3a3e0fad16d40a2aa68ddf7eea4acdf48b22dd44
- https://git.kernel.org/stable/c/3b8b6399666a29daa30b0bb3f5c9e3fc81c5a6a6
- https://git.kernel.org/stable/c/93dbbf20e3ffad14f04227a0b7105f6e6f0387ce
- https://git.kernel.org/stable/c/940230a5c31e2714722aee04c521a21f484b4df7
Modified: 2025-01-08
CVE-2021-46968
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.
- https://git.kernel.org/stable/c/026499a9c2e002e621ad568d1378324ae97e5524
- https://git.kernel.org/stable/c/055a063a18bcd19b93709e3eac8078d6b2f04599
- https://git.kernel.org/stable/c/70fac8088cfad9f3b379c9082832b4d7532c16c2
- https://git.kernel.org/stable/c/971dc8706cee47393d393905d294ea47e39503d3
- https://git.kernel.org/stable/c/026499a9c2e002e621ad568d1378324ae97e5524
- https://git.kernel.org/stable/c/055a063a18bcd19b93709e3eac8078d6b2f04599
- https://git.kernel.org/stable/c/70fac8088cfad9f3b379c9082832b4d7532c16c2
- https://git.kernel.org/stable/c/971dc8706cee47393d393905d294ea47e39503d3
Modified: 2025-03-14
CVE-2021-46973
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..
- https://git.kernel.org/stable/c/03c649dee8b1eb5600212a249542a70f47a5ab40
- https://git.kernel.org/stable/c/47a017f33943278570c072bc71681809b2567b3a
- https://git.kernel.org/stable/c/48ec949ac979b4b42d740f67b6177797af834f80
- https://git.kernel.org/stable/c/ea474054c2cc6e1284604b21361f475c7cc8c0a0
- https://git.kernel.org/stable/c/03c649dee8b1eb5600212a249542a70f47a5ab40
- https://git.kernel.org/stable/c/47a017f33943278570c072bc71681809b2567b3a
- https://git.kernel.org/stable/c/48ec949ac979b4b42d740f67b6177797af834f80
- https://git.kernel.org/stable/c/ea474054c2cc6e1284604b21361f475c7cc8c0a0
Modified: 2025-01-10
CVE-2021-46976
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---
- https://git.kernel.org/stable/c/402be8a101190969fc7ff122d07e262df86e132b
- https://git.kernel.org/stable/c/608441de3976c526b02af4d7063093c8adf351e3
- https://git.kernel.org/stable/c/805c990a9c54b9451d3daff640b850909c31ab9d
- https://git.kernel.org/stable/c/f7520970d5353cb1fa4d9089a1b23669c5da97fe
- https://git.kernel.org/stable/c/402be8a101190969fc7ff122d07e262df86e132b
- https://git.kernel.org/stable/c/608441de3976c526b02af4d7063093c8adf351e3
- https://git.kernel.org/stable/c/805c990a9c54b9451d3daff640b850909c31ab9d
- https://git.kernel.org/stable/c/f7520970d5353cb1fa4d9089a1b23669c5da97fe
Modified: 2025-01-08
CVE-2021-46977
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.
- https://git.kernel.org/stable/c/31f29749ee970c251b3a7e5b914108425940d089
- https://git.kernel.org/stable/c/5104d7ffcf24749939bea7fdb5378d186473f890
- https://git.kernel.org/stable/c/5adcdeb57007ccf8ab7ac20bf787ffb6fafb1a94
- https://git.kernel.org/stable/c/e3ea1895df719c4ef87862501bb10d95f4177bed
- https://git.kernel.org/stable/c/31f29749ee970c251b3a7e5b914108425940d089
- https://git.kernel.org/stable/c/5104d7ffcf24749939bea7fdb5378d186473f890
- https://git.kernel.org/stable/c/5adcdeb57007ccf8ab7ac20bf787ffb6fafb1a94
- https://git.kernel.org/stable/c/e3ea1895df719c4ef87862501bb10d95f4177bed
Modified: 2025-03-14
CVE-2021-46978
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().
- https://git.kernel.org/stable/c/200a45649ab7361bc80c70aebf7165b64f9a6c9f
- https://git.kernel.org/stable/c/bd0e8455b85b651a4c77de9616e307129b15aaa7
- https://git.kernel.org/stable/c/c8bf64e3fb77cc19bad146fbe26651985b117194
- https://git.kernel.org/stable/c/f5c7e8425f18fdb9bdb7d13340651d7876890329
- https://git.kernel.org/stable/c/200a45649ab7361bc80c70aebf7165b64f9a6c9f
- https://git.kernel.org/stable/c/bd0e8455b85b651a4c77de9616e307129b15aaa7
- https://git.kernel.org/stable/c/c8bf64e3fb77cc19bad146fbe26651985b117194
- https://git.kernel.org/stable/c/f5c7e8425f18fdb9bdb7d13340651d7876890329
Modified: 2024-12-31
CVE-2021-46980
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.
- https://git.kernel.org/stable/c/1f4642b72be79757f050924a9b9673b6a02034bc
- https://git.kernel.org/stable/c/5e9c6f58b01e6fdfbc740390c01f542a35c97e57
- https://git.kernel.org/stable/c/a453bfd7ef15fd9d524004d3ca7b05353a302911
- https://git.kernel.org/stable/c/e5366bea0277425e1868ba20eeb27c879d5a6e2d
- https://git.kernel.org/stable/c/1f4642b72be79757f050924a9b9673b6a02034bc
- https://git.kernel.org/stable/c/5e9c6f58b01e6fdfbc740390c01f542a35c97e57
- https://git.kernel.org/stable/c/a453bfd7ef15fd9d524004d3ca7b05353a302911
- https://git.kernel.org/stable/c/e5366bea0277425e1868ba20eeb27c879d5a6e2d
Modified: 2024-12-06
CVE-2021-46981
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
- https://git.kernel.org/stable/c/1c4962df938891af9ab4775f5224ef8601764107
- https://git.kernel.org/stable/c/54b78ba7e96e5fe1edb8054e375d31a6c0dc60dc
- https://git.kernel.org/stable/c/79ebe9110fa458d58f1fceb078e2068d7ad37390
- https://git.kernel.org/stable/c/b31d237796fd618379ec8e0f4de3370b5e4aeee7
- https://git.kernel.org/stable/c/cde4b55cfb24522dcbba80bbdb0c082303e76c43
- https://git.kernel.org/stable/c/1c4962df938891af9ab4775f5224ef8601764107
- https://git.kernel.org/stable/c/54b78ba7e96e5fe1edb8054e375d31a6c0dc60dc
- https://git.kernel.org/stable/c/79ebe9110fa458d58f1fceb078e2068d7ad37390
- https://git.kernel.org/stable/c/b31d237796fd618379ec8e0f4de3370b5e4aeee7
- https://git.kernel.org/stable/c/cde4b55cfb24522dcbba80bbdb0c082303e76c43
Modified: 2024-12-31
CVE-2021-46982
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.
- https://git.kernel.org/stable/c/5639b73fd3bc6fc8ca72e3a9ac15aacaabd7ebff
- https://git.kernel.org/stable/c/64acb100fe3beb5d20184d0ae3307235bd3555c4
- https://git.kernel.org/stable/c/936158b15e2648253afb824d252c910c496d34b5
- https://git.kernel.org/stable/c/a949dc5f2c5cfe0c910b664650f45371254c0744
- https://git.kernel.org/stable/c/5639b73fd3bc6fc8ca72e3a9ac15aacaabd7ebff
- https://git.kernel.org/stable/c/64acb100fe3beb5d20184d0ae3307235bd3555c4
- https://git.kernel.org/stable/c/936158b15e2648253afb824d252c910c496d34b5
- https://git.kernel.org/stable/c/a949dc5f2c5cfe0c910b664650f45371254c0744
Modified: 2024-12-06
CVE-2021-46983
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
- https://git.kernel.org/stable/c/17fb6dfa5162b89ecfa07df891a53afec321abe8
- https://git.kernel.org/stable/c/5bdb34466ad8370546dfa0497594fb1d6f2fed90
- https://git.kernel.org/stable/c/64f3410c7bfc389b1a58611d0799f4a36ce4b6b5
- https://git.kernel.org/stable/c/8cc365f9559b86802afc0208389f5c8d46b4ad61
- https://git.kernel.org/stable/c/17fb6dfa5162b89ecfa07df891a53afec321abe8
- https://git.kernel.org/stable/c/5bdb34466ad8370546dfa0497594fb1d6f2fed90
- https://git.kernel.org/stable/c/64f3410c7bfc389b1a58611d0799f4a36ce4b6b5
- https://git.kernel.org/stable/c/8cc365f9559b86802afc0208389f5c8d46b4ad61
Modified: 2024-12-06
CVE-2021-46984
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.
- https://git.kernel.org/stable/c/0b6b4b90b74c27bea968c214d820ba4254b903a5
- https://git.kernel.org/stable/c/2ef3c76540c49167a0bc3d5f80d00fd1fc4586df
- https://git.kernel.org/stable/c/54dbe2d2c1fcabf650c7a8b747601da355cd7f9f
- https://git.kernel.org/stable/c/a287cd84e047045f5a4d4da793414e848de627c6
- https://git.kernel.org/stable/c/efed9a3337e341bd0989161b97453b52567bc59d
- https://git.kernel.org/stable/c/0b6b4b90b74c27bea968c214d820ba4254b903a5
- https://git.kernel.org/stable/c/2ef3c76540c49167a0bc3d5f80d00fd1fc4586df
- https://git.kernel.org/stable/c/54dbe2d2c1fcabf650c7a8b747601da355cd7f9f
- https://git.kernel.org/stable/c/a287cd84e047045f5a4d4da793414e848de627c6
- https://git.kernel.org/stable/c/efed9a3337e341bd0989161b97453b52567bc59d
Modified: 2024-12-06
CVE-2021-46985
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.
- https://git.kernel.org/stable/c/0c8bd174f0fc131bc9dfab35cd8784f59045da87
- https://git.kernel.org/stable/c/5ab9857dde7c3ea3faef6b128d718cf8ba98721b
- https://git.kernel.org/stable/c/6901a4f795e0e8d65ae779cb37fc22e0bf294712
- https://git.kernel.org/stable/c/69cc821e89ce572884548ac54c4f80eec7a837a5
- https://git.kernel.org/stable/c/a7e17a8d421ae23c920240625b4413c7b94d94a4
- https://git.kernel.org/stable/c/c5c8f6ffc942cf42f990f22e35bcf4cbe9d8c2fb
- https://git.kernel.org/stable/c/dafd4c0b5e835db020cff11c74b4af9493a58e72
- https://git.kernel.org/stable/c/e2381174daeae0ca35eddffef02dcc8de8c1ef8a
- https://git.kernel.org/stable/c/0c8bd174f0fc131bc9dfab35cd8784f59045da87
- https://git.kernel.org/stable/c/5ab9857dde7c3ea3faef6b128d718cf8ba98721b
- https://git.kernel.org/stable/c/6901a4f795e0e8d65ae779cb37fc22e0bf294712
- https://git.kernel.org/stable/c/69cc821e89ce572884548ac54c4f80eec7a837a5
- https://git.kernel.org/stable/c/a7e17a8d421ae23c920240625b4413c7b94d94a4
- https://git.kernel.org/stable/c/c5c8f6ffc942cf42f990f22e35bcf4cbe9d8c2fb
- https://git.kernel.org/stable/c/dafd4c0b5e835db020cff11c74b4af9493a58e72
- https://git.kernel.org/stable/c/e2381174daeae0ca35eddffef02dcc8de8c1ef8a
Modified: 2024-12-31
CVE-2021-46986
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().
- https://git.kernel.org/stable/c/1ea775021282d90e1d08d696b7ab54aa75d688e5
- https://git.kernel.org/stable/c/b4b8e9601d7ee8806d2687f081a42485d27674a1
- https://git.kernel.org/stable/c/bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139
- https://git.kernel.org/stable/c/bc0cdd72493236fb72b390ad38ce581e353c143c
- https://git.kernel.org/stable/c/1ea775021282d90e1d08d696b7ab54aa75d688e5
- https://git.kernel.org/stable/c/b4b8e9601d7ee8806d2687f081a42485d27674a1
- https://git.kernel.org/stable/c/bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139
- https://git.kernel.org/stable/c/bc0cdd72493236fb72b390ad38ce581e353c143c
Modified: 2024-12-26
CVE-2021-46988
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.
- https://git.kernel.org/stable/c/07c9b834c97d0fa3402fb7f3f3b32df370a6ff1f
- https://git.kernel.org/stable/c/140cfd9980124aecb6c03ef2e69c72d0548744de
- https://git.kernel.org/stable/c/2d59a0ed8b26b8f3638d8afc31f839e27759f1f6
- https://git.kernel.org/stable/c/319116227e52d49eee671f0aa278bac89b3c1b69
- https://git.kernel.org/stable/c/7ed9d238c7dbb1fdb63ad96a6184985151b0171c
- https://git.kernel.org/stable/c/ad53127973034c63b5348715a1043d0e80ceb330
- https://git.kernel.org/stable/c/b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43
- https://git.kernel.org/stable/c/07c9b834c97d0fa3402fb7f3f3b32df370a6ff1f
- https://git.kernel.org/stable/c/140cfd9980124aecb6c03ef2e69c72d0548744de
- https://git.kernel.org/stable/c/2d59a0ed8b26b8f3638d8afc31f839e27759f1f6
- https://git.kernel.org/stable/c/319116227e52d49eee671f0aa278bac89b3c1b69
- https://git.kernel.org/stable/c/7ed9d238c7dbb1fdb63ad96a6184985151b0171c
- https://git.kernel.org/stable/c/ad53127973034c63b5348715a1043d0e80ceb330
- https://git.kernel.org/stable/c/b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43
Modified: 2025-03-14
CVE-2021-46989
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.
- https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a
- https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446
- https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99
- https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d
- https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c
- https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685
- https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a
- https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446
- https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99
- https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d
- https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c
- https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685
Modified: 2024-12-26
CVE-2021-46990
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.
- https://git.kernel.org/stable/c/0b4eb172cc12dc102cd0ad013e53ee4463db9508
- https://git.kernel.org/stable/c/0c25a7bb697f2e6ee65b6d63782f675bf129511a
- https://git.kernel.org/stable/c/2db22ba4e0e103f00e0512e0ecce36ac78c644f8
- https://git.kernel.org/stable/c/5bc00fdda1e934c557351a9c751a205293e68cbf
- https://git.kernel.org/stable/c/8382b15864e5014261b4f36c2aa89723612ee058
- https://git.kernel.org/stable/c/aec86b052df6541cc97c5fca44e5934cbea4963b
- https://git.kernel.org/stable/c/d2e3590ca39ccfd8a5a46d8c7f095cb6c7b9ae92
- https://git.kernel.org/stable/c/dd0d6117052faace5440db20fc37175efe921c7d
- https://git.kernel.org/stable/c/ee4b7aab93c2631c3bb0753023c5dda592bb666b
- https://git.kernel.org/stable/c/0b4eb172cc12dc102cd0ad013e53ee4463db9508
- https://git.kernel.org/stable/c/0c25a7bb697f2e6ee65b6d63782f675bf129511a
- https://git.kernel.org/stable/c/2db22ba4e0e103f00e0512e0ecce36ac78c644f8
- https://git.kernel.org/stable/c/5bc00fdda1e934c557351a9c751a205293e68cbf
- https://git.kernel.org/stable/c/8382b15864e5014261b4f36c2aa89723612ee058
- https://git.kernel.org/stable/c/aec86b052df6541cc97c5fca44e5934cbea4963b
- https://git.kernel.org/stable/c/d2e3590ca39ccfd8a5a46d8c7f095cb6c7b9ae92
- https://git.kernel.org/stable/c/dd0d6117052faace5440db20fc37175efe921c7d
- https://git.kernel.org/stable/c/ee4b7aab93c2631c3bb0753023c5dda592bb666b
Modified: 2024-12-06
CVE-2021-46991
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")
- https://git.kernel.org/stable/c/1fd5d262e7442192ac7611ff1597a36c5b044323
- https://git.kernel.org/stable/c/38318f23a7ef86a8b1862e5e8078c4de121960c3
- https://git.kernel.org/stable/c/4ebc10aa7cd17fd9857dedac69600465c9dd16d1
- https://git.kernel.org/stable/c/829a713450b8fb127cbabfc1244c1d8179ec5107
- https://git.kernel.org/stable/c/c1322eaeb8af0d8985b5cc5fa759140fa0e57b84
- https://git.kernel.org/stable/c/d718c15a2bf9ae082d5ae4d177fb19ef23cb4132
- https://git.kernel.org/stable/c/1fd5d262e7442192ac7611ff1597a36c5b044323
- https://git.kernel.org/stable/c/38318f23a7ef86a8b1862e5e8078c4de121960c3
- https://git.kernel.org/stable/c/4ebc10aa7cd17fd9857dedac69600465c9dd16d1
- https://git.kernel.org/stable/c/829a713450b8fb127cbabfc1244c1d8179ec5107
- https://git.kernel.org/stable/c/c1322eaeb8af0d8985b5cc5fa759140fa0e57b84
- https://git.kernel.org/stable/c/d718c15a2bf9ae082d5ae4d177fb19ef23cb4132
Modified: 2024-12-24
CVE-2021-46992
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
- https://git.kernel.org/stable/c/1e8ab479cfbe5751efccedb95afb9b112a5ba475
- https://git.kernel.org/stable/c/2824cafc6a93792d9ad85939c499161214d84c4b
- https://git.kernel.org/stable/c/72b49dd116ca00a46a11d5a4d8d7987f05ed9cd7
- https://git.kernel.org/stable/c/a388d10961ff8578b1a6691945d406c0f33aa71b
- https://git.kernel.org/stable/c/a54754ec9891830ba548e2010c889e3c8146e449
- https://git.kernel.org/stable/c/c77e2ef18167ad334e27610ced9a7f6af5ec1787
- https://git.kernel.org/stable/c/efcd730ddd6f25578bd31bfe703e593e2421d708
- https://git.kernel.org/stable/c/1e8ab479cfbe5751efccedb95afb9b112a5ba475
- https://git.kernel.org/stable/c/2824cafc6a93792d9ad85939c499161214d84c4b
- https://git.kernel.org/stable/c/72b49dd116ca00a46a11d5a4d8d7987f05ed9cd7
- https://git.kernel.org/stable/c/a388d10961ff8578b1a6691945d406c0f33aa71b
- https://git.kernel.org/stable/c/a54754ec9891830ba548e2010c889e3c8146e449
- https://git.kernel.org/stable/c/c77e2ef18167ad334e27610ced9a7f6af5ec1787
- https://git.kernel.org/stable/c/efcd730ddd6f25578bd31bfe703e593e2421d708
Modified: 2024-12-24
CVE-2021-46993
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.
- https://git.kernel.org/stable/c/3da3f804b82a0a382d523a21acf4cf3bb35f936d
- https://git.kernel.org/stable/c/42ee47c7e3569d9a0e2cb5053c496d97d380472f
- https://git.kernel.org/stable/c/687f523c134b7f0bd040ee1230f6d17990d54172
- https://git.kernel.org/stable/c/6d2f8909a5fabb73fe2a63918117943986c39b6c
- https://git.kernel.org/stable/c/f7347c85490b92dd144fa1fba9e1eca501656ab3
- https://git.kernel.org/stable/c/3da3f804b82a0a382d523a21acf4cf3bb35f936d
- https://git.kernel.org/stable/c/42ee47c7e3569d9a0e2cb5053c496d97d380472f
- https://git.kernel.org/stable/c/687f523c134b7f0bd040ee1230f6d17990d54172
- https://git.kernel.org/stable/c/6d2f8909a5fabb73fe2a63918117943986c39b6c
- https://git.kernel.org/stable/c/f7347c85490b92dd144fa1fba9e1eca501656ab3
Modified: 2024-12-06
CVE-2021-46994
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()]
- https://git.kernel.org/stable/c/03c427147b2d3e503af258711af4fc792b89b0af
- https://git.kernel.org/stable/c/6f8f1c27b577de15f69fefce3c502bb6300d825c
- https://git.kernel.org/stable/c/e1e10a390fd9479209c4d834d916ca5e6d5d396b
- https://git.kernel.org/stable/c/eecb4df8ec9f896b19ee05bfa632ac6c1dcd8f21
- https://git.kernel.org/stable/c/03c427147b2d3e503af258711af4fc792b89b0af
- https://git.kernel.org/stable/c/6f8f1c27b577de15f69fefce3c502bb6300d825c
- https://git.kernel.org/stable/c/e1e10a390fd9479209c4d834d916ca5e6d5d396b
- https://git.kernel.org/stable/c/eecb4df8ec9f896b19ee05bfa632ac6c1dcd8f21
Modified: 2024-12-06
CVE-2021-46996
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.
- https://git.kernel.org/stable/c/2c784a500f5edd337258b0fdb2f31bc9abde1a23
- https://git.kernel.org/stable/c/59fa98bfa1f4013d658d990cac88c87b46ff410c
- https://git.kernel.org/stable/c/85dfd816fabfc16e71786eda0a33a7046688b5b0
- https://git.kernel.org/stable/c/dd3bebf515f336214a91994348a2b86b9a1d3d7f
- https://git.kernel.org/stable/c/2c784a500f5edd337258b0fdb2f31bc9abde1a23
- https://git.kernel.org/stable/c/59fa98bfa1f4013d658d990cac88c87b46ff410c
- https://git.kernel.org/stable/c/85dfd816fabfc16e71786eda0a33a7046688b5b0
- https://git.kernel.org/stable/c/dd3bebf515f336214a91994348a2b86b9a1d3d7f
Modified: 2024-12-24
CVE-2021-46997
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
- https://git.kernel.org/stable/c/4d6a38da8e79e94cbd1344aa90876f0f805db705
- https://git.kernel.org/stable/c/51524fa8b5f7b879ba569227738375d283b79382
- https://git.kernel.org/stable/c/d8d52005f57bbb4a4ec02f647e2555d327135c68
- https://git.kernel.org/stable/c/e67a83f078005461b59b4c776e6b5addd11725fa
- https://git.kernel.org/stable/c/4d6a38da8e79e94cbd1344aa90876f0f805db705
- https://git.kernel.org/stable/c/51524fa8b5f7b879ba569227738375d283b79382
- https://git.kernel.org/stable/c/d8d52005f57bbb4a4ec02f647e2555d327135c68
- https://git.kernel.org/stable/c/e67a83f078005461b59b4c776e6b5addd11725fa
Modified: 2024-12-06
CVE-2021-46998
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.
- https://git.kernel.org/stable/c/25a87b1f566b5eb2af2857a928f0e2310d900976
- https://git.kernel.org/stable/c/643001b47adc844ae33510c4bb93c236667008a3
- https://git.kernel.org/stable/c/6892396ebf04ea2c021d80e10f4075e014cd7cc3
- https://git.kernel.org/stable/c/7afdd6aba95c8a526038e7abe283eeac3e4320f1
- https://git.kernel.org/stable/c/d90529392aaf498dafa95d212295d64b2cea4e24
- https://git.kernel.org/stable/c/f7f6f07774091a6ddd98500b85386c3c6afb30d3
- https://git.kernel.org/stable/c/25a87b1f566b5eb2af2857a928f0e2310d900976
- https://git.kernel.org/stable/c/643001b47adc844ae33510c4bb93c236667008a3
- https://git.kernel.org/stable/c/6892396ebf04ea2c021d80e10f4075e014cd7cc3
- https://git.kernel.org/stable/c/7afdd6aba95c8a526038e7abe283eeac3e4320f1
- https://git.kernel.org/stable/c/d90529392aaf498dafa95d212295d64b2cea4e24
- https://git.kernel.org/stable/c/f7f6f07774091a6ddd98500b85386c3c6afb30d3
Modified: 2025-01-08
CVE-2021-46999
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.
- https://git.kernel.org/stable/c/0bfd913c2121b3d553bfd52810fe6061d542d625
- https://git.kernel.org/stable/c/35b4f24415c854cd718ccdf38dbea6297f010aae
- https://git.kernel.org/stable/c/61b877bad9bb0d82b7d8841be50872557090a704
- https://git.kernel.org/stable/c/b1b31948c0af44628e43353828453461bb74098f
- https://git.kernel.org/stable/c/d624f2991b977821375fbd56c91b0c91d456a697
- https://git.kernel.org/stable/c/f01988ecf3654f805282dce2d3bb9afe68d2691e
- https://git.kernel.org/stable/c/0bfd913c2121b3d553bfd52810fe6061d542d625
- https://git.kernel.org/stable/c/35b4f24415c854cd718ccdf38dbea6297f010aae
- https://git.kernel.org/stable/c/61b877bad9bb0d82b7d8841be50872557090a704
- https://git.kernel.org/stable/c/b1b31948c0af44628e43353828453461bb74098f
- https://git.kernel.org/stable/c/d624f2991b977821375fbd56c91b0c91d456a697
- https://git.kernel.org/stable/c/f01988ecf3654f805282dce2d3bb9afe68d2691e
Modified: 2025-03-14
CVE-2021-47000
In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode leak on getattr error in __fh_to_dentry
- https://git.kernel.org/stable/c/0a219432127d396120fc88cabd82785e0ff72a2f
- https://git.kernel.org/stable/c/1775c7ddacfcea29051c67409087578f8f4d751b
- https://git.kernel.org/stable/c/22fa4c8288f1ec40f6d62d7a32c57ac176f9f0bc
- https://git.kernel.org/stable/c/2ad8af2b70e986284050213230428b823b950a38
- https://git.kernel.org/stable/c/bf45c9fe99aa8003d2703f1bd353f956dea47e40
- https://git.kernel.org/stable/c/0a219432127d396120fc88cabd82785e0ff72a2f
- https://git.kernel.org/stable/c/1775c7ddacfcea29051c67409087578f8f4d751b
- https://git.kernel.org/stable/c/22fa4c8288f1ec40f6d62d7a32c57ac176f9f0bc
- https://git.kernel.org/stable/c/2ad8af2b70e986284050213230428b823b950a38
- https://git.kernel.org/stable/c/bf45c9fe99aa8003d2703f1bd353f956dea47e40
Modified: 2025-04-11
CVE-2021-47001
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().
- https://git.kernel.org/stable/c/19b5fa9489b5706bc878c3a522a7f771079e2fa0
- https://git.kernel.org/stable/c/35d8b10a25884050bb3b0149b62c3818ec59f77c
- https://git.kernel.org/stable/c/8834ecb5df22b7ff3c9b0deba7726579bb613f95
- https://git.kernel.org/stable/c/eddae8be7944096419c2ae29477a45f767d0fcd4
- https://git.kernel.org/stable/c/19b5fa9489b5706bc878c3a522a7f771079e2fa0
- https://git.kernel.org/stable/c/35d8b10a25884050bb3b0149b62c3818ec59f77c
- https://git.kernel.org/stable/c/8834ecb5df22b7ff3c9b0deba7726579bb613f95
- https://git.kernel.org/stable/c/eddae8be7944096419c2ae29477a45f767d0fcd4
- https://security.netapp.com/advisory/ntap-20250411-0001/
Modified: 2024-12-09
CVE-2021-47003
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")
- https://git.kernel.org/stable/c/2280b4cc29d8cdd2be3d1b2d1ea4f958e2131c97
- https://git.kernel.org/stable/c/28ac8e03c43dfc6a703aa420d18222540b801120
- https://git.kernel.org/stable/c/5756f757c72501ef1a16f5f63f940623044180e9
- https://git.kernel.org/stable/c/7bc402f843e7817a4a808e7b9ab0bcd7ffd55bfa
- https://git.kernel.org/stable/c/2280b4cc29d8cdd2be3d1b2d1ea4f958e2131c97
- https://git.kernel.org/stable/c/28ac8e03c43dfc6a703aa420d18222540b801120
- https://git.kernel.org/stable/c/5756f757c72501ef1a16f5f63f940623044180e9
- https://git.kernel.org/stable/c/7bc402f843e7817a4a808e7b9ab0bcd7ffd55bfa
Modified: 2025-01-08
CVE-2021-47004
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.
- https://git.kernel.org/stable/c/105155a8146ddb54c119d8318964eef3859d109d
- https://git.kernel.org/stable/c/1e116f87825f01a6380286472196882746b16f63
- https://git.kernel.org/stable/c/211372b2571520e394b56b431a0705586013b3ff
- https://git.kernel.org/stable/c/61461fc921b756ae16e64243f72af2bfc2e620db
- https://git.kernel.org/stable/c/105155a8146ddb54c119d8318964eef3859d109d
- https://git.kernel.org/stable/c/1e116f87825f01a6380286472196882746b16f63
- https://git.kernel.org/stable/c/211372b2571520e394b56b431a0705586013b3ff
- https://git.kernel.org/stable/c/61461fc921b756ae16e64243f72af2bfc2e620db
Modified: 2024-12-09
CVE-2021-47005
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 ]---
- https://git.kernel.org/stable/c/0169d4f0bee44fdfef908c13ed21fcb326c38695
- https://git.kernel.org/stable/c/6613bc2301ba291a1c5a90e1dc24cf3edf223c03
- https://git.kernel.org/stable/c/679ebad058b8168f10e63876d63b0877fd2fe784
- https://git.kernel.org/stable/c/bbed83d7060e07a5d309104d25a00f0a24441428
- https://git.kernel.org/stable/c/0169d4f0bee44fdfef908c13ed21fcb326c38695
- https://git.kernel.org/stable/c/6613bc2301ba291a1c5a90e1dc24cf3edf223c03
- https://git.kernel.org/stable/c/679ebad058b8168f10e63876d63b0877fd2fe784
- https://git.kernel.org/stable/c/bbed83d7060e07a5d309104d25a00f0a24441428
Modified: 2025-03-19
CVE-2021-47006
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/
- https://git.kernel.org/stable/c/3ed8832aeaa9a37b0fc386bb72ff604352567c80
- https://git.kernel.org/stable/c/555a70f7fff03bd669123487905c47ae27dbdaac
- https://git.kernel.org/stable/c/630146203108bf6b8934eec0dfdb3e46dcb917de
- https://git.kernel.org/stable/c/7eeacc6728c5478e3c01bc82a1f08958eaa12366
- https://git.kernel.org/stable/c/a506bd5756290821a4314f502b4bafc2afcf5260
- https://git.kernel.org/stable/c/a9938d6d78a238d6ab8de57a4d3dcf77adceb9bb
- https://git.kernel.org/stable/c/dabe299425b1a53a69461fed7ac8922ea6733a25
- https://git.kernel.org/stable/c/ed1f67465327cec4457bb988775245b199da86e6
- https://git.kernel.org/stable/c/3ed8832aeaa9a37b0fc386bb72ff604352567c80
- https://git.kernel.org/stable/c/555a70f7fff03bd669123487905c47ae27dbdaac
- https://git.kernel.org/stable/c/630146203108bf6b8934eec0dfdb3e46dcb917de
- https://git.kernel.org/stable/c/7eeacc6728c5478e3c01bc82a1f08958eaa12366
- https://git.kernel.org/stable/c/a506bd5756290821a4314f502b4bafc2afcf5260
- https://git.kernel.org/stable/c/a9938d6d78a238d6ab8de57a4d3dcf77adceb9bb
- https://git.kernel.org/stable/c/dabe299425b1a53a69461fed7ac8922ea6733a25
- https://git.kernel.org/stable/c/ed1f67465327cec4457bb988775245b199da86e6
Modified: 2025-01-08
CVE-2021-47007
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().
- https://git.kernel.org/stable/c/1c20a4896409f5ca1c770e1880c33d0a28a8b10f
- https://git.kernel.org/stable/c/3ab0598e6d860ef49d029943ba80f627c15c15d6
- https://git.kernel.org/stable/c/822054e5026c43b1dd60cf387dd999e95ee2ecc2
- https://git.kernel.org/stable/c/860afd680d9cc1dabd61cda3cd246f60aa1eb705
- https://git.kernel.org/stable/c/1c20a4896409f5ca1c770e1880c33d0a28a8b10f
- https://git.kernel.org/stable/c/3ab0598e6d860ef49d029943ba80f627c15c15d6
- https://git.kernel.org/stable/c/822054e5026c43b1dd60cf387dd999e95ee2ecc2
- https://git.kernel.org/stable/c/860afd680d9cc1dabd61cda3cd246f60aa1eb705
Modified: 2024-12-09
CVE-2021-47009
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]
- https://git.kernel.org/stable/c/1c4031014106aff48e1e686e40101c31eab5d44c
- https://git.kernel.org/stable/c/31c9a4b24d86cbb36ff0d7a085725a3b4f0138c8
- https://git.kernel.org/stable/c/3e24fbd37e72e8a67b74991970fecc82d14f57af
- https://git.kernel.org/stable/c/83a775d5f9bfda95b1c295f95a3a041a40c7f321
- https://git.kernel.org/stable/c/1c4031014106aff48e1e686e40101c31eab5d44c
- https://git.kernel.org/stable/c/31c9a4b24d86cbb36ff0d7a085725a3b4f0138c8
- https://git.kernel.org/stable/c/3e24fbd37e72e8a67b74991970fecc82d14f57af
- https://git.kernel.org/stable/c/83a775d5f9bfda95b1c295f95a3a041a40c7f321
Modified: 2025-03-19
CVE-2021-47010
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
- https://git.kernel.org/stable/c/6c1ea8bee75df8fe2184a50fcd0f70bf82986f42
- https://git.kernel.org/stable/c/8d432592f30fcc34ef5a10aac4887b4897884493
- https://git.kernel.org/stable/c/9884f745108f7d25b189bbcd6754e284fb29ab68
- https://git.kernel.org/stable/c/992de06308d9a9584d59b96d294ac676f924e437
- https://git.kernel.org/stable/c/e7d7bedd507bb732e600403b7a96f9fe48d0ca31
- https://git.kernel.org/stable/c/efe1532a6e1a8e3c343d04fff510f0ed80328f9c
- https://git.kernel.org/stable/c/6c1ea8bee75df8fe2184a50fcd0f70bf82986f42
- https://git.kernel.org/stable/c/8d432592f30fcc34ef5a10aac4887b4897884493
- https://git.kernel.org/stable/c/9884f745108f7d25b189bbcd6754e284fb29ab68
- https://git.kernel.org/stable/c/992de06308d9a9584d59b96d294ac676f924e437
- https://git.kernel.org/stable/c/e7d7bedd507bb732e600403b7a96f9fe48d0ca31
- https://git.kernel.org/stable/c/efe1532a6e1a8e3c343d04fff510f0ed80328f9c
Modified: 2025-01-08
CVE-2021-47011
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().
- https://git.kernel.org/stable/c/31df8bc4d3feca9f9c6b2cd06fd64a111ae1a0e6
- https://git.kernel.org/stable/c/89b1ed358e01e1b0417f5d3b0082359a23355552
- https://git.kernel.org/stable/c/9f38f03ae8d5f57371b71aa6b4275765b65454fd
- https://git.kernel.org/stable/c/c3ae6a3f3ca4f02f6ccddf213c027302586580d0
- https://git.kernel.org/stable/c/31df8bc4d3feca9f9c6b2cd06fd64a111ae1a0e6
- https://git.kernel.org/stable/c/89b1ed358e01e1b0417f5d3b0082359a23355552
- https://git.kernel.org/stable/c/9f38f03ae8d5f57371b71aa6b4275765b65454fd
- https://git.kernel.org/stable/c/c3ae6a3f3ca4f02f6ccddf213c027302586580d0
Modified: 2024-12-09
CVE-2021-47012
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.
- https://git.kernel.org/stable/c/3093ee182f01689b89e9f8797b321603e5de4f63
- https://git.kernel.org/stable/c/30b9e92d0b5e5d5dc1101ab856c17009537cbca4
- https://git.kernel.org/stable/c/3e22b88e02c194f6c80867abfef5cc09383461f4
- https://git.kernel.org/stable/c/608a4b90ece039940e9425ee2b39c8beff27e00c
- https://git.kernel.org/stable/c/ad9ce7188432650469a6c7625bf479f5ed0b6155
- https://git.kernel.org/stable/c/3093ee182f01689b89e9f8797b321603e5de4f63
- https://git.kernel.org/stable/c/30b9e92d0b5e5d5dc1101ab856c17009537cbca4
- https://git.kernel.org/stable/c/3e22b88e02c194f6c80867abfef5cc09383461f4
- https://git.kernel.org/stable/c/608a4b90ece039940e9425ee2b39c8beff27e00c
- https://git.kernel.org/stable/c/ad9ce7188432650469a6c7625bf479f5ed0b6155
Modified: 2024-12-09
CVE-2021-47013
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.
- https://git.kernel.org/stable/c/16d8c44be52e3650917736d45f5904384a9da834
- https://git.kernel.org/stable/c/55fcdd1258faaecca74b91b88cc0921f9edd775d
- https://git.kernel.org/stable/c/6d72e7c767acbbdd44ebc7d89c6690b405b32b57
- https://git.kernel.org/stable/c/8c06f34785068b87e2b560534c77c163d6c6dca7
- https://git.kernel.org/stable/c/9dc373f74097edd0e35f3393d6248eda8d1ba99d
- https://git.kernel.org/stable/c/c7f75d11fe72913d2619f97b2334b083cd7bb955
- https://git.kernel.org/stable/c/dc1b438a35773d030be0ee80d9c635c3e558a322
- https://git.kernel.org/stable/c/e407495ba6788a67d1bd41714158c079e340879b
- https://git.kernel.org/stable/c/16d8c44be52e3650917736d45f5904384a9da834
- https://git.kernel.org/stable/c/55fcdd1258faaecca74b91b88cc0921f9edd775d
- https://git.kernel.org/stable/c/6d72e7c767acbbdd44ebc7d89c6690b405b32b57
- https://git.kernel.org/stable/c/8c06f34785068b87e2b560534c77c163d6c6dca7
- https://git.kernel.org/stable/c/9dc373f74097edd0e35f3393d6248eda8d1ba99d
- https://git.kernel.org/stable/c/c7f75d11fe72913d2619f97b2334b083cd7bb955
- https://git.kernel.org/stable/c/dc1b438a35773d030be0ee80d9c635c3e558a322
- https://git.kernel.org/stable/c/e407495ba6788a67d1bd41714158c079e340879b
Modified: 2025-01-08
CVE-2021-47015
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
- https://git.kernel.org/stable/c/3fbc5bc651d688fbea2a59cdc91520a2f5334d0a
- https://git.kernel.org/stable/c/4fcaad2b7dac3f16704f8118c7e481024ddbd3ed
- https://git.kernel.org/stable/c/b1523e4ba293b2a32d9fabaf70c1dcaa6e3e2847
- https://git.kernel.org/stable/c/bbd6f0a948139970f4a615dff189d9a503681a39
- https://git.kernel.org/stable/c/e187ef83c04a5d23e68d39cfdff1a1931e29890c
- https://git.kernel.org/stable/c/3fbc5bc651d688fbea2a59cdc91520a2f5334d0a
- https://git.kernel.org/stable/c/4fcaad2b7dac3f16704f8118c7e481024ddbd3ed
- https://git.kernel.org/stable/c/b1523e4ba293b2a32d9fabaf70c1dcaa6e3e2847
- https://git.kernel.org/stable/c/bbd6f0a948139970f4a615dff189d9a503681a39
- https://git.kernel.org/stable/c/e187ef83c04a5d23e68d39cfdff1a1931e29890c
Modified: 2025-01-09
CVE-2021-47016
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.
- https://git.kernel.org/stable/c/1dfb26df15fc7036a74221d43de7427f74293dae
- https://git.kernel.org/stable/c/43262178c043032e7c42d00de44c818ba05f9967
- https://git.kernel.org/stable/c/5d34225169346cab5145978d153b9ce90e9ace21
- https://git.kernel.org/stable/c/73fdeb612d25b5e105c219e05434285a45d23576
- https://git.kernel.org/stable/c/f6a90818a32058fca62cda3a2027a6a2364e1878
- https://git.kernel.org/stable/c/1dfb26df15fc7036a74221d43de7427f74293dae
- https://git.kernel.org/stable/c/43262178c043032e7c42d00de44c818ba05f9967
- https://git.kernel.org/stable/c/5d34225169346cab5145978d153b9ce90e9ace21
- https://git.kernel.org/stable/c/73fdeb612d25b5e105c219e05434285a45d23576
- https://git.kernel.org/stable/c/f6a90818a32058fca62cda3a2027a6a2364e1878
Modified: 2024-12-09
CVE-2021-47017
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.
- https://git.kernel.org/stable/c/3b1ac40c6012140828caa79e592a438a18ebf71b
- https://git.kernel.org/stable/c/5e413c0831ff4700d1739db3fa3ae9f859744676
- https://git.kernel.org/stable/c/8392df5d7e0b6a7d21440da1fc259f9938f4dec3
- https://git.kernel.org/stable/c/8bb054fb336f4250002fff4e0b075221c05c3c65
- https://git.kernel.org/stable/c/3b1ac40c6012140828caa79e592a438a18ebf71b
- https://git.kernel.org/stable/c/5e413c0831ff4700d1739db3fa3ae9f859744676
- https://git.kernel.org/stable/c/8392df5d7e0b6a7d21440da1fc259f9938f4dec3
- https://git.kernel.org/stable/c/8bb054fb336f4250002fff4e0b075221c05c3c65
Modified: 2025-01-08
CVE-2021-47018
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.
- https://git.kernel.org/stable/c/4b9fb2c9039a206d37f215936a4d5bee7b1bf9cd
- https://git.kernel.org/stable/c/9ccba66d4d2aff9a3909aa77d57ea8b7cc166f3c
- https://git.kernel.org/stable/c/a84df7c80bdac598d6ac9268ae578da6928883e8
- https://git.kernel.org/stable/c/abb07dc5e8b61ab7b1dde20dd73aa01a3aeb183f
- https://git.kernel.org/stable/c/4b9fb2c9039a206d37f215936a4d5bee7b1bf9cd
- https://git.kernel.org/stable/c/9ccba66d4d2aff9a3909aa77d57ea8b7cc166f3c
- https://git.kernel.org/stable/c/a84df7c80bdac598d6ac9268ae578da6928883e8
- https://git.kernel.org/stable/c/abb07dc5e8b61ab7b1dde20dd73aa01a3aeb183f
Modified: 2024-12-10
CVE-2021-47020
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.
- https://git.kernel.org/stable/c/2f17ac005b320c85d686088cfd4c2e7017912b88
- https://git.kernel.org/stable/c/342260fe821047c3d515e3d28085d73fbdce3e80
- https://git.kernel.org/stable/c/48f17f96a81763c7c8bf5500460a359b9939359f
- https://git.kernel.org/stable/c/7c468deae306d0cbbd539408c26cfec04c66159a
- https://git.kernel.org/stable/c/870533403ffa28ff63e173045fc5369365642002
- https://git.kernel.org/stable/c/effd2bd62b416f6629e18e3ce077c60de14cfdea
- https://git.kernel.org/stable/c/2f17ac005b320c85d686088cfd4c2e7017912b88
- https://git.kernel.org/stable/c/342260fe821047c3d515e3d28085d73fbdce3e80
- https://git.kernel.org/stable/c/48f17f96a81763c7c8bf5500460a359b9939359f
- https://git.kernel.org/stable/c/7c468deae306d0cbbd539408c26cfec04c66159a
- https://git.kernel.org/stable/c/870533403ffa28ff63e173045fc5369365642002
- https://git.kernel.org/stable/c/effd2bd62b416f6629e18e3ce077c60de14cfdea
Modified: 2024-12-09
CVE-2021-47022
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().
- https://git.kernel.org/stable/c/107bcbb219ac84d885ac63b25246f8d33212bc47
- https://git.kernel.org/stable/c/4fa28c807da54c1d720b3cc12e48eb9bea1e2c8f
- https://git.kernel.org/stable/c/6c5b2b0c6e5a6ce2d8f9f85b8b72bfad60eaa506
- https://git.kernel.org/stable/c/8ab31da7b89f71c4c2defcca989fab7b42f87d71
- https://git.kernel.org/stable/c/107bcbb219ac84d885ac63b25246f8d33212bc47
- https://git.kernel.org/stable/c/4fa28c807da54c1d720b3cc12e48eb9bea1e2c8f
- https://git.kernel.org/stable/c/6c5b2b0c6e5a6ce2d8f9f85b8b72bfad60eaa506
- https://git.kernel.org/stable/c/8ab31da7b89f71c4c2defcca989fab7b42f87d71
Modified: 2025-03-19
CVE-2021-47023
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 ]---
- https://git.kernel.org/stable/c/0ce6052802be2cb61a57b753e41301339c88c839
- https://git.kernel.org/stable/c/333980481b99edb24ebd5d1a53af70a15d9146de
- https://git.kernel.org/stable/c/9d1ba11fabdd8f25abb24272ef1621417981320b
- https://git.kernel.org/stable/c/b5bba6ede42693f50ce1c9944315cefed7491061
- https://git.kernel.org/stable/c/0ce6052802be2cb61a57b753e41301339c88c839
- https://git.kernel.org/stable/c/333980481b99edb24ebd5d1a53af70a15d9146de
- https://git.kernel.org/stable/c/9d1ba11fabdd8f25abb24272ef1621417981320b
- https://git.kernel.org/stable/c/b5bba6ede42693f50ce1c9944315cefed7491061
Modified: 2024-12-06
CVE-2021-47024
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
- https://git.kernel.org/stable/c/27691665145e74a45034a9dccf1150cf1894763a
- https://git.kernel.org/stable/c/37c38674ef2f8d7e8629e5d433c37d6c1273d16b
- https://git.kernel.org/stable/c/8432b8114957235f42e070a16118a7f750de9d39
- https://git.kernel.org/stable/c/b605673b523fe33abeafb2136759bcbc9c1e6ebf
- https://git.kernel.org/stable/c/27691665145e74a45034a9dccf1150cf1894763a
- https://git.kernel.org/stable/c/37c38674ef2f8d7e8629e5d433c37d6c1273d16b
- https://git.kernel.org/stable/c/8432b8114957235f42e070a16118a7f750de9d39
- https://git.kernel.org/stable/c/b605673b523fe33abeafb2136759bcbc9c1e6ebf
Modified: 2025-01-09
CVE-2021-47026
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.
- https://git.kernel.org/stable/c/676171f9405dcaa45a33d18241c32f387dbaae39
- https://git.kernel.org/stable/c/7f4a8592ff29f19c5a2ca549d0973821319afaad
- https://git.kernel.org/stable/c/b64415c6b3476cf9fa4d0aea3807065b8403a937
- https://git.kernel.org/stable/c/d3cca8067d43dfee4a3535c645b55f618708dccb
- https://git.kernel.org/stable/c/676171f9405dcaa45a33d18241c32f387dbaae39
- https://git.kernel.org/stable/c/7f4a8592ff29f19c5a2ca549d0973821319afaad
- https://git.kernel.org/stable/c/b64415c6b3476cf9fa4d0aea3807065b8403a937
- https://git.kernel.org/stable/c/d3cca8067d43dfee4a3535c645b55f618708dccb
Modified: 2024-12-12
CVE-2021-47032
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
- https://git.kernel.org/stable/c/4a9dcd6efb2a268fc5707dcfb3b0c412975c4462
- https://git.kernel.org/stable/c/4e7914ce23306b28d377ec395e00e5fde0e6f96e
- https://git.kernel.org/stable/c/7dcf3c04f0aca746517a77433b33d40868ca4749
- https://git.kernel.org/stable/c/e2cdc9cb33c5963efe1a7c022753386f9463d1b7
- https://git.kernel.org/stable/c/4a9dcd6efb2a268fc5707dcfb3b0c412975c4462
- https://git.kernel.org/stable/c/4e7914ce23306b28d377ec395e00e5fde0e6f96e
- https://git.kernel.org/stable/c/7dcf3c04f0aca746517a77433b33d40868ca4749
- https://git.kernel.org/stable/c/e2cdc9cb33c5963efe1a7c022753386f9463d1b7
Modified: 2024-12-12
CVE-2021-47033
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
- https://git.kernel.org/stable/c/75bc5f779a7664d1fc19cb915039439c6e58bb94
- https://git.kernel.org/stable/c/821ae236ccea989a1fcc6abfc4d5b74ad4ba39d2
- https://git.kernel.org/stable/c/a025277a80add18c33d01042525a74fe5b875f25
- https://git.kernel.org/stable/c/ebee7885bb12a8fe2c2f9bac87dbd87a05b645f9
- https://git.kernel.org/stable/c/75bc5f779a7664d1fc19cb915039439c6e58bb94
- https://git.kernel.org/stable/c/821ae236ccea989a1fcc6abfc4d5b74ad4ba39d2
- https://git.kernel.org/stable/c/a025277a80add18c33d01042525a74fe5b875f25
- https://git.kernel.org/stable/c/ebee7885bb12a8fe2c2f9bac87dbd87a05b645f9
Modified: 2025-04-03
CVE-2021-47034
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
- https://git.kernel.org/stable/c/01ac203e2119d8922126886ddea309fb676f955f
- https://git.kernel.org/stable/c/73f9dccb29e4f82574bec2765c0090cdb0404301
- https://git.kernel.org/stable/c/84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f
- https://git.kernel.org/stable/c/b3d5d0983388d6c4fb35f7d722556d5595f167a7
- https://git.kernel.org/stable/c/b8b2f37cf632434456182e9002d63cbc4cccc50c
- https://git.kernel.org/stable/c/e40c52ee67b155ad59f59e73ea136d02685f0e0d
- https://git.kernel.org/stable/c/01ac203e2119d8922126886ddea309fb676f955f
- https://git.kernel.org/stable/c/73f9dccb29e4f82574bec2765c0090cdb0404301
- https://git.kernel.org/stable/c/84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f
- https://git.kernel.org/stable/c/b3d5d0983388d6c4fb35f7d722556d5595f167a7
- https://git.kernel.org/stable/c/b8b2f37cf632434456182e9002d63cbc4cccc50c
- https://git.kernel.org/stable/c/e40c52ee67b155ad59f59e73ea136d02685f0e0d
Modified: 2025-01-24
CVE-2021-47035
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.
- https://git.kernel.org/stable/c/25faff78138933244c678c7fc78f7c0340fa04a0
- https://git.kernel.org/stable/c/66c24699f266ff310381a9552d3576eea8ad6e20
- https://git.kernel.org/stable/c/89bd620798704a8805fc9db0d71d7f812cf5b3d2
- https://git.kernel.org/stable/c/eea53c5816889ee8b64544fa2e9311a81184ff9c
- https://git.kernel.org/stable/c/25faff78138933244c678c7fc78f7c0340fa04a0
- https://git.kernel.org/stable/c/66c24699f266ff310381a9552d3576eea8ad6e20
- https://git.kernel.org/stable/c/89bd620798704a8805fc9db0d71d7f812cf5b3d2
- https://git.kernel.org/stable/c/c848416cc05afc1589edba04fe00b85c2f797ee3
- https://git.kernel.org/stable/c/eea53c5816889ee8b64544fa2e9311a81184ff9c
Modified: 2024-12-06
CVE-2021-47038
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---
- https://git.kernel.org/stable/c/17486960d79b900c45e0bb8fbcac0262848582ba
- https://git.kernel.org/stable/c/332e69eb3bd90370f2d9f2c2ca7974ff523dea17
- https://git.kernel.org/stable/c/7cc0ba67883c6c8d3bddb283f56c167fc837a555
- https://git.kernel.org/stable/c/fee71f480bc1dec5f6ae3b0b185ff12a62bceabc
- https://git.kernel.org/stable/c/17486960d79b900c45e0bb8fbcac0262848582ba
- https://git.kernel.org/stable/c/332e69eb3bd90370f2d9f2c2ca7974ff523dea17
- https://git.kernel.org/stable/c/7cc0ba67883c6c8d3bddb283f56c167fc837a555
- https://git.kernel.org/stable/c/fee71f480bc1dec5f6ae3b0b185ff12a62bceabc
Modified: 2025-01-09
CVE-2021-47040
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_
- https://git.kernel.org/stable/c/38134ada0ceea3e848fe993263c0ff6207fd46e7
- https://git.kernel.org/stable/c/51bf90901952aaac564bbdb36b2b503050c53dd9
- https://git.kernel.org/stable/c/84b8c266c4bfe9ed5128e13253c388deb74b1b03
- https://git.kernel.org/stable/c/cbbc13b115b8f18e0a714d89f87fbdc499acfe2d
- https://git.kernel.org/stable/c/38134ada0ceea3e848fe993263c0ff6207fd46e7
- https://git.kernel.org/stable/c/51bf90901952aaac564bbdb36b2b503050c53dd9
- https://git.kernel.org/stable/c/84b8c266c4bfe9ed5128e13253c388deb74b1b03
- https://git.kernel.org/stable/c/cbbc13b115b8f18e0a714d89f87fbdc499acfe2d
Modified: 2024-12-06
CVE-2021-47041
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): [
- https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5
- https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc
- https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da
- https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777
- https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722
- https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5
- https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc
- https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da
- https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777
- https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722
Modified: 2025-01-09
CVE-2021-47043
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.
- https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db5296057030
- https://git.kernel.org/stable/c/5a465c5391a856a0c1e9554964d660676c35d1b2
- https://git.kernel.org/stable/c/711acdf0228dc71601247f28b56f13e850e395c8
- https://git.kernel.org/stable/c/940d01eceb3a7866fbfca136a55a5625fc75a565
- https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db5296057030
- https://git.kernel.org/stable/c/5a465c5391a856a0c1e9554964d660676c35d1b2
- https://git.kernel.org/stable/c/711acdf0228dc71601247f28b56f13e850e395c8
- https://git.kernel.org/stable/c/940d01eceb3a7866fbfca136a55a5625fc75a565
Modified: 2025-03-19
CVE-2021-47044
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.
- https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54
- https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c8055026303b3aa681b49a5
- https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f
- https://git.kernel.org/stable/c/80862cbf76c2646f709a57c4517aefe0b094c774
- https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54
- https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c8055026303b3aa681b49a5
- https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f
- https://git.kernel.org/stable/c/80862cbf76c2646f709a57c4517aefe0b094c774
Modified: 2024-12-09
CVE-2021-47046
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.
- https://git.kernel.org/stable/c/080bd41d6478a64edf96704fddcda52b1fd5fed7
- https://git.kernel.org/stable/c/403c4528e5887af3deb9838cb77a557631d1e138
- https://git.kernel.org/stable/c/6a58310d5d1e5b02d0fc9b393ba540c9367bced5
- https://git.kernel.org/stable/c/8e6fafd5a22e7a2eb216f5510db7aab54cc545c1
- https://git.kernel.org/stable/c/080bd41d6478a64edf96704fddcda52b1fd5fed7
- https://git.kernel.org/stable/c/403c4528e5887af3deb9838cb77a557631d1e138
- https://git.kernel.org/stable/c/6a58310d5d1e5b02d0fc9b393ba540c9367bced5
- https://git.kernel.org/stable/c/8e6fafd5a22e7a2eb216f5510db7aab54cc545c1
Modified: 2025-01-10
CVE-2021-47047
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
- https://git.kernel.org/stable/c/126bdb606fd2802454e6048caef1be3e25dd121e
- https://git.kernel.org/stable/c/5980a3b9c933408bc22b0e349b78c3ebd7cbf880
- https://git.kernel.org/stable/c/bad5a23cf2b477fa78b85fd392736dae09a1e818
- https://git.kernel.org/stable/c/c26c026eb496261dbc0adbf606cc81989cd2038c
- https://git.kernel.org/stable/c/126bdb606fd2802454e6048caef1be3e25dd121e
- https://git.kernel.org/stable/c/5980a3b9c933408bc22b0e349b78c3ebd7cbf880
- https://git.kernel.org/stable/c/bad5a23cf2b477fa78b85fd392736dae09a1e818
- https://git.kernel.org/stable/c/c26c026eb496261dbc0adbf606cc81989cd2038c
Modified: 2024-12-09
CVE-2021-47048
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.
- https://git.kernel.org/stable/c/1231279389b5e638bc3b66b9741c94077aed4b5a
- https://git.kernel.org/stable/c/23269ac9f123eca3aea7682d3345c02e71ed696c
- https://git.kernel.org/stable/c/a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58
- https://git.kernel.org/stable/c/d67e0d6bd92ebbb0294e7062bbf5cdc773764e62
- https://git.kernel.org/stable/c/1231279389b5e638bc3b66b9741c94077aed4b5a
- https://git.kernel.org/stable/c/23269ac9f123eca3aea7682d3345c02e71ed696c
- https://git.kernel.org/stable/c/a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58
- https://git.kernel.org/stable/c/d67e0d6bd92ebbb0294e7062bbf5cdc773764e62
Modified: 2024-12-09
CVE-2021-47049
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.
- https://git.kernel.org/stable/c/2728f289b3270b0e273292b46c534421a33bbfd5
- https://git.kernel.org/stable/c/3e9bf43f7f7a46f21ec071cb47be92d0874c48da
- https://git.kernel.org/stable/c/d5c7b42c9f56ca46b286daa537d181bd7f69214f
- https://git.kernel.org/stable/c/f37dd5d1b5d38a79a4f7b8dd7bbb705505f05560
- https://git.kernel.org/stable/c/2728f289b3270b0e273292b46c534421a33bbfd5
- https://git.kernel.org/stable/c/3e9bf43f7f7a46f21ec071cb47be92d0874c48da
- https://git.kernel.org/stable/c/d5c7b42c9f56ca46b286daa537d181bd7f69214f
- https://git.kernel.org/stable/c/f37dd5d1b5d38a79a4f7b8dd7bbb705505f05560
Modified: 2024-12-09
CVE-2021-47050
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
- https://git.kernel.org/stable/c/59e27d7c94aa02da039b000d33c304c179395801
- https://git.kernel.org/stable/c/71bcc1b4a1743534d8abdcb57ff912e6bc390438
- https://git.kernel.org/stable/c/a74cb41af7dbe019e4096171f8bc641c7ce910ad
- https://git.kernel.org/stable/c/e16acc3a37f09e18835dc5d8014942c2ef6ca957
- https://git.kernel.org/stable/c/59e27d7c94aa02da039b000d33c304c179395801
- https://git.kernel.org/stable/c/71bcc1b4a1743534d8abdcb57ff912e6bc390438
- https://git.kernel.org/stable/c/a74cb41af7dbe019e4096171f8bc641c7ce910ad
- https://git.kernel.org/stable/c/e16acc3a37f09e18835dc5d8014942c2ef6ca957
Modified: 2024-12-09
CVE-2021-47051
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.
- https://git.kernel.org/stable/c/4a01ad002d2e03c399af536562693752af7c81b1
- https://git.kernel.org/stable/c/6a2b5cee0d31ab6cc51030c441135b0e31217282
- https://git.kernel.org/stable/c/a03675497970a93fcf25d81d9d92a59c2d7377a7
- https://git.kernel.org/stable/c/b8207bfc539cd07d15e753ff2d179c5b61c673b1
- https://git.kernel.org/stable/c/ce02e58ddf8658a4c3bed2296f32a5873b3f7cce
- https://git.kernel.org/stable/c/4a01ad002d2e03c399af536562693752af7c81b1
- https://git.kernel.org/stable/c/6a2b5cee0d31ab6cc51030c441135b0e31217282
- https://git.kernel.org/stable/c/a03675497970a93fcf25d81d9d92a59c2d7377a7
- https://git.kernel.org/stable/c/b8207bfc539cd07d15e753ff2d179c5b61c673b1
- https://git.kernel.org/stable/c/ce02e58ddf8658a4c3bed2296f32a5873b3f7cce
Modified: 2024-12-09
CVE-2021-47052
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")
- https://git.kernel.org/stable/c/0e596b3734649041ed77edc86a23c0442bbe062b
- https://git.kernel.org/stable/c/854b7737199848a91f6adfa0a03cf6f0c46c86e8
- https://git.kernel.org/stable/c/b7bd0657c2036add71981d88a7fae50188150b6e
- https://git.kernel.org/stable/c/dfd6443bf49ac17adf882ca46c40c506a0284bd6
- https://git.kernel.org/stable/c/0e596b3734649041ed77edc86a23c0442bbe062b
- https://git.kernel.org/stable/c/854b7737199848a91f6adfa0a03cf6f0c46c86e8
- https://git.kernel.org/stable/c/b7bd0657c2036add71981d88a7fae50188150b6e
- https://git.kernel.org/stable/c/dfd6443bf49ac17adf882ca46c40c506a0284bd6
Modified: 2024-12-09
CVE-2021-47053
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")
- https://git.kernel.org/stable/c/2c67a9333da9d0a3b87310e0d116b7c9070c7b00
- https://git.kernel.org/stable/c/50274b01ac1689b1a3f6bc4b5b3dbf361a55dd3a
- https://git.kernel.org/stable/c/c633e025bd04f54d7b33331cfcdb71354b08ce59
- https://git.kernel.org/stable/c/d3d702084d125689edb2b9395c707e09b471352e
- https://git.kernel.org/stable/c/2c67a9333da9d0a3b87310e0d116b7c9070c7b00
- https://git.kernel.org/stable/c/50274b01ac1689b1a3f6bc4b5b3dbf361a55dd3a
- https://git.kernel.org/stable/c/c633e025bd04f54d7b33331cfcdb71354b08ce59
- https://git.kernel.org/stable/c/d3d702084d125689edb2b9395c707e09b471352e
Modified: 2024-12-10
CVE-2021-47054
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.
- https://git.kernel.org/stable/c/00f6abd3509b1d70d0ab0fbe65ce5685cebed8be
- https://git.kernel.org/stable/c/3a76ec28824c01b57aa1f0927841d75e4f167cb8
- https://git.kernel.org/stable/c/6b68c03dfc79cd95a58dfd03f91f6e82829a1b0c
- https://git.kernel.org/stable/c/94810fc52925eb122a922df7f9966cf3f4ba7391
- https://git.kernel.org/stable/c/a399dd80e697a02cfb23e2fc09b87849994043d9
- https://git.kernel.org/stable/c/a6191e91c10e50bd51db65a00e03d02b6b0cf8c4
- https://git.kernel.org/stable/c/ac6ad7c2a862d682bb584a4bc904d89fa7721af8
- https://git.kernel.org/stable/c/c6f8e0dc8da1cd78d640dee392071cc2326ec1b2
- https://git.kernel.org/stable/c/00f6abd3509b1d70d0ab0fbe65ce5685cebed8be
- https://git.kernel.org/stable/c/3a76ec28824c01b57aa1f0927841d75e4f167cb8
- https://git.kernel.org/stable/c/6b68c03dfc79cd95a58dfd03f91f6e82829a1b0c
- https://git.kernel.org/stable/c/94810fc52925eb122a922df7f9966cf3f4ba7391
- https://git.kernel.org/stable/c/a399dd80e697a02cfb23e2fc09b87849994043d9
- https://git.kernel.org/stable/c/a6191e91c10e50bd51db65a00e03d02b6b0cf8c4
- https://git.kernel.org/stable/c/ac6ad7c2a862d682bb584a4bc904d89fa7721af8
- https://git.kernel.org/stable/c/c6f8e0dc8da1cd78d640dee392071cc2326ec1b2
Modified: 2025-01-09
CVE-2021-47055
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.
- https://git.kernel.org/stable/c/077259f5e777c3c8821f6b41dee709fcda27306b
- https://git.kernel.org/stable/c/1e97743fd180981bef5f01402342bb54bf1c6366
- https://git.kernel.org/stable/c/5880afefe0cb9b2d5e801816acd58bfe91a96981
- https://git.kernel.org/stable/c/75ed985bd6c8ac1d4e673e93ea9d96c9908c1d37
- https://git.kernel.org/stable/c/7b6552719c0ccbbea29dde4be141da54fdb5877e
- https://git.kernel.org/stable/c/9625b00cac6630479c0ff4b9fafa88bee636e1f0
- https://git.kernel.org/stable/c/a08799d3e8c8088640956237c183f83463c39668
- https://git.kernel.org/stable/c/f4d28d8b9b0e7c4ae04214b8d7e0b0466ec6bcaf
- https://git.kernel.org/stable/c/f73b29819c6314c0ba8b7d5892dfb03487424bee
- https://git.kernel.org/stable/c/077259f5e777c3c8821f6b41dee709fcda27306b
- https://git.kernel.org/stable/c/1e97743fd180981bef5f01402342bb54bf1c6366
- https://git.kernel.org/stable/c/5880afefe0cb9b2d5e801816acd58bfe91a96981
- https://git.kernel.org/stable/c/75ed985bd6c8ac1d4e673e93ea9d96c9908c1d37
- https://git.kernel.org/stable/c/7b6552719c0ccbbea29dde4be141da54fdb5877e
- https://git.kernel.org/stable/c/9625b00cac6630479c0ff4b9fafa88bee636e1f0
- https://git.kernel.org/stable/c/a08799d3e8c8088640956237c183f83463c39668
- https://git.kernel.org/stable/c/f4d28d8b9b0e7c4ae04214b8d7e0b0466ec6bcaf
- https://git.kernel.org/stable/c/f73b29819c6314c0ba8b7d5892dfb03487424bee
Modified: 2025-01-09
CVE-2021-47056
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]
- https://git.kernel.org/stable/c/05ec8192ee4bfdf2a8894a68350dac9f1a155fa6
- https://git.kernel.org/stable/c/09d16cee6285d37cc76311c29add6d97a7e4acda
- https://git.kernel.org/stable/c/1ea500ce6f7c9106e4a561d28e69215f3d451818
- https://git.kernel.org/stable/c/1f50392650ae794a1aea41c213c6a3e1c824413c
- https://git.kernel.org/stable/c/20fd40fc6f2c2b41dc6f637f88d494b14e9c21f1
- https://git.kernel.org/stable/c/446045cf682af12d9294765f6c46084b374b5654
- https://git.kernel.org/stable/c/8609f5cfdc872fc3a462efa6a3eca5cb1e2f6446
- https://git.kernel.org/stable/c/f4c4e07140687f42bfa40e091bb4a55d7960ce4d
- https://git.kernel.org/stable/c/05ec8192ee4bfdf2a8894a68350dac9f1a155fa6
- https://git.kernel.org/stable/c/09d16cee6285d37cc76311c29add6d97a7e4acda
- https://git.kernel.org/stable/c/1ea500ce6f7c9106e4a561d28e69215f3d451818
- https://git.kernel.org/stable/c/1f50392650ae794a1aea41c213c6a3e1c824413c
- https://git.kernel.org/stable/c/20fd40fc6f2c2b41dc6f637f88d494b14e9c21f1
- https://git.kernel.org/stable/c/446045cf682af12d9294765f6c46084b374b5654
- https://git.kernel.org/stable/c/8609f5cfdc872fc3a462efa6a3eca5cb1e2f6446
- https://git.kernel.org/stable/c/f4c4e07140687f42bfa40e091bb4a55d7960ce4d
Modified: 2025-03-19
CVE-2021-47057
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")
- https://git.kernel.org/stable/c/617ec35ed51f731a593ae7274228ef2cfc9cb781
- https://git.kernel.org/stable/c/6516cb852d704ff8d615de1f93cd443a99736c3d
- https://git.kernel.org/stable/c/98b5ef3e97b16eaeeedb936f8bda3594ff84a70e
- https://git.kernel.org/stable/c/e1f2d739849c3239df1ea3f97d40bade4b808410
- https://git.kernel.org/stable/c/617ec35ed51f731a593ae7274228ef2cfc9cb781
- https://git.kernel.org/stable/c/6516cb852d704ff8d615de1f93cd443a99736c3d
- https://git.kernel.org/stable/c/98b5ef3e97b16eaeeedb936f8bda3594ff84a70e
- https://git.kernel.org/stable/c/e1f2d739849c3239df1ea3f97d40bade4b808410
Modified: 2024-12-10
CVE-2021-47058
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.
- https://git.kernel.org/stable/c/2dc1554d5f0fdaf47cc5bea442b84b9226fea867
- https://git.kernel.org/stable/c/b9e569ae1da3a113b3acee8703c94777fd20938a
- https://git.kernel.org/stable/c/c764e375ae647832de1ee73d43a4bb3ef8a8f43d
- https://git.kernel.org/stable/c/d8897f7b2283a500666c85ef06e820df38ed7b52
- https://git.kernel.org/stable/c/e41a962f82e7afb5b1ee644f48ad0b3aee656268
- https://git.kernel.org/stable/c/eb949f891226c012138ffd9df90d1e509f428ae6
- https://git.kernel.org/stable/c/2dc1554d5f0fdaf47cc5bea442b84b9226fea867
- https://git.kernel.org/stable/c/b9e569ae1da3a113b3acee8703c94777fd20938a
- https://git.kernel.org/stable/c/c764e375ae647832de1ee73d43a4bb3ef8a8f43d
- https://git.kernel.org/stable/c/d8897f7b2283a500666c85ef06e820df38ed7b52
- https://git.kernel.org/stable/c/e41a962f82e7afb5b1ee644f48ad0b3aee656268
- https://git.kernel.org/stable/c/eb949f891226c012138ffd9df90d1e509f428ae6
Modified: 2024-12-10
CVE-2021-47059
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.
- https://git.kernel.org/stable/c/1dbc6a1e25be8575d6c4114d1d2b841a796507f7
- https://git.kernel.org/stable/c/1f12aaf07f61122cf5074d29714ee26f8d44b0e7
- https://git.kernel.org/stable/c/50e7b39b808430ad49a637dc6fb72ca93b451b13
- https://git.kernel.org/stable/c/ca065a93699f8cf3f42c60eefed73086007e928e
- https://git.kernel.org/stable/c/1dbc6a1e25be8575d6c4114d1d2b841a796507f7
- https://git.kernel.org/stable/c/1f12aaf07f61122cf5074d29714ee26f8d44b0e7
- https://git.kernel.org/stable/c/50e7b39b808430ad49a637dc6fb72ca93b451b13
- https://git.kernel.org/stable/c/ca065a93699f8cf3f42c60eefed73086007e928e
Modified: 2025-04-08
CVE-2021-47060
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.
- https://git.kernel.org/stable/c/168e82f640ed1891a700bdb43e37da354b2ab63c
- https://git.kernel.org/stable/c/2a20592baff59c5351c5200ec667e1a2aa22af85
- https://git.kernel.org/stable/c/50cbad42bfea8c052b7ca590bd4126cdc898713c
- https://git.kernel.org/stable/c/5d3c4c79384af06e3c8e25b7770b6247496b4417
- https://git.kernel.org/stable/c/7d1bc32d6477ff96a32695ea4be8144e4513ab2d
- https://git.kernel.org/stable/c/168e82f640ed1891a700bdb43e37da354b2ab63c
- https://git.kernel.org/stable/c/2a20592baff59c5351c5200ec667e1a2aa22af85
- https://git.kernel.org/stable/c/50cbad42bfea8c052b7ca590bd4126cdc898713c
- https://git.kernel.org/stable/c/5d3c4c79384af06e3c8e25b7770b6247496b4417
- https://git.kernel.org/stable/c/7d1bc32d6477ff96a32695ea4be8144e4513ab2d
Modified: 2024-12-10
CVE-2021-47061
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.
- https://git.kernel.org/stable/c/03c6cccedd3913006744faa252a4da5145299343
- https://git.kernel.org/stable/c/2ee3757424be7c1cd1d0bbfa6db29a7edd82a250
- https://git.kernel.org/stable/c/30f46c6993731efb2a690c9197c0fd9ed425da2d
- https://git.kernel.org/stable/c/4e899ca848636b37e9ac124bc1723862a7d7d927
- https://git.kernel.org/stable/c/03c6cccedd3913006744faa252a4da5145299343
- https://git.kernel.org/stable/c/2ee3757424be7c1cd1d0bbfa6db29a7edd82a250
- https://git.kernel.org/stable/c/30f46c6993731efb2a690c9197c0fd9ed425da2d
- https://git.kernel.org/stable/c/4e899ca848636b37e9ac124bc1723862a7d7d927
Modified: 2024-12-10
CVE-2021-47063
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
- https://git.kernel.org/stable/c/18149b420c9bd93c443e8d1f48a063d71d9f6aa1
- https://git.kernel.org/stable/c/4d906839d321c2efbf3fed4bc31ffd9ff55b75c0
- https://git.kernel.org/stable/c/98d7d76a74e48ec3ddf2e23950adff7edcab9327
- https://git.kernel.org/stable/c/ce450934a00cf896e648fde08d0bd1426653d7a2
- https://git.kernel.org/stable/c/18149b420c9bd93c443e8d1f48a063d71d9f6aa1
- https://git.kernel.org/stable/c/4d906839d321c2efbf3fed4bc31ffd9ff55b75c0
- https://git.kernel.org/stable/c/98d7d76a74e48ec3ddf2e23950adff7edcab9327
- https://git.kernel.org/stable/c/ce450934a00cf896e648fde08d0bd1426653d7a2
Modified: 2025-04-08
CVE-2021-47064
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
- https://git.kernel.org/stable/c/91b9548d413fda488ea853cd1b9f59b572db3a0c
- https://git.kernel.org/stable/c/9b68ce2856dadc0e1cb6fd21fbeb850da49efd08
- https://git.kernel.org/stable/c/9fa26701cd1fc4d932d431971efc5746325bdfce
- https://git.kernel.org/stable/c/b4403cee6400c5f679e9c4a82b91d61aa961eccf
- https://git.kernel.org/stable/c/91b9548d413fda488ea853cd1b9f59b572db3a0c
- https://git.kernel.org/stable/c/9b68ce2856dadc0e1cb6fd21fbeb850da49efd08
- https://git.kernel.org/stable/c/9fa26701cd1fc4d932d431971efc5746325bdfce
- https://git.kernel.org/stable/c/b4403cee6400c5f679e9c4a82b91d61aa961eccf
Modified: 2024-12-10
CVE-2021-47065
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")
- https://git.kernel.org/stable/c/2ff25985ea9ccc6c9af2c77b0b49045adcc62e0e
- https://git.kernel.org/stable/c/5f3dbced8eaa5c9ed7d6943f3fea99f235a6516a
- https://git.kernel.org/stable/c/6b5aa0cf321c25f41e09a61c83ee4dc7ab9549cb
- https://git.kernel.org/stable/c/95fb153c6027924cda3422120169d1890737f3a0
- https://git.kernel.org/stable/c/9cd09722e18a08b6a3d68b8bccfac39ddc22434c
- https://git.kernel.org/stable/c/2ff25985ea9ccc6c9af2c77b0b49045adcc62e0e
- https://git.kernel.org/stable/c/5f3dbced8eaa5c9ed7d6943f3fea99f235a6516a
- https://git.kernel.org/stable/c/6b5aa0cf321c25f41e09a61c83ee4dc7ab9549cb
- https://git.kernel.org/stable/c/95fb153c6027924cda3422120169d1890737f3a0
- https://git.kernel.org/stable/c/9cd09722e18a08b6a3d68b8bccfac39ddc22434c
Modified: 2025-01-09
CVE-2021-47066
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.
- https://git.kernel.org/stable/c/29ffa50f33de824b5491f8239c88c4a0efdd03af
- https://git.kernel.org/stable/c/53f8208e11abd6dde9480dfcb97fecdb1bc2ac18
- https://git.kernel.org/stable/c/cab2e8e5997b592fdb7d02cf2387b4b8e3057174
- https://git.kernel.org/stable/c/ceaf2966ab082bbc4d26516f97b3ca8a676e2af8
- https://git.kernel.org/stable/c/29ffa50f33de824b5491f8239c88c4a0efdd03af
- https://git.kernel.org/stable/c/53f8208e11abd6dde9480dfcb97fecdb1bc2ac18
- https://git.kernel.org/stable/c/cab2e8e5997b592fdb7d02cf2387b4b8e3057174
- https://git.kernel.org/stable/c/ceaf2966ab082bbc4d26516f97b3ca8a676e2af8
Modified: 2024-12-10
CVE-2021-47067
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.
- https://git.kernel.org/stable/c/a1ad124c836816fac8bd5e461d36eaf33cee4e24
- https://git.kernel.org/stable/c/dc4452867200fa94589b382740952b58aa1c3e6c
- https://git.kernel.org/stable/c/ef85bb582c41524e9e68dfdbde48e519dac4ab3d
- https://git.kernel.org/stable/c/ff39adf5d31c72025bba799aec69c5c86d81d549
- https://git.kernel.org/stable/c/a1ad124c836816fac8bd5e461d36eaf33cee4e24
- https://git.kernel.org/stable/c/dc4452867200fa94589b382740952b58aa1c3e6c
- https://git.kernel.org/stable/c/ef85bb582c41524e9e68dfdbde48e519dac4ab3d
- https://git.kernel.org/stable/c/ff39adf5d31c72025bba799aec69c5c86d81d549
Modified: 2025-04-22
CVE-2021-47068
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.
- https://git.kernel.org/stable/c/18175fe17ae043a0b81e5d511f8817825784c299
- https://git.kernel.org/stable/c/18ae4a192a4496e48a5490b52812645d2413307c
- https://git.kernel.org/stable/c/26157c82ba756767b2bd66d28a71b1bc454447f6
- https://git.kernel.org/stable/c/374cdde4dcc9c909a60713abdbbf96d5e3e09f91
- https://git.kernel.org/stable/c/48fba458fe54cc2a980a05c13e6c19b8b2cfb610
- https://git.kernel.org/stable/c/6b7021ed36dabf29e56842e3408781cd3b82ef6e
- https://git.kernel.org/stable/c/c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6
- https://git.kernel.org/stable/c/ccddad6dd28530e716448e594c9ca7c76ccd0570
- https://git.kernel.org/stable/c/e32352070bcac22be6ed8ab635debc280bb65b8c
- https://git.kernel.org/stable/c/18175fe17ae043a0b81e5d511f8817825784c299
- https://git.kernel.org/stable/c/18ae4a192a4496e48a5490b52812645d2413307c
- https://git.kernel.org/stable/c/26157c82ba756767b2bd66d28a71b1bc454447f6
- https://git.kernel.org/stable/c/374cdde4dcc9c909a60713abdbbf96d5e3e09f91
- https://git.kernel.org/stable/c/48fba458fe54cc2a980a05c13e6c19b8b2cfb610
- https://git.kernel.org/stable/c/6b7021ed36dabf29e56842e3408781cd3b82ef6e
- https://git.kernel.org/stable/c/c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6
- https://git.kernel.org/stable/c/ccddad6dd28530e716448e594c9ca7c76ccd0570
- https://git.kernel.org/stable/c/e32352070bcac22be6ed8ab635debc280bb65b8c
Modified: 2025-01-09
CVE-2021-47069
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.
- https://git.kernel.org/stable/c/4528c0c323085e645b8765913b4a7fd42cf49b65
- https://git.kernel.org/stable/c/807fa14536b26803b858da878b643be72952a097
- https://git.kernel.org/stable/c/a11ddb37bf367e6b5239b95ca759e5389bb46048
- https://git.kernel.org/stable/c/4528c0c323085e645b8765913b4a7fd42cf49b65
- https://git.kernel.org/stable/c/807fa14536b26803b858da878b643be72952a097
- https://git.kernel.org/stable/c/a11ddb37bf367e6b5239b95ca759e5389bb46048
Modified: 2024-12-12
CVE-2021-47071
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.
- https://git.kernel.org/stable/c/3ee098f96b8b6c1a98f7f97915f8873164e6af9d
- https://git.kernel.org/stable/c/53486c467e356e06aa37047c984fccd64d78c827
- https://git.kernel.org/stable/c/cdd91637d4ef33e2be19a8e16e72e7d00c996d76
- https://git.kernel.org/stable/c/d84b5e912212b05f6b5bde9f682046accfbe0354
- https://git.kernel.org/stable/c/3ee098f96b8b6c1a98f7f97915f8873164e6af9d
- https://git.kernel.org/stable/c/53486c467e356e06aa37047c984fccd64d78c827
- https://git.kernel.org/stable/c/cdd91637d4ef33e2be19a8e16e72e7d00c996d76
- https://git.kernel.org/stable/c/d84b5e912212b05f6b5bde9f682046accfbe0354
Modified: 2025-01-09
CVE-2021-47073
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.
- https://git.kernel.org/stable/c/0cf036a0d325200e6c27b90908e51195bbc557b1
- https://git.kernel.org/stable/c/3a53587423d25c87af4b4126a806a0575104b45e
- https://git.kernel.org/stable/c/6fa78a6b9a3beb676a010dc489c1257f7e432525
- https://git.kernel.org/stable/c/75cfc833da4a2111106d4c134e93e0c7f41e35e7
- https://git.kernel.org/stable/c/8d746ea7c687bab060a2c05a35c449302406cd52
- https://git.kernel.org/stable/c/0cf036a0d325200e6c27b90908e51195bbc557b1
- https://git.kernel.org/stable/c/3a53587423d25c87af4b4126a806a0575104b45e
- https://git.kernel.org/stable/c/6fa78a6b9a3beb676a010dc489c1257f7e432525
- https://git.kernel.org/stable/c/75cfc833da4a2111106d4c134e93e0c7f41e35e7
- https://git.kernel.org/stable/c/8d746ea7c687bab060a2c05a35c449302406cd52
Modified: 2024-12-12
CVE-2021-47074
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.
- https://git.kernel.org/stable/c/03504e3b54cc8118cc26c064e60a0b00c2308708
- https://git.kernel.org/stable/c/551ba08d4b7eb26f75758cdb9f15105b276517ad
- https://git.kernel.org/stable/c/9c980795ccd77e8abec33dd6fe28dfe1c4083e65
- https://git.kernel.org/stable/c/03504e3b54cc8118cc26c064e60a0b00c2308708
- https://git.kernel.org/stable/c/551ba08d4b7eb26f75758cdb9f15105b276517ad
- https://git.kernel.org/stable/c/9c980795ccd77e8abec33dd6fe28dfe1c4083e65
Modified: 2025-03-19
CVE-2021-47075
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.
- https://git.kernel.org/stable/c/4720f29acb3fe67aa8aa71e6b675b079d193aaeb
- https://git.kernel.org/stable/c/afb680ed7ecbb7fd66ddb43650e9b533fd8b4b9a
- https://git.kernel.org/stable/c/fec356a61aa3d3a66416b4321f1279e09e0f256f
- https://git.kernel.org/stable/c/4720f29acb3fe67aa8aa71e6b675b079d193aaeb
- https://git.kernel.org/stable/c/afb680ed7ecbb7fd66ddb43650e9b533fd8b4b9a
- https://git.kernel.org/stable/c/fec356a61aa3d3a66416b4321f1279e09e0f256f
Modified: 2024-12-10
CVE-2021-47077
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]
- https://git.kernel.org/stable/c/11014efcec378bb0050a6cf08eaf375e3693400a
- https://git.kernel.org/stable/c/73578af92a0fae6609b955fcc9113e50e413c80f
- https://git.kernel.org/stable/c/a6362a737572f66051deb7637f3f77ddf7a4402f
- https://git.kernel.org/stable/c/11014efcec378bb0050a6cf08eaf375e3693400a
- https://git.kernel.org/stable/c/73578af92a0fae6609b955fcc9113e50e413c80f
- https://git.kernel.org/stable/c/a6362a737572f66051deb7637f3f77ddf7a4402f
Modified: 2025-03-19
CVE-2021-47078
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---
- https://git.kernel.org/stable/c/03344e843ab6dd3b3f2cadfb65ed910590856c70
- https://git.kernel.org/stable/c/2ee4d79c364914989c80de382c0b1a7259a7e4b3
- https://git.kernel.org/stable/c/67f29896fdc83298eed5a6576ff8f9873f709228
- https://git.kernel.org/stable/c/6a8086a42dfbf548a42bf2ae4faa291645c72c66
- https://git.kernel.org/stable/c/a62225d951d77eb20208fed8fc199e0c9b1df08b
- https://git.kernel.org/stable/c/c65391dd9f0a47617e96e38bd27e277cbe1c40b0
- https://git.kernel.org/stable/c/f3783c415bf6d2ead3d7aa2c38802bbe10723646
- https://git.kernel.org/stable/c/03344e843ab6dd3b3f2cadfb65ed910590856c70
- https://git.kernel.org/stable/c/2ee4d79c364914989c80de382c0b1a7259a7e4b3
- https://git.kernel.org/stable/c/67f29896fdc83298eed5a6576ff8f9873f709228
- https://git.kernel.org/stable/c/6a8086a42dfbf548a42bf2ae4faa291645c72c66
- https://git.kernel.org/stable/c/a62225d951d77eb20208fed8fc199e0c9b1df08b
- https://git.kernel.org/stable/c/c65391dd9f0a47617e96e38bd27e277cbe1c40b0
- https://git.kernel.org/stable/c/f3783c415bf6d2ead3d7aa2c38802bbe10723646
Modified: 2024-12-09
CVE-2021-47080
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
- https://git.kernel.org/stable/c/54d87913f147a983589923c7f651f97de9af5be1
- https://git.kernel.org/stable/c/66ab7fcdac34b890017f04f391507ef5b2b89a13
- https://git.kernel.org/stable/c/e6871b4270c05f8b212e7d98aee82b357972c80a
- https://git.kernel.org/stable/c/54d87913f147a983589923c7f651f97de9af5be1
- https://git.kernel.org/stable/c/66ab7fcdac34b890017f04f391507ef5b2b89a13
- https://git.kernel.org/stable/c/e6871b4270c05f8b212e7d98aee82b357972c80a
Modified: 2025-01-07
CVE-2021-47180
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
- https://git.kernel.org/stable/c/0365701bc44e078682ee1224866a71897495c7ef
- https://git.kernel.org/stable/c/2c2fb2df46ea866b49fea5ec7112ec3cd4896c74
- https://git.kernel.org/stable/c/448a1cb12977f52142e6feb12022c59662d88dc1
- https://git.kernel.org/stable/c/4a621621c7af3cec21c47c349b30cd9c3cea11c8
- https://git.kernel.org/stable/c/65234f50a90b64b335cbb9164b8a98c2a0d031dd
- https://git.kernel.org/stable/c/af2a4426baf71163c0c354580ae98c7888a9aba7
- https://git.kernel.org/stable/c/b34cb7ac32cc8e5471dc773180ea9ae676b1a745
- https://git.kernel.org/stable/c/e0652f8bb44d6294eeeac06d703185357f25d50b
- https://git.kernel.org/stable/c/0365701bc44e078682ee1224866a71897495c7ef
- https://git.kernel.org/stable/c/2c2fb2df46ea866b49fea5ec7112ec3cd4896c74
- https://git.kernel.org/stable/c/448a1cb12977f52142e6feb12022c59662d88dc1
- https://git.kernel.org/stable/c/4a621621c7af3cec21c47c349b30cd9c3cea11c8
- https://git.kernel.org/stable/c/65234f50a90b64b335cbb9164b8a98c2a0d031dd
- https://git.kernel.org/stable/c/af2a4426baf71163c0c354580ae98c7888a9aba7
- https://git.kernel.org/stable/c/b34cb7ac32cc8e5471dc773180ea9ae676b1a745
- https://git.kernel.org/stable/c/e0652f8bb44d6294eeeac06d703185357f25d50b
