ALT-BU-2022-5348-11
Branch p9 update bulletin.
Package kernel-image-un-def updated to version 5.10.127-alt1 for branch p9 in task 302805.
Closed vulnerabilities
Modified: 2023-11-13
BDU:2022-03283
Уязвимость функции nft_expr_init программного обеспечения фильтрации пакетов Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
Modified: 2025-08-19
BDU:2022-03704
Уязвимость функции dx_insert_block() (fs/ext4/namei.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-05-28
BDU:2022-03922
Уязвимость компонента net/netfilter/nf_tables_api.c подсистемы netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
Modified: 2024-05-28
BDU:2022-04315
Уязвимость подсистемы фильтрации и классификации nftable ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
Modified: 2024-09-30
BDU:2022-05829
Уязвимость ioctl cmd PIO_FONT ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код с повышенными привилегиями
Modified: 2025-01-29
BDU:2022-06902
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-06-07
BDU:2022-07353
Уязвимость функции pipe_resize_ring ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-06-10
BDU:2023-02634
Уязвимость функции x86_emulate_insn компонента arch/x86/kvm/emulate.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-06664
Уязвимость драйвера drivers/hid/hid-bigbenff.c операционной системы Linux , связанная с записью за границами буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-05-05
BDU:2025-03962
Уязвимость компонента extents.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04337
Уязвимость функции nfc_unregister_device() модуля net/nfc/core.c подсистемы NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-04355
Уязвимость функции radeon_fp_native_mode() модуля drivers/gpu/drm/radeon/radeon_connectors.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04417
Уязвимость функции igb_clean_tx_ring() модуля drivers/net/ethernet/intel/igb/igb_main.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04424
Уязвимость функции cx23885_initdev() модуля drivers/media/pci/cx23885/cx23885-core.c - драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04425
Уязвимость функции rt5645_i2c_remove() модуля sound/soc/codecs/rt5645.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-04426
Уязвимость функции sco_sock_connect() модуля net/bluetooth/sco.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04472
Уязвимость функции iio_sysfs_trigger_remove() модуля drivers/iio/trigger/iio-trig-sysfs.c - драйвера поддержки различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-04473
Уязвимость функции tipc_exit_net() модуля net/tipc/core.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-10249
Уязвимость функций bpf_trampoline_get_progs() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-10250
Уязвимость функций exfat_clear_bitmap() и exfat_set_bitmap() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-10269
Уязвимость функции ext4_get_first_dir_block() модуля fs/ext4/namei.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10270
Уязвимость функции bus_add_driver() модуля drivers/base/bus.c - драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10271
Уязвимость функции bfq_bio_merge() модуля block/bfq-iosched.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10272
Уязвимость функции ieee80211_vif_use_reserved_context() модуля net/mac80211/chan.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-10576
Уязвимость функции bfq_setup_merge() модуля block/bfq-iosched.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10578
Уязвимость функции ubi_create_volume() модуля drivers/mtd/ubi/vmt.c - драйвера поддержки памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01310
Уязвимость функции snd_usbmidi_output_open() модуля sound/usb/midi.c поддержки звуковых устройств USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01394
Уязвимость функции nbd_alloc_config() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01454
Уязвимость функции rcu_tasks_rude_wait_gp() модуля kernel/rcu/tasks.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01498
Уязвимость функции si_parse_power_table() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02207
Уязвимость функции ext4_resize_begin() модуля fs/ext4/resize.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02211
Уязвимость функции hdlcdev_init() модуля drivers/tty/synclink_gt.c - драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02212
Уязвимость функции extcon_dev_register() модуля drivers/extcon/extcon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02213
Уязвимость функции _nfs4_open_and_get_state() модуля fs/nfs/nfs4proc.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02214
Уязвимость функции arm_smmu_device_probe() модуля drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c - драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02215
Уязвимость функции rpcrdma_is_bcall() модуля net/sunrpc/xprtrdma/rpc_rdma.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02216
Уязвимость функции trace_event_buffer_lock_reserve() модуля kernel/trace/trace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02217
Уязвимость функции dx_probe() модуля fs/ext4/namei.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02218
Уязвимость функции ext4_convert_inline_data() модуля fs/ext4/inline.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02220
Уязвимость функции icp_opal_init() модуля arch/powerpc/sysdev/xics/icp-opal.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02221
Уязвимость функции nvme_alloc_admin_tags() модуля drivers/nvme/host/pci.c - драйвера поддержки NVME ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02222
Уязвимость функции lpfc_fc_frame_check() модуля drivers/scsi/lpfc/lpfc_sli.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02225
Уязвимость функции snd_jack_dev_register() модуля sound/core/jack.c поддержки аудио карт ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02232
Уязвимость функции ata_host_alloc_pinfo() модуля drivers/ata/libata-core.c - драйвера поддержки SATA/PATA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02266
Уязвимость функции cx25821_finidev() модуля drivers/media/pci/cx25821/cx25821-core.c драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02269
Уязвимость функции dcscb_init() модуля arch/arm/mach-vexpress/dcscb.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02565
Уязвимость функции arm_smmu_device_probe() модуля drivers/iommu/arm/arm-smmu/arm-smmu.c - драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02567
Уязвимость функции get_handler_for_db() модуля security/integrity/platform_certs/keyring_handler.h подсистемы обеспечения безопаности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02568
Уязвимость функции hfi1_write_iter() модуля drivers/infiniband/hw/hfi1/file_ops.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02569
Уязвимость функции pci_dev_lock() модуля drivers/pci/pci.c драйвера поддержки утройств PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02570
Уязвимость функции md_bitmap_read_sb() модуля drivers/md/md-bitmap.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02596
Уязвимость функции r871xu_drv_init() модуля drivers/staging/rtl8712/usb_intf.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02597
Уязвимость функции usb_read8() модуля drivers/staging/rtl8712/usb_ops.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02598
Уязвимость функции isp116x_remove() модуля drivers/usb/host/isp116x-hcd.c драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02599
Уязвимость функции sa1100_set_termios() модуля drivers/tty/serial/sa1100.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02600
Уязвимость функции ieee80211_beacons_stop() модуля drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02601
Уязвимость функции oxu_bus_suspend() модуля drivers/usb/host/oxu210hp-hcd.c драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02602
Уязвимость функции __is_bitmap_valid() модуля fs/f2fs/checkpoint.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02603
Уязвимость функции mips_cpc_default_phys_base() модуля arch/mips/kernel/mips-cpc.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02604
Уязвимость функции rtl8180_tx() модуля drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c - драйвера поддержки адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02605
Уязвимость функции do_journal_discard() модуля drivers/md/bcache/journal.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02606
Уязвимость функции etnaviv_iommu_unmap_gem() модуля drivers/gpu/drm/etnaviv/etnaviv_mmu.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02607
Уязвимость функции user_dlm_destroy_lock() модуля fs/ocfs2/dlmfs/userdlm.c поддержки файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02608
Уязвимость функции ext4_setattr() модуля fs/ext4/inode.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02609
Уязвимость функции build_sit_entries() модуля fs/f2fs/segment.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02610
Уязвимость функции sanity_check_inode() модуля fs/f2fs/inode.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02611
Уязвимость функции f2fs_do_zero_range() модуля fs/f2fs/file.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02612
Уязвимость функции f2fs_evict_inode() модуля fs/f2fs/inode.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02613
Уязвимость функции iommu_init_early_dart() модуля arch/powerpc/sysdev/dart_iommu.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02615
Уязвимость функции hi3xxx_smp_prepare_cpus() модуля arch/arm/mach-hisi/platsmp.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02616
Уязвимость функции kszphy_config_reset() модуля drivers/net/phy/micrel.c - драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02617
Уязвимость функции skb_checksum_help() модуля net/core/dev.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02618
Уязвимость функции jz4740_mmc_acquire_dma_channels() модуля drivers/mmc/host/jz4740_mmc.c драйвера поддержки карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02619
Уязвимость функции ath11k_spectral_scan_config() модуля drivers/net/wireless/ath/ath11k/spectral.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02620
Уязвимость функции virtio_gpu_conn_get_modes() модуля drivers/gpu/drm/virtio/virtgpu_display.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02622
Уязвимость функции libipw_xmit() модуля drivers/net/wireless/intel/ipw2x00/libipw_tx.c - драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02625
Уязвимость функции machine_setup() модуля arch/xtensa/platforms/xtfpga/setup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02626
Уязвимость функции calibrate_ccount() модуля arch/xtensa/kernel/time.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02627
Уязвимость функции l2tp_ip6_sendmsg() модуля net/l2tp/l2tp_ip6.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02629
Уязвимость функции nfcmrvl_play_deferred() модуля drivers/nfc/nfcmrvl/usb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02647
Уязвимость функции r8712_free_drv_sw() модуля drivers/staging/rtl8712/os_intfs.c - поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02648
Уязвимость функции icom_probe() модуля drivers/tty/serial/icom.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02649
Уязвимость функции zynqmp_dma_alloc_chan_resources() модуля drivers/dma/xilinx/zynqmp_dma.c драйвера поддержки движка DMA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02650
Уязвимость функции rtllib_beacons_stop() модуля drivers/staging/rtl8192e/rtllib_softmac.c - поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03122
Уязвимость функции snd_pcm_lib_free_pages() модуля sound/core/pcm_memory.c поддержки аудио карт ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03488
Уязвимость функции clcdfb_of_vram_setup() модуля drivers/video/fbdev/amba-clcd.c драйвера поддержки устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03493
Уязвимость функции tcp_mtup_probe_success() модуля net/ipv4/tcp_input.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03494
Уязвимость функции seg6_hmac_init() модуля net/ipv6/seg6_hmac.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03495
Уязвимость функции xfrm4_protocol_init() модуля net/ipv4/xfrm4_protocol.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03496
Уязвимость функции mdio_bus_init() модуля drivers/net/phy/mdio_bus.c драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03511
Уязвимость функции deferred_probe_timeout_work_func() модуля drivers/base/dd.c драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03583
Уязвимость функции sev_launch_measure() модуля arch/x86/kvm/svm/sev.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03671
Уязвимость функции nbd_cleanup() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03672
Уязвимость функции nbd_start_device_ioctl() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03674
Уязвимость функции bpf_int_jit_compile() модуля arch/arm64/net/bpf_jit_comp.c поддержки сети на платформе ARM 64бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03675
Уязвимость функции tcp_rtx_synack() модуля net/ipv4/tcp_output.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03676
Уязвимость функции goldfish_tty_probe() модуля drivers/tty/goldfish.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03677
Уязвимость функции ftrace_func_mapper_add_ip() модуля kernel/trace/ftrace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03678
Уязвимость функции ath9k_rx_prepare() модуля drivers/net/wireless/ath/ath9k/htc_drv_txrx.c драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03679
Уязвимость функции f2fs_drop_inmem_page() модуля fs/f2fs/segment.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03681
Уязвимость функции davinci_vc_probe() модуля drivers/mfd/davinci_voicecodec.c драйвера контроллера многофункциональных устройств (MFD) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03684
Уязвимость функции qca_close() модуля drivers/bluetooth/hci_qca.c драйвера поддержки устройств Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03686
Уязвимость функции nf_conntrack_confirm() модуля include/net/netfilter/nf_conntrack_core.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03692
Уязвимость функции rk3399_dmcfreq_remove() модуля drivers/devfreq/rk3399_dmc.c драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03707
Уязвимость функции erspan_fb_xmit() модуля net/ipv4/ip_gre.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03708
Уязвимость функции ext4_mb_normalize_request() модуля fs/ext4/mballoc.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03709
Уязвимость функции error_state_read() модуля drivers/gpu/drm/i915/i915_sysfs.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03710
Уязвимость функции get_ftrace_plt() модуля arch/arm64/kernel/ftrace.c поддержки платформы ARM 64-бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03712
Уязвимость функции goldfish_tty_remove() модуля drivers/tty/goldfish.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2026-03713
Уязвимость функции i40e_diag_test() модуля drivers/net/ethernet/intel/i40e/i40e_ethtool.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03714
Уязвимость функции hv_init_clocksource() модуля drivers/clocksource/hyperv_timer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03810
Уязвимость функции __drm_universal_plane_init() модуля drivers/gpu/drm/drm_plane.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03862
Уязвимость функции dlm_posix_lock() модуля fs/dlm/plock.c поддержки распределенного менеджера блокировок ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03863
Уязвимость функции zonefs_i_size_write() модуля fs/zonefs/super.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03869
Уязвимость функции register_node() модуля drivers/base/node.c драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03899
Уязвимость функции blkcg_iolatency_throttle() модуля block/blk-iolatency.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03926
Уязвимость функции denali_pci_probe() модуля drivers/mtd/nand/raw/denali_pci.c драйвера поддержки памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03994
Уязвимость функции create_log_context() модуля drivers/md/dm-log.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03996
Уязвимость функции __bpf_sk_lookup() модуля net/core/filter.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03999
Уязвимость функции afs_getattr() модуля fs/afs/inode.c файловой системы Andrew (AFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04021
Уязвимость функции reset_page() модуля mm/zsmalloc.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04025
Уязвимость функции mdp5_crtc_setup_pipeline() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04026
Уязвимость функции mdp5_pipe_assign() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04030
Уязвимость функции sdma_clean() модуля drivers/infiniband/hw/hfi1/sdma.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04031
Уязвимость функции idxd_cdev_register() модуля drivers/dma/idxd/cdev.c драйвера поддержки движка DMA Intel Data Accelerator ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04035
Уязвимость функции efx_channel_is_xdp_tx() модуля drivers/net/ethernet/sfc/net_driver.h драйвера поддержки сетевых адаптеров Ethernet Solarflare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04038
Уязвимость функции ipgre_xmit() модуля net/ipv4/ip_gre.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04116
Уязвимость функции nft_meta_get_eval_ifname() модуля net/netfilter/nft_meta.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04274
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04275
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-02
CVE-2021-33656
When setting font with malicous data by ioctl cmd PIO_FONT,kernel will write memory out of bounds.
- http://www.openwall.com/lists/oss-security/2022/07/19/3
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/releases/5.10.127/vt-drop-old-font-ioctls.patch
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-33656&packageName=kernel
- http://www.openwall.com/lists/oss-security/2022/07/19/3
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/releases/5.10.127/vt-drop-old-font-ioctls.patch
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-33656&packageName=kernel
Modified: 2025-10-14
CVE-2021-47659
In the Linux kernel, the following vulnerability has been resolved: drm/plane: Move range check for format_count earlier While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.
- https://git.kernel.org/stable/c/1e29d829ad51d1472dd035487953a6724b56fc33
- https://git.kernel.org/stable/c/4ab7e453a3ee88c274cf97bee9487ab92a66d313
- https://git.kernel.org/stable/c/4b674dd69701c2e22e8e7770c1706a69f3b17269
- https://git.kernel.org/stable/c/787163d19bc3cdc6ca4b96223f62208534d1cf6b
- https://git.kernel.org/stable/c/978e3d023256bfaf34a0033d40c94e8a8e70cf3c
- https://git.kernel.org/stable/c/ad6dd7a2bac86118985c7b3426e175b9d3c1ec4f
- https://git.kernel.org/stable/c/b5cd108143513e4498027b96ec4710702d186f11
Modified: 2024-11-21
CVE-2022-1012
A memory leak problem was found in the TCP source port generation algorithm in net/ipv4/tcp.c due to the small table perturb size. This flaw may allow an attacker to information leak and may cause a denial of service problem.
- https://bugzilla.redhat.com/show_bug.cgi?id=2064604
- https://lore.kernel.org/lkml/20220427065233.2075-1-w%401wt.eu/T/
- https://security.netapp.com/advisory/ntap-20221020-0006/
- https://bugzilla.redhat.com/show_bug.cgi?id=2064604
- https://lore.kernel.org/lkml/20220427065233.2075-1-w%401wt.eu/T/
- https://security.netapp.com/advisory/ntap-20221020-0006/
Modified: 2024-11-21
CVE-2022-1184
A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel’s filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service.
- https://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
- https://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-1789
With shadow paging enabled, the INVPCID instruction results in a call to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the invlpg callback is not set and the result is a NULL pointer dereference.
- https://bugzilla.redhat.com/show_bug.cgi?id=1832397
- https://francozappa.github.io/about-bias/
- https://kb.cert.org/vuls/id/647177/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H6JP355XFVAB33X4BNO3ERVTURFYEDB7/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IBUOQTNTQ4ZCXHOCNKYIL2ZUIAZ675RD/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KCEAPIVPRTJHKPF2A2HVF5XHD5XJT3MN/
- https://www.debian.org/security/2022/dsa-5161
- https://bugzilla.redhat.com/show_bug.cgi?id=1832397
- https://francozappa.github.io/about-bias/
- https://kb.cert.org/vuls/id/647177/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H6JP355XFVAB33X4BNO3ERVTURFYEDB7/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IBUOQTNTQ4ZCXHOCNKYIL2ZUIAZ675RD/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KCEAPIVPRTJHKPF2A2HVF5XHD5XJT3MN/
- https://www.debian.org/security/2022/dsa-5161
Modified: 2024-11-21
CVE-2022-1852
A NULL pointer dereference flaw was found in the Linux kernel’s KVM module, which can lead to a denial of service in the x86_emulate_insn in arch/x86/kvm/emulate.c. This flaw occurs while executing an illegal instruction in guest in the Intel CPU.
Modified: 2023-11-07
CVE-2022-1966
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2022-32250. Reason: This candidate is a duplicate of CVE-2022-32250. Notes: All CVE users should reference CVE-2022-32250 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
Modified: 2023-11-07
CVE-2022-1972
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2022-2078. Reason: This candidate is a reservation duplicate of CVE-2022-2078. Notes: All CVE users should reference CVE-2022-2078 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage
Modified: 2024-11-21
CVE-2022-2959
A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring(). The specific flaw exists within the handling of pipe buffers. The issue results from the lack of proper locking when performing operations on an object. This flaw allows a local user to crash the system or escalate their privileges on the system.
- https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a
- https://security.netapp.com/advisory/ntap-20230214-0005/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1165/
- https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a
- https://security.netapp.com/advisory/ntap-20230214-0005/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1165/
Modified: 2024-11-21
CVE-2022-32250
net/netfilter/nf_tables_api.c in the Linux kernel through 5.18.1 allows a local user (able to create user/net namespaces) to escalate privileges to root because an incorrect NFT_STATEFUL_EXPR check leads to a use-after-free.
- http://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
- http://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
Modified: 2025-05-08
CVE-2022-3577
An out-of-bounds memory write flaw was found in the Linux kernel’s Kid-friendly Wired Controller driver. This flaw allows a local user to crash or potentially escalate their privileges on the system. It is in bigben_probe of drivers/hid/hid-bigbenff.c. The reason is incorrect assumption - bigben devices all have inputs. However, malicious devices can break this assumption, leaking to out-of-bound write.
- https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=9d64d2405f7d30d49818f6682acd0392348f0fdb
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=945a9a8e448b65bec055d37eba58f711b39f66f0
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc4ef9d5724973193bfa5ebed181dba6de3a56db
- https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=9d64d2405f7d30d49818f6682acd0392348f0fdb
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=945a9a8e448b65bec055d37eba58f711b39f66f0
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc4ef9d5724973193bfa5ebed181dba6de3a56db
Modified: 2024-12-31
CVE-2022-48710
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix a possible null pointer dereference In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. The failure status of drm_cvt_mode() on the other path is checked too.
- https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
- https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
Modified: 2025-10-01
CVE-2022-49295
In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-)
- https://git.kernel.org/stable/c/013a79f1b5c89290e2e97f1ebf14b14e0cf5fe5c
- https://git.kernel.org/stable/c/06c4da89c24e7023ea448cadf8e9daf06a0aae6e
- https://git.kernel.org/stable/c/1be608e1ee1f222464b2856bda9b85ab5184a33e
- https://git.kernel.org/stable/c/3d5da1ffba3388c2ae2e6c598855a4d887d3bf79
- https://git.kernel.org/stable/c/6f505bbb8063fd3a238a4239d2d8c165e5279f6f
- https://git.kernel.org/stable/c/8a1435c862ea09b06be7acda325128dc08458e25
- https://git.kernel.org/stable/c/c0868f6e728c3c28bef0e8bee89d2daf86a8bbca
- https://git.kernel.org/stable/c/cbeafa7a79d08ecdb55f8f1d41a11323d0f709db
Modified: 2025-10-21
CVE-2022-49297
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix io hung while disconnecting device
In our tests, "qemu-nbd" triggers a io hung:
INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000
Call Trace:
- https://git.kernel.org/stable/c/09dadb5985023e27d4740ebd17e6fea4640110e5
- https://git.kernel.org/stable/c/141318e62db87105b0103fccc59c9c5940da248d
- https://git.kernel.org/stable/c/54b06dc2a206b4d67349bb56b92d4bd32700b7b1
- https://git.kernel.org/stable/c/62d227f67a8c25d5e16f40e5290607f9306d2188
- https://git.kernel.org/stable/c/67e403136a0e1a55fef6a05f103a3979a39ad3fd
- https://git.kernel.org/stable/c/69893d6d7f5c10d8306c1b5fc64b71efc91aa6cd
- https://git.kernel.org/stable/c/c4ba982bd5084fa659ef518aaf159e4dab02ecda
- https://git.kernel.org/stable/c/f72df77600a43e59b3189e53b47f8685739867d3
Modified: 2025-10-01
CVE-2022-49298
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in r871xu_drv_init() When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
- https://git.kernel.org/stable/c/0458e5428e5e959d201a40ffe71d762a79ecedc4
- https://git.kernel.org/stable/c/0b7371a22489cbb2e8e826ca03fb5ce92afb04fe
- https://git.kernel.org/stable/c/277faa442fe0c59f418ac53f47a78e1266addd65
- https://git.kernel.org/stable/c/52a0d88c328098b4e9fb8f2f3877fec0eff4104b
- https://git.kernel.org/stable/c/70df04433fd351ba72bc635bd0b5fe443d9ac964
- https://git.kernel.org/stable/c/76a964ad0ea8f2b10abd69a7532e174a28258283
- https://git.kernel.org/stable/c/a6535d00a9d54ce1c2a8d86a85001ffb6844f9b2
- https://git.kernel.org/stable/c/f36e754a1f0bafb9feeea63463de78080acb6de0
- https://git.kernel.org/stable/c/ff727ab0b7d7a56b5ef281f12abd00c4b85894e9
Modified: 2025-10-01
CVE-2022-49300
In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between nbd_alloc_config() and module removal When nbd module is being removing, nbd_alloc_config() may be called concurrently by nbd_genl_connect(), although try_module_get() will return false, but nbd_alloc_config() doesn't handle it. The race may lead to the leak of nbd_config and its related resources (e.g, recv_workq) and oops in nbd_read_stat() due to the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Fixing it by checking the return value of try_module_get() in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV), assign nbd->config only when nbd_alloc_config() succeeds to ensure the value of nbd->config is binary (valid or NULL). Also adding a debug message to check the reference counter of nbd_config during module removal.
- https://git.kernel.org/stable/c/122e4adaff2439f1cc18cc7e931980fa7560df5c
- https://git.kernel.org/stable/c/165cf2e0019fa6cedc75b456490c41494c34abb4
- https://git.kernel.org/stable/c/2573f2375b64280be977431701ed5d33b75b9ad0
- https://git.kernel.org/stable/c/2888fa41985f93ed0a6837cfbb06bcbfd7fa2314
- https://git.kernel.org/stable/c/71c142f910da44421213ade601bcbd23ceae19fa
- https://git.kernel.org/stable/c/8a7da4ced236ce6637fe70f14ca18e718d4bf9e9
- https://git.kernel.org/stable/c/c55b2b983b0fa012942c3eb16384b2b722caa810
- https://git.kernel.org/stable/c/d09525720dd5201756f698bee1076de9aefd4602
Modified: 2025-10-01
CVE-2022-49301
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in usb_read8() and friends When r8712_usbctrl_vendorreq() returns negative, 'data' in usb_read{8,16,32} will not be initialized. BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline] BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:643 [inline] string+0x4ec/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 va_format lib/vsprintf.c:1704 [inline] pointer+0x18e6/0x1f70 lib/vsprintf.c:2443 vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604 dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615 __dev_printk+0x3be/0x440 drivers/base/core.c:4627 _dev_info+0x1ea/0x22f drivers/base/core.c:4673 r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5363 [inline] hub_port_connect_change drivers/usb/core/hub.c:5507 [inline] port_event drivers/usb/core/hub.c:5665 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289 worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436 kthread+0x3c7/0x500 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Local variable data created at: usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33 r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
- https://git.kernel.org/stable/c/33ef21d55418ab6a62a63fd550b2dbe297433372
- https://git.kernel.org/stable/c/58762f1c63c75cbe1dc393eed3c9cf8e38310ca1
- https://git.kernel.org/stable/c/95b0f54f8a898072a2810c05fab34d971f23a612
- https://git.kernel.org/stable/c/d1b57669732d09da7e13ef86d058dab0cd57f6e0
- https://git.kernel.org/stable/c/d7ed3c85da0b230bcdf5329acfe012ed093f3daa
- https://git.kernel.org/stable/c/de075af8c404f7d59ed34df230aedd9f645fb846
Modified: 2025-10-01
CVE-2022-49302
In the Linux kernel, the following vulnerability has been resolved: USB: host: isp116x: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e
- https://git.kernel.org/stable/c/3592cfd8b848bf0c4d7740d78a87a7b8f6e1fa9a
- https://git.kernel.org/stable/c/3825db88d8c704e7992b685618a03f82bffcf2ef
- https://git.kernel.org/stable/c/7bffda1560a6f255fdf504e059fbbdb5d46b9e44
- https://git.kernel.org/stable/c/804de302ada3544699c5f48c5314b249af76faa3
- https://git.kernel.org/stable/c/82a101f14943f479fd190b1e5b40d91c77e2ac1b
- https://git.kernel.org/stable/c/aca0cab0e9ed33b6371aafb519a6c38f2850ffc3
- https://git.kernel.org/stable/c/c91a74b1f0f2d2d7e728742ae55e3ffe9ba7853d
- https://git.kernel.org/stable/c/ee105039d3653444de4d3ede642383c92855dc1e
Modified: 2025-10-01
CVE-2022-49304
In the Linux kernel, the following vulnerability has been resolved: drivers: tty: serial: Fix deadlock in sa1100_set_termios() There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever. This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock.
- https://git.kernel.org/stable/c/0976808d0d171ec837d4bd3e9f4ad4a00ab703b8
- https://git.kernel.org/stable/c/09a5958a2452ad22d0cb638711ef34ea1863a829
- https://git.kernel.org/stable/c/2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b
- https://git.kernel.org/stable/c/34d91e555e5582cffdbcbb75517bc9217866823e
- https://git.kernel.org/stable/c/553213432ef0c295becdc08c0207d2094468f673
- https://git.kernel.org/stable/c/62b2caef400c1738b6d22f636c628d9f85cd4c4c
- https://git.kernel.org/stable/c/6e2273eefab54a521d9c59efb6e1114e742bdf41
- https://git.kernel.org/stable/c/85e20f8bd31a46d8c60103d0274a8ebe8f47f2b2
- https://git.kernel.org/stable/c/920f0ae7a129ffee98a106e3bbdfd61a2a59e939
Modified: 2025-10-01
CVE-2022-49305
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/042915c1bfedd684c1d98a841794ee203200571a
- https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25
- https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710
- https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273
- https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2
- https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e
- https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3
Modified: 2025-10-01
CVE-2022-49307
In the Linux kernel, the following vulnerability has been resolved:
tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
When the driver fails at alloc_hdlcdev(), and then we remove the driver
module, we will get the following splat:
[ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
[ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
[ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
[ 25.077709] Call Trace:
[ 25.077924]
- https://git.kernel.org/stable/c/078212ad15dbd88840c82c97f12c93d83703c8fd
- https://git.kernel.org/stable/c/1ceb4ca9543a8a788febf6bc8dad2e605e172d5e
- https://git.kernel.org/stable/c/50c341f9a2adc4c32a8ad5a39eb99d9c4a419e0d
- https://git.kernel.org/stable/c/689ca31c542687709ba21ec2195c1fbce34fd029
- https://git.kernel.org/stable/c/8a95696bdc0e13f8980f05b54a3b9081963d1256
- https://git.kernel.org/stable/c/ba08cbc5b53e151d0acf1930fb526fc65b7f3e65
- https://git.kernel.org/stable/c/d68d5e68b7f64de7170f8e04dd9b995c36b2c71c
- https://git.kernel.org/stable/c/ddd67751ab86c6a65f95c35293c42f85a42ac05d
- https://git.kernel.org/stable/c/f6e07eb7ebec53ffe81fc2489589320fbe4a6b75
Modified: 2025-10-21
CVE-2022-49308
In the Linux kernel, the following vulnerability has been resolved:
extcon: Modify extcon device to be created after driver data is set
Currently, someone can invoke the sysfs such as state_show()
intermittently before dev_set_drvdata() is done.
And it can be a cause of kernel Oops because of edev is Null at that time.
So modified the driver registration to after setting drviver data.
- Oops's backtrace.
Backtrace:
[
- https://git.kernel.org/stable/c/033ec4e7e59ae5e1ef1e8c10bc6552926044ed1c
- https://git.kernel.org/stable/c/35ff1ac55d301efb3f467cf5426faaeb3452994b
- https://git.kernel.org/stable/c/368e68ad6da4317fc4170e8d92b51c13d1bfe7a7
- https://git.kernel.org/stable/c/5dcc2afe716d69f5112ce035cb14f007461ff189
- https://git.kernel.org/stable/c/6e721f3ad0535b24f19a62420f4da95212cf069c
- https://git.kernel.org/stable/c/abf3b222614f49f98e606fccdd269161c0d70204
- https://git.kernel.org/stable/c/cb81ea998c461868d1168411a867d8ffee12f23f
- https://git.kernel.org/stable/c/d472c78cc82999d07bd09193a6718016ce9cd386
Modified: 2025-10-01
CVE-2022-49312
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix a potential memory leak in r871xu_drv_init() In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not properly released as there is no action will be performed by r8712_usb_dvobj_deinit(). To properly release it, we should call r8712_free_io_queue() in r8712_usb_dvobj_deinit(). Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called by r871x_dev_unload() under condition `padapter->bup` and r8712_free_io_queue() is called by r8712_free_drv_sw(). However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for better understading the code. So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove r8712_free_io_queue() from r8712_free_drv_sw().
- https://git.kernel.org/stable/c/205e039fead72e87ad2838f5e649a4c4834f648b
- https://git.kernel.org/stable/c/5a89a92efc342dd7c44b6056da87debc598f9c73
- https://git.kernel.org/stable/c/7288ff561de650d4139fab80e9cb0da9b5b32434
- https://git.kernel.org/stable/c/8eb42d6d10f8fe509117859defddf9e72b4fa4d0
- https://git.kernel.org/stable/c/a2882b8baad068d21c99fb2ab5a85a2bdbd5b834
Modified: 2025-10-01
CVE-2022-49313
In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/2dcec0bc142be2096af71a5703d63237127db204
- https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868
- https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524
- https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58
- https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124
- https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677
- https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab
- https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221
- https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df
Modified: 2025-10-01
CVE-2022-49314
In the Linux kernel, the following vulnerability has been resolved: tty: Fix a possible resource leak in icom_probe When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated.
- https://git.kernel.org/stable/c/23e155b51d403c0ccedc60c0d6c3c452afed07fe
- https://git.kernel.org/stable/c/5f9b2e4ca88cab1a96b86ecd45544e488ca43faf
- https://git.kernel.org/stable/c/8c014373f178a4f13a08e045ef63bdb23f62e892
- https://git.kernel.org/stable/c/9a8305f357a8d03698fc7bc855ff9c6865d5486b
- https://git.kernel.org/stable/c/a2df0b4d080cc770b4da7bff487048c803dfd07e
- https://git.kernel.org/stable/c/cb7147afd328c07edeeee287710d8d96ac0459f5
- https://git.kernel.org/stable/c/d703d912a985c1c5b50dd38c3181fc3540fa77cb
- https://git.kernel.org/stable/c/ee157a79e7c82b01ae4c25de0ac75899801f322c
- https://git.kernel.org/stable/c/f4c836d90da1ece88905d62ce2ce39a962f25d1a
Modified: 2025-10-01
CVE-2022-49315
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/08bacf871c019163ccd1389d0bc957a43324967a
- https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada
- https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446
- https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12
- https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72
- https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b
- https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303
- https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db
- https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434
Modified: 2025-10-01
CVE-2022-49316
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Don't hold the layoutget locks across multiple RPC calls When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock.
- https://git.kernel.org/stable/c/08d7a26d115cc7892668baa9750f64bd8baca29b
- https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c
- https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee
- https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010
- https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd
- https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e
- https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1
Modified: 2025-10-01
CVE-2022-49318
In the Linux kernel, the following vulnerability has been resolved: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr Syzbot triggers two WARNs in f2fs_is_valid_blkaddr and __is_bitmap_valid. For example, in f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON if blkaddr is not in the right range. The call trace is as follows: f2fs_get_node_info+0x45f/0x1070 read_node_page+0x577/0x1190 __get_node_page.part.0+0x9e/0x10e0 __get_node_page f2fs_get_node_page+0x109/0x180 do_read_inode f2fs_iget+0x2a5/0x58b0 f2fs_fill_super+0x3b39/0x7ca0 Fix these two WARNs by replacing WARN_ON with dump_stack.
- https://git.kernel.org/stable/c/0a7a1fc7e71eecf2e5053a6c312c9f0dcbb9b8fd
- https://git.kernel.org/stable/c/32bea51fe4c6e92c00403739f7547c89219bea88
- https://git.kernel.org/stable/c/8c62c5e26345c34d199b4b8c8e69255ba3d0e751
- https://git.kernel.org/stable/c/99c09b298e47ebbe345a6da9f268b32a6b0f4582
- https://git.kernel.org/stable/c/cd6374af36cc548464d8c47a93fdba7303bb82a4
- https://git.kernel.org/stable/c/dc2f78e2d4cc844a1458653d57ce1b54d4a29f21
Modified: 2025-10-01
CVE-2022-49319
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/54c1e0e3bbcab2abe25b2874a43050ae5df87831
- https://git.kernel.org/stable/c/54cf47da0c7532d151d76e5d63f5936191698c44
- https://git.kernel.org/stable/c/b131fa8c1d2afd05d0b7598621114674289c2fbb
- https://git.kernel.org/stable/c/db728a891f9177b044aaca89b678f6b5e24d5cc3
- https://git.kernel.org/stable/c/fb0f1c5eb8d60b3e018ba7c87da249b52674ebe6
Modified: 2025-09-22
CVE-2022-49320
In the Linux kernel, the following vulnerability has been resolved: dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type In zynqmp_dma_alloc/free_chan_resources functions there is a potential overflow in the below expressions. dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL); dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p); The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though this overflow condition is not observed but it is a potential problem in the case of 32-bit multiplication. Hence fix it by changing the desc_size data type to size_t. In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in dma_alloc_coherent API argument. Addresses-Coverity: Event overflow_before_widen.
- https://git.kernel.org/stable/c/4838969e4d95d2bd2995d1605b20d3144fcb3e74
- https://git.kernel.org/stable/c/7b5488f4721fed6e121e661e165bab06ae2f8675
- https://git.kernel.org/stable/c/83960276ffc9bf5570d4106490346b61e61be5f3
- https://git.kernel.org/stable/c/90aefae2e3a770a6909d339f5d8a988c0b0ceaf0
- https://git.kernel.org/stable/c/95a0ba85c1b51b36e909841c02d205cd223ab753
- https://git.kernel.org/stable/c/f9a9f43a62a04ec3183fb0da9226c7706eed0115
Modified: 2025-10-01
CVE-2022-49321
In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ...
- https://git.kernel.org/stable/c/11270e7ca268e8d61b5d9e5c3a54bd1550642c9c
- https://git.kernel.org/stable/c/8dbae5affbdbf524b48000f9d357925bb001e5f4
- https://git.kernel.org/stable/c/8e3943c50764dc7c5f25911970c3ff062ec1f18c
- https://git.kernel.org/stable/c/90c4f73104016748533a5707ecd15930fbeff402
- https://git.kernel.org/stable/c/91784f3d77b73885e1b2e6b59d3cbf0de0a1126a
- https://git.kernel.org/stable/c/998d35a2aff4b81a1c784f3aa45cd3afff6814c1
- https://git.kernel.org/stable/c/a3fc8051ee061e31db13e2fe011e8e0b71a7f815
- https://git.kernel.org/stable/c/da99331fa62131a38a0947a8204c5208de7b0454
Modified: 2025-10-01
CVE-2022-49322
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
be triggered.
Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
[
- https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd
- https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762
- https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4
- https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b
- https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0
- https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59
- https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec
- https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1
Modified: 2025-10-01
CVE-2022-49323
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.
- https://git.kernel.org/stable/c/3660db29b0305f9a1d95979c7af0f5db6ea99f5d
- https://git.kernel.org/stable/c/449fc4561762ad9ad85362d5f01f0d0df397457a
- https://git.kernel.org/stable/c/80776a71340f57d6a4952635fc89f0342072f3ca
- https://git.kernel.org/stable/c/98dd53a92825747395649f54d23512a13c3ed471
- https://git.kernel.org/stable/c/d9ed8af1dee37f181096631fb03729ece98ba816
Modified: 2025-10-01
CVE-2022-49324
In the Linux kernel, the following vulnerability has been resolved: mips: cpc: Fix refcount leak in mips_cpc_default_phys_base Add the missing of_node_put() to release the refcount incremented by of_find_compatible_node().
- https://git.kernel.org/stable/c/1699ec1bfb59304a788901474f6bb003f7831b61
- https://git.kernel.org/stable/c/4107fa700f314592850e2c64608f6ede4c077476
- https://git.kernel.org/stable/c/8f843cdfc202caaa5d67db3395d893e56362e43a
- https://git.kernel.org/stable/c/961ee8a6eeef4632a215d995d837b204f8c7c2d4
- https://git.kernel.org/stable/c/aae6b4bb63c694bc91714412718f15468407fe51
- https://git.kernel.org/stable/c/bed702566dcdb6ebe300bc0c62bf3600cf4d5874
- https://git.kernel.org/stable/c/c667b3872a4c435a3f29d4e15971cd8c378b0043
- https://git.kernel.org/stable/c/cc0aed22d33ced9e266c50bdf1cbe668c5acfdf8
Modified: 2025-10-01
CVE-2022-49326
In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized.
- https://git.kernel.org/stable/c/6ad81ad0cf5744738ce94c8e64051ddd80a1734c
- https://git.kernel.org/stable/c/746285cf81dc19502ab238249d75f5990bd2d231
- https://git.kernel.org/stable/c/769ec2a824deae2f1268dfda14999a4d14d0d0c5
- https://git.kernel.org/stable/c/98e55b0b876bde3353f4e074883d66ecb55c65a3
- https://git.kernel.org/stable/c/9ad1981fc4de3afb7db3e8eb5a6a52d4c7d0d577
- https://git.kernel.org/stable/c/9d5e96cc1f1720019ce27b127a31695148d38bb0
- https://git.kernel.org/stable/c/b5dca2cd3f0239512da808598b4e70557eb4c2a1
- https://git.kernel.org/stable/c/b8ce58ab80faaea015c206382041ff3bcf5495ff
- https://git.kernel.org/stable/c/d7e30dfc166d33470bba31a42f9bbc346e5409d5
Modified: 2025-10-01
CVE-2022-49327
In the Linux kernel, the following vulnerability has been resolved: bcache: avoid journal no-space deadlock by reserving 1 journal bucket The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation. When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered. For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens. The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore. This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time. During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock.
- https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159
- https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6
- https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363
- https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce
- https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497
Modified: 2025-09-22
CVE-2022-49330
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
syzbot got a new report [1] finally pointing to a very old bug,
added in initial support for MTU probing.
tcp_mtu_probe() has checks about starting an MTU probe if
tcp_snd_cwnd(tp) >= 11.
But nothing prevents tcp_snd_cwnd(tp) to be reduced later
and before the MTU probe succeeds.
This bug would lead to potential zero-divides.
Debugging added in commit 40570375356c ("tcp: add accessors
to read/set tp->snd_cwnd") has paid off :)
While we are at it, address potential overflows in this code.
[1]
WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Modules linked in:
CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/11825765291a93d8e7f44230da67b9f607c777bf
- https://git.kernel.org/stable/c/29e13f6b38f0816af2012e0725507754e8f4569c
- https://git.kernel.org/stable/c/38ca71a24cd4845021eed35fd2594d89dba9a5a8
- https://git.kernel.org/stable/c/42726877453afdbe1508a8a96884ea907741d9a7
- https://git.kernel.org/stable/c/602b338e3c3cd7f935f3f5011882961d074e5ac1
- https://git.kernel.org/stable/c/90385f2b65d0cd2b3b1ac8909f0cc6dd31062cfc
- https://git.kernel.org/stable/c/9ba2b4ac35935f05ac98cff722f36ba07d62270e
- https://git.kernel.org/stable/c/aa7f333efd1138a68517a6a6a69ae540dd59d800
- https://git.kernel.org/stable/c/f2845e1504a3bc4f3381394f057e8b63cb5f3f7a
Modified: 2025-10-01
CVE-2022-49331
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.
- https://git.kernel.org/stable/c/3eca2c42daa4659965db6817479027cbc6df7899
- https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f
- https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd
- https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74
- https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded
- https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe
- https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383
- https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7
- https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e
Modified: 2025-10-01
CVE-2022-49335
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
- https://git.kernel.org/stable/c/15c3bcc9b5349d40207e5f8d4d799b8b4b7d13b8
- https://git.kernel.org/stable/c/20b947e5a3c74c5084d661c097517a554989d462
- https://git.kernel.org/stable/c/31ab27b14daaa75541a415c6794d6f3567fea44a
- https://git.kernel.org/stable/c/70276460e914d560e96bfc208695a872fe9469c9
- https://git.kernel.org/stable/c/7086a23890d255bb5761604e39174b20d06231a4
- https://git.kernel.org/stable/c/8189f44270db1be78169e11eec51a3eeb980bc63
- https://git.kernel.org/stable/c/aa25acbe96692e4bf8482311c293f72d8c6034c0
- https://git.kernel.org/stable/c/be585921f29df5422a39c952d188b418ad48ffab
- https://git.kernel.org/stable/c/c12984cdb077b9042d2dc20ca18cb16a87bcc774
Modified: 2025-10-21
CVE-2022-49336
In the Linux kernel, the following vulnerability has been resolved: drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures.
- https://git.kernel.org/stable/c/03bd455a79f69d97fee3e3b212ab754442f10e5c
- https://git.kernel.org/stable/c/19323b3671a85788569d15685c8f83a05ec48cbb
- https://git.kernel.org/stable/c/436cff507f2a41230baacc3e2ef1d3b2d2653f40
- https://git.kernel.org/stable/c/461c0fdf9434188875da9f10cfc86065866bb797
- https://git.kernel.org/stable/c/64f4edec081cb7c97c5e928529d0e1b0dbbffb83
- https://git.kernel.org/stable/c/e168c25526cd0368af098095c2ded4a008007e1b
Modified: 2025-09-22
CVE-2022-49337
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_lock failed, it didn't clean up the flags it set
before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of
lock is still in used, next time when unlink invokes this function, it
will return succeed, and then unlink will remove inode and dentry if lock
is not in used(file closed), but the dlm lock is still linked in dlm lock
resource, then when bast come in, it will trigger a panic due to
user-after-free. See the following panic call trace. To fix this,
USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should
be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink
fail.
For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,
USER_LOCK_BUSY is also required to be cleared. Even though spin lock is
released in between, but USER_LOCK_IN_TEARDOWN is still set, for
USER_LOCK_BUSY, if before every place that waits on this flag,
USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow
waits on the busy flag set by user_dlm_destroy_lock(), then we can
simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix
user_dlm_cluster_lock() which is the only function not following this.
[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink
004fb0000060000b5a90b8c847b72e1, error -16 from destroy
[ 989.757536] ------------[ cut here ]------------
[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!
[ 989.757876] invalid opcode: 0000 [#1] SMP
[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)
ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc
xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5
auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs
ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc
fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc
rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad
rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)
mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad
ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support
pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si
ipmi_msghandler
[ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp
pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel
be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio
libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi
dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
ksplice_2zhuk2jr_ib_ipoib_old]
[ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE
4.1.12-124.57.1.el6uek.x86_64 #2
[ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021
[ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:
ffff88017f7c8000
[ 989.762848] RIP: e030:[
- https://git.kernel.org/stable/c/02480e2e82ae0e5588374bbbcf4fa6e4959fa174
- https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207c
- https://git.kernel.org/stable/c/2c5e26a626fe46675bceba853e12aaf13c712e10
- https://git.kernel.org/stable/c/337e36550788dbe03254f0593a231c1c4873b20d
- https://git.kernel.org/stable/c/733a35c00ef363a1c774d7ea486e0735b7c13a15
- https://git.kernel.org/stable/c/82bf8e7271fade40184177cb406203addc34c4a0
- https://git.kernel.org/stable/c/863e0d81b6683c4cbc588ad831f560c90e494bef
- https://git.kernel.org/stable/c/9c96238fac045b289993d7bc5aae7b2d72b25c76
- https://git.kernel.org/stable/c/efb54ec548829e1d3605f0434526f86e345b1b28
Modified: 2025-09-22
CVE-2022-49339
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the caller (net/ipv6/seg6.c) and the callee (net/ipv6/seg6_hmac.c) belong to the same module. It seems an internal function call in ipv6.ko.
- https://git.kernel.org/stable/c/1084716f76c8045eadf92a9d9a62641f3c8d8c90
- https://git.kernel.org/stable/c/317260b3eb6384a05a8af212308fa50f3b2e8290
- https://git.kernel.org/stable/c/3e6de5037148c5a93a436b1e8d2edad3dac11755
- https://git.kernel.org/stable/c/5801f064e35181c71857a80ff18af4dbec3c5f5c
- https://git.kernel.org/stable/c/5d9c1b081ad28c852a97e10dd75412546497694a
- https://git.kernel.org/stable/c/64aef8efe96c1616142c4476a05731306fc4494e
- https://git.kernel.org/stable/c/9ba4416b831eeb4d185e88e73488d1d21288e63a
- https://git.kernel.org/stable/c/ab8b2c2de273ec1d698a18e399896a6febb5cda0
Modified: 2025-10-21
CVE-2022-49340
In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local checksum offload on CHECKSUM_PARTIAL packets. ipgre_xmit must validate csum_start after an optional skb_pull, else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; This had false positives when skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement was straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; But was eventually revised more thoroughly: - restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull. - test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath. Turns out skbs can arrive in this branch without the transport header set, e.g., through BPF redirection. Revise the check back to check csum_start directly, and only if CHECKSUM_PARTIAL. Do leave the check in the updated location. Check field regardless of whether TUNNEL_CSUM is configured.
- https://git.kernel.org/stable/c/0c92d813c7c9ca2212ecd879232e7d87362fce98
- https://git.kernel.org/stable/c/0ffa268724656633af5f37a38c212326d98ebe8c
- https://git.kernel.org/stable/c/3d08bc3a5d9b2106f5c8bcf1adb73147824aa006
- https://git.kernel.org/stable/c/7596bd7920985f7fc8579a92e48bc53ce4475b21
- https://git.kernel.org/stable/c/8d21e9963bec1aad2280cdd034c8993033ef2948
- https://git.kernel.org/stable/c/e6b6f98fc7605c06c0a3baa70f62c534d7b4ce58
- https://git.kernel.org/stable/c/fbeb8dfa8b87ef259eef0c89e39b53962a3cf604
Modified: 2025-10-21
CVE-2022-49341
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)
- https://git.kernel.org/stable/c/0cf7aaff290cdc4d7cee683d4a18138b0dacac48
- https://git.kernel.org/stable/c/10f3b29c65bb2fe0d47c2945cd0b4087be1c5218
- https://git.kernel.org/stable/c/3f4d5e727aeaa610688d46c9f101f78b7f712583
- https://git.kernel.org/stable/c/41f7c4f85d402043687e863627a1a84fa867c62d
- https://git.kernel.org/stable/c/5c25a3040bc0486c41a7b63a1fb0de7cdb846ad7
- https://git.kernel.org/stable/c/aaf61a312af63e1cfe2264c4c5b8cd4ea3626025
- https://git.kernel.org/stable/c/e412b3d178ea4bf746f6b8ee086761613704c6be
Modified: 2025-10-21
CVE-2022-49343
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique.
- https://git.kernel.org/stable/c/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3
- https://git.kernel.org/stable/c/3a3ce941645407cd0b0b7f01ad9e2ea3770f46cc
- https://git.kernel.org/stable/c/3ba733f879c2a88910744647e41edeefbc0d92b2
- https://git.kernel.org/stable/c/6084240bfc44bf265ab6ae7d96980469b05be0f1
- https://git.kernel.org/stable/c/b3ad9ff6f06c1dc6abf7437691c88ca3d6da3ac0
- https://git.kernel.org/stable/c/d5a16a6df2c16eaf4de04948553ef0089dee463f
- https://git.kernel.org/stable/c/e157c8f87e8fac112d6c955e69a60cdb9bc80a60
- https://git.kernel.org/stable/c/ff4cafa51762da3824881a9000ca421d4b78b138
Modified: 2025-10-01
CVE-2022-49344
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race.
- https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf
- https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432
- https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2
- https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6
- https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca
- https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f
- https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913
Modified: 2025-09-22
CVE-2022-49345
In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean)
- https://git.kernel.org/stable/c/2b253fbc9f7b5db18d716436bdcf8ecef09fd63d
- https://git.kernel.org/stable/c/31f3c6a4dcd3260a386e62cef2d5b36e902600a1
- https://git.kernel.org/stable/c/4a388f08d8784af48f352193d2b72aaf167a57a1
- https://git.kernel.org/stable/c/85a055c03691e51499123194a14a0c249cf33227
- https://git.kernel.org/stable/c/be3884d5cd04ccd58294b83a02d70b7c5fca19d3
- https://git.kernel.org/stable/c/c58d82a1264813e69119c13e9804e2e60b664ad5
- https://git.kernel.org/stable/c/e04d59cfe0c0129df7aba7ef7bb17b96be2a64f2
- https://git.kernel.org/stable/c/e53cd3814504b2cadaba4d5a8a07eeea9ddacd03
- https://git.kernel.org/stable/c/ef6d2354de238b065d8799c80da4be9a6af18e39
Modified: 2025-10-01
CVE-2022-49346
In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. when breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the gphy_fw_np. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/0737e018a05e2aa352828c52bdeed3b02cff2930
- https://git.kernel.org/stable/c/2e007ac6fa7c9c94ad84da075c5c504afad690a0
- https://git.kernel.org/stable/c/32cd78c5610f02a929f63cac985e73692d05f33e
- https://git.kernel.org/stable/c/54d6802c4d83fa8de7696cfec06f475d5fd92d27
- https://git.kernel.org/stable/c/7c8df6fad43d9d5d77f281f794b2a93cd02fd1a9
- https://git.kernel.org/stable/c/c2ae49a113a5344232f1ebb93bcf18bbd11e9c39
Modified: 2025-09-22
CVE-2022-49347
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on in ext4_writepages
we got issue as follows:
EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls
------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2708!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155
RIP: 0010:ext4_writepages+0x1977/0x1c10
RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000
RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002
RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000
R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001
R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028
FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/013f12bdedb96816aaa27ee04349f4433d361f52
- https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4
- https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce
- https://git.kernel.org/stable/c/1b061af037646c9cdb0afd8a8d2f1e1c06285866
- https://git.kernel.org/stable/c/1cde35417edc0370fb0179a4e38b78a15350a8d0
- https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9
- https://git.kernel.org/stable/c/b2b78f5bf2d453dda3903955efee059260787a42
- https://git.kernel.org/stable/c/de1732b5c1693ad489c5d254f124f67cb775f37d
- https://git.kernel.org/stable/c/ef09ed5d37b84d18562b30cf7253e57062d0db05
Modified: 2025-10-21
CVE-2022-49348
In the Linux kernel, the following vulnerability has been resolved: ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state The EXT4_FC_REPLAY bit in sbi->s_mount_state is used to indicate that we are in the middle of replay the fast commit journal. This was actually a mistake, since the sbi->s_mount_info is initialized from es->s_state. Arguably s_mount_state is misleadingly named, but the name is historical --- s_mount_state and s_state dates back to ext2. What should have been used is the ext4_{set,clear,test}_mount_flag() inline functions, which sets EXT4_MF_* bits in sbi->s_mount_flags. The problem with using EXT4_FC_REPLAY is that a maliciously corrupted superblock could result in EXT4_FC_REPLAY getting set in s_mount_state. This bypasses some sanity checks, and this can trigger a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter out the EXT4_FC_REPLAY bit for now. We should eventually transition away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY.
- https://git.kernel.org/stable/c/55b4dbb29054a05d839562f6d635ce05669b016d
- https://git.kernel.org/stable/c/af2f1932743fb52ebcb008ad7ac500d9df0aa796
- https://git.kernel.org/stable/c/b99fd73418350dea360da8311e87a6a7b0e15a4c
- https://git.kernel.org/stable/c/c878bea3c9d724ddfa05a813f30de3d25a0ba83f
- https://git.kernel.org/stable/c/cc5b09cb6dacd4b32640537929ab4ee8fb2b9e04
Modified: 2025-03-25
CVE-2022-49349
In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ]
- https://git.kernel.org/stable/c/0be698ecbe4471fcad80e81ec6a05001421041b3
- https://git.kernel.org/stable/c/0ff38b99fa075ddd246487a28cb9af049f4ceef1
- https://git.kernel.org/stable/c/10801095224de0d0ab06ae60698680c1f883a3ae
- https://git.kernel.org/stable/c/1a3a15bf6f9963d755270cbdb282863b84839195
- https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f
- https://git.kernel.org/stable/c/4a2bea60cf7ff957b3eda0b17750d483876a02fa
- https://git.kernel.org/stable/c/97f802a652a749422dede32071d29a53cf4bd034
- https://git.kernel.org/stable/c/dd887f83ea54aea5b780a84527e23ab95f777fed
- https://git.kernel.org/stable/c/eaecf7ebfd5dd09038a80b14be46b844f54cfc5c
Modified: 2025-09-22
CVE-2022-49350
In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phy_device.c is never compiled as modular. (CONFIG_PHYLIB is boolean)
- https://git.kernel.org/stable/c/35b42dce619701f1300fb8498dae82c9bb1f0263
- https://git.kernel.org/stable/c/5534bcd7c40299862237c4a8fd9c5031b3db1538
- https://git.kernel.org/stable/c/59fa94cddf9eef8d8dae587373eed8b8f4eb11d7
- https://git.kernel.org/stable/c/6a90a44d53428a3bf01bd80df9ba78b19959270c
- https://git.kernel.org/stable/c/7759c3222815b945a94b212bc0c6cdec475cfec2
- https://git.kernel.org/stable/c/ab64ec2c75683f30ccde9eaaf0761002f901aa12
- https://git.kernel.org/stable/c/f2f0f8c18b60ca64ff50892ed899cf1c77864755
- https://git.kernel.org/stable/c/f5c68137f1191ba3fcf6260ec71b30be2e2bf4c3
Modified: 2025-10-01
CVE-2022-49351
In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d31950dcba0b3dd7283c
- https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584
- https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de
- https://git.kernel.org/stable/c/5cd0e22fa11f4a21a8c09cc258f20b1474c95801
- https://git.kernel.org/stable/c/803b217f1fb49a2dbb2123acdb45111b9c48b8be
- https://git.kernel.org/stable/c/8174acbef87b8dd8bf3731eba2a5af1ac857e239
- https://git.kernel.org/stable/c/96bf5ed057df2d157274d4e2079002f9a9404bb8
- https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833
- https://git.kernel.org/stable/c/e31d9ba169860687dba19bdc8fccbfd34077f655
Modified: 2025-10-21
CVE-2022-49352
In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_handle_inode_extension We got issue as follows: EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Modules linked in: CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a R13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_iter_readv_writev+0x2e5/0x360 do_iter_write+0x112/0x4c0 do_pwritev+0x1e5/0x390 __x64_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: Assume inode.i_size=4096 EXT4_I(inode)->i_disksize=4096 step 1: set inode->i_isize = 8192 ext4_setattr if (attr->ia_size != inode->i_size) EXT4_I(inode)->i_disksize = attr->ia_size; rc = ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc sb_getblk --> return -ENOMEM ... if (!error) ->will not update i_size i_size_write(inode, attr->ia_size); Now: inode.i_size=4096 EXT4_I(inode)->i_disksize=8192 step 2: Direct write 4096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->return error if (extend) ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize); ->Then trigger warning. To solve above issue, if mark inode dirty failed in ext4_setattr just set 'EXT4_I(inode)->i_disksize' with old value.
- https://git.kernel.org/stable/c/1bcce88da60eccc946c0f4ed942b0f08cd565778
- https://git.kernel.org/stable/c/adf490083ca52ebfb0b2fe64ff1ead00c0452dd7
- https://git.kernel.org/stable/c/b81d2ff6885e38fc745eeaf9565775055778fc0b
- https://git.kernel.org/stable/c/e383c2aa5f02ab571530dc5c5696479672478c25
- https://git.kernel.org/stable/c/f4534c9fc94d22383f187b9409abb3f9df2e3db3
Modified: 2025-10-01
CVE-2022-49354
In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak.
- https://git.kernel.org/stable/c/10d6bdf532902be1d8aa5900b3c03c5671612aa2
- https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1
- https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf
- https://git.kernel.org/stable/c/888312dc297a8a103f6371ef668c7e04f57a7679
- https://git.kernel.org/stable/c/8d8ad067b90f231b8fdb14acee673ca4012f6045
- https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b
- https://git.kernel.org/stable/c/c9782e1b21bee4b783a64b2a91e7e71406c21a21
- https://git.kernel.org/stable/c/d5a1e7f33c88780b279835d63665d7e38ccb671f
- https://git.kernel.org/stable/c/fb2cb409b504bb3a69e65a17f3120328c8e50219
Modified: 2025-10-21
CVE-2022-49357
In the Linux kernel, the following vulnerability has been resolved:
efi: Do not import certificates from UEFI Secure Boot for T2 Macs
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables
at early boot to load UEFI Secure Boot certificates, a page fault occurs
in Apple firmware code and EFI runtime services are disabled with the
following logs:
[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000
WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0
(Removed some logs from here)
Call Trace:
- https://git.kernel.org/stable/c/155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb
- https://git.kernel.org/stable/c/1f7264f0510f519b4e4f575a8f0579ea65e7592e
- https://git.kernel.org/stable/c/65237307f88f5200782ae7f243bdd385e37cde5d
- https://git.kernel.org/stable/c/b1cda6dd2c44771f042d65f0d17bec322ef99a0a
- https://git.kernel.org/stable/c/b34786b25d75f9c119696e6bdf3827f54ae3601b
- https://git.kernel.org/stable/c/c072cab98bac11f6ef9db640fb51834d9552e2e6
Modified: 2025-10-01
CVE-2022-49358
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: memleak flow rule from commit path Abort path release flow rule object, however, commit path does not. Update code to destroy these objects before releasing the transaction.
- https://git.kernel.org/stable/c/330c0c6cd2150a2d7f47af16aa590078b0d2f736
- https://git.kernel.org/stable/c/5b8d63489c3b701eb2a76f848ec94d8cbc9373b9
- https://git.kernel.org/stable/c/80de9ea1f5b808a6601e91111fae601df2b26369
- https://git.kernel.org/stable/c/9dd732e0bdf538b1b76dc7c157e2b5e560ff30d3
- https://git.kernel.org/stable/c/ab9f34a30c23f656e76f4c5b83125a4e7b53c86e
- https://git.kernel.org/stable/c/e33d9bd563e71f6c6528b96008d65524a459c4dc
Modified: 2025-10-21
CVE-2022-49360
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on total_data_blocks As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215916 The kernel message is shown below: kernel BUG at fs/f2fs/segment.c:2560! Call Trace: allocate_segment_by_default+0x228/0x440 f2fs_allocate_data_block+0x13d1/0x31f0 do_write_page+0x18d/0x710 f2fs_outplace_write_data+0x151/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0x3bc0 f2fs_balance_fs+0x921/0x2260 f2fs_write_single_data_page+0x16be/0x2370 f2fs_write_cache_pages+0x428/0xd00 f2fs_write_data_pages+0x96e/0xd50 do_writepages+0x168/0x550 __writeback_single_inode+0x9f/0x870 writeback_sb_inodes+0x47d/0xb20 __writeback_inodes_wb+0xb2/0x200 wb_writeback+0x4bd/0x660 wb_workfn+0x5f3/0xab0 process_one_work+0x79f/0x13e0 worker_thread+0x89/0xf60 kthread+0x26a/0x300 ret_from_fork+0x22/0x30 RIP: 0010:new_curseg+0xe8d/0x15f0 The root cause is: ckpt.valid_block_count is inconsistent with SIT table, stat info indicates filesystem has free blocks, but SIT table indicates filesystem has no free segment. So that during garbage colloection, it triggers panic when LFS allocator fails to find free segment. This patch tries to fix this issue by checking consistency in between ckpt.valid_block_count and block accounted from SIT.
- https://git.kernel.org/stable/c/071b1269a3b3ad9cec16ed76a48015bfffd9aee8
- https://git.kernel.org/stable/c/6b8beca0edd32075a769bfe4178ca00c0dcd22a9
- https://git.kernel.org/stable/c/c9e4cd5b0ccd7168801d6a811919171b185c5cf8
- https://git.kernel.org/stable/c/cc8c9df19971e59ebbe669ce710080e347dfec32
- https://git.kernel.org/stable/c/ef221b738b26d8c9f7e7967f4586db2dd3bd5288
Modified: 2025-10-21
CVE-2022-49361
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check for inline inode Yanming reported a kernel bug in Bugzilla kernel [1], which can be reproduced. The bug message is: The kernel message is shown below: kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 dput+0x2dd/0x720 do_renameat2+0x596/0x970 __x64_sys_rename+0x78/0x90 do_syscall_64+0x3b/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 The bug is due to fuzzed inode has both inline_data and encrypted flags. During f2fs_evict_inode(), as the inode was deleted by rename(), it will cause inline data conversion due to conflicting flags. The page cache will be polluted and the panic will be triggered in clear_inode(). Try fixing the bug by doing more sanity checks for inline data inode in sanity_check_inode().
- https://git.kernel.org/stable/c/11c1cd032df85df3c096a57a7f27d57819956e4a
- https://git.kernel.org/stable/c/198fd9faa271dd54dca6fc8eb6873f42dfd3b4d8
- https://git.kernel.org/stable/c/677a82b44ebf263d4f9a0cfbd576a6ade797a07b
- https://git.kernel.org/stable/c/7cfe2d43becaf76e562b9617d2c2d9b445f86761
- https://git.kernel.org/stable/c/efdefbe8b7564602ab446474788225a1f2a323b5
Modified: 2025-10-21
CVE-2022-49363
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on block address in f2fs_do_zero_range() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215894 I have encountered a bug in F2FS file system in kernel v5.17. I have uploaded the system call sequence as case.c, and a fuzzed image can be found in google net disk The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: kernel BUG at fs/f2fs/segment.c:2291! Call Trace: f2fs_invalidate_blocks+0x193/0x2d0 f2fs_fallocate+0x2593/0x4a70 vfs_fallocate+0x2a5/0xac0 ksys_fallocate+0x35/0x70 __x64_sys_fallocate+0x8e/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is, after image was fuzzed, block mapping info in inode will be inconsistent with SIT table, so in f2fs_fallocate(), it will cause panic when updating SIT with invalid blkaddr. Let's fix the issue by adding sanity check on block address before updating SIT table with it.
- https://git.kernel.org/stable/c/25f8236213a91efdf708b9d77e9e51b6fc3e141c
- https://git.kernel.org/stable/c/470493be19a5730ed432e3ac0f29a2ee7fc6c557
- https://git.kernel.org/stable/c/7361c9f2bd6a8f0cbb41cdea9aff04765ff23f67
- https://git.kernel.org/stable/c/805b48b234a2803cb7daec7f158af12f0fbaefac
- https://git.kernel.org/stable/c/a34d7b49894b0533222188a52e2958750f830efd
- https://git.kernel.org/stable/c/f2e1c38b5ac64eb1a16a89c52fb419409d12c25b
Modified: 2025-10-21
CVE-2022-49364
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty inode in f2fs_evict_inode() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215904 The kernel message is shown below: kernel BUG at fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 shrink_dentry_list+0x17c/0x4f0 shrink_dcache_parent+0x143/0x1e0 do_one_tree+0x9/0x30 shrink_dcache_for_umount+0x51/0x120 generic_shutdown_super+0x5c/0x3a0 kill_block_super+0x90/0xd0 kill_f2fs_super+0x225/0x310 deactivate_locked_super+0x78/0xc0 cleanup_mnt+0x2b7/0x480 task_work_run+0xc8/0x150 exit_to_user_mode_prepare+0x14a/0x150 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 The root cause is: inode node and dnode node share the same nid, so during f2fs_evict_inode(), dnode node truncation will invalidate its NAT entry, so when truncating inode node, it fails due to invalid NAT entry, result in inode is still marked as dirty, fix this issue by clearing dirty for inode and setting SBI_NEED_FSCK flag in filesystem. output from dump.f2fs: [print_node_info: 354] Node ID [0xf:15] is inode i_nid[0] [0x f : 15]
- https://git.kernel.org/stable/c/03c9373b15fa1c245ec99b2b5e7ba209eae4ef42
- https://git.kernel.org/stable/c/54c116615c99e22aa08aa950757ed726e2f60821
- https://git.kernel.org/stable/c/c469953917b319d415fd621b9e5d0ea5203565cd
- https://git.kernel.org/stable/c/c9196d21359be8c7ee231029d13682273925fd00
- https://git.kernel.org/stable/c/ccd58045beb997544b94558a9156be4742628491
- https://git.kernel.org/stable/c/f2db71053dc0409fae785096ad19cce4c8a95af7
Modified: 2025-10-01
CVE-2022-49367
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/02ded5a173619b11728b8bf75a3fd995a2c1ff28
- https://git.kernel.org/stable/c/42658e47f1abbbe592007d3ba303de466114d0bb
- https://git.kernel.org/stable/c/86c3c5f8e4bd1325e24f6fba9017cade29933377
- https://git.kernel.org/stable/c/8a1a1255152da4fb934290e7ababc66f24985520
- https://git.kernel.org/stable/c/a101793994c0a14c70bb4e44c7fda597eeebba0a
- https://git.kernel.org/stable/c/c1df9cb756e5a9ba1841648c44ee5d92306b9c65
- https://git.kernel.org/stable/c/dc1cf8c6f9793546696fded437a5b4c84944c48b
- https://git.kernel.org/stable/c/e0d763d0c7665c7897e4f5a0847ab0c82543345f
Modified: 2025-10-01
CVE-2022-49368
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read.
- https://git.kernel.org/stable/c/0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8
- https://git.kernel.org/stable/c/2bd1faedb74dc2a2be3972abcd4239b75a3e7b00
- https://git.kernel.org/stable/c/4cde554c70d7397cfa2e4116bacb4accdfb6fd48
- https://git.kernel.org/stable/c/5ba81f82607ead85fe36f50869fc4f5661359ab8
- https://git.kernel.org/stable/c/657e7174603f0aab2cdedc64ac81edffd2a87afe
- https://git.kernel.org/stable/c/71ae30662ec610b92644d13f79c78f76f17873b3
- https://git.kernel.org/stable/c/b24ca1cf846273361d5bd73a35de95a486a54b6d
- https://git.kernel.org/stable/c/b4f0e57ea0d867aacffad7999527e48bd4ea9293
- https://git.kernel.org/stable/c/e7e7104e2d5ddf3806a28695670f21bef471f1e1
Modified: 2025-10-01
CVE-2022-49370
In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put().
- https://git.kernel.org/stable/c/3ba359ebe914ac3f8c6c832b28007c14c39d3766
- https://git.kernel.org/stable/c/660ba678f9998aca6db74f2dd912fa5124f0fa31
- https://git.kernel.org/stable/c/985706bd3bbeffc8737bc05965ca8d24837bc7db
- https://git.kernel.org/stable/c/a724634b2a49f6ff0177a9e19a5a92fc1545e1b7
- https://git.kernel.org/stable/c/a9bfb37d6ba7c376b0d53337a4c5f5ff324bd725
- https://git.kernel.org/stable/c/c66cc3c62870a27ea8f060a7e4c1ad8d26dd3f0d
- https://git.kernel.org/stable/c/ec752973aa721ee281d5441e497364637c626c7b
- https://git.kernel.org/stable/c/ed38d04342dfbe9e5aca745c8b5eb4188a74f0ef
- https://git.kernel.org/stable/c/fdffa4ad8f6bf1ece877edfb807f2b2c729d8578
Modified: 2025-10-01
CVE-2022-49371
In the Linux kernel, the following vulnerability has been resolved: driver core: fix deadlock in __device_attach In __device_attach function, The lock holding logic is as follows: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As shown above, when it is allowed to do async probes, because of out of memory or work limit, async work is not allowed, to do sync execute instead. it will lead to A-A deadlock because of __device_attach_async_helper getting lock dev. To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock.
- https://git.kernel.org/stable/c/34fdd9b7def9d2fcb71bb7b0bc4848dd7313767e
- https://git.kernel.org/stable/c/36ee9ffca8ef56c302f2855c4a5fccf61c0c1ada
- https://git.kernel.org/stable/c/593b595332bd2d65e1a5c1ae7897996c157f5468
- https://git.kernel.org/stable/c/b232b02bf3c205b13a26dcec08e53baddd8e59ed
- https://git.kernel.org/stable/c/d53a227bfcd5160ce1b61d9954901968a20651e7
- https://git.kernel.org/stable/c/df6de52b80aa3b46f5ac804412355ffe2e1df93e
Modified: 2025-10-21
CVE-2022-49372
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_rtx_synack() can be called from process context
Laurent reported the enclosed report [1]
This bug triggers with following coditions:
0) Kernel built with CONFIG_DEBUG_PREEMPT=y
1) A new passive FastOpen TCP socket is created.
This FO socket waits for an ACK coming from client to be a complete
ESTABLISHED one.
2) A socket operation on this socket goes through lock_sock()
release_sock() dance.
3) While the socket is owned by the user in step 2),
a retransmit of the SYN is received and stored in socket backlog.
4) At release_sock() time, the socket backlog is processed while
in process context.
5) A SYNACK packet is cooked in response of the SYN retransmit.
6) -> tcp_rtx_synack() is called in process context.
Before blamed commit, tcp_rtx_synack() was always called from BH handler,
from a timer handler.
Fix this by using TCP_INC_STATS() & NET_INC_STATS()
which do not assume caller is in non preemptible context.
[1]
BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
caller is tcp_rtx_synack.part.0+0x36/0xc0
CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1
Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
Call Trace:
- https://git.kernel.org/stable/c/0a0f7f84148445c9f02f226928803a870139d820
- https://git.kernel.org/stable/c/0a375c822497ed6ad6b5da0792a12a6f1af10c0b
- https://git.kernel.org/stable/c/3db889f883e65bbd3b1401279bfc1e9ed255c481
- https://git.kernel.org/stable/c/58bd38cbc961fd799842b7be8c5222310f04b908
- https://git.kernel.org/stable/c/88cd232146207ff1d41dededed5e77c0d4438113
- https://git.kernel.org/stable/c/bdc28a8fb43cc476e33b11519235adb816ce00e8
- https://git.kernel.org/stable/c/c348b0f8d035fc4bdc040796889beec7218bd1b8
- https://git.kernel.org/stable/c/d05c2fdf8e10528bb6751bd95243e862d5402a9b
- https://git.kernel.org/stable/c/d8e1bc6029acac796293310aacef7b7336f35b6a
Modified: 2025-10-01
CVE-2022-49373
In the Linux kernel, the following vulnerability has been resolved: watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() in some error paths.
- https://git.kernel.org/stable/c/5b110d940417942bc87d9e4bea6d4f24e05ed483
- https://git.kernel.org/stable/c/5d24df3d690809952528e7a19a43d84bc5b99d44
- https://git.kernel.org/stable/c/7a4afd8a003d6abf1f5d159c2bb67e6b7cbde253
- https://git.kernel.org/stable/c/910b1cdf6c50ae8fb222e46657d04fb181577017
- https://git.kernel.org/stable/c/91fa5aa53f68b85e779164b3127c7e23cad5c457
- https://git.kernel.org/stable/c/f067b5286edfd83d2d3903e8578b561599d62539
Modified: 2025-10-01
CVE-2022-49374
In the Linux kernel, the following vulnerability has been resolved: tipc: check attribute length for bearer name syzbot reported uninit-value: ===================================================== BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME. - Do not use 'illegal name' in printing message.
- https://git.kernel.org/stable/c/292be63c382ce20673ee61dff1ee9ed4a3dcaae7
- https://git.kernel.org/stable/c/3af15272cde28fe5c8489174b8624e232c1775ec
- https://git.kernel.org/stable/c/7f36f798f89bf32c0164049cb0e3fd1af613d0bb
- https://git.kernel.org/stable/c/8b91d0dfc839e67708c905648cd0e7507a2263e5
- https://git.kernel.org/stable/c/92a930fcf4250fe961f6238b99af0bc405799f39
- https://git.kernel.org/stable/c/b8fac8e321044a9ac50f7185b4e9d91a7745e4b0
- https://git.kernel.org/stable/c/f07670871f4d19e613740eebe210e7e9ea535973
Modified: 2025-10-01
CVE-2022-49375
In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/3867f0bbb94773d41e789257abec0d14f37da217
- https://git.kernel.org/stable/c/58a729c55ce3a432eb827fdaa24c7909cd3b0a6b
- https://git.kernel.org/stable/c/6ecd4d5c28408df36a1a6f0b1973f633c949ac1f
- https://git.kernel.org/stable/c/79fa3f5758d8712df0678df98161f948fc4370e5
- https://git.kernel.org/stable/c/82bfea344e8f7e9a0e0b1bf9af27552baa756620
- https://git.kernel.org/stable/c/865051de2d9eaa50630e055b73921ceaf3c4a7fc
- https://git.kernel.org/stable/c/d3b43eb505bffb8e4cdf6800c15660c001553fe6
- https://git.kernel.org/stable/c/d77f28c1bc9d3043a52069fe42e4a26fbf961ebd
- https://git.kernel.org/stable/c/da38e86d6cf6dd3bc65c602d998f357145aa1a0b
Modified: 2025-10-01
CVE-2022-49376
In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix potential NULL pointer dereference If sd_probe() sees an early error before sdkp->device is initialized, sd_zbc_release_disk() is called. This causes a NULL pointer dereference when sd_is_zoned() is called inside that function. Avoid this by removing the call to sd_zbc_release_disk() in sd_probe() error path. This change is safe and does not result in zone information memory leakage because the zone information for a zoned disk is allocated only when sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set, resulting in sd_disk_release() being called when needed to cleanup a disk zone information using sd_zbc_release_disk().
- https://git.kernel.org/stable/c/05fbde3a77a4f1d62e4c4428f384288c1f1a0be5
- https://git.kernel.org/stable/c/0fcb0b131cc90c8f523a293d84c58d0c7273c96f
- https://git.kernel.org/stable/c/3733439593ad12f7b54ae35c273ea6f15d692de3
- https://git.kernel.org/stable/c/78f8e96df06e2d04d82d4071c299b59d28744f47
- https://git.kernel.org/stable/c/c1f0187025905e9981000d44a92e159468b561a8
Modified: 2025-10-21
CVE-2022-49378
In the Linux kernel, the following vulnerability has been resolved: sfc: fix considering that all channels have TX queues Normally, all channels have RX and TX queues, but this is not true if modparam efx_separate_tx_channels=1 is used. In that cases, some channels only have RX queues and others only TX queues (or more preciselly, they have them allocated, but not initialized). Fix efx_channel_has_tx_queues to return the correct value for this case too. Messages shown at probe time before the fix: sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0 ------------[ cut here ]------------ netdevice: ens6f0np0: failed to initialise TXQ -1 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped Call Trace: efx_init_tx_queue+0xaa/0xf0 [sfc] efx_start_channels+0x49/0x120 [sfc] efx_start_all+0x1f8/0x430 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xd0/0x190 __dev_change_flags+0x1b3/0x220 dev_change_flags+0x21/0x60 [...] stripped Messages shown at remove time before the fix: sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues sfc 0000:03:00.0 ens6f0np0: failed to flush queues
- https://git.kernel.org/stable/c/2e102b53f8a778f872dc137f4c7ac548705817aa
- https://git.kernel.org/stable/c/5567d69b95b9c07e1c56f15cf0301251d12e5f97
- https://git.kernel.org/stable/c/8f81a4113e1e574d2cbde4f2cd599380a9189c0f
- https://git.kernel.org/stable/c/913d45f02d346ce41c4aad057eaf53a8ed449dc3
- https://git.kernel.org/stable/c/e7e8d5e25dc762b70f9c88ec6b7d451d0816eead
Modified: 2025-09-22
CVE-2022-49379
In the Linux kernel, the following vulnerability has been resolved: driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction Mounting NFS rootfs was timing out when deferred_probe_timeout was non-zero [1]. This was because ip_auto_config() initcall times out waiting for the network interfaces to show up when deferred_probe_timeout was non-zero. While ip_auto_config() calls wait_for_device_probe() to make sure any currently running deferred probe work or asynchronous probe finishes, that wasn't sufficient to account for devices being deferred until deferred_probe_timeout. Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires") tried to fix that by making sure wait_for_device_probe() waits for deferred_probe_timeout to expire before returning. However, if wait_for_device_probe() is called from the kernel_init() context: - Before deferred_probe_initcall() [2], it causes the boot process to hang due to a deadlock. - After deferred_probe_initcall() [3], it blocks kernel_init() from continuing till deferred_probe_timeout expires and beats the point of deferred_probe_timeout that's trying to wait for userspace to load modules. Neither of this is good. So revert the changes to wait_for_device_probe(). [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/ [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/ [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/
- https://git.kernel.org/stable/c/29357883a89193863f3cc6a2c5e0b42ceb022761
- https://git.kernel.org/stable/c/4ad6af07efcca85369c21e4897b3020cff2c170b
- https://git.kernel.org/stable/c/528229474e1cbb1b3451cb713d94aecb5f6ee264
- https://git.kernel.org/stable/c/5ee76c256e928455212ab759c51d198fedbe7523
- https://git.kernel.org/stable/c/71cbce75031aed26c72c2dc8a83111d181685f1b
Modified: 2025-10-21
CVE-2022-49380
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid f2fs_bug_on() in dec_valid_node_count() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215897 I have encountered a bug in F2FS file system in kernel v5.17. The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: The kernel message is shown below: kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fs_remove_inode_page+0x2a2/0x830 f2fs_evict_inode+0x9b7/0x1510 evict+0x282/0x4e0 do_unlinkat+0x33a/0x540 __x64_sys_unlinkat+0x8e/0xd0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is: .total_valid_block_count or .total_valid_node_count could fuzzed to zero, then once dec_valid_node_count() was called, it will cause BUG_ON(), this patch fixes to print warning info and set SBI_NEED_FSCK into CP instead of panic.
- https://git.kernel.org/stable/c/2766ddaf45b69252bb8fe526b5b6e56904a9ae7a
- https://git.kernel.org/stable/c/4d17e6fe9293d57081ffdc11e1cf313e25e8fd9e
- https://git.kernel.org/stable/c/89d9a48d0cd30429463ea4e37ca83be6773ed5eb
- https://git.kernel.org/stable/c/bce859358d3d5940aa858e40ceee70ee6e76130e
- https://git.kernel.org/stable/c/ccffa99ae6a1f44797b57444c6a80382a42928fe
- https://git.kernel.org/stable/c/f8b3c3fcf33105bc1ee7788e3b51b0a1ae42ae53
Modified: 2025-10-01
CVE-2022-49381
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_fill_super
If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
an error, we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff888105a65340 (size 64):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/28048a4cf3813b7cf5cc8cce629dfdc7951cb1c2
- https://git.kernel.org/stable/c/3252d327f977b14663a10967f3b0930d6c325687
- https://git.kernel.org/stable/c/4ba7bbeab8009faf3a726e565d98816593ddd5b0
- https://git.kernel.org/stable/c/4da8763a3d2b684c773b72ed80fad40bc264bc40
- https://git.kernel.org/stable/c/69295267c481545f636b69ff341b8db75aa136b9
- https://git.kernel.org/stable/c/c14adb1cf70a984ed081c67e9d27bc3caad9537c
- https://git.kernel.org/stable/c/cf9db013e167bc8fc2ecd7a13ed97a37df0c9dab
- https://git.kernel.org/stable/c/d3a4fff1e7e408c32649030daa7c2c42a7e19a95
- https://git.kernel.org/stable/c/ecc53e58596542791e82eff00702f8af7a313f70
Modified: 2025-10-01
CVE-2022-49382
In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/042571fe1d171773655ad706715ecc865913d9a4
- https://git.kernel.org/stable/c/28133325526b92921f3269fdf97a20d90b92b217
- https://git.kernel.org/stable/c/5b3e990f85eb034faa461e691e719e8ce9e2a3c8
- https://git.kernel.org/stable/c/69a30b2ed620c2206cbbd1e9c112e4fc584e02bd
- https://git.kernel.org/stable/c/8f64e84924604bb969ee1fbc4b8d7d09b9214889
- https://git.kernel.org/stable/c/9b59588d8be91c96bfb0371e912ceb4f16315dbf
- https://git.kernel.org/stable/c/aab25b669cb9fd3698c2631be4435f4fe92d9e59
- https://git.kernel.org/stable/c/d5422f323858cad3ac3581075f9a3a5e0d41c0d8
Modified: 2025-03-25
CVE-2022-49385
In the Linux kernel, the following vulnerability has been resolved: driver: base: fix UAF when driver_attach failed When driver_attach(drv); failed, the driver_private will be freed. But it has been added to the bus, which caused a UAF. To fix it, we need to delete it from the bus when failed.
- https://git.kernel.org/stable/c/310862e574001a97ad02272bac0fd13f75f42a27
- https://git.kernel.org/stable/c/5389101257828d1913d713d9a40acbe14f5961df
- https://git.kernel.org/stable/c/5d709f58c743166fe1c6914b9de0ae8868600d9b
- https://git.kernel.org/stable/c/823f24f2e329babd0330200d0b74882516fe57f4
- https://git.kernel.org/stable/c/c059665c84feab46b7173d3a1bf36c2fb7f9df86
- https://git.kernel.org/stable/c/cdf1a683a01583bca4b618dd16223cbd6e462e21
Modified: 2025-10-01
CVE-2022-49386
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don't release the refcount in error case. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/2e44f21c384503562713b7d3b673c40bed20af3d
- https://git.kernel.org/stable/c/5dd89d2fc438457811cbbec07999ce0d80051ff5
- https://git.kernel.org/stable/c/78aca10a16f001c9f49f1cc4dadfee8d444bb173
- https://git.kernel.org/stable/c/a4b7ef3b159805ba6be061d0cd2403d84b9b0063
- https://git.kernel.org/stable/c/f7ba2cc57f404d2d9f26fb85bd3833d35a477829
Modified: 2025-03-25
CVE-2022-49388
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link].
- https://git.kernel.org/stable/c/1174ab8ba36a48025b68b5ff1085000b1e510217
- https://git.kernel.org/stable/c/25ff1e3a1351c0d936dd1ac2f9e58231ea1510c9
- https://git.kernel.org/stable/c/5ff2514e4fb55dcf3d88294686040ca73ea0c1a2
- https://git.kernel.org/stable/c/6d8d3f68cbecfd31925796f0fb668eb21ab06734
- https://git.kernel.org/stable/c/8302620aeb940f386817321d272b12411ae7d39f
- https://git.kernel.org/stable/c/8c03a1c21d72210f81cb369cc528e3fde4b45411
- https://git.kernel.org/stable/c/abb67043060f2bf4c03d7c3debb9ae980e2b6db3
- https://git.kernel.org/stable/c/e27ecf325e51abd06aaefba57a6322a46fa4178b
Modified: 2025-10-01
CVE-2022-49389
In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review.
- https://git.kernel.org/stable/c/11c65408bd0ba1d9cd1307caa38169292de9cdfb
- https://git.kernel.org/stable/c/247d3809e45a34d9e1a3a2bb7012e31ed8b46031
- https://git.kernel.org/stable/c/2f0ae93ec33c8456cdfbf7876b80403a6318ebce
- https://git.kernel.org/stable/c/51422046be504515eb5a591adf0f424b62f46804
- https://git.kernel.org/stable/c/6bafee2f18af5e5ac125e42960bc65496d0e56a0
- https://git.kernel.org/stable/c/8afb048800919d0ab10c57983940eba956339f21
- https://git.kernel.org/stable/c/9ec4cbf1cc55d126759051acfe328d489c5d6e60
- https://git.kernel.org/stable/c/bcbb795a9e78180d74c6ab21518da87e803dfdce
- https://git.kernel.org/stable/c/f20d2d3b3364ce6525c050a8b6b4c54c8c19674d
Modified: 2025-10-21
CVE-2022-49394
In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix inflight count imbalances and IO hangs on offline iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.
- https://git.kernel.org/stable/c/515d077ee3085ae343b6bea7fd031f9906645f38
- https://git.kernel.org/stable/c/5b0ff3ebbef791341695b718f8d2870869cf1d01
- https://git.kernel.org/stable/c/77692c02e1517c54f2fd0535f41aa4286ac9f140
- https://git.kernel.org/stable/c/8a177a36da6c54c98b8685d4f914cb3637d53c0d
- https://git.kernel.org/stable/c/968f7a239c590454ffba79c126fbe0e963a0ba78
- https://git.kernel.org/stable/c/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547
- https://git.kernel.org/stable/c/d19fa8f252000d141f9199ca32959c50314e1f05
Modified: 2025-10-01
CVE-2022-49395
In the Linux kernel, the following vulnerability has been resolved: um: Fix out-of-bounds read in LDT setup syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================
- https://git.kernel.org/stable/c/10995a382271254bd276627ec74136da4a23c4a6
- https://git.kernel.org/stable/c/24ca648bf5f72ed8878cf09b5d4431935779681e
- https://git.kernel.org/stable/c/2a4a62a14be1947fa945c5c11ebf67326381a568
- https://git.kernel.org/stable/c/3549ab4b962cf619e8c55484a0d870a34b3f845f
- https://git.kernel.org/stable/c/668ca34a428d6ffc0f99a1a6a9b661a288d4183b
- https://git.kernel.org/stable/c/91e5ba2af2d729d5126aefd5aa3eadc69b8426e5
- https://git.kernel.org/stable/c/9caad70819aef3431abaf73ba5163b55b161aba0
- https://git.kernel.org/stable/c/cf0dabc37446c5ee538ae7b4c467ab0e53fa5463
- https://git.kernel.org/stable/c/ef1dc929a1e5fa1b2d842256db9fb8710d3be910
Modified: 2025-09-22
CVE-2022-49396
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix reset-controller leak on probe errors Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly.
- https://git.kernel.org/stable/c/2156dc390402043ba5982489c6625adcb0b0975c
- https://git.kernel.org/stable/c/4d2900f20edfe541f75756a00deeb2ffe7c66bc1
- https://git.kernel.org/stable/c/7ac21b24af859c097eb4034e93430056068f8f31
- https://git.kernel.org/stable/c/8c03eb0c8982677b4e17174073a011788891304d
- https://git.kernel.org/stable/c/a39d9eccb333b8c07c43ebea1c6dfda122378a0f
- https://git.kernel.org/stable/c/b7b5fbcaac5355e2e695dc0c08a0fcf248250388
- https://git.kernel.org/stable/c/ba173a6f8d8dffed64bb13ab23081bdddfb464f0
- https://git.kernel.org/stable/c/feb05b10b3ed3ae21b851520a0d0b71685439517
Modified: 2025-09-22
CVE-2022-49397
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix struct clk leak on probe errors Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral).
- https://git.kernel.org/stable/c/1668ad103679306ba2ef37f758d704e58a3ef1a0
- https://git.kernel.org/stable/c/621a4bcfb7aa031e7760d7b156bad7a45df58387
- https://git.kernel.org/stable/c/6f3673c8d8eff0c4ab5a5ee0d3ca9717d85419b4
- https://git.kernel.org/stable/c/ad9b0fad02f9b3a06ad5ac7df11f244e316a6254
- https://git.kernel.org/stable/c/b246695636a861a09f0e2cde92bb2dd8f114f024
- https://git.kernel.org/stable/c/b999d48b0869b8599de532ff6081575a7ab5358a
- https://git.kernel.org/stable/c/f0a4bc38a12f5a0cc5ad68670d9480e91e6a94df
- https://git.kernel.org/stable/c/f8d23895a41243c6a8dbf392e531fff9497bb023
Modified: 2025-10-21
CVE-2022-49399
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Use tty_port_destroy() to destroy port In goldfish_tty_probe(), the port initialized through tty_port_init() should be destroyed in error paths.In goldfish_tty_remove(), qtty->port also should be destroyed or else might leak resources. Fix the above by calling tty_port_destroy().
- https://git.kernel.org/stable/c/241fcb79dd1df276d80b19f5f6acc9eaaaa63309
- https://git.kernel.org/stable/c/326192b99c903a2193d820c30ed936cc2402382c
- https://git.kernel.org/stable/c/45f6ce70abfb7ccf9d787781cbc4c03294a775a1
- https://git.kernel.org/stable/c/4639d1b992de8f37d66f698056875c274efcd45f
- https://git.kernel.org/stable/c/507b05063d1b7a1fcb9f7d7c47586fc4f3508f98
- https://git.kernel.org/stable/c/9ae3d073f7db5578ae1907544f0c15947e9678e6
- https://git.kernel.org/stable/c/da64f419d7f78272bfe40dde1262602d4ff6b32c
- https://git.kernel.org/stable/c/ee6c33b29e624f515202a31bf6ef0437f26a1867
Modified: 2025-10-21
CVE-2022-49402
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Clean up hash direct_functions on register failures
We see the following GPF when register_ftrace_direct fails:
[ ] general protection fault, probably for non-canonical address \
0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[...]
[ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70
[ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...]
[ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206
[ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b
[ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0
[ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001
[ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0
[ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000
[ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000
[ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0
[ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ ] Call Trace:
[ ]
- https://git.kernel.org/stable/c/7d54c15cb89a29a5f59e5ffc9ee62e6591769ef1
- https://git.kernel.org/stable/c/805e87af946d8d2954171361e64d143ff37a441b
- https://git.kernel.org/stable/c/82c888e51c2176a06f8b4541cf748ee81aac6e7e
- https://git.kernel.org/stable/c/a0392833a178cf109a57c2a9d4d531bdfc6cd98f
- https://git.kernel.org/stable/c/cae2978d6907ef2c08b9b15f704e783f7c284713
Modified: 2025-10-01
CVE-2022-49404
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow.
- https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188407eba2996d
- https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a
- https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6
- https://git.kernel.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b
- https://git.kernel.org/stable/c/79c164e61f818054cd6012e9035701840d895c51
- https://git.kernel.org/stable/c/8858284dd74906fa00f04f0252c75df4893a7959
- https://git.kernel.org/stable/c/a89cb7ddf6a89bab6012e19da38b7cdb26175c19
- https://git.kernel.org/stable/c/ef5ab2e48a5f9960e2352332b7cdb7064bb49032
- https://git.kernel.org/stable/c/f93e91a0372c922c20d5bee260b0f43b4b8a1bee
Modified: 2025-09-22
CVE-2022-49407
In the Linux kernel, the following vulnerability has been resolved: dlm: fix plock invalid read This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated---
- https://git.kernel.org/stable/c/2c55155cc365861044d9e6e80e342693e8805e33
- https://git.kernel.org/stable/c/42252d0d2aa9b94d168241710a761588b3959019
- https://git.kernel.org/stable/c/49cd9eb7b9a7b88124b31e31f8e539acaf1b3a6d
- https://git.kernel.org/stable/c/56aa8d1fbd02357f3bf81bdfba1cde87ce8402fc
- https://git.kernel.org/stable/c/5a1765adf9855cf0f6d3f7e0eb4b78ca66f70dee
- https://git.kernel.org/stable/c/72f2f68970f9bdc252d59e119b385a6441b0b155
- https://git.kernel.org/stable/c/899bc4429174861122f0c236588700a4710c1fec
- https://git.kernel.org/stable/c/acdad5bc9827922ec2f2e84fd198718aa8e8ab92
- https://git.kernel.org/stable/c/e421872fa17542cf33747071fb141b0130ce9ef7
Modified: 2025-09-22
CVE-2022-49409
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in __es_tree_search Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/extents_status.c:199! [...] RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 [...] Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk) The error ext4 extents is as follows: 0af3 0300 0400 0000 00000000 extent_header 00000000 0100 0000 12000000 extent1 00000000 0100 0000 18000000 extent2 02000000 0400 0000 14000000 extent3 In the ext4_valid_extent_entries function, if prev is 0, no error is returned even if lblock<=prev. This was intended to skip the check on the first extent, but in the error image above, prev=0+1-1=0 when checking the second extent, so even though lblock<=prev, the function does not return an error. As a result, bug_ON occurs in __es_tree_search and the system panics. To solve this problem, we only need to check that: 1. The lblock of the first extent is not less than 0. 2. The lblock of the next extent is not less than the next block of the previous extent. The same applies to extent_idx.
- https://git.kernel.org/stable/c/3c617827cd51018bc377bd2954e176920ddbcfad
- https://git.kernel.org/stable/c/4fd58b5cf118d2d9038a0b8c9cc0e43096297686
- https://git.kernel.org/stable/c/59cf2fabbfe76de29d88dd7ae69858a25735b59f
- https://git.kernel.org/stable/c/d0083459e2b6b07ebd78bea2fe684a19cc0f3d0f
- https://git.kernel.org/stable/c/d36f6ed761b53933b0b4126486c10d3da7751e7f
- https://git.kernel.org/stable/c/ea6ea18b3ab0c0d7fefffb3c4d27df758b1c790a
Modified: 2025-10-01
CVE-2022-49410
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref().
- https://git.kernel.org/stable/c/058cb6d86b9789377216c936506b346aaa1eb581
- https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50
- https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e
- https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f
- https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae
- https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2
- https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a
Modified: 2025-03-25
CVE-2022-49411
In the Linux kernel, the following vulnerability has been resolved: bfq: Make sure bfqg for which we are queueing requests is online Bios queued into BFQ IO scheduler can be associated with a cgroup that was already offlined. This may then cause insertion of this bfq_group into a service tree. But this bfq_group will get freed as soon as last bio associated with it is completed leading to use after free issues for service tree users. Fix the problem by making sure we always operate on online bfq_group. If the bfq_group associated with the bio is not online, we pick the first online parent.
- https://git.kernel.org/stable/c/075a53b78b815301f8d3dd1ee2cd99554e34f0dd
- https://git.kernel.org/stable/c/51f724bffa3403a5236597e6b75df7329c1ec6e9
- https://git.kernel.org/stable/c/6ee0868b0c3ccead5907685fcdcdd0c08dfe4b0b
- https://git.kernel.org/stable/c/7781c38552e6cc54ed8e9040279561340516b881
- https://git.kernel.org/stable/c/97bd6c56bdcb41079e488e31df56809e3b2ce628
- https://git.kernel.org/stable/c/ccddf8cd411c1800863ed357064e56ceffd356bb
Modified: 2025-06-19
CVE-2022-49412
In the Linux kernel, the following vulnerability has been resolved:
bfq: Avoid merging queues with different parents
It can happen that the parent of a bfqq changes between the moment we
decide two queues are worth to merge (and set bic->stable_merge_bfqq)
and the moment bfq_setup_merge() is called. This can happen e.g. because
the process submitted IO for a different cgroup and thus bfqq got
reparented. It can even happen that the bfqq we are merging with has
parent cgroup that is already offline and going to be destroyed in which
case the merge can lead to use-after-free issues such as:
BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50
Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544
CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
Call Trace:
Modified: 2025-03-24
CVE-2022-49413
In the Linux kernel, the following vulnerability has been resolved: bfq: Update cgroup information before merging bio When the process is migrated to a different cgroup (or in case of writeback just starts submitting bios associated with a different cgroup) bfq_merge_bio() can operate with stale cgroup information in bic. Thus the bio can be merged to a request from a different cgroup or it can result in merging of bfqqs for different cgroups or bfqqs of already dead cgroups and causing possible use-after-free issues. Fix the problem by updating cgroup information in bfq_merge_bio().
- https://git.kernel.org/stable/c/2a1077f17169a6059992a0bbdb330e0abad1e6d9
- https://git.kernel.org/stable/c/b06691af08b41dfd81052a3362514d9827b44bb1
- https://git.kernel.org/stable/c/d9165200c5627a2cf4408eefabdf0058bdf95e1a
- https://git.kernel.org/stable/c/da9f3025d595956410ceaab2bea01980d7775948
- https://git.kernel.org/stable/c/e8821f45612f2e6d9adb9c6ba0fb4184f57692aa
- https://git.kernel.org/stable/c/ea591cd4eb270393810e7be01feb8fde6a34fbbe
Modified: 2025-03-24
CVE-2022-49416
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx.
- https://git.kernel.org/stable/c/265bec4779a38b65e86a25120370f200822dfa76
- https://git.kernel.org/stable/c/2965c4cdf7ad9ce0796fac5e57debb9519ea721e
- https://git.kernel.org/stable/c/4ba81e794f0fad6234f644c2da1ae14d5b95e1c4
- https://git.kernel.org/stable/c/4f05a9e15edcdf5b97e0d86ab6ecd5f187289f6c
- https://git.kernel.org/stable/c/6118bbdf69f4718b02d26bbcf2e497eb66004331
- https://git.kernel.org/stable/c/82c8e7bbdd06c7ed58e22450cc5b37f33a25bb2c
- https://git.kernel.org/stable/c/88cc8f963febe192d6ded9df7217f92f380b449a
- https://git.kernel.org/stable/c/9f1e5cc85ad77e52f54049a94db0407445ae2a34
- https://git.kernel.org/stable/c/b79110f2bf6022e60e590d2e094728a8eec3e79e
Modified: 2025-09-22
CVE-2022-49421
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/2e2e2c71b2642289438392edbf5d08cdbc0b138b
- https://git.kernel.org/stable/c/38d245cebf545338a6bc1c7762023de3fbecd7b7
- https://git.kernel.org/stable/c/51eb1bb6baeb478538dd4ec6459fd68c44a855b1
- https://git.kernel.org/stable/c/6c92711db7c90f78e0b67ac2a8944d0fe7e12d83
- https://git.kernel.org/stable/c/8db59df7f5826e104db82cfddbf22a33a151193e
- https://git.kernel.org/stable/c/b23789a59fa6f00e98a319291819f91fbba0deb8
- https://git.kernel.org/stable/c/bbb2a24e863b6a10129546a0a4ceea2f07deec39
- https://git.kernel.org/stable/c/c1c4405222b6fc98c16e8c2aa679c14e41d81465
- https://git.kernel.org/stable/c/f2dfb4ab887d67be7d0892ba041d3c8d738d3356
Modified: 2025-10-22
CVE-2022-49422
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix the error handling path in idxd_cdev_register() If a call to alloc_chrdev_region() fails, the already allocated resources are leaking. Add the needed error handling path to fix the leak.
- https://git.kernel.org/stable/c/5e88561eceb34ae3f88451c2b8e30fe403484189
- https://git.kernel.org/stable/c/6073af78156b8c3fc1198f8bcc190b7ac3ac0143
- https://git.kernel.org/stable/c/aab08c1aac01097815fbcf10fce7021d2396a31f
- https://git.kernel.org/stable/c/b3c7b5d08e9d5b2ff31c03078c00ecf11042419f
- https://git.kernel.org/stable/c/c308a2e711a52a47f4b45e7add2b5200169e429a
Modified: 2025-10-22
CVE-2022-49425
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dereference of stale list iterator after loop body The list iterator variable will be a bogus pointer if no break was hit. Dereferencing it (cur->page in this case) could load an out-of-bounds/undefined value making it unsafe to use that in the comparision to determine if the specific element was found. Since 'cur->page' *can* be out-ouf-bounds it cannot be guaranteed that by chance (or intention of an attacker) it matches the value of 'page' even though the correct element was not found. This is fixed by using a separate list iterator variable for the loop and only setting the original variable if a suitable element was found. Then determing if the element was found is simply checking if the variable is set.
- https://git.kernel.org/stable/c/2aaf51dd39afb6d01d13f1e6fe20b684733b37d5
- https://git.kernel.org/stable/c/385edd3ce5b4b1e9d31f474a5e35a39779ec1110
- https://git.kernel.org/stable/c/45b2b7d7108ae1e25a5036cab04ab9273e792332
- https://git.kernel.org/stable/c/51d584704d18e60fa473823654f35611c777b291
- https://git.kernel.org/stable/c/5e47a7add3dda7f236548c5ec3017776dc2a729f
- https://git.kernel.org/stable/c/b26e1c777890e4b938136deb8ec07a29f33862e4
- https://git.kernel.org/stable/c/ed7efc472c00986dcd6903ab6ed165c7fa167674
Modified: 2025-10-22
CVE-2022-49429
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent panic when SDMA is disabled If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.
- https://git.kernel.org/stable/c/0e4dda8b3f4c07ee9ea670a10ea3171a5e63a86f
- https://git.kernel.org/stable/c/22e7e400fd1a890db2ea13686324aff50e972f4f
- https://git.kernel.org/stable/c/29952ab85d6c3fe0b7909d9a737f10c58bf6824d
- https://git.kernel.org/stable/c/32e6aea33944f364d51cd263e4cd236393a188b6
- https://git.kernel.org/stable/c/33794e8e9bcb4affc0ebff9cdec85acc8b8a1762
- https://git.kernel.org/stable/c/629e052d0c98e46dde9f0824f0aa437f678d9b8f
- https://git.kernel.org/stable/c/cc80d3c37cec9d6ddb140483647901bc7cc6c31d
- https://git.kernel.org/stable/c/e60ad83f645ee6fadd5a8057ba267aeec54f08fe
Modified: 2025-10-22
CVE-2022-49431
In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: Add missing of_node_put in iommu_init_early_dart The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/57b742a5b8945118022973e6416b71351df512fb
- https://git.kernel.org/stable/c/7e3f1dfb9e21733d7276bc9ccea4daada163f2ba
- https://git.kernel.org/stable/c/8657e8ea23325949091da72453ba84fb73cc2bd9
- https://git.kernel.org/stable/c/cb4f2dc513e99c5d0485661f114e4dda73612d10
- https://git.kernel.org/stable/c/df6d8b689252c0acc0448d4ae3d33f2d6db048ab
- https://git.kernel.org/stable/c/dfc308d6f29aa28463deb9a12278a85a382385ca
Modified: 2025-10-22
CVE-2022-49432
In the Linux kernel, the following vulnerability has been resolved: powerpc/xics: fix refcount leak in icp_opal_init() The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done.
- https://git.kernel.org/stable/c/1d5c8cea85fb1680eae8d645b96b92146cb4633c
- https://git.kernel.org/stable/c/2357bd7499a81c70b460e2191852bbfc7b63c354
- https://git.kernel.org/stable/c/537a317e5ff45d1f5a0ecaf6a0d7c8043c878cb1
- https://git.kernel.org/stable/c/53f3f7f73e609b934083f896cb7ca2c2cb009b9f
- https://git.kernel.org/stable/c/5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9
- https://git.kernel.org/stable/c/6a61a97106279c2aa16fbbb2a171fd5dde127d23
- https://git.kernel.org/stable/c/977dbc81d0f866ef63b93c127b7404f07734b3cc
- https://git.kernel.org/stable/c/9a42bc2494fadb453de00ce61042e588563ddc6d
- https://git.kernel.org/stable/c/df802880a7f9cd96b921b00639b00871f18a9a57
Modified: 2025-10-22
CVE-2022-49433
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent use of lock before it is initialized If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized.
- https://git.kernel.org/stable/c/05c03dfd09c069c4ffd783b47b2da5dcc9421f2c
- https://git.kernel.org/stable/c/288d198f50434f29b4a26a9de4394ae2305ad8af
- https://git.kernel.org/stable/c/30eb275e7ed588270ae159cc590a96658e0cfd8f
- https://git.kernel.org/stable/c/66090815a24ce14cf51ef5453fc0218fe8a39bc2
- https://git.kernel.org/stable/c/addb192000d8819c0b1553453994df9bb54c28db
- https://git.kernel.org/stable/c/ca55150bff5817af4f857a746ecab9862c23e12a
- https://git.kernel.org/stable/c/fc0750e659db7b315bf6348902cc8ca3cdd4b8d8
Modified: 2025-12-23
CVE-2022-49434
In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
- https://git.kernel.org/stable/c/2cdd5284035322795b0964f899eefba254cfe483
- https://git.kernel.org/stable/c/59ea6b3ae51df7cd6bfd84c9c0030609b9315622
- https://git.kernel.org/stable/c/a91ee0e9fca9d7501286cfbced9b30a33e52740a
- https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c
- https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831
- https://git.kernel.org/stable/c/c9a81f9ed6ae3554621d6a50220b1bc74b67d81e
- https://git.kernel.org/stable/c/ea047f51172aa68841adef7f52d375002438b8f0
- https://git.kernel.org/stable/c/eff3587b9c01439b738298475e555c028ac9f55e
Modified: 2025-10-22
CVE-2022-49435
In the Linux kernel, the following vulnerability has been resolved: mfd: davinci_voicecodec: Fix possible null-ptr-deref davinci_vc_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.
- https://git.kernel.org/stable/c/2d00158a06efe6bbcd020108634ea0f2ed8b32f7
- https://git.kernel.org/stable/c/311242c7703df0da14c206260b7e855f69cb0264
- https://git.kernel.org/stable/c/49c1e32e7b3f301642a60448700ec531df981269
- https://git.kernel.org/stable/c/5289795824b77489803b0802cd9edc13824a2d0b
- https://git.kernel.org/stable/c/579944b9f38727d9ff570b58f83bc424e8af8398
- https://git.kernel.org/stable/c/a1d4941d9a24999f680799f9bbde7f57351ca637
Modified: 2025-10-01
CVE-2022-49438
In the Linux kernel, the following vulnerability has been resolved: Input: sparcspkr - fix refcount leak in bbc_beep_probe of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1124e39fea0e2fdb4202f95b716cb97cc7de7cc7
- https://git.kernel.org/stable/c/2f51db16cb740ff90086189a1ef2581eab665591
- https://git.kernel.org/stable/c/353bc58ac6c782d4dcde9136a91d1f90867938fe
- https://git.kernel.org/stable/c/418b6a3e12f75638abc5673eb76cb32127d0ab13
- https://git.kernel.org/stable/c/6e07ccc7d56130f760d23f67a70c45366c07debc
- https://git.kernel.org/stable/c/73d6f42d8d86648bec2e73d34fe1648cb6d23e08
- https://git.kernel.org/stable/c/bbc2b0ce6042dd3117827f10ea8cb67e0ab786da
- https://git.kernel.org/stable/c/c8994b30d71d64d5dcc9bc0edbfdf367171aa96f
- https://git.kernel.org/stable/c/f13064b0f2c651a3fbb0749932795c6fd21556a8
Modified: 2025-10-01
CVE-2022-49439
In the Linux kernel, the following vulnerability has been resolved: powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/46fd994763cf6884b88a2da712af918f3ed54d7b
- https://git.kernel.org/stable/c/51e25fbf20c9152d84a34b7afac15a41fe5c9116
- https://git.kernel.org/stable/c/5607a77a365df8c0fd5ff43ac424812b95775527
- https://git.kernel.org/stable/c/5b8aa2ba38c010f47c965dd9bb5a8561813ed649
- https://git.kernel.org/stable/c/7b668a59ddfb32727e39b06fdf52b28e58c684e0
- https://git.kernel.org/stable/c/bcb6c4c5eb4836a21411dfe8247bf9951eb6e7c3
- https://git.kernel.org/stable/c/c70dd353d37158e06bf8d450d4b31a7091609924
- https://git.kernel.org/stable/c/fcee96924ba1596ca80a6770b2567ca546f9a482
Modified: 2025-10-01
CVE-2022-49441
In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
- https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314
- https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50
- https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded
- https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28
- https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246
- https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9
- https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3
- https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede
- https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6
Modified: 2025-10-22
CVE-2022-49442
In the Linux kernel, the following vulnerability has been resolved: drivers/base/node.c: fix compaction sysfs file leak Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix this issue.
- https://git.kernel.org/stable/c/386e69e068177ee91cac27f2f0e6ebda1515f5ca
- https://git.kernel.org/stable/c/39642b0feddb9c39faa6de469a94bfeb4dc0d3a9
- https://git.kernel.org/stable/c/466134df7561aeb801baddf6666b512e0e1a1707
- https://git.kernel.org/stable/c/606732650a2c88e66c59c22dd5464ea0d820250e
- https://git.kernel.org/stable/c/6905be93d1ab54f73718047536fec0ca488d5315
- https://git.kernel.org/stable/c/b3fcf1f583b1a0946d9d9bfb7362c9c186801775
- https://git.kernel.org/stable/c/d8a5bdc767f17281da648555cdbd286f98fd98ee
- https://git.kernel.org/stable/c/da63dc84befaa9e6079a0bc363ff0eaa975f9073
- https://git.kernel.org/stable/c/f76ddc8fcf6d81fe89bfa4d3efcbc4fe69a91d48
Modified: 2025-10-01
CVE-2022-49445
In the Linux kernel, the following vulnerability has been resolved: pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.
- https://git.kernel.org/stable/c/5376e3d904532e657fd7ca1a9b1ff3d351527b90
- https://git.kernel.org/stable/c/5ed0519d425619b435150372cce2ffeec71581fa
- https://git.kernel.org/stable/c/e3a1ad8fd0ac11f4fa1260c23b5db71a25473254
- https://git.kernel.org/stable/c/f991879762392c19661af5b722578089a12b305f
- https://git.kernel.org/stable/c/fb4f022b3ad1f3ff3cafdbc7d51896090ae17701
Modified: 2025-10-01
CVE-2022-49446
In the Linux kernel, the following vulnerability has been resolved: nvdimm: Fix firmware activation deadlock scenarios Lockdep reports the following deadlock scenarios for CXL root device power-management, device_prepare(), operations, and device_shutdown() operations for 'nd_region' devices: Chain exists of: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(system_transition_mutex); lock(&nvdimm_bus->reconfig_mutex); lock(system_transition_mutex); lock(&nvdimm_region_key); Chain exists of: &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cxl_root_key); lock(acpi_scan_lock); lock(&cxl_root_key); lock(&cxl_nvdimm_bridge_key); These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec() which walks the entire system device topology taking device_lock() along the way. The nvdimm_bus_lock() is protecting against unregistration, multiple simultaneous ops callers, and preventing activate_show() from racing activate_store(). For the first 2, the lock is redundant. Unregistration already flushes all ops users, and sysfs already prevents multiple threads to be active in an ops handler at the same time. For the last userspace should already be waiting for its last activate_store() to complete, and does not need activate_show() to flush the write side, so this lock usage can be deleted in these attributes.
- https://git.kernel.org/stable/c/2f97ebc58d5fc83ca1528cd553fa725472ab3ca8
- https://git.kernel.org/stable/c/2fd853fdb40afc052de338693df1372f2ead7be7
- https://git.kernel.org/stable/c/641649f31e20df630310f5c22f26c071acc676d4
- https://git.kernel.org/stable/c/ceb924ee16b2c8e48dcac3d9ad6be01c40b5a228
- https://git.kernel.org/stable/c/e6829d1bd3c4b58296ee9e412f7ed4d6cb390192
Modified: 2025-10-01
CVE-2022-49447
In the Linux kernel, the following vulnerability has been resolved: ARM: hisi: Add missing of_node_put after of_find_compatible_node of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak
- https://git.kernel.org/stable/c/21a3effe446dd6dc5eed7fe897c2f9b88c9a5d6d
- https://git.kernel.org/stable/c/45d211668d33c49d73f5213e8c2b58468108647c
- https://git.kernel.org/stable/c/46cb7868811d025c3d29c10d18b3422db1cf20d5
- https://git.kernel.org/stable/c/9bc72e47d4630d58a840a66a869c56b29554cfe4
- https://git.kernel.org/stable/c/a3265a9440030068547a20dfee646666f3ca5278
- https://git.kernel.org/stable/c/cafaaae4bb9ce84a2791fa29bf6907a9466c3883
- https://git.kernel.org/stable/c/dd4be8ecfb41a29e7c4e551b4e866157ce4a3429
- https://git.kernel.org/stable/c/e109058165137ef42841abd989f080adfefa14fa
- https://git.kernel.org/stable/c/f8da78b2bae1f54746647a2bb44f8bd6025c57af
Modified: 2025-10-01
CVE-2022-49449
In the Linux kernel, the following vulnerability has been resolved: pinctrl: renesas: rzn1: Fix possible null-ptr-deref in sh_pfc_map_resources() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.
- https://git.kernel.org/stable/c/01f9e02e0f13df3fd291676dc80054e977be1601
- https://git.kernel.org/stable/c/2f661477c2bb8068194dbba9738d05219f111c6e
- https://git.kernel.org/stable/c/34c719b8fdfbd0c7c54cae56e6b0f16e9f8bf03e
- https://git.kernel.org/stable/c/b646e0cfeb38bf5f1944fd548f1dfa9b129fa00c
- https://git.kernel.org/stable/c/c16b59d445135c8026a04e388d8b2762feaa3b3b
Modified: 2025-10-01
CVE-2022-49450
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump
up the sysctl), but whilst the preallocation circular buffers have 32 slots
in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket
is closed because rxrpc_service_prealloc_one() allocated one too many calls
and rxrpc_discard_prealloc() won't then be able to get rid of them because
it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries
to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match
the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086
...
RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]
Call Trace:
- https://git.kernel.org/stable/c/369de57492c4f1a42563c5a3bd365822ca3bfc79
- https://git.kernel.org/stable/c/4a3a78b7918bdd723d8c7c9786522ca969bffcc4
- https://git.kernel.org/stable/c/5b4826657d36c218e9f08e8d3223b0edce3de88f
- https://git.kernel.org/stable/c/616f76498d5ddf26b997caf64a95cda3c8a55533
- https://git.kernel.org/stable/c/61fb38cfbb1d54d3dafd0c25752f684b3cd00b32
- https://git.kernel.org/stable/c/88e22159750b0d55793302eeed8ee603f5c1a95c
- https://git.kernel.org/stable/c/91b34bf0409f43bb60453bab23c5beadd726d022
- https://git.kernel.org/stable/c/b3a9b227d5e7467b8518160ff034ea22bb9de573
- https://git.kernel.org/stable/c/e198f1930050e3115c80b67d9249f80f98a27c67
Modified: 2025-10-01
CVE-2022-49451
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix list protocols enumeration in the base protocol While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition.
- https://git.kernel.org/stable/c/1052f22e127d0c34c3387bb389424ba1c61491ff
- https://git.kernel.org/stable/c/2ccfcd7a09c826516edcfe464b05071961aada3f
- https://git.kernel.org/stable/c/444a2d27fe9867d0da4b28fc45b793f32e099ab8
- https://git.kernel.org/stable/c/6e7978695f4a6cbd83616b5a702b77fa2087b247
- https://git.kernel.org/stable/c/8009120e0354a67068e920eb10dce532391361d0
- https://git.kernel.org/stable/c/98342148a8cd242855d7e257f298c966c96dba9f
- https://git.kernel.org/stable/c/b0e4bafac8963c2d85ee18d3d01f393735acceec
Modified: 2025-10-01
CVE-2022-49453
In the Linux kernel, the following vulnerability has been resolved: soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc The allocation funciton devm_kcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devm_kcalloc in previous code.
- https://git.kernel.org/stable/c/01ba41a359622ab256ce4d4f8b94c67165ae3daf
- https://git.kernel.org/stable/c/05efc4591f80582b6fe53366b70b6a35a42fd255
- https://git.kernel.org/stable/c/7cef9274fa1b8506949d74bc45aef072b890824a
- https://git.kernel.org/stable/c/ba56291e297d28aa6eb82c5c1964fae2d7594746
- https://git.kernel.org/stable/c/c4e188869406b47ac3350920bf165be303cb1c96
Modified: 2025-10-01
CVE-2022-49455
In the Linux kernel, the following vulnerability has been resolved: misc: ocxl: fix possible double free in ocxl_file_register_afu info_release() will be called in device_unregister() when info->dev's reference count is 0. So there is no need to call ocxl_afu_put() and kfree() again. Fix this by adding free_minor() and return to err_unregister error path.
- https://git.kernel.org/stable/c/252768d32e92c1214aeebb5fec0844ca479bcf5c
- https://git.kernel.org/stable/c/8fb674216835e1f0c143762696d645facebb4685
- https://git.kernel.org/stable/c/950cf957fe34d40d63dfa3bf3968210430b6491e
- https://git.kernel.org/stable/c/9e9087cf34ee69f4e95d146ac29385d6e367a97b
- https://git.kernel.org/stable/c/de65c32ace9aa70d51facc61ba986607075e3a25
- https://git.kernel.org/stable/c/ee89d8dee55ab4b3b8ad8b70866b2841ba334767
Modified: 2025-10-01
CVE-2022-49457
In the Linux kernel, the following vulnerability has been resolved: ARM: versatile: Add missing of_node_put in dcscb_init The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/23b44f9c649bbef10b45fa33080cd8b4166800ae
- https://git.kernel.org/stable/c/2d7b23db35254b7d46e852967090c64cdccf24da
- https://git.kernel.org/stable/c/3c6006faed9aba5144b33176d061031a9be66954
- https://git.kernel.org/stable/c/83c329b980bddbc8c6a3d287d91f2103a4d4a860
- https://git.kernel.org/stable/c/a0fc05cd17617e63fc13ad0c01f3f0afd890d8ec
- https://git.kernel.org/stable/c/bbdfb7d4f036118d36415a2575efa6f5246505ae
- https://git.kernel.org/stable/c/d146e2a9864ade19914494de3fb520390b415d58
- https://git.kernel.org/stable/c/d6de7b181c29cd4578ec139aafb5eac062abbe1b
- https://git.kernel.org/stable/c/fcd1999ba97445a12cc394f5f42ffd9116bf0185
Modified: 2025-10-01
CVE-2022-49459
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing.
- https://git.kernel.org/stable/c/61621e042c22b47d1eadee617bdd26835294b425
- https://git.kernel.org/stable/c/79098339ac2065f4b4352ef5921628970b6f47e6
- https://git.kernel.org/stable/c/b3461ccaa5d2588568d865faee285512ad448049
- https://git.kernel.org/stable/c/e20d136ec7d6f309989c447638365840d3424c8e
- https://git.kernel.org/stable/c/ee9b6b02e8c140323ed46d6602d805ea735c7719
- https://git.kernel.org/stable/c/ef1235c6514a58f274246cf4a2d5f4e40af539ce
Modified: 2025-10-22
CVE-2022-49460
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: rk3399_dmc: Disable edev on remove() Otherwise we hit an unablanced enable-count when unbinding the DFI device: [ 1279.659119] ------------[ cut here ]------------ [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c ... [ 1279.659352] Hardware name: Google Kevin (DT) [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28 ... [ 1279.659571] Call trace: [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c [ 1279.659590] devm_devfreq_event_release+0x1c/0x28 [ 1279.659602] release_nodes+0x1cc/0x244 [ 1279.659611] devres_release_all+0x44/0x60 [ 1279.659621] device_release_driver_internal+0x11c/0x1ac [ 1279.659629] device_driver_detach+0x20/0x2c [ 1279.659641] unbind_store+0x7c/0xb0 [ 1279.659650] drv_attr_store+0x2c/0x40 [ 1279.659663] sysfs_kf_write+0x44/0x58 [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190 [ 1279.659684] vfs_write+0x2b0/0x2e4 [ 1279.659693] ksys_write+0x80/0xec [ 1279.659701] __arm64_sys_write+0x24/0x30 [ 1279.659714] el0_svc_common+0xf0/0x1d8 [ 1279.659724] do_el0_svc_compat+0x28/0x3c [ 1279.659738] el0_svc_compat+0x10/0x1c [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc [ 1279.659758] el0_sync_compat+0x188/0x1c0 [ 1279.659768] ---[ end trace cec200e5094155b4 ]---
- https://git.kernel.org/stable/c/2fccf9e6050e0e3b8b4cd275d41daf7f7fa22804
- https://git.kernel.org/stable/c/664736e2cc09e504ce58ec61164d029d1f2651bb
- https://git.kernel.org/stable/c/86b091b6894c449d2734de7aa7d79ccb33ffd97d
- https://git.kernel.org/stable/c/a0180e324a9a63de8f770da300477b48cb4a53f1
- https://git.kernel.org/stable/c/a9c2b23a7ac6ab19214cad8cac8af8608a4d9cef
- https://git.kernel.org/stable/c/cb1be1d4be18fe286ba5a67d928598378fd7fbe5
- https://git.kernel.org/stable/c/fb089b6f21de03a685dd31df3789bbb01c59f8e3
Modified: 2025-10-01
CVE-2022-49462
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. a6xx_gmu_init() passes the node to of_find_device_by_node() and of_dma_configure(), of_find_device_by_node() will takes its reference, of_dma_configure() doesn't need the node after usage. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/06907a374f1b74f8f2fb30720dc6df81331e4fb5
- https://git.kernel.org/stable/c/48e82ce8cdb19c20a5020fa446b286d6a147450c
- https://git.kernel.org/stable/c/65ddbc0d26824e2a5d6154d01d8cf39344900213
- https://git.kernel.org/stable/c/6832e36f156ea35a6ed74bca72727806116effdd
- https://git.kernel.org/stable/c/c56de483093d7ad0782327f95dda7da97bc4c315
- https://git.kernel.org/stable/c/edff4c1af831d0c02e654eed9da7d74174de49d5
Modified: 2025-10-01
CVE-2022-49463
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/09700c504d8e63faffd2a2235074e8c5d130cb8f
- https://git.kernel.org/stable/c/0ec10303c10833c1bcba7a1bde2f297e494d5464
- https://git.kernel.org/stable/c/3ade442ea5d3512a3c67984489ab4d8a6fb3b29f
- https://git.kernel.org/stable/c/8bbf522a2c51ef939d0e8835e236bfcd252193af
- https://git.kernel.org/stable/c/ec0925b731697db7cab5944a3e55d2d58bb3d075
Modified: 2025-10-01
CVE-2022-49467
In the Linux kernel, the following vulnerability has been resolved: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails.
- https://git.kernel.org/stable/c/33546183c16c7b9650682dc610bedd732d9c6919
- https://git.kernel.org/stable/c/449374565f349d4233beec811d4286fdfe5de44b
- https://git.kernel.org/stable/c/656aa3c51fc662064f17179b38ec3ce43af53bca
- https://git.kernel.org/stable/c/947a844bb3ebff0f4736d244d792ce129f6700d7
- https://git.kernel.org/stable/c/d544880482a5558ec06393b1b3d5dc9275b7a32b
- https://git.kernel.org/stable/c/d63ffe3fb3f8327ca21cf91b6a14a2961bc629b4
- https://git.kernel.org/stable/c/f8cd192752a1f613b14eee77783c6f0aebb49691
Modified: 2025-10-01
CVE-2022-49468
In the Linux kernel, the following vulnerability has been resolved: thermal/core: Fix memory leak in __thermal_cooling_device_register() I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888010080000 (size 264312): comm "182", pid 102533, jiffies 4296434960 (age 10.100s) 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 40 7f 1f b9 ff ff ff ff ........@....... backtrace: [<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969 [<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510 [<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586 [<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927 [<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041 [<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211 [<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561 If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called to free the memory allocated in thermal_cooling_device_setup_sysfs().
- https://git.kernel.org/stable/c/18530bedd221160823f63ccc20dd55c7a03edbcf
- https://git.kernel.org/stable/c/21ccc58b671aea924f2481cf5c1cf0ebbfd3552d
- https://git.kernel.org/stable/c/3802171f0b5b8b831f4ade5c827547cb323a5bb2
- https://git.kernel.org/stable/c/98a160e898c0f4a979af9de3ab48b4b1d42d1dbb
- https://git.kernel.org/stable/c/9abdf0c0184230f0cb5c6685aabf33dda89aa9fb
Modified: 2025-10-01
CVE-2022-49472
In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type.
- https://git.kernel.org/stable/c/143878e18001c5a61fcc7ae5c5240323753bb641
- https://git.kernel.org/stable/c/1e5fbfc2a6f384e3195446c14bbd3bc298eb88c2
- https://git.kernel.org/stable/c/660dfa033ccc9afb032015b6dc76e846bba42cfb
- https://git.kernel.org/stable/c/7dcb404662839a4ed1a9703658fee979eb894ca4
- https://git.kernel.org/stable/c/91e720b32cba25fa58eaa4c88fe957009cffe9f3
- https://git.kernel.org/stable/c/abb5594ae2ba7b82cce85917cc6337ec5d774837
- https://git.kernel.org/stable/c/bd219273b4e004a3f853da72e111fc8f81357501
- https://git.kernel.org/stable/c/f2ef6f7539c68c6bd6c32323d8845ee102b7c450
Modified: 2025-10-01
CVE-2022-49473
In the Linux kernel, the following vulnerability has been resolved: ASoC: ti: j721e-evm: Fix refcount leak in j721e_soc_probe_* of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/2a3966b950b37a6f10c5f9caee15b4cdcf5a7413
- https://git.kernel.org/stable/c/510e879420b410d88c612aecc6ca15dc6fe77473
- https://git.kernel.org/stable/c/554df0f70bff1ace6d2df2fcaddbc9b7bd509de2
- https://git.kernel.org/stable/c/a34840c4eb3278a7c29c9c57a65ce7541c66f9f2
- https://git.kernel.org/stable/c/d748ff8fbb3a5296bddd586445dc692b079cbe3d
Modified: 2025-03-24
CVE-2022-49474
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30
- https://git.kernel.org/stable/c/36c644c63bfcaee2d3a426f45e89a9cd09799318
- https://git.kernel.org/stable/c/390d82733a953c1fabf3de9c9618091a7a9c90a6
- https://git.kernel.org/stable/c/537f619dea4e3fa8ed1f8f938abffe3615794bcc
- https://git.kernel.org/stable/c/65d347cb39e2e6bd0c2a745ad7c928998ebb0162
- https://git.kernel.org/stable/c/6f55fac0af3531cf60d11369454c41f5fc81ab3f
- https://git.kernel.org/stable/c/7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2
- https://git.kernel.org/stable/c/7d61dbd7311ab978d8ddac1749a758de4de00374
- https://git.kernel.org/stable/c/99df16007f4bbf9abfc3478cb17d10f0d7f8906e
- https://git.kernel.org/stable/c/9de3dc09e56f8deacd2bdbf4cecb71e11a312405
Modified: 2025-10-01
CVE-2022-49475
In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-qspi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/10f537219629769498ecb8515e096be213224c24
- https://git.kernel.org/stable/c/33dda87d04598ac5d9a849218a373443f7d3de66
- https://git.kernel.org/stable/c/560dcbe1c7a78f597f2167371ebdbe2bca3d0735
- https://git.kernel.org/stable/c/9d9c84825c3ec359b165c762a424cfdefe87fdd7
- https://git.kernel.org/stable/c/a2b331ac11e1cac56f5b7d367e9f3c5796deaaed
Modified: 2025-10-01
CVE-2022-49477
In the Linux kernel, the following vulnerability has been resolved: ASoC: samsung: Fix refcount leak in aries_audio_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. If extcon_find_edev_by_node() fails, it doesn't call of_node_put() Calling of_node_put() after extcon_find_edev_by_node() to fix this.
- https://git.kernel.org/stable/c/46d1b310a2d571811c4e08041ce287babb60b86a
- https://git.kernel.org/stable/c/70130bde3457d28c02c76b6cacc5d40a72dd6e17
- https://git.kernel.org/stable/c/85d899f396622d3034643bf89615a78f9be7c91a
- https://git.kernel.org/stable/c/bf4a9b2467b775717d0e9034ad916888e19713a3
- https://git.kernel.org/stable/c/cacea459f95be22b3750f3b25b7a1c5897a68206
Modified: 2025-10-01
CVE-2022-49478
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work.
- https://git.kernel.org/stable/c/1310fc3538dcc375a2f46ef0a438512c2ca32827
- https://git.kernel.org/stable/c/24e807541e4a9263ed928e6ae3498de3ad43bd1e
- https://git.kernel.org/stable/c/2e004fe914b243db41fa96f9e583385f360ea58e
- https://git.kernel.org/stable/c/3309c2c574e13b21b44729f5bdbf21f60189b79a
- https://git.kernel.org/stable/c/4351bfe36aba9fa7dc9d68d498d25d41a0f45e67
- https://git.kernel.org/stable/c/471bec68457aaf981add77b4f590d65dd7da1059
- https://git.kernel.org/stable/c/a3304766d9384886e6d3092c776273526947a2e9
- https://git.kernel.org/stable/c/a3660e06675bccec4bf149c7229ea1d491ba10d7
- https://git.kernel.org/stable/c/f99a8b1ec0eddc2931aeaa4f490277a15b39f511
Modified: 2025-10-01
CVE-2022-49481
In the Linux kernel, the following vulnerability has been resolved: regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore.
- https://git.kernel.org/stable/c/0be5d9da5743b9825a95baec85a67500b2c1d362
- https://git.kernel.org/stable/c/49d785baeb91568332197be356d138e5e59c7ddb
- https://git.kernel.org/stable/c/56ab0c01027492cd161c64148e1dc892c56887ad
- https://git.kernel.org/stable/c/671be14fc31374b1a10a3abd93db6a8480838fc9
- https://git.kernel.org/stable/c/6ca675f4abbc74bc991d154a1ecc8b384dc2aae4
- https://git.kernel.org/stable/c/984cfef0675ed7398814e14af2c5323911723e1c
- https://git.kernel.org/stable/c/9f564e29a51210a49df3d925117777c157a17d6d
- https://git.kernel.org/stable/c/afaa7b933ef00a2d3262f4d1252087613fb5c06d
- https://git.kernel.org/stable/c/b74c0dd9179d21b7260260e075d597b23970100c
Modified: 2025-10-01
CVE-2022-49482
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done.
- https://git.kernel.org/stable/c/18b907ff0ae4bf20120aae1538f7156b9d08e3a7
- https://git.kernel.org/stable/c/24491124406666bf0dcb9ee10c5575c6ce6a1730
- https://git.kernel.org/stable/c/2a0da7641e1f17a744ac7b3f76471388c97b63dc
- https://git.kernel.org/stable/c/2be84f73785fa9ed6443e3c5b158730266f1c2ee
- https://git.kernel.org/stable/c/30d110ca703ce60162ec337aa564a3e4da30715f
- https://git.kernel.org/stable/c/4e2a1bcc51bdebed48176f6e88c150f175983f9c
- https://git.kernel.org/stable/c/c933829cbf3338b684869e6c4c8931abf5d68fbd
- https://git.kernel.org/stable/c/d42601e93fce7802bb8d70dd59b60cfeefa20469
- https://git.kernel.org/stable/c/d855505851ee8ba666eb204149b49f906130dc17
Modified: 2025-10-01
CVE-2022-49486
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe of_find_i2c_device_by_node() takes a reference, In error paths, we should call put_device() to drop the reference to aviod refount leak.
- https://git.kernel.org/stable/c/41cd312dfe980af869c3503b4d38e62ed20dd3b7
- https://git.kernel.org/stable/c/4bfbbfdb3d761323127a67d7d765abe2f77d7b21
- https://git.kernel.org/stable/c/7f75e9f629ef54a0845b43889d8ab9dd6e280dd5
- https://git.kernel.org/stable/c/922bccdb1796a9e7b989f2bc6d9ada7b499a4329
- https://git.kernel.org/stable/c/96fc3da6184af5687e153d420cd7dcdeefdd2f9a
- https://git.kernel.org/stable/c/e84aaf23ca82753d765bf84d05295d9d9c5fed29
Modified: 2025-10-22
CVE-2022-49488
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Patchwork: https://patchwork.freedesktop.org/patch/485181/
- https://git.kernel.org/stable/c/09bdeedc1fc53e64b8282e1de67752c69e43bdba
- https://git.kernel.org/stable/c/1a5d1474026ea4f1a6f931075ca2adb884af39cf
- https://git.kernel.org/stable/c/22d8424913b1348c6324916745fadaeea5273f0e
- https://git.kernel.org/stable/c/46e5ce63924a96af452c4fc5ee0bb3b241e1b9f4
- https://git.kernel.org/stable/c/47e393061049aff6818d1b9fdca7351411a23fc2
- https://git.kernel.org/stable/c/883f1d52a57bf51e1d7a80c432345e2c6222477e
- https://git.kernel.org/stable/c/ca75f6f7c6f89365e40f10f641b15981b1f07c31
Modified: 2025-03-24
CVE-2022-49489
In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag]
- https://git.kernel.org/stable/c/134760263f6441741db0b2970e7face6b34b6d1c
- https://git.kernel.org/stable/c/5b0adf5cbf3b74721e4e4c4e0cadc91b8df8bcc2
- https://git.kernel.org/stable/c/97ac682b6f7d36be5d934f86c9911066540a68f1
- https://git.kernel.org/stable/c/aa4cb188988dc6f1b3f4917d4dbc452150a5d871
- https://git.kernel.org/stable/c/ef10d0c68e8608848cd58fca2589685718426607
- https://git.kernel.org/stable/c/ef4bdaac7cb5416f236613ed9337ff0ea8ee329b
- https://git.kernel.org/stable/c/fa5186b279ecf44b14fb435540d2065be91cb1ed
Modified: 2025-10-22
CVE-2022-49490
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Patchwork: https://patchwork.freedesktop.org/patch/485179/
- https://git.kernel.org/stable/c/04bef5f1ba8ea6d7c1c8f5f65e0395c62db59cb8
- https://git.kernel.org/stable/c/19964dfb39bda4d7716a71009488f0668ecbcf52
- https://git.kernel.org/stable/c/33dc5aac46e0fad8f5eb193e5906ed0eb6b66ceb
- https://git.kernel.org/stable/c/49dc28b4b2e28ef7564e355c91487996c1cbebd7
- https://git.kernel.org/stable/c/776f5c58bfe16cf322d71eeed3c5dda1eeac7e6b
- https://git.kernel.org/stable/c/b2aa2c4efe93e2580d6a8774b04fe2b99756a322
- https://git.kernel.org/stable/c/d59be579fa932c46b908f37509f319cbd4ca9a68
Modified: 2025-10-01
CVE-2022-49491
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref.
- https://git.kernel.org/stable/c/3451852312303d54a003c73bd0ae39cebb960bd5
- https://git.kernel.org/stable/c/452922955df215a417c80d09dab72bbc667a1861
- https://git.kernel.org/stable/c/6ff986e057bf28e2f7690dad410768b2270f9453
- https://git.kernel.org/stable/c/769c53bb6116d0eaec0f1fe4ec4b27a74465cad1
- https://git.kernel.org/stable/c/a9b4599665e437de8a1152799c34841b799a2e1c
- https://git.kernel.org/stable/c/b54926bd558d97c888c3d2d87886f3c159d3254a
- https://git.kernel.org/stable/c/ecfa52654d0c9c333c1fe1611f47105f6bce9591
- https://git.kernel.org/stable/c/f8c242908ad15bbd604d3bcb54961b7d454c43f8
- https://git.kernel.org/stable/c/fcd6a886443730c39170b8383411e52118aec0a3
Modified: 2025-10-01
CVE-2022-49492
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference.
- https://git.kernel.org/stable/c/54a4c1e47d1b2585e74920399455bd9abbfb2bd7
- https://git.kernel.org/stable/c/7a28556082d1fbcbc599baf1c24252dfc73efefc
- https://git.kernel.org/stable/c/8321b17789f614414206af07e17ce4751c95dc76
- https://git.kernel.org/stable/c/8da2b7bdb47e94bbc4062a3978c708926bcb022c
- https://git.kernel.org/stable/c/906c81dba8ee8057523859b5e1a2479e9fd34860
- https://git.kernel.org/stable/c/9e649471b396fa0139d53919354ce1eace9b9a24
- https://git.kernel.org/stable/c/af98940dd33c9f9e1beb4f71c0a39260100e2a65
- https://git.kernel.org/stable/c/da42761181627e9bdc37d18368b827948a583929
- https://git.kernel.org/stable/c/f76729662650cd7bc8f8194e057af381370349a7
Modified: 2025-09-03
CVE-2022-49493
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix errorenous cleanup order There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync.
- https://git.kernel.org/stable/c/061a6159cea583f1155f67d1915917a6b9282662
- https://git.kernel.org/stable/c/0941150100173d4eaf3fe08ff4b16740e7c3026f
- https://git.kernel.org/stable/c/1a5a3dfd9f172dcb115072f0aea5e27d3083c20e
- https://git.kernel.org/stable/c/236d29c5857f02e0a53fdf15d3dce1536c4322ce
- https://git.kernel.org/stable/c/2def44d3aec59e38d2701c568d65540783f90f2f
- https://git.kernel.org/stable/c/453f0920ffc1a28e28ddb9c3cd5562472b2895b0
- https://git.kernel.org/stable/c/88c09e4812d72c3153afc8e5a45ecac2d0eae3ff
- https://git.kernel.org/stable/c/abe7554da62cb489712a54de69ef5665c250e564
Modified: 2025-10-01
CVE-2022-49494
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.
- https://git.kernel.org/stable/c/069af5e27c1b0f7677ef76d8d3102e503ca4f80b
- https://git.kernel.org/stable/c/0cfee868b89ffa945f3d535ee5c985cb40c5a0f8
- https://git.kernel.org/stable/c/13b60d3dc84b47307669edb66b633b18466014b4
- https://git.kernel.org/stable/c/81f1ddffdc22ca5789e33b9d4712914e302090c1
- https://git.kernel.org/stable/c/a28ed09dafee20da51eb26452950839633afd824
Modified: 2025-10-01
CVE-2022-49495
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/
- https://git.kernel.org/stable/c/0978fcce91b90b561b8c82e7c492ba9fc8440eef
- https://git.kernel.org/stable/c/2b3ed7547b1a052209da6c4ab886ffe0eed88c42
- https://git.kernel.org/stable/c/4cd66a8016b872a153bf892fe4258cbc0dacf5b1
- https://git.kernel.org/stable/c/6369dda4a2209142ab819f01d3d2076d81e3ebdd
- https://git.kernel.org/stable/c/9cb1ee33efccb8b107ee04b7b3441820de3fd2da
- https://git.kernel.org/stable/c/9f5495a5c51c1d11c6ffc13aa2befffec0c2651a
- https://git.kernel.org/stable/c/a36e506711548df923ceb7ec9f6001375be799a5
- https://git.kernel.org/stable/c/c1bfacf0daf25a5fc7d667399d6ff2dffda84cd8
- https://git.kernel.org/stable/c/d9cb951d11a4ace4de5c50b1178ad211de17079e
Modified: 2025-10-01
CVE-2022-49497
In the Linux kernel, the following vulnerability has been resolved: net: remove two BUG() from skb_checksum_help() I have a syzbot report that managed to get a crash in skb_checksum_help() If syzbot can trigger these BUG(), it makes sense to replace them with more friendly WARN_ON_ONCE() since skb_checksum_help() can instead return an error code. Note that syzbot will still crash there, until real bug is fixed.
- https://git.kernel.org/stable/c/312c43e98ed190bd8fd7a71a0addf9539d5b8ab1
- https://git.kernel.org/stable/c/6320ae1b5876c30bf98203b6a5abe8b5c45e6a04
- https://git.kernel.org/stable/c/b1320c9a4d30ff54b824a8ad6036e0b5fb4c5e73
- https://git.kernel.org/stable/c/d5281245f3502e960cb6b89348767b935379cee3
- https://git.kernel.org/stable/c/d7ea0d9df2a6265b2b180d17ebc64b38105968fc
Modified: 2025-10-01
CVE-2022-49498
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Check for null pointer of pointer substream before dereferencing it Pointer substream is being dereferenced on the assignment of pointer card before substream is being null checked with the macro PCM_RUNTIME_CHECK. Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the the pointer check before card is assigned.
- https://git.kernel.org/stable/c/011b559be832194f992f73d6c0d5485f5925a10b
- https://git.kernel.org/stable/c/1f2e28857be1e5c7db39bbc221332215fc5467e3
- https://git.kernel.org/stable/c/7784d22f81a29df2ec57ca90d54f93a35cbcd1a2
- https://git.kernel.org/stable/c/b2421a196cb0911ea95aec1050a0b830464c8fa6
- https://git.kernel.org/stable/c/b41ef7ad9238c22aa2e142f5ce4ce1a1a0d48123
- https://git.kernel.org/stable/c/f2c68c52898f623fe84518da4606538d193b0cca
Modified: 2025-10-01
CVE-2022-49502
In the Linux kernel, the following vulnerability has been resolved: media: rga: fix possible memory leak in rga_probe rga->m2m_dev needs to be freed when rga_probe fails.
- https://git.kernel.org/stable/c/1cdc768468c25d6b10ab83ec1efd4a8554532d69
- https://git.kernel.org/stable/c/8ddc89437ccefa18279918c19a61fd81527f40b9
- https://git.kernel.org/stable/c/a71eb6025305192e646040cd76ccacb5bd48a1b5
- https://git.kernel.org/stable/c/b7bbca4d08471bc8404a946bab1aa017dd05199b
- https://git.kernel.org/stable/c/eeb4819e94aa69767b9e5591e70c63e8b7c5786a
Modified: 2025-10-21
CVE-2022-49503
In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()'
- https://git.kernel.org/stable/c/0bcb528402cd5e1a6e1833e956fd58a12d509e8e
- https://git.kernel.org/stable/c/2326d398ccd41ba6d93b8346532dfa432ab00fee
- https://git.kernel.org/stable/c/2dc509305cf956381532792cb8dceef2b1504765
- https://git.kernel.org/stable/c/3dad3fed5672828c7fb0465cb66a3d9a70952fa6
- https://git.kernel.org/stable/c/461e4c1f199076275f16bf6f3d3e42c6b6c79f33
- https://git.kernel.org/stable/c/4bdcf32c965c27f55ccc4ee71c1927131115b0bb
- https://git.kernel.org/stable/c/7f6defe0fabc79f29603c6fa3c80e4fe0456a3e9
- https://git.kernel.org/stable/c/a048e0c3caa852397b7b50d4c82a0415c05f7ac3
- https://git.kernel.org/stable/c/eda518db7db16c360bc84379d90675650daa3048
Modified: 2025-03-24
CVE-2022-49505
In the Linux kernel, the following vulnerability has been resolved:
NFC: NULL out the dev->rfkill to prevent UAF
Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
assumes the device_is_registered() in function nfc_dev_up() will help
to check when the rfkill is unregistered. However, this check only
take effect when device_del(&dev->dev) is done in nfc_unregister_device().
Hence, the rfkill object is still possible be dereferenced.
The crash trace in latest kernel (5.18-rc2):
[ 68.760105] ==================================================================
[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750
[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313
[ 68.760756]
[ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4
[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 68.760756] Call Trace:
[ 68.760756]
- https://git.kernel.org/stable/c/1632be63862f183cd5cf1cc094e698e6ec005dfd
- https://git.kernel.org/stable/c/1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9
- https://git.kernel.org/stable/c/2a1b5110c95e4d49c8c3906270dfcde680a5a7be
- https://git.kernel.org/stable/c/4a68938f43b7c2663e4c90bb9bbe29ac8b9a42a0
- https://git.kernel.org/stable/c/4f5d71930f41be78557f9714393179025baacd65
- https://git.kernel.org/stable/c/6abfaca8711803d0d7cc8c0fac1070a88509d463
- https://git.kernel.org/stable/c/a8e03bcad52dc9afabf650fdbad84f739cec9efa
- https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf
- https://git.kernel.org/stable/c/fbf9c4c714d3cdeb98b6a18e4d057f931cad1d81
Modified: 2025-10-01
CVE-2022-49508
In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails).
- https://git.kernel.org/stable/c/1af20714fedad238362571620be0bd690ded05b6
- https://git.kernel.org/stable/c/24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47
- https://git.kernel.org/stable/c/5291451851feeb66fd4bf0826710f482f3b1ab38
- https://git.kernel.org/stable/c/6d0726725c7c560495f5ff364862a2cefea542e3
- https://git.kernel.org/stable/c/8bb1716507ebf12d50bbf181764481de3b6bc7fd
- https://git.kernel.org/stable/c/c92ec22a991778a096342cf1a917ae36c5c86a90
- https://git.kernel.org/stable/c/f1d4f19a796551edc6679a681ea1756b8c578c08
Modified: 2025-10-21
CVE-2022-49512
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: denali: Use managed device resources
All of the resources used by this driver has managed interfaces, so use
them. Otherwise we will get the following splat:
[ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000
[ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5
[ 4.473538] nand: No NAND device found
[ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410
[ 4.475169] #PF: supervisor write access in kernel mode
[ 4.475579] #PF: error_code(0x0002) - not-present page
[ 4.478362] RIP: 0010:iowrite32+0x9/0x50
[ 4.486068] Call Trace:
[ 4.486269]
- https://git.kernel.org/stable/c/3830dbdfb9a4aec680e43ed80b9f23db7a88eac9
- https://git.kernel.org/stable/c/3a745b51cddafade99aaea1b93aad31e9614e230
- https://git.kernel.org/stable/c/3c68daf4a368cd9e63ae5a2145c9e4a6f838c166
- https://git.kernel.org/stable/c/87149cf9186201a63f0e0b93d9fa93d480bcb771
- https://git.kernel.org/stable/c/efea1dd176edd17c8252051b7de6957f06efc394
Modified: 2025-10-01
CVE-2022-49514
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe Call of_node_put(platform_node) to avoid refcount leak in the error path.
- https://git.kernel.org/stable/c/0a1901f34f775b83ea4b8dbb5ed992147b9b8531
- https://git.kernel.org/stable/c/1e932aba3c7628c9f880ee9c2cfcc2ae3ba0c01e
- https://git.kernel.org/stable/c/23f340ed906c758cec6527376768e3bc1474ac30
- https://git.kernel.org/stable/c/48889eb3cce91d7f58e02bc07277b7f724b7a54a
- https://git.kernel.org/stable/c/4f4e0454e226de3bf4efd7e7924d1edc571c52d5
- https://git.kernel.org/stable/c/98d5afe868df998b0244f4c229ab758b4083684a
- https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6
- https://git.kernel.org/stable/c/ebd5cb4f1f3f10b839e7575219e0f17b60c23113
- https://git.kernel.org/stable/c/fb66e0512e5ccc093070e21cf88cce8d98c181b5
Modified: 2025-10-01
CVE-2022-49517
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/05654431a18fe24e5e46a375d98904134628a102
- https://git.kernel.org/stable/c/318afb1442eeef089fe7f8a8297d97c0302ff6f6
- https://git.kernel.org/stable/c/61a85a20e8df5e0a92cfe169c92425c7bae0753b
- https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912
- https://git.kernel.org/stable/c/94587aa17abf8b26f543d2b29c44abc21bc36836
- https://git.kernel.org/stable/c/bc2afecaabd2a2c9f17e43b4793a30e3461bfb29
- https://git.kernel.org/stable/c/c71494f5f2b444adfd992a7359a0d2a791642b39
- https://git.kernel.org/stable/c/f279c49f17ce10866087ea6c0c57382158974b63
Modified: 2025-10-21
CVE-2022-49519
In the Linux kernel, the following vulnerability has been resolved: ath10k: skip ath10k_halt during suspend for driver state RESTARTING Double free crash is observed when FW recovery(caused by wmi timeout/crash) is followed by immediate suspend event. The FW recovery is triggered by ath10k_core_restart() which calls driver clean up via ath10k_halt(). When the suspend event occurs between the FW recovery, the restart worker thread is put into frozen state until suspend completes. The suspend event triggers ath10k_stop() which again triggers ath10k_halt() The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be called twice(Note: ath10k_htt_rx_alloc was not called by restart worker thread because of its frozen state), causing the crash. To fix this, during the suspend flow, skip call to ath10k_halt() in ath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING. Also, for driver state ATH10K_STATE_RESTARTING, call ath10k_wait_for_suspend() in ath10k_stop(). This is because call to ath10k_wait_for_suspend() is skipped later in [ath10k_halt() > ath10k_core_stop()] for the driver state ATH10K_STATE_RESTARTING. The frozen restart worker thread will be cancelled during resume when the device comes out of suspend. Below is the crash stack for reference: [ 428.469167] ------------[ cut here ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: events_unbound async_run_entry_fn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dma_free_attrs+0x5f/0x7d [ 428.469320] ath10k_core_stop+0x5b/0x6f [ 428.469336] ath10k_halt+0x126/0x177 [ 428.469352] ath10k_stop+0x41/0x7e [ 428.469387] drv_stop+0x88/0x10e [ 428.469410] __ieee80211_suspend+0x297/0x411 [ 428.469441] rdev_suspend+0x6e/0xd0 [ 428.469462] wiphy_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_show+0x2d/0x2d [ 428.469517] __device_suspend+0x2e7/0x41b [ 428.469523] async_suspend+0x1f/0x93 [ 428.469529] async_run_entry_fn+0x3d/0xd1 [ 428.469535] process_one_work+0x1b1/0x329 [ 428.469541] worker_thread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? pr_cont_work+0x58/0x58 [ 428.469558] ? kthread_blkcg+0x31/0x31 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
- https://git.kernel.org/stable/c/5321e5211b5dc873e2e3d0deb749e69ecf4dbfe5
- https://git.kernel.org/stable/c/7eb14cb604f49e58b7cf6faa87961a865a3c8649
- https://git.kernel.org/stable/c/8aa3750986ffcf73e0692db3b40dd3a8e8c0c575
- https://git.kernel.org/stable/c/b72a4aff947ba807177bdabb43debaf2c66bee05
- https://git.kernel.org/stable/c/c2272428090d0d215a3f017cbbbad731c07eee53
Modified: 2025-10-21
CVE-2022-49520
In the Linux kernel, the following vulnerability has been resolved: arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall If a compat process tries to execute an unknown system call above the __ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() -> arm64_show_signal(). arm64_show_signal() interprets a non-zero value for current->thread.fault_code as an exception syndrome and displays the message associated with the ESR_ELx.EC field (bits 31:26). current->thread.fault_code is set in compat_arm_syscall() -> arm64_notify_die() with the bad syscall number instead of a valid ESR_ELx value. This means that the ESR_ELx.EC field has the value that the user set for the syscall number and the kernel can end up printing bogus exception messages*. For example, for the syscall number 0x68000000, which evaluates to ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error: [ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79 [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which is misleading, as the bad compat syscall has nothing to do with pointer authentication. Stop arm64_show_signal() from printing exception syndrome information by having compat_arm_syscall() set the ESR_ELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes: [ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which although shows less information because the syscall number, wrongfully advertised as the ESR value, is missing, it is better than showing plainly wrong information. The syscall number can be easily obtained with strace. *A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative integer in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64_notify_die() being called.
- https://git.kernel.org/stable/c/095e975f8150ccd7f852eb578c1cdbdd2f517c7a
- https://git.kernel.org/stable/c/3910ae71cb963fa2b68e684489d4fc3d105afda0
- https://git.kernel.org/stable/c/3fed9e551417b84038b15117732ea4505eee386b
- https://git.kernel.org/stable/c/621916afe8cd4f322eb12759b64a2f938d4e551d
- https://git.kernel.org/stable/c/ad97425d23af3c3b8d4f6a2bb666cb485087c007
- https://git.kernel.org/stable/c/efd183d988b416fcdf6f7c298a17ced4859ca77d
Modified: 2025-10-21
CVE-2022-49521
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp() If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a received frame, the frame is dropped and resources are leaked. Fix by returning resources when discarding an unhandled frame type. Update lpfc_fc_frame_check() handling of NOP basic link service.
- https://git.kernel.org/stable/c/08709769ff2fb6c5ffedcda3742700d8ea1618a8
- https://git.kernel.org/stable/c/40cf4ea4d2d497f7732c87d350ba5c3f5e8a43a1
- https://git.kernel.org/stable/c/646db1a560f44236b7278b822ca99a1d3b6ea72c
- https://git.kernel.org/stable/c/7860d8f8082605b57596aa82d3d438c1fdad9a9e
- https://git.kernel.org/stable/c/fa1b509d41c5433672f72c0615cf4aefa0611c99
Modified: 2025-10-21
CVE-2022-49522
In the Linux kernel, the following vulnerability has been resolved: mmc: jz4740: Apply DMA engine limits to maximum segment size Do what is done in other DMA-enabled MMC host drivers (cf. host/mmci.c) and limit the maximum segment size based on the DMA engine's capabilities. This is needed to avoid warnings like the following with CONFIG_DMA_API_DEBUG=y. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536] CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19 Workqueue: kblockd blk_mq_run_work_fn Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80528cd8>] __warn+0xb8/0xec [<80528d78>] warn_slowpath_fmt+0x6c/0xb8 [<8016f1d4>] debug_dma_map_sg+0x2f4/0x39c [<80169d4c>] __dma_map_sg_attrs+0xf0/0x118 [<8016a27c>] dma_map_sg_attrs+0x14/0x28 [<804f66b4>] jz4740_mmc_prepare_dma_data+0x74/0xa4 [<804f6714>] jz4740_mmc_pre_request+0x30/0x54 [<804f4ff4>] mmc_blk_mq_issue_rq+0x6e0/0x7bc [<804f5590>] mmc_mq_queue_rq+0x220/0x2d4 [<8038b2c0>] blk_mq_dispatch_rq_list+0x480/0x664 [<80391040>] blk_mq_do_dispatch_sched+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/0x94 [<80387900>] __blk_mq_run_hw_queue+0xb0/0xcc [<80134c14>] process_one_work+0x1b8/0x264 [<80134ff8>] worker_thread+0x2ec/0x3b8 [<8013b13c>] kthread+0x104/0x10c [<80101dcc>] ret_from_kernel_thread+0x14/0x1c ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/353298cadbd4c7d8e8a16d6000066414694933c3
- https://git.kernel.org/stable/c/7923f95997a79cef2ad161a2facae64c25a0bca0
- https://git.kernel.org/stable/c/807f90f1960a59dc557542b818c484a8db9ac978
- https://git.kernel.org/stable/c/90281cadf5077f2d2bec8b08c2ead1f8cd12660e
- https://git.kernel.org/stable/c/a828920b9ec0d89d3011198d482b7fe224d2de19
- https://git.kernel.org/stable/c/afadb04f1d6e74b18a253403f5274cde5e3fd7bd
Modified: 2025-10-01
CVE-2022-49523
In the Linux kernel, the following vulnerability has been resolved: ath11k: disable spectral scan during spectral deinit When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash. Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectral_deinit API to avoid this crash. call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] *pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci]) [ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1
- https://git.kernel.org/stable/c/161c64de239c7018e0295e7e0520a19f00aa32dc
- https://git.kernel.org/stable/c/451b9076903a057b7b8d5b24dc84b3e436a1c743
- https://git.kernel.org/stable/c/4b9c54caef58d2b55074710952cda70540722c01
- https://git.kernel.org/stable/c/60afa4f4e1350c876d8a061182a70c224de275dd
- https://git.kernel.org/stable/c/8f15e67af9bec5a69e815e0230a70cffddae371a
Modified: 2025-03-24
CVE-2022-49524
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: Fix the error handling in cx23885_initdev() When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask().
- https://git.kernel.org/stable/c/453514a874c78df1e7804e6e3aaa60c8d8deb6a8
- https://git.kernel.org/stable/c/6041d1a0365baa729b6adfb6ed5386d9388018db
- https://git.kernel.org/stable/c/7b9978e1c94e569d65a0e7e719abb9340f5db4a0
- https://git.kernel.org/stable/c/86bd6a579c6c60547706cabf299cd2c9feab3332
- https://git.kernel.org/stable/c/98106f100f50c487469903b9cf6d966785fc9cc3
- https://git.kernel.org/stable/c/ca17e7a532d1a55466cc007b3f4d319541a27493
- https://git.kernel.org/stable/c/e8123311cf06d7dae71e8c5fe78e0510d20cd30b
- https://git.kernel.org/stable/c/fa636e9ee4442215cd9a2e079cd5a8e1fe0cb8ba
Modified: 2025-10-21
CVE-2022-49525
In the Linux kernel, the following vulnerability has been resolved:
media: cx25821: Fix the warning when removing the module
When removing the module, we will get the following warning:
[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'
[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0
[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0
[ 14.759589] Call Trace:
[ 14.759792]
- https://git.kernel.org/stable/c/005fd553f5f10fe8618d92f94ad10f9051eac331
- https://git.kernel.org/stable/c/1f0fc1dfb5fdd456657519a97fab83691b96c6a0
- https://git.kernel.org/stable/c/2203436a4d24302871617373a7eb21bc17e38762
- https://git.kernel.org/stable/c/222292930c8ecc3516e03ec1f9fa8448be7ff496
- https://git.kernel.org/stable/c/258639bc55a586ee6df92d89786ccf1c71546d70
- https://git.kernel.org/stable/c/3f94169affa33c9db4a439d88f09cb2ed3a33332
- https://git.kernel.org/stable/c/4d6295b6d986476232332fffd08575b185f90d81
- https://git.kernel.org/stable/c/5beb85ff7d005ddb7bf604a4f2dc76f01b84b318
- https://git.kernel.org/stable/c/9d92291698e5cc35a2b8a1106a01ddd7d60ade2d
Modified: 2025-10-21
CVE-2022-49526
In the Linux kernel, the following vulnerability has been resolved: md/bitmap: don't set sb values if can't pass sanity check If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed. How to trigger: (faulty injection) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
- https://git.kernel.org/stable/c/0959aa00f9765bd8c654b1365012e41b51c733cc
- https://git.kernel.org/stable/c/27f672af28a8e9b783ff7f0eaf7ef2fbd5a2f4ba
- https://git.kernel.org/stable/c/422e8f7ba1e08c8e0e88d375bcb550bc2bbfe96d
- https://git.kernel.org/stable/c/cf9392282a2cf5a8d83dd1c5aa1a097e12f172bc
- https://git.kernel.org/stable/c/d8f1558e1daf54f53a90b4c5700ae3e3a4b13412
- https://git.kernel.org/stable/c/e68cb83a57a458b01c9739e2ad9cb70b04d1e6d2
- https://git.kernel.org/stable/c/e69e93120f6219b9cc4fba3b515b6ababd8548aa
Modified: 2025-10-01
CVE-2022-49527
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: avoid null dereference in deinit If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary.
- https://git.kernel.org/stable/c/0ac84ab50712879eac3c1dd2598440652a85d3d0
- https://git.kernel.org/stable/c/0ed5a643b1a4a46b9b7bfba5d468c10cc30e1359
- https://git.kernel.org/stable/c/2533acb652359c9e097dfa33587896af782e8a91
- https://git.kernel.org/stable/c/27ad46da44177a78a4a0cae6fe03906888c61aa1
- https://git.kernel.org/stable/c/86594f6af867b5165d2ba7b5a71fae3a5961e56c
- https://git.kernel.org/stable/c/9c385b961d4c378228e80f6abea8509cb67feab6
- https://git.kernel.org/stable/c/a21d15dde21d7e8ae047eb8368677407db45d840
- https://git.kernel.org/stable/c/b73ed0510bb8d9647cd8e8a4c4c8772bbe545c3a
Modified: 2025-10-01
CVE-2022-49530
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix double free in si_parse_power_table() In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated.
- https://git.kernel.org/stable/c/2615464854505188f909d0c07c37a6623693b5c7
- https://git.kernel.org/stable/c/43eb9b667b95f2a31c63e8949b0d2161b9be59c3
- https://git.kernel.org/stable/c/6c5bdaa1325be7f04b79ea992ab216739192d342
- https://git.kernel.org/stable/c/a5ce7051db044290b1a95045ff03c249005a3aa4
- https://git.kernel.org/stable/c/af832028af6f44c6c45645757079c4ed6884ade5
- https://git.kernel.org/stable/c/c0e811c4ccf3b42705976285e3a94cc82dea7300
- https://git.kernel.org/stable/c/ca1ce206894dd976275c78ee38dbc19873f22de9
- https://git.kernel.org/stable/c/f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd
- https://git.kernel.org/stable/c/fd2eff8b9dcbe469c3b7bbbc7083ab5ed94de07b
Modified: 2025-10-01
CVE-2022-49532
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218
- https://git.kernel.org/stable/c/0f8bc147a963686b7351aa35d1701124ffacac08
- https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e9846957402
- https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c
- https://git.kernel.org/stable/c/848dd072744ea662ab3097e3c8282bee552df218
- https://git.kernel.org/stable/c/c51d00472fa54b9b05c17789ed665c17adf3a25d
- https://git.kernel.org/stable/c/e0828456578cc8ba0a69147f7ae3428392eec287
- https://git.kernel.org/stable/c/edafcad84c4134ebec4bc24b29ca4497a1184eea
- https://git.kernel.org/stable/c/f85cb059fad03a3b33a50023be91e944bb065ae8
- https://git.kernel.org/stable/c/fadc626cae99aaa1325094edc6a9e2b883f3e562
Modified: 2025-10-01
CVE-2022-49538
In the Linux kernel, the following vulnerability has been resolved: ALSA: jack: Access input_dev under mutex It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock.
- https://git.kernel.org/stable/c/1b6a6fc5280e97559287b61eade2d4b363e836f2
- https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348
- https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5
- https://git.kernel.org/stable/c/74bab3bcf422593c582e47130aa8eb41ebb2dc09
- https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879
- https://git.kernel.org/stable/c/9e6a73b0c0f2014eb89249fb1640c5a3d58221c4
- https://git.kernel.org/stable/c/c093b62c40027c21d649c5534ad7aa3605a99b00
- https://git.kernel.org/stable/c/e2b8681769f6e205382f026b907d28aa5ec9d59a
- https://git.kernel.org/stable/c/f68bed124c7699e23ffb4ce4fcc84671e9193cde
Modified: 2025-10-21
CVE-2022-49540
In the Linux kernel, the following vulnerability has been resolved:
rcu-tasks: Fix race in schedule and flush work
While booting secondary CPUs, cpus_read_[lock/unlock] is not keeping
online cpumask stable. The transient online mask results in below
calltrace.
[ 0.324121] CPU1: Booted secondary processor 0x0000000001 [0x410fd083]
[ 0.346652] Detected PIPT I-cache on CPU2
[ 0.347212] CPU2: Booted secondary processor 0x0000000002 [0x410fd083]
[ 0.377255] Detected PIPT I-cache on CPU3
[ 0.377823] CPU3: Booted secondary processor 0x0000000003 [0x410fd083]
[ 0.379040] ------------[ cut here ]------------
[ 0.383662] WARNING: CPU: 0 PID: 10 at kernel/workqueue.c:3084 __flush_work+0x12c/0x138
[ 0.384850] Modules linked in:
[ 0.385403] CPU: 0 PID: 10 Comm: rcu_tasks_rude_ Not tainted 5.17.0-rc3-v8+ #13
[ 0.386473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 0.387289] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.388308] pc : __flush_work+0x12c/0x138
[ 0.388970] lr : __flush_work+0x80/0x138
[ 0.389620] sp : ffffffc00aaf3c60
[ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27: ffffff80f761df48
[ 0.391316] x26: 0000000000000004 x25: 0000000000000003 x24: 0000000000000100
[ 0.392493] x23: ffffffffffffffff x22: ffffffc009c16b10 x21: ffffffc009c16b28
[ 0.393668] x20: ffffffc009e53861 x19: ffffff80f77fbf40 x18: 00000000d744fcc9
[ 0.394842] x17: 000000000000000b x16: 00000000000001c2 x15: ffffffc009e57550
[ 0.396016] x14: 0000000000000000 x13: ffffffffffffffff x12: 0000000100000000
[ 0.397190] x11: 0000000000000462 x10: ffffff8040258008 x9 : 0000000100000000
[ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000
[ 0.399538] x5 : 0000000000000000 x4 : ffffffc00a976e40 x3 : ffffffc00810444c
[ 0.400711] x2 : 0000000000000004 x1 : 0000000000000000 x0 : 0000000000000000
[ 0.401886] Call trace:
[ 0.402309] __flush_work+0x12c/0x138
[ 0.402941] schedule_on_each_cpu+0x228/0x278
[ 0.403693] rcu_tasks_rude_wait_gp+0x130/0x144
[ 0.404502] rcu_tasks_kthread+0x220/0x254
[ 0.405264] kthread+0x174/0x1ac
[ 0.405837] ret_from_fork+0x10/0x20
[ 0.406456] irq event stamp: 102
[ 0.406966] hardirqs last enabled at (101): [
- https://git.kernel.org/stable/c/1c6c3f2336642fb3074593911f5176565f47ec41
- https://git.kernel.org/stable/c/230bf5878af6038dfb63d9184272a58475236580
- https://git.kernel.org/stable/c/8f49a8758b5cd541bd7aa9a0d0d11c7426141c0e
- https://git.kernel.org/stable/c/ba722d061bc4b54802d701fc63fc2fd988934603
- https://git.kernel.org/stable/c/f75fd4b9221d93177c50dcfde671b2e907f53e86
Modified: 2025-10-01
CVE-2022-49544
In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference
- https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21
- https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd
- https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882
- https://git.kernel.org/stable/c/528d2023ccf4748fd542582955236c1634a7d293
- https://git.kernel.org/stable/c/5f7ea274e88c0eeffe6bd6dbf6cf5c479d356af6
- https://git.kernel.org/stable/c/8fb1b9beb085bb767ae43e441db5ac6fcd66a04d
- https://git.kernel.org/stable/c/98d1dc32f890642476dbb78ed3437a456bf421b0
- https://git.kernel.org/stable/c/b4628e0d3754ab2fc98ee6e3d21851ba45798077
- https://git.kernel.org/stable/c/e8366bbabe1d207cf7c5b11ae50e223ae6fc278b
Modified: 2025-10-22
CVE-2022-49545
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Cancel pending work at closing a MIDI substream At closing a USB MIDI output substream, there might be still a pending work, which would eventually access the rawmidi runtime object that is being released. For fixing the race, make sure to cancel the pending work at closing.
- https://git.kernel.org/stable/c/0125de38122f0f66bf61336158d12a1aabfe6425
- https://git.kernel.org/stable/c/11868ca21585561659c2575b0d6508ef8e9c4291
- https://git.kernel.org/stable/c/40bdb5ec957aca5c5c1924602bef6b0ab18e22d3
- https://git.kernel.org/stable/c/517dcef4d2dda0132648f1e4c079ed17bba4d1a4
- https://git.kernel.org/stable/c/5e5fe2b6065541c6216a7a003b0cddf386be0d2d
Modified: 2025-10-01
CVE-2022-49548
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential array overflow in bpf_trampoline_get_progs() The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline can exceed BPF_MAX_TRAMP_PROGS. When this happens, the assignment '*progs++ = aux->prog' in bpf_trampoline_get_progs() will cause progs array overflow as the progs field in the bpf_tramp_progs struct can only hold at most BPF_MAX_TRAMP_PROGS bpf programs.
- https://git.kernel.org/stable/c/32c4559c61652f24c9fdd5440342196fe37453bc
- https://git.kernel.org/stable/c/4f8897bcc20b9ae44758e0572538d741ab66f0dc
- https://git.kernel.org/stable/c/7f845de2863334bed4f362e95853f5e7bc323737
- https://git.kernel.org/stable/c/a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d
- https://git.kernel.org/stable/c/e36452d5da6325df7c10cffc60a9e68d21e2606d
Modified: 2025-10-01
CVE-2022-49549
In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails In mce_threshold_create_device(), if threshold_create_bank() fails, the previously allocated threshold banks array @bp will be leaked because the call to mce_threshold_remove_device() will not free it. This happens because mce_threshold_remove_device() fetches the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when threshold_create_bank() fails. Add a helper which unwinds all the bank creation work previously done and pass into it the previously allocated threshold banks array for freeing. [ bp: Massage. ]
- https://git.kernel.org/stable/c/396b8e7ab2a99ddac57d3522b3da5e58cb608d37
- https://git.kernel.org/stable/c/9708f1956eeb70c86943e0bc62fa3b0101b59616
- https://git.kernel.org/stable/c/b4acb8e7f1594607bc9017ef0aacb40b24a003d6
- https://git.kernel.org/stable/c/cc0dd4456f9573bf8af9b4d8754433918e809e1e
- https://git.kernel.org/stable/c/e5f28623ceb103e13fc3d7bd45edf9818b227fd0
Modified: 2025-10-22
CVE-2022-49554
In the Linux kernel, the following vulnerability has been resolved: zsmalloc: fix races between asynchronous zspage free and page migration The asynchronous zspage free worker tries to lock a zspage's entire page list without defending against page migration. Since pages which haven't yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage's pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.
- https://git.kernel.org/stable/c/2505a981114dcb715f8977b8433f7540854851d8
- https://git.kernel.org/stable/c/3674d8a8dadd03a447dd21069d4dacfc3399b63b
- https://git.kernel.org/stable/c/3ec459c8810e658401be428d3168eacfc380bdd0
- https://git.kernel.org/stable/c/645996efc2ae391246d595832aaa6f9d3cc338c7
- https://git.kernel.org/stable/c/8ba7b7c1dad1f6503c541778f31b33f7f62eb966
- https://git.kernel.org/stable/c/c5402fb5f71f1a725f1e55d9c6799c0c7bec308f
- https://git.kernel.org/stable/c/fae05b2314b147a78fbed1dc4c645d9a66313758
- https://git.kernel.org/stable/c/fc658c083904427abbf8f18280d517ee2668677c
Modified: 2025-10-22
CVE-2022-49555
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Use del_timer_sync() before freeing While looking at a crash report on a timer list being corrupted, which usually happens when a timer is freed while still active. This is commonly triggered by code calling del_timer() instead of del_timer_sync() just before freeing. One possible culprit is the hci_qca driver, which does exactly that. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the work queue before del_timer_sync().
- https://git.kernel.org/stable/c/2717654ae022e6ea959a4b7b762702fe1a4690c2
- https://git.kernel.org/stable/c/37d17f63d085d601011964ade7371aeebeb6ed4b
- https://git.kernel.org/stable/c/4989bb03342941f2b730b37dfa38bce27b543661
- https://git.kernel.org/stable/c/72ef98445aca568a81c2da050532500a8345ad3a
- https://git.kernel.org/stable/c/db03727b4bbbbb36e6ef4cb655c670eefb6448e9
Modified: 2026-01-22
CVE-2022-49556
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak For some sev ioctl interfaces, the length parameter that is passed maybe less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the allocated buffer, these sev ioctl interface may return uninitialized kernel slab memory.
- https://git.kernel.org/stable/c/401bef1f95de92c3a8c6eece46e02fa88d7285ee
- https://git.kernel.org/stable/c/57a01725339f9d82b099102ba2751621b1caab93
- https://git.kernel.org/stable/c/bbdcc644b59e01e98c68894a9fab42b9687f42b0
- https://git.kernel.org/stable/c/d22d2474e3953996f03528b84b7f52cc26a39403
- https://git.kernel.org/stable/c/d8fdb4b24097472ff6b3c0559448200d420b1418
Modified: 2025-10-01
CVE-2022-49560
In the Linux kernel, the following vulnerability has been resolved: exfat: check if cluster num is valid Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap. This was triggered by reproducer calling truncute with size 0, which causes the following trace: BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65 Move the is_valid_cluster() helper from fatent.c to a common header to make it reusable in other *.c files. And add is_valid_cluster() to validate if cluster number is within valid range in exfat_clear_bitmap() and exfat_set_bitmap().
- https://git.kernel.org/stable/c/2193286402df2d9c53294f7a858d5e6fd7346e08
- https://git.kernel.org/stable/c/64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d
- https://git.kernel.org/stable/c/7c58b14b6f9cde9f69e7fa053ab73f6e013a7131
- https://git.kernel.org/stable/c/82f723b8a5adf497f9e34c702a30ca7298615654
- https://git.kernel.org/stable/c/c504167adc3248095a905fa0700a9693897cb5ed
Modified: 2025-10-24
CVE-2022-49561
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: re-fetch conntrack after insertion In case the conntrack is clashing, insertion can free skb->_nfct and set skb->_nfct to the already-confirmed entry. This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger.
- https://git.kernel.org/stable/c/01989d7eebb61c99bd4b88ebc8e261bd2f02caed
- https://git.kernel.org/stable/c/04e4a11dc723c52db7a36dc58f0d69ce6426f8f0
- https://git.kernel.org/stable/c/04f9e9104c969d8ce10a4a43634f641ed082092d
- https://git.kernel.org/stable/c/56b14ecec97f39118bf85c9ac2438c5a949509ed
- https://git.kernel.org/stable/c/91a36ec160ec1a0c8f5352b772dffcbb0b6023e3
- https://git.kernel.org/stable/c/92a999d1963eed0df666284e20055136ceabd12f
- https://git.kernel.org/stable/c/b16bb373988da3ceb0308381634117e18b6ec60d
- https://git.kernel.org/stable/c/e97222b785e70e8973281666d709baad6523d8af
Modified: 2025-10-01
CVE-2022-49676
In the Linux kernel, the following vulnerability has been resolved: memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in some error paths. To unify the structure, Add put_node label and goto it on errors.
Modified: 2025-10-01
CVE-2022-49677
In the Linux kernel, the following vulnerability has been resolved: ARM: cns3xxx: Fix refcount leak in cns3xxx_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1ba904b6b16e08de5aed7c1349838d9cd0d178c5
- https://git.kernel.org/stable/c/45bebbc8cea7d586a6216dc62814bdb380b9b29b
- https://git.kernel.org/stable/c/68d4303bf59662b64bd555e2aa0518282d20aa4f
- https://git.kernel.org/stable/c/b8b84e01ca94e2e1f5492353e9c24dab520b2e5b
- https://git.kernel.org/stable/c/c980392af1473d6d5662f70d8089c8e6d85144a4
- https://git.kernel.org/stable/c/d1359e4129ad43e43972a28838b87291c51de23d
- https://git.kernel.org/stable/c/da3ee7cd2f15922ad88a7ca6deee2eafdc7cd214
- https://git.kernel.org/stable/c/dc5170aae24e04068fd5ea125d06c0ab51f48a27
Modified: 2025-10-01
CVE-2022-49678
In the Linux kernel, the following vulnerability has been resolved: soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In brcmstb_init_sram, it pass dn to of_address_to_resource(), of_address_to_resource() will call of_find_device_by_node() to take reference, so we should release the reference returned by of_find_matching_node().
- https://git.kernel.org/stable/c/10ba9d499a9fd82ed40897e734ba19870a879407
- https://git.kernel.org/stable/c/30bbfeb480ae8b5ee43199d72417b232590440c2
- https://git.kernel.org/stable/c/37d838de369b07b596c19ff3662bf0293fdb09ee
- https://git.kernel.org/stable/c/4f5877bdf7b593e988f1924f4c3df6523f80b39c
- https://git.kernel.org/stable/c/734a4d15142bb4c8ecad2d8ec70d7564e78ae34d
- https://git.kernel.org/stable/c/dcafd5463d8f20c4f90ddc138a5738adb99f74c8
Modified: 2025-10-01
CVE-2022-49679
In the Linux kernel, the following vulnerability has been resolved: ARM: Fix refcount leak in axxia_boot_secondary of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/29ca9c4efacccdc15104a8d4bf10b5183fc92840
- https://git.kernel.org/stable/c/3c19fe3f04f4f4e7a2b722c2fd3c98356fc1d72b
- https://git.kernel.org/stable/c/44a5b3a073e5aaa5720929dba95b2725eb32bb65
- https://git.kernel.org/stable/c/4d9c60e868f7cf8e09956e7d5bb44d807d712699
- https://git.kernel.org/stable/c/71e12e5b02674459a24f16e965255d63b31fe049
- https://git.kernel.org/stable/c/7c7ff68daa93d8c4cdea482da4f2429c0398fcde
- https://git.kernel.org/stable/c/a9b76c232a1ce4cbf27862097f7eb634dcc779eb
- https://git.kernel.org/stable/c/b385cb59aac8d61c29bc72ebf3d19a536914af96
Modified: 2025-10-01
CVE-2022-49680
In the Linux kernel, the following vulnerability has been resolved: ARM: exynos: Fix refcount leak in exynos_map_pmu of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer.
- https://git.kernel.org/stable/c/31d09571bb071c20f6bdc0bb7ac1ef8dd2987c04
- https://git.kernel.org/stable/c/545ae5cbae839ce39bfe09828e413f1c916082de
- https://git.kernel.org/stable/c/68f28d52e6cbab8dcfa249cac4356d1d0573e868
- https://git.kernel.org/stable/c/7571bcecf01b69f0d3ec60ca41ce5d4c75411a4a
- https://git.kernel.org/stable/c/c4c79525042a4a7df96b73477feaf232fe44ae81
- https://git.kernel.org/stable/c/d23f76018e17618559da9eea179d137362023f95
- https://git.kernel.org/stable/c/f9b77a52937582a5b99a5a07e4ef1e2f48f87347
- https://git.kernel.org/stable/c/fc354856e9fad9cd36e2ad28f9da70716025055a
Modified: 2025-10-01
CVE-2022-49681
In the Linux kernel, the following vulnerability has been resolved: xtensa: xtfpga: Fix refcount leak bug in setup In machine_setup(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0162451723178602c37f0555d235dfa17e486112
- https://git.kernel.org/stable/c/0715d0e60052662c3f225342062f174dd721d1c7
- https://git.kernel.org/stable/c/173940b3ae40114d4179c251a98ee039dc9cd5b3
- https://git.kernel.org/stable/c/35d7e961be68732eb3acaeba81fb81ca16eafd05
- https://git.kernel.org/stable/c/6c0839cf1b9e1b3c88da6af76794583cbfae8da3
- https://git.kernel.org/stable/c/9b30c5c8884eda3f541229899671cebbad15979b
- https://git.kernel.org/stable/c/a52972ee706b438302eb0350e61f378eb191e3d1
- https://git.kernel.org/stable/c/b12d5c52f073a0420622aaf2f21b615cce8b36cc
Modified: 2025-10-01
CVE-2022-49682
In the Linux kernel, the following vulnerability has been resolved: xtensa: Fix refcount leak bug in time.c In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0dcc1dd8a5dd9240639f1051dfaa2dffc9fbbde5
- https://git.kernel.org/stable/c/0e403a383c14b63c86bd9df085b7e573e9caee64
- https://git.kernel.org/stable/c/3e5eb904d9ba657308fc75a5de434b0e58dcb8d7
- https://git.kernel.org/stable/c/7de4502af68f4f3932f450157f5483eb7b33cb74
- https://git.kernel.org/stable/c/a0117dc956429f2ede17b323046e1968d1849150
- https://git.kernel.org/stable/c/af0ff2da01521144bc11194f4c26485d7c9cee73
- https://git.kernel.org/stable/c/e5234a9d64a976abd134a14710dcd5188158a7c5
- https://git.kernel.org/stable/c/f1eaf4ba5372ad111f687a80c67e270708e14c23
Modified: 2025-10-01
CVE-2022-49683
In the Linux kernel, the following vulnerability has been resolved: iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-03-24
CVE-2022-49685
In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix use-after-free on remove Ensure that the irq_work has completed before the trigger is freed. ================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25 Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write ==================================================================
- https://git.kernel.org/stable/c/31ff3309b47d98313c61b8301bf595820cc3cc33
- https://git.kernel.org/stable/c/4687c3f955240ca2a576bdc3f742d4d915b6272d
- https://git.kernel.org/stable/c/4ef1e521be610b720daeb7cf899fedc7db0274c4
- https://git.kernel.org/stable/c/5e39397d60dacc7f5d81d442c1c958eaaaf31128
- https://git.kernel.org/stable/c/78601726d4a59a291acc5a52da1d3a0a6831e4e8
- https://git.kernel.org/stable/c/b07a30a774b3c3e584a68dc91779c68ea2da4813
- https://git.kernel.org/stable/c/d6111e7bdb8ec27eb43d01c4cd4ff1620a75f7f2
- https://git.kernel.org/stable/c/fd5d8fb298a2866c337da635c79d63c3afabcaf7
Modified: 2026-01-22
CVE-2022-49687
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix xdp_rxq_info bug after suspend/resume
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
- https://git.kernel.org/stable/c/340fbdc8011f2dc678f622c5ce1cbb5ab8305de7
- https://git.kernel.org/stable/c/57ee40f1b198b59d43c216fbc4672f9300d3c8b0
- https://git.kernel.org/stable/c/8af52fe9fd3bf5e7478da99193c0632276e1dfce
- https://git.kernel.org/stable/c/8c7a32b7c15555beddc5810c3334d9cefff061bf
- https://git.kernel.org/stable/c/8d7fe9ad6fddc2af8bde4b921b4f8fab231ed38c
- https://git.kernel.org/stable/c/9222672fa6370f0ec3d899662cb8680e9282fc4c
Modified: 2025-10-24
CVE-2022-49688
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix dynamic root getattr
The recent patch to make afs_getattr consult the server didn't account
for the pseudo-inodes employed by the dynamic root-type afs superblock
not having a volume or a server to access, and thus an oops occurs if
such a directory is stat'd.
Fix this by checking to see if the vnode->volume pointer actually points
anywhere before following it in afs_getattr().
This can be tested by stat'ing a directory in /afs. It may be
sufficient just to do "ls /afs" and the oops looks something like:
BUG: kernel NULL pointer dereference, address: 0000000000000020
...
RIP: 0010:afs_getattr+0x8b/0x14b
...
Call Trace:
- https://git.kernel.org/stable/c/2b2bba96526f25f2eba74ecadb031de2e05a83ce
- https://git.kernel.org/stable/c/65c24caf1b9f5b08397c6e805ec24ebc390c6e4d
- https://git.kernel.org/stable/c/7844ceada44eca740d31beb3d97b8511b1ca0a9b
- https://git.kernel.org/stable/c/7b564e3254b7db5fbfbf11a824627a6c31b932b4
- https://git.kernel.org/stable/c/cb78d1b5efffe4cf97e16766329dd7358aed3deb
- https://git.kernel.org/stable/c/e3a232e5767051483ffad4cef7d0a89d292a192b
Modified: 2025-10-24
CVE-2022-49691
In the Linux kernel, the following vulnerability has been resolved:
erspan: do not assume transport header is always set
Rewrite tests in ip6erspan_tunnel_xmit() and
erspan_fb_xmit() to not assume transport header is set.
syzbot reported:
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Modules linked in:
CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00
RSP: 0018:ffffc90005daf910 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003
RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40
R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000
FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0
Call Trace:
- https://git.kernel.org/stable/c/02da602bc2f353dccd9e489a604490034ded941e
- https://git.kernel.org/stable/c/2c8aeffc7c586d53e1d380f010bdca4f710f2480
- https://git.kernel.org/stable/c/301bd140ed0b24f0da660874c7e8a47dad8c8222
- https://git.kernel.org/stable/c/a3b2470399f679587c45abe56e551caf10becca2
- https://git.kernel.org/stable/c/cec9867ee55478ef5dcb2adf030fe0c442a4c4ee
- https://git.kernel.org/stable/c/fb401f37f6eadf24956d93687e5758c163c0d12b
Modified: 2025-10-01
CVE-2022-49693
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Patchwork: https://patchwork.freedesktop.org/patch/488473/
- https://git.kernel.org/stable/c/3c39a17197733bc37786ed68c83267c2f491840b
- https://git.kernel.org/stable/c/b9cc4598607cb7f7eae5c75fc1e3209cd52ff5e0
- https://git.kernel.org/stable/c/d1592d3e362cc59b29f15019707b16c695d70ca3
- https://git.kernel.org/stable/c/d16a4339825e64f9ddcdff5277982d640bae933b
- https://git.kernel.org/stable/c/d607da76fd2b1cf1d377af9d9b7c6f8fecbb0e1d
Modified: 2025-03-24
CVE-2022-49695
In the Linux kernel, the following vulnerability has been resolved:
igb: fix a use-after-free issue in igb_clean_tx_ring
Fix the following use-after-free bug in igb_clean_tx_ring routine when
the NIC is running in XDP mode. The issue can be triggered redirecting
traffic into the igb NIC and then closing the device while the traffic
is flowing.
[ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9
[ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017
[ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0
[ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282
[ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000
[ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0
[ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058
[ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090
[ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000
[ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000
[ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0
[ 73.426565] Call Trace:
[ 73.429087]
Modified: 2025-03-25
CVE-2022-49696
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix use-after-free Read in tipc_named_reinit
syzbot found the following issue on:
==================================================================
BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0
net/tipc/name_distr.c:413
Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764
CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted
5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0
Hardware name: Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: events tipc_net_finalize_work
Call Trace:
Modified: 2025-10-24
CVE-2022-49697
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix request_sock leak in sk lookup helpers A customer reported a request_socket leak in a Calico cloud environment. We found that a BPF program was doing a socket lookup with takes a refcnt on the socket and that it was finding the request_socket but returning the parent LISTEN socket via sk_to_full_sk() without decrementing the child request socket 1st, resulting in request_sock slab object leak. This patch retains the existing behaviour of returning full socks to the caller but it also decrements the child request_socket if one is present before doing so to prevent the leak. Thanks to Curtis Taylor for all the help in diagnosing and testing this. And thanks to Antoine Tenart for the reproducer and patch input. v2 of this patch contains, refactor as per Daniel Borkmann's suggestions to validate RCU flags on the listen socket so that it balances with bpf_sk_release() and update comments as per Martin KaFai Lau's suggestion. One small change to Daniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extra instruction.
- https://git.kernel.org/stable/c/3046a827316c0e55fc563b4fb78c93b9ca5c7c37
- https://git.kernel.org/stable/c/516760f1d2979903eaad5b437256913c5cd98416
- https://git.kernel.org/stable/c/5a62b5ba4c0ce8315b6382cd4ace81b48cd121cd
- https://git.kernel.org/stable/c/8ffe2e50e9678c8373027492035f094b130437f1
- https://git.kernel.org/stable/c/b03607437ea81b850599f705096b05b85e7a4a71
Modified: 2025-10-24
CVE-2022-49698
In the Linux kernel, the following vulnerability has been resolved: netfilter: use get_random_u32 instead of prandom bh might occur while updating per-cpu rnd_state from user context, ie. local_out path. BUG: using smp_processor_id() in preemptible [00000000] code: nginx/2725 caller is nft_ng_random_eval+0x24/0x54 [nft_numgen] Call Trace: check_preemption_disabled+0xde/0xe0 nft_ng_random_eval+0x24/0x54 [nft_numgen] Use the random driver instead, this also avoids need for local prandom state. Moreover, prandom now uses the random driver since d4150779e60f ("random32: use real rng for non-deterministic randomness"). Based on earlier patch from Pablo Neira.
Modified: 2025-10-24
CVE-2022-49706
In the Linux kernel, the following vulnerability has been resolved:
zonefs: fix zonefs_iomap_begin() for reads
If a readahead is issued to a sequential zone file with an offset
exactly equal to the current file size, the iomap type is set to
IOMAP_UNWRITTEN, which will prevent an IO, but the iomap length is
calculated as 0. This causes a WARN_ON() in iomap_iter():
[17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80
[...]
[17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80
[...]
[17309.754560] Call Trace:
[17309.757078]
Modified: 2025-10-01
CVE-2022-49707
In the Linux kernel, the following vulnerability has been resolved:
ext4: add reserved GDT blocks check
We capture a NULL pointer issue when resizing a corrupt ext4 image which
is freshly clear resize_inode feature (not run e2fsck). It could be
simply reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
not reduced to zero, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.
mkfs.ext4 /dev/sda 3G
tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
mount /dev/sda /mnt
resize2fs /dev/sda 8G
========
BUG: kernel NULL pointer dereference, address: 0000000000000028
CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
...
RIP: 0010:ext4_flex_group_add+0xe08/0x2570
...
Call Trace:
- https://git.kernel.org/stable/c/0dc2fca8e4f9ac4a40e8424a10163369cca0cc06
- https://git.kernel.org/stable/c/33b1bba31f4c784d33d2c2517964bdccdc9204cd
- https://git.kernel.org/stable/c/7c921328ac760bba780bdace41f4cd045f7f1405
- https://git.kernel.org/stable/c/af75c481a2e45e70f62f5942c93695e95bf7bd21
- https://git.kernel.org/stable/c/b55c3cd102a6f48b90e61c44f7f3dda8c290c694
- https://git.kernel.org/stable/c/b9747263b13e5290ac4d63bec47e38f701303cad
- https://git.kernel.org/stable/c/bfd004a1d3a062aac300523d406ac1f3e5f1a82c
- https://git.kernel.org/stable/c/fba54289176702a7caac0b64738406775817f451
Modified: 2025-10-24
CVE-2022-49708
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on ext4_mb_use_inode_pa Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f [...] Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0 [...] ================================================================== Above issue may happen as follows: ------------------------------------- do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0); we can easily reproduce this problem with the following commands: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1` The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP. Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur when the size is truncated. So start should be the start position of the group where ac_o_ex.fe_logical is located after alignment. In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP is very large, the value calculated by start_off is more accurate.
- https://git.kernel.org/stable/c/5707d721d1819db57dba57b1d4623034fcb32047
- https://git.kernel.org/stable/c/6880fb2e64331b9fdc85d3f32b1d7e81ad8703f1
- https://git.kernel.org/stable/c/6fdaf31ad5f3d3afab744dfd9a8b0d9142aa881f
- https://git.kernel.org/stable/c/887a3e9ad4b8309a2266bce7ae749b2bf1f7a687
- https://git.kernel.org/stable/c/90f0f9d45dff0128c0fca0d2358c4153b024afa6
- https://git.kernel.org/stable/c/a08f789d2ab5242c07e716baf9a835725046be89
- https://git.kernel.org/stable/c/a37c1359714da42517dd19d36fc3c4d17edba832
- https://git.kernel.org/stable/c/a6b31616e5afe1d3972cb0682a373e50597faf5c
Modified: 2025-10-24
CVE-2022-49710
In the Linux kernel, the following vulnerability has been resolved: dm mirror log: round up region bitmap size to BITS_PER_LONG The code in dm-log rounds up bitset_size to 32 bits. It then uses find_next_zero_bit_le on the allocated region. find_next_zero_bit_le accesses the bitmap using unsigned long pointers. So, on 64-bit architectures, it may access 4 bytes beyond the allocated size. Fix this bug by rounding up bitset_size to BITS_PER_LONG. This bug was found by running the lvm2 testsuite with kasan.
- https://git.kernel.org/stable/c/0d2209b54f1de0c2f99cab246d4cf2cfe24aaaa9
- https://git.kernel.org/stable/c/85e123c27d5cbc22cfdc01de1e2ca1d9003a02d0
- https://git.kernel.org/stable/c/9a02f3275acc628c0d956be771405ced79ac36df
- https://git.kernel.org/stable/c/ae460312875159285cef5bf3dc654593f404a1ef
- https://git.kernel.org/stable/c/ba751f0d25f07aa21ce9b85372a3792bf7969d13
Modified: 2025-10-01
CVE-2022-49712
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer.
- https://git.kernel.org/stable/c/0ef6917c0524da5b88496b9706628ffef108b9bb
- https://git.kernel.org/stable/c/2a598da14856ead80c726b38ba426c68637d9211
- https://git.kernel.org/stable/c/46da1e4a8b6329479433b2a4056941dfdd7f3efd
- https://git.kernel.org/stable/c/4757c9ade34178b351580133771f510b5ffcf9c8
- https://git.kernel.org/stable/c/57901c658f77d9ea2e772f35cb38e47efb54c558
- https://git.kernel.org/stable/c/727c82d003e0ec64411fd1257a9a57de4ad7a99a
- https://git.kernel.org/stable/c/b75bddfcc18170ce8e3fb695a76ec2dec4ce0ea5
- https://git.kernel.org/stable/c/d85e4e6284a91aa2d1ab004e9d84b9c09b4aa203
Modified: 2025-10-01
CVE-2022-49713
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix memory leak in dwc2_hcd_init usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 to fix this.
- https://git.kernel.org/stable/c/3755278f078460b021cd0384562977bf2039a57a
- https://git.kernel.org/stable/c/52bfcedbfd5bf962dbdcb6e761f4d0dd3ba26dfd
- https://git.kernel.org/stable/c/6506aff2dc2f7059aa3d45ee2e8639b25e87090f
- https://git.kernel.org/stable/c/701d8ec01e0f229d4db6f43d3d64ee479120cbeb
- https://git.kernel.org/stable/c/84e6d0af87e27bbc0db94f2e7323b34abe17b6e5
- https://git.kernel.org/stable/c/981ee40649e5fd9550f82db1fbb3bfab037da346
- https://git.kernel.org/stable/c/a44a8a762f7fe9ad3c065813d058e835a6180cb2
Modified: 2025-10-01
CVE-2022-49715
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/506a88a5bf261d76a5214c0338a320f2214c67ac
- https://git.kernel.org/stable/c/8d884c08eeb83142a7173cb46bcff0434ec42cf1
- https://git.kernel.org/stable/c/c136c2924a59a399aa789858cfb320d481964fb7
- https://git.kernel.org/stable/c/cc5984cf270b69d03f9f4b27063e535036c659e9
- https://git.kernel.org/stable/c/e824482e2c5edacc961b7dd30a92fd47606c3036
- https://git.kernel.org/stable/c/fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b
Modified: 2025-10-01
CVE-2022-49716
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. When kcalloc fails, it missing of_node_put() and results in refcount leak. Fix this by goto out_put_node label.
- https://git.kernel.org/stable/c/0b325d993995a321f6ab4e6c51f0504ec092bf5b
- https://git.kernel.org/stable/c/58e67c81e229351027d28c610638378606e33a08
- https://git.kernel.org/stable/c/7c9dd9d23f26dabcfb14148b9acdfba540418b19
- https://git.kernel.org/stable/c/c83c34c57798fc41faefcf078be78683db2f4beb
- https://git.kernel.org/stable/c/ec8401a429ffee34ccf38cebf3443f8d5ae6cb0d
Modified: 2025-10-01
CVE-2022-49719
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic/realview: Fix refcount leak in realview_gic_of_init of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/16b603cb8d34c2d917983918db1f88c8b831baaa
- https://git.kernel.org/stable/c/486f68f85085d9b16ae097679b1486dcb1b6eb69
- https://git.kernel.org/stable/c/56526c3883fc7a1f5898b1d40a02c8b8685a5d92
- https://git.kernel.org/stable/c/5d38720661a4b9c87705c206a6081177ffb8ec1d
- https://git.kernel.org/stable/c/87da903ce632d5689bef66d56ee5dae700d82104
- https://git.kernel.org/stable/c/b634af84bc1edece4e63317b0ad95618dd3a8693
- https://git.kernel.org/stable/c/e52a58b79f11755ea7e877015c4a1704303fa55f
- https://git.kernel.org/stable/c/f4b98e314888cc51486421bcf6d52852452ea48b
Modified: 2025-10-24
CVE-2022-49721
In the Linux kernel, the following vulnerability has been resolved:
arm64: ftrace: consistently handle PLTs.
Sometimes it is necessary to use a PLT entry to call an ftrace
trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(),
with each having *almost* identical logic, but this is not handled by
ftrace_modify_call() since its introduction in commit:
3b23e4991fb66f6d ("arm64: implement ftrace with regs")
Due to this, if we ever were to call ftrace_modify_call() for a callsite
which requires a PLT entry for a trampoline, then either:
a) If the old addr requires a trampoline, ftrace_modify_call() will use
an out-of-range address to generate the 'old' branch instruction.
This will result in warnings from aarch64_insn_gen_branch_imm() and
ftrace_modify_code(), and no instructions will be modified. As
ftrace_modify_call() will return an error, this will result in
subsequent internal ftrace errors.
b) If the old addr does not require a trampoline, but the new addr does,
ftrace_modify_call() will use an out-of-range address to generate the
'new' branch instruction. This will result in warnings from
aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace
the 'old' branch with a BRK. This will result in a kernel panic when
this BRK is later executed.
Practically speaking, case (a) is vastly more likely than case (b), and
typically this will result in internal ftrace errors that don't
necessarily affect the rest of the system. This can be demonstrated with
an out-of-tree test module which triggers ftrace_modify_call(), e.g.
| # insmod test_ftrace.ko
| test_ftrace: Function test_function raw=0xffffb3749399201c, callsite=0xffffb37493992024
| branch_imm_common: offset out of range
| branch_imm_common: offset out of range
| ------------[ ftrace bug ]------------
| ftrace failed to modify
| [
Modified: 2025-10-24
CVE-2022-49723
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/reset: Fix error_state_read ptr + offset use
Fix our pointer offset usage in error_state_read
when there is no i915_gpu_coredump but buf offset
is non-zero.
This fixes a kernel page fault can happen when
multiple tests are running concurrently in a loop
and one is producing engine resets and consuming
the i915 error_state dump while the other is
forcing full GT resets. (takes a while to trigger).
The dmesg call trace:
[ 5590.803000] BUG: unable to handle page fault for address:
ffffffffa0b0e000
[ 5590.803009] #PF: supervisor read access in kernel mode
[ 5590.803013] #PF: error_code(0x0000) - not-present page
[ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067
PTE 0
[ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 5590.803026] CPU: 5 PID: 13656 Comm: i915_hangman Tainted: G U
5.17.0-rc5-ups69-guc-err-capt-rev6+ #136
[ 5590.803033] Hardware name: Intel Corporation Alder Lake Client
Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00.
3031.A02.2201171222 01/17/2022
[ 5590.803039] RIP: 0010:memcpy_erms+0x6/0x10
[ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1
48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3
66 0f 1f 44 00 00 48 89 f8 48 89 d1
Modified: 2025-10-24
CVE-2022-49724
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Fix free_irq() on remove Pass the correct dev_id to free_irq() to fix this splat when the driver is unbound: WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq Trying to free already-free IRQ 65 Call Trace: warn_slowpath_fmt free_irq goldfish_tty_remove platform_remove device_remove device_release_driver_internal device_driver_detach unbind_store drv_attr_store ...
- https://git.kernel.org/stable/c/499e13aac6c762e1e828172b0f0f5275651d6512
- https://git.kernel.org/stable/c/65ca4db68b6819244df9024aea4be55edf8af1ef
- https://git.kernel.org/stable/c/a6fcd7ffd76a9c1d998a2d02d518c78a55c5bed8
- https://git.kernel.org/stable/c/c4b0b8edccb0cfb15a8cecf4161e0571d3daac64
- https://git.kernel.org/stable/c/c83a1d40dc624070a203eb383ef9fb60eb634136
- https://git.kernel.org/stable/c/f7183c76d500324b8b5bd0af5e663cfa57b7b836
- https://git.kernel.org/stable/c/fb15e79cacddfbc62264e6e807bde50ad688e988
Modified: 2025-10-24
CVE-2022-49725
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix call trace in setup_tx_descriptors After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors. Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash. Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test()
- https://git.kernel.org/stable/c/0a4e5a3dc5e41212870e6043895ae02455c93f63
- https://git.kernel.org/stable/c/15950157e2c24865b696db1c9ccc72743ae0e967
- https://git.kernel.org/stable/c/322271351b0e41565171e4cce70ea41854fac115
- https://git.kernel.org/stable/c/5ba9956ca57e361fb13ea369bb753eb33177acc7
- https://git.kernel.org/stable/c/814092927a215f5ca6c08249ec72a205e0b473cd
- https://git.kernel.org/stable/c/fd5855e6b1358e816710afee68a1d2bc685176ca
- https://git.kernel.org/stable/c/ff6e03fe84bc917bb0c907d02de668c2fe101712
Modified: 2025-10-24
CVE-2022-49726
In the Linux kernel, the following vulnerability has been resolved: clocksource: hyper-v: unexport __init-annotated hv_init_clocksource() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, arch/x86/kernel/cpu/mshyperv.c is never compiled as modular. (CONFIG_HYPERVISOR_GUEST is boolean)
- https://git.kernel.org/stable/c/0414eab7c78f3518143d383e448d44fc573ac6d2
- https://git.kernel.org/stable/c/245b993d8f6c4e25f19191edfbd8080b645e12b1
- https://git.kernel.org/stable/c/937fcbb55a1e48a6422e87e8f49422c92265f102
- https://git.kernel.org/stable/c/cff3a7ce6e81418b6e8bac941779bbf5d342d626
- https://git.kernel.org/stable/c/db965e2757d95f695e606856418cd84003dd036d
Modified: 2025-10-01
CVE-2022-49727
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max.
- https://git.kernel.org/stable/c/034246122f5c5e2e2a0b9fe04e24517920e9beb1
- https://git.kernel.org/stable/c/0e818d433fc2718fe4da044ffca7431812a7e04e
- https://git.kernel.org/stable/c/27a37755ceb401111ded76810359d3adc4b268a1
- https://git.kernel.org/stable/c/2cf73c7cb6125083408d77f43d0e84d86aed0000
- https://git.kernel.org/stable/c/2f42389d270f2304c8855b0b63498a5a4d0c053d
- https://git.kernel.org/stable/c/6c4e3486d21173d60925ef52e512cae727b43d30
- https://git.kernel.org/stable/c/b8879ca1fd7348b4d5db7db86dcb97f60c73d751
- https://git.kernel.org/stable/c/f638a84afef3dfe10554c51820c16e39a278c915
Modified: 2025-10-01
CVE-2022-49729
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well. Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak. Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.
- https://git.kernel.org/stable/c/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed
- https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee
- https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f
- https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4
- https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d
- https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537
- https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e
- https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c
Modified: 2025-10-01
CVE-2022-49731
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/07cbdb4807d369fbda73062a91b570c4dc5ec429
- https://git.kernel.org/stable/c/1ac5efee33f29e704226506d429b84575a5d66f8
- https://git.kernel.org/stable/c/253334f84c81bc6a43af489f108c0bddad989eef
- https://git.kernel.org/stable/c/36cd19e7d4e5571d77a2ed20c5b6ef50cf57734a
- https://git.kernel.org/stable/c/a810bd5af06977a847d1f202b22d7defd5c62497
- https://git.kernel.org/stable/c/bf476fe22aa1851bab4728e0c49025a6a0bea307
- https://git.kernel.org/stable/c/ca4693e6e06e4fd2b240c0fec47aa2498c94848e
- https://git.kernel.org/stable/c/ff128fbea720bf763fa345680dda5f050bc24a47
Modified: 2023-07-08
GHSA-j4rf-7357-f4cg
Unpatched extfs vulnerabilities are exploitable through suid-mode Apptainer
- https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
- https://nvd.nist.gov/vuln/detail/CVE-2022-1184
- https://nvd.nist.gov/vuln/detail/CVE-2023-30549
- https://github.com/apptainer/apptainer/commit/5a4964f5ba9c8d89a0e353b97f51fd607670a9f7
- https://github.com/torvalds/linux/commit/2220eaf90992c11d888fe771055d4de3303
- https://github.com/torvalds/linux/commit/4f04351888a83e595571de672e0a4a8b74f
- https://github.com/torvalds/linux/commit/61a1d87a324ad5e3ed27c6699dfc93218fcf3201
- https://github.com/torvalds/linux/commit/65f8ea4cd57dbd46ea13b41dc8bac03176b04233
- https://www.suse.com/security/cve/CVE-2022-1184.html
- https://ubuntu.com/security/CVE-2022-1184
- https://sylabs.io/2023/04/response-to-cve-2023-30549
- https://security.gentoo.org/glsa/202311-13
- https://security-tracker.debian.org/tracker/CVE-2022-1184
- https://lwn.net/Articles/932137
- https://lwn.net/Articles/932136
- https://github.com/apptainer/apptainer/releases/tag/v1.1.8
- https://github.com/apptainer/apptainer
- https://access.redhat.com/security/cve/cve-2022-1184
