ALT-PU-2022-2497-21
Package kernel-image-mp updated to version 5.19.4-alt1 for branch sisyphus in task 305738.
Closed vulnerabilities
Modified: 2024-09-30
BDU:2022-03162
Уязвимость функции ath9k_htc_wait_for_target драйвера беспроводного адаптера Atheros ядра операционной системы Linux, позволяющая нарушителю получить доступ к памяти ядра, что может привести к сбою системы или утечке внутренней информации ядра
Modified: 2023-03-15
BDU:2022-04090
Уязвимость функции nft_set_desc_concat_parse() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2024-09-30
BDU:2022-04878
Уязвимость ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-12-05
BDU:2022-05178
Уязвимость функции route4_change (net/sched/cls_route.c) ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать аварийное завершение работы приложения
Modified: 2023-11-13
BDU:2022-05539
Уязвимость функции pxa3xx_gcu_write ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-05633
Уязвимость компонента POSIX CPU ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-05-06
BDU:2022-06024
Уязвимость функции ismt_access() драйвера i2c-ismt ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-19
BDU:2022-06056
Уязвимость функции bpf_sys_bpf() подсистемы BPF ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-24
BDU:2022-06169
Уязвимость функции unmap_mapping_range (include/asm-generic/tlb.h) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2022-06616
Уязвимость функции devlink_param_set/devlink_param_get (net/core/devlink.c) компонента IPsec ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-06903
Уязвимость компонента net/rose/rose_timer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-07345
Уязвимость функции постановки в очередь sch_sfb ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-07348
Уязвимость функции kcm_tx_work() (net/kcm/kcmsock.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2023-12-26
BDU:2022-07354
Уязвимость ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-07401
Уязвимость функции smb2_tree_disconnect (fs/ksmbd/smb2pdu.c) модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-01-10
BDU:2022-07480
Уязвимость функции smb2_write (fs/ksmbd/smb2pdu.c) модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2024-06-10
BDU:2022-07502
Уязвимость подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-06-10
BDU:2022-07503
Уязвимость подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю удалённо вызывать отказ в обслуживании
Modified: 2023-12-26
BDU:2022-07504
Уязвимость подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-10
BDU:2022-07512
Уязвимость функции smb2_write (fs/ksmbd/smb2pdu.c) модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2023-01213
Уязвимость функции malidp_check_pages_threshold() (drivers/gpu/drm/arm/malidp_planes.c) драйвера Mali-DP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2024-09-30
BDU:2023-02363
Уязвимость функции verity_ctr() в модуле drivers/md/dm-verity-target.c подсистемы device-mapper ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код и подключить уязвимое оборудование
Modified: 2025-01-29
BDU:2023-02397
Уязвимость функции udmabuf_vm_fault() в модуле drivers/dma-buf/udmabuf.c ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код
Modified: 2025-01-29
BDU:2023-02525
Уязвимость реализации протокола sctp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02628
Уязвимость функции ext4_xattr_set_entry() в модуле fs/ext4/xattr.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных
Modified: 2024-06-10
BDU:2023-02634
Уязвимость функции x86_emulate_insn компонента arch/x86/kvm/emulate.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02738
Уязвимость функции kvm_steal_time_set_preempted() в модуле arch/x86/kvm/x86.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2026-01-20
BDU:2023-03163
Уязвимость функции prepare_to_relocate() в модуле fs/btrfs/relocation.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2023-04272
Уязвимость функции idt77252_exit() в модуле drivers/atm/idt77252.c сетевого драйвера ATM idt77252 операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2023-04901
Уязвимость функции dbFree() в модуле fs/jfs/jfs_dmap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01697
Уязвимость функции i2c_put_adapter() драйвера шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08072
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08078
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-26
BDU:2025-16079
Уязвимость функции write_same() драйвера SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01252
Уязвимость функции ext4_bmap() модуля fs/ext4/inode.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01521
Уязвимость функций ext4_mb_clear_bb() и ext4_free_blocks() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01522
Уязвимость функции raid5_end_write_request() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01523
Уязвимость функций lpfc_debugfs_multixripools_write() и lpfc_debugfs_nvmestat_write() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01524
Уязвимость функции prepare_to_relocate() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01546
Уязвимость функции attempt_restore_of_faulty_devices() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01549
Уязвимость функций scpi_init_versions() и scpi_probe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01550
Уязвимость функций usbnet_stop() и usbnet_disconnect() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01558
Уязвимость функции meson_encoder_hdmi_init() модуля drivers/gpu/drm/meson/meson_encoder_hdmi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02255
Уязвимость функции raid_status() в модуле drivers/md/dm-raid.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02256
Уязвимость функции put_entry() в модуле security/selinux/ss/policydb.h ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02257
Уязвимость функции raid10_remove_disk() в модуле drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02281
Уязвимость функции k3_r5_cluster_of_init() в модуле drivers/remoteproc/ti_k3_r5_remoteproc.c драйвера подсистемы удаленного процессора ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02337
Уязвимость функций sg_read() и sg_get_rq_mark() в модуле drivers/scsi/sg.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02364
Уязвимость функций hda_dsp_ipc4_irq_thread() и hda_dsp_ipc_irq_thread() в модуле sound/soc/sof/intel/hda-ipc.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02365
Уязвимость функций cnl_ipc4_irq_thread() и cnl_ipc_irq_thread() в модуле sound/soc/sof/intel/cnl.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02366
Уязвимость функции ext4_resize_fs() в модуле fs/ext4/resize.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02369
Уязвимость функции gaudi_parse_cb_no_ext_queue() в модуле drivers/misc/habanalabs/gaudi/gaudi.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-02561
Уязвимость функции memory_info_update() в модуле sound/soc/sof/debug.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02576
Уязвимость функции cdns3_wa2_remove_old_request() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02577
Уязвимость функции qcom_mhi_qrtr_probe() в модуле net/qrtr/mhi.c поддержки маршрутизаторов Qualcomm IPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02578
Уязвимость функции hda_dsp_dump_ext_rom_status() в модуле sound/soc/sof/intel/hda.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02579
Уязвимость функции iavf_reset_task() в модуле drivers/net/ethernet/intel/iavf/iavf_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02580
Уязвимость функций iavf_init_asq() и iavf_init_arq() в модуле drivers/net/ethernet/intel/iavf/iavf_adminq.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02582
Уязвимость функции early_init_devtree() в модуле arch/powerpc/kernel/prom.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02660
Уязвимость функции f2fs_new_node_page() в модуле fs/f2fs/node.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02662
Уязвимость функции sun6i_dsi_setup_timings() в модуле drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02663
Уязвимость функции sja1105_setup_devlink_regions() в модуле drivers/net/dsa/sja1105/sja1105_devlink.c драйвера коммутаторов семейства NXP SJA1105 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02664
Уязвимость функции mv88e6060_setup_port() в модуле drivers/net/dsa/mv88e6060.c драйвера DSA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02665
Уязвимость функции vt8623fb_set_par() в модуле drivers/video/fbdev/vt8623fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02764
Уязвимость функции ttm_bo_validate() модуля drivers/gpu/drm/ttm/ttm_bo.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02791
Уязвимость функции meson_vpu_has_available_connectors() модуля drivers/gpu/drm/meson/meson_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02802
Уязвимость функции afu_allocate_irqs() модуля drivers/misc/cxl/irq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02803
Уязвимость функции dcn303_stream_encoder_create() модуля drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02804
Уязвимость функции csdlock_debug() модуля kernel/smp.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02805
Уязвимость функции dm_pool_register_metadata_threshold() модуля drivers/md/dm-thin-metadata.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02806
Уязвимость функции dmar_parse_one_rhsa() модуля drivers/iommu/intel/dmar.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02807
Уязвимость функции begin_new_exec() модуля fs/exec.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02808
Уязвимость функции set_current_kprobe() модуля arch/x86/kernel/kprobes/core.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02809
Уязвимость функции qla2x00_eh_wait_for_pending_commands() модуля drivers/scsi/qla2xxx/qla_os.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02810
Уязвимость функции arkfb_set_par() модуля drivers/video/fbdev/arkfb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02811
Уязвимость функции arkfb_set_par() модуля drivers/video/fbdev/arkfb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02812
Уязвимость функции __graph_get_type() модуля sound/soc/generic/audio-graph-card2.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02813
Уязвимость функции task_can_attach() модуля kernel/sched/core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02814
Уязвимость функции sof_ipc3_control_load_bytes() модуля sound/soc/sof/ipc3-topology.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02815
Уязвимость функций hisi_acc_vfio_pci_open_device() и hisi_acc_vfio_pci_close_device() модуля drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c драйвера устройств VFIO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03106
Уязвимость функции vc_uniscr_alloc() модуля drivers/tty/vt/vt.c драйвера виртуального терминала консоли ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03107
Уязвимость функции security_read_state_kernel() модуля security/selinux/ss/services.c подсистемы обеспечения безопаности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03123
Уязвимость функции intel_eth_pci_remove() модуля drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c драйвера сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03124
Уязвимость функции msb_data_clear() модуля drivers/memstick/core/ms_block.c драйвера карт Sony MemoryStick ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03129
Уязвимость функций copy_from_bpfptr_offset() и strncpy_from_bpfptr() модуля include/linux/bpfptr.h ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03178
Уязвимость функций aq_nic_service_timer_cb() и aq_nic_get_stats() модуля drivers/net/ethernet/aquantia/atlantic/aq_nic.c драйвера сетевых адаптеров Ethernet с чипсетом aQuantia Atlantic ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03179
Уязвимость функции __driver_attach() модуля drivers/base/dd.c драйвера шинных устройства ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03180
Уязвимость функции __kernfs_remove() модуля fs/kernfs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03251
Уязвимость функции get_nodes() модуля mm/mempolicy.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03252
Уязвимость функций sf_pdma_alloc_desc() и sf_pdma_desc_residue() модуля drivers/dma/sf-pdma/sf-pdma.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03253
Уязвимость функций __msc_buffer_win_free() и msc_buffer_get_page() модуля drivers/hwtracing/intel_th/msu.c драйвера трассировки HW ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03254
Уязвимость функции irdma_destroy_cq() модуля drivers/infiniband/hw/irdma/verbs.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03255
Уязвимость функции siw_proc_mpareply() модуля drivers/infiniband/sw/siw/siw_cm.c драйвера Infiniband ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03257
Уязвимость функции mcp_smbus_write() модуля drivers/hid/hid-mcp2221.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03261
Уязвимость функции power_pmu_disable() модуля arch/powerpc/perf/core-book3s.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03262
Уязвимость функции jbd2_journal_dirty_metadata() модуля fs/jbd2/transaction.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03263
Уязвимость функций rxe_qp_init_misc() и rxe_qp_init_req() модуля drivers/infiniband/sw/rxe/rxe_qp.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03264
Уязвимость функции fbtft_framebuffer_alloc() модуля drivers/staging/fbtft/fbtft-core.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03373
Уязвимость функций cifs_close_deferred_file() и cifs_close_all_deferred_files() модуля fs/cifs/misc.c файловой системы cifs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03374
Уязвимость функции soc_info() модуля drivers/tty/serial/ucc_uart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03375
Уязвимость функций mptcp_sendmsg_frag() и mptcp_subflow_get_send() модуля net/mptcp/protocol.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03396
Уязвимость функции xive_get_max_prio() модуля arch/powerpc/sysdev/xive/spapr.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03397
Уязвимость функций trace_spmi_write_begin() и trace_spmi_read_end() модуля include/trace/events/spmi.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03398
Уязвимость функций get_eprobe_size() и process_fetch_insn() модуля kernel/trace/trace_eprobe.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03399
Уязвимость функций btrfs_split_delalloc_extent() и btrfs_merge_delalloc_extent() модуля fs/btrfs/inode.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03400
Уязвимость функции ice_reset_vf() модуля drivers/net/ethernet/intel/ice/ice_vf_lib.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03401
Уязвимость функции netlink_policy_dump_add_policy() модуля net/netlink/policy.c поддержки интерфейса мониторинга сокетов NETLINK ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03403
Уязвимость функции ohci_hcd_ppc_of_probe() модуля drivers/usb/host/ohci-ppc-of.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03404
Уязвимость функции lpfc_issue_cmf_sync_wqe() модуля drivers/scsi/lpfc/lpfc_sli.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03405
Уязвимость функции dw_axi_dma_chan_slave_config() модуля drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03456
Уязвимость функции spufs_init_isolated_loader() модуля arch/powerpc/platforms/cell/spufs/inode.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03460
Уязвимость функции setup_msi_msg_address() модуля arch/powerpc/platforms/cell/axon_msi.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03463
Уязвимость функции cifs_readahead() модуля fs/cifs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03468
Уязвимость функции max77620_initialise_fps() модуля drivers/mfd/max77620.c драйвера контроллера многофункциональных устройств (MFD) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03470
Уязвимость функции clcdfb_of_init_display() модуля drivers/video/fbdev/amba-clcd.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03471
Уязвимость функции sp5100_tco_setupdevice_mmio() модуля drivers/watchdog/sp5100_tco.c поддержки сторожевого таймера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03472
Уязвимость функций mt6359_accdet_parse_dt() и mt6359_parse_dt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03473
Уязвимость функций parse_probe_vars() и parse_probe_arg() модуля kernel/trace/trace_probe.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03474
Уязвимость функции aa_pivotroot() модуля security/apparmor/mount.c компонента обеспечения безопасности AppArmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03476
Уязвимость функции qcom_smd_parse_edge() модуля drivers/rpmsg/qcom_smd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03478
Уязвимость функции rpc_sysfs_xprt_state_change() модуля net/sunrpc/sysfs.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03479
Уязвимость функции nft_set_elem_expr_clone() модуля net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03481
Уязвимость функции ndisc_router_discovery() модуля net/ipv6/ndisc.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03482
Уязвимость функции handle_cap_grant() модуля fs/ceph/caps.c поддержки распределенной файловой системы Ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03734
Уязвимость функции cdns3_allocate_trb_pool() модуля drivers/usb/cdns3/cdns3-gadget.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03736
Уязвимость функции ath9k_htc_probe_device() модуля drivers/net/wireless/ath/ath9k/htc_drv_init.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03750
Уязвимость функции cp2112_xfer() модуля drivers/hid/hid-cp2112.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04489
Уязвимость функции ttwu_queue_cond() модуля kernel/sched/core.c поддержки системы учета ресурсов ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04502
Уязвимость функции __get_segment_type_6() и f2fs_ioc_start_atomic_write() модуля fs/f2fs/segment.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04503
Уязвимость функции i740fb_decode_var() модуля drivers/video/fbdev/i740fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04504
Уязвимость функции core_get_v4() модуля drivers/media/platform/qcom/venus/pm_helpers.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04505
Уязвимость функции octeon2_usb_clocks_start() модуля arch/mips/cavium-octeon/octeon-platform.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04506
Уязвимость функции axi_chan_block_xfer_complete() модуля drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04507
Уязвимость функции ep_io() модуля drivers/usb/gadget/legacy/inode.c драйвера гаджетов USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04508
Уязвимость функции clk_branch_wait() модуля drivers/clk/qcom/clk-branch.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04509
Уязвимость функции usbhs_rza1_hardware_init() модуля drivers/usb/renesas_usbhs/rza.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04510
Уязвимость функций blk_iocost_init() (block/blk-iocost.c) и wbt_init() (block/blk-wbt.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04511
Уязвимость функций snapshot_write() и snapshot_ioctl() модуля kernel/power/user.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04512
Уязвимость функции ext2_fill_super() модуля fs/ext2/super.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04514
Уязвимость функции emulation_proc_handler() модуля arch/arm64/kernel/armv8_deprecated.c поддержки платформы ARM 64бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04515
Уязвимость функции c_start() модуля arch/mips/kernel/proc.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04564
Уязвимость функции dw_pcie_ep_init() модуля drivers/pci/controller/dwc/pcie-designware-ep.c драйвера уcтройств PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04565
Уязвимость функции sdw_drv_probe() модуля drivers/soundwire/bus_type.c драйвера SoundWire ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04566
Уязвимость функции intel_th_pci_probe() модуля drivers/hwtracing/intel_th/pci.c драйвера трассировки HW ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04567
Уязвимость функции esdhc_signal_voltage_switch() модуля drivers/mmc/host/sdhci-of-esdhc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04568
Уязвимость функции ast_vhub_init_desc() модуля drivers/usb/gadget/udc/aspeed-vhub/hub.c драйвера гаджетов USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04569
Уязвимость функции __qedr_alloc_mr() модуля drivers/infiniband/hw/qedr/verbs.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04571
Уязвимость функции setup_base_ctxt() модуля drivers/infiniband/hw/hfi1/file_ops.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04572
Уязвимость функций cdns3_gadget_ep_enable() и cdns3_gadget_ep_dequeue() модуля drivers/usb/cdns3/cdns3-gadget.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04573
Уязвимость функции cros_ec_codec_platform_probe() модуля sound/soc/codecs/cros_ec_codec.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04576
Уязвимость функции mt6797_mt6351_dev_probe() модуля sound/soc/mediatek/mt6797/mt6797-mt6351.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04577
Уязвимость функции mt8173_rt5650_rt5676_dev_probe() модуля sound/soc/mediatek/mt8173/mt8173-rt5650-rt5676.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04578
Уязвимость функции mt8173_rt5650_dev_probe() модуля sound/soc/mediatek/mt8173/mt8173-rt5650.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04582
Уязвимость функции imx_rproc_addr_init() модуля drivers/remoteproc/imx_rproc.c драйвера подсистемы удаленного процессора ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04584
Уязвимость функции gsm_send() и gsm_data_kick() модуля drivers/tty/n_gsm.c драйвера консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04585
Уязвимость функции p9_read_work() модуля net/9p/trans_fd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04869
Уязвимость функции omapdss_init_fbdev() модуля arch/arm/mach-omap2/display.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04870
Уязвимость функции pdata_quirks_init_clocks() модуля arch/arm/mach-omap2/pdata-quirks.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04874
Уязвимость функции s3fb_set_par() модуля drivers/video/fbdev/s3fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04875
Уязвимость функции bgmac_dma_tx_add() модуля drivers/net/ethernet/broadcom/bgmac.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04877
Уязвимость функции iavf_init_get_resources() модуля drivers/net/ethernet/intel/iavf/iavf_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04879
Уязвимость функции dpcm_get_be() модуля sound/soc/soc-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04886
Уязвимость функций srpt_refresh_port() и srpt_cm_req_recv() модуля drivers/infiniband/ulp/srpt/ib_srpt.c драйвера сервера и клиента RTRS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04895
Уязвимость функции ntfs_update_mftmirr() модуля fs/ntfs3/fsntfs.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04896
Уязвимость функции ntfs_read_mft() модуля fs/ntfs3/inode.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05721
Уязвимость функции receive_mergeable() в модуле drivers/net/virtio_net.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05730
Уязвимость функции __rvu_flr_handler() в модуле drivers/net/ethernet/marvell/octeontx2/af/rvu.c драйвера сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05731
Уязвимость функций mptcp_destroy_common() и mptcp_destroy() в модуле net/mptcp/protocol.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05732
Уязвимость функции hinic_get_stats64() в модуле drivers/net/ethernet/huawei/hinic/hinic_main.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05784
Уязвимость функции ima_get_kexec_buffer() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05785
Уязвимость функции drain_workqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05786
Уязвимость функции coresight_release_platform_data() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05787
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05849
Уязвимость функции elem_size() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05850
Уязвимость функции of_find_compatible_node() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05851
Уязвимость функции isl29028_remove() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05852
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05853
Уязвимость функции neon_poly1305_blocks ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06012
Уязвимость функции reset_tdp_shadow_zero_bits_mask() в модуле arch/x86/kvm/mmu/mmu.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06047
Уязвимость функции z_erofs_lzma_head() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06048
Уязвимость функции htc_tx_completion() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06049
Уязвимость функции kunit_filter_tests() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06067
Уязвимость функции mcde_dsi_bind() в модуле drivers/gpu/drm/mcde/mcde_dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-21
CVE-2019-25162
In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. [wsa: added comment to the code, added Fixes tag]
- https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d
- https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829
- https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7
- https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9
- https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87
- https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf
- https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a
- https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4
- https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d
- https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829
- https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7
- https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9
- https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87
- https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf
- https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a
- https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4
Modified: 2024-11-21
CVE-2021-33655
When sending malicous data to kernel by ioctl cmd FBIOPUT_VSCREENINFO,kernel will write memory out of bounds.
- http://www.openwall.com/lists/oss-security/2022/07/19/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://www.debian.org/security/2022/dsa-5191
- http://www.openwall.com/lists/oss-security/2022/07/19/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://www.debian.org/security/2022/dsa-5191
Modified: 2024-11-21
CVE-2022-1679
A use-after-free flaw was found in the Linux kernel’s Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/
- https://security.netapp.com/advisory/ntap-20220629-0007/
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/
- https://security.netapp.com/advisory/ntap-20220629-0007/
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: 2024-11-21
CVE-2022-2078
A vulnerability was found in the Linux kernel's nft_set_desc_concat_parse() function .This flaw allows an attacker to trigger a buffer overflow via nft_set_desc_concat_parse() , causing a denial of service and possibly to run code.
- https://bugzilla.redhat.com/show_bug.cgi?id=2096178
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85
- https://www.debian.org/security/2022/dsa-5161
- https://bugzilla.redhat.com/show_bug.cgi?id=2096178
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85
- https://www.debian.org/security/2022/dsa-5161
Modified: 2025-11-10
CVE-2022-21546
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like "sg_write_same --ndob" we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer.
- https://git.kernel.org/stable/c/4226622647e3e5ac06d3ebc1605b917446157510
- https://git.kernel.org/stable/c/54e57be2573cf0b8bf650375fd8752987b6c3d3b
- https://git.kernel.org/stable/c/ccd3f449052449a917a3e577d8ba0368f43b8f29
- https://git.kernel.org/stable/c/d8e6a27e9238dd294d6f2f401655f300dca20899
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2024-11-21
CVE-2022-2318
There are use-after-free vulnerabilities caused by timer handler in net/rose/rose_timer.c of linux that allow attackers to crash linux kernel without any privileges.
- https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2022/dsa-5191
- https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2022/dsa-5191
Modified: 2024-11-21
CVE-2022-2503
Dm-verity is used for extending root-of-trust to root filesystems. LoadPin builds on this property to restrict module/firmware loads to just the trusted root filesystem. Device-mapper table reloads currently allow users with root privileges to switch out the target with an equivalent dm-linear target and bypass verification till reboot. This allows root to bypass LoadPin and can be used to load untrusted and unverified kernel modules and firmware, which implies arbitrary kernel execution and persistence for peripherals that do not verify firmware updates. We recommend upgrading past commit 4caae58406f8ceb741603eee460d79bacca9b1b5
Modified: 2024-11-21
CVE-2022-2585
It was discovered that when exec'ing from a non-leader thread, armed POSIX CPU timers would be left on a list but freed, leading to a use-after-free.
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585
- https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://www.openwall.com/lists/oss-security/2022/08/09/7
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585
- https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://www.openwall.com/lists/oss-security/2022/08/09/7
Modified: 2024-11-21
CVE-2022-2588
It was discovered that the cls_route filter implementation in the Linux kernel would not remove an old filter from the hashtable before freeing it if its handle had the value 0.
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588
- https://github.com/Markakd/CVE-2022-2588
- https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5557-1
- https://ubuntu.com/security/notices/USN-5560-1
- https://ubuntu.com/security/notices/USN-5560-2
- https://ubuntu.com/security/notices/USN-5562-1
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://ubuntu.com/security/notices/USN-5582-1
- https://ubuntu.com/security/notices/USN-5588-1
- https://www.openwall.com/lists/oss-security/2022/08/09/6
- https://www.zerodayinitiative.com/advisories/ZDI-22-1117/
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588
- https://github.com/Markakd/CVE-2022-2588
- https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5557-1
- https://ubuntu.com/security/notices/USN-5560-1
- https://ubuntu.com/security/notices/USN-5560-2
- https://ubuntu.com/security/notices/USN-5562-1
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://ubuntu.com/security/notices/USN-5582-1
- https://ubuntu.com/security/notices/USN-5588-1
- https://www.openwall.com/lists/oss-security/2022/08/09/6
- https://www.zerodayinitiative.com/advisories/ZDI-22-1117/
Modified: 2026-04-14
CVE-2022-2785
There exists an arbitrary memory read within the Linux Kernel BPF - Constants provided to fill pointers in structs passed in to bpf_sys_bpf are not verified and can point anywhere, including memory not owned by BPF. An attacker with CAP_BPF can arbitrarily read memory from anywhere on the system. We recommend upgrading past commit 86f44fcec22c
Modified: 2024-11-21
CVE-2022-2873
An out-of-bounds memory access flaw was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way a user triggers the I2C_SMBUS_BLOCK_DATA (with the ioctl I2C_SMBUS) with malicious input data. This flaw allows a local user to crash the system.
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2023/dsa-5324
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2023/dsa-5324
Modified: 2025-06-27
CVE-2022-3077
A buffer overflow vulnerability was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way it handled the I2C_SMBUS_BLOCK_PROC_CALL case (via the ioctl I2C_SMBUS) with malicious input data. This flaw could allow a local user to crash the system.
Modified: 2024-11-21
CVE-2022-3521
A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function kcm_tx_work of the file net/kcm/kcmsock.c of the component kcm. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. VDB-211018 is the identifier assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211018
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211018
Modified: 2025-06-25
CVE-2022-3586
A flaw was found in the Linux kernel’s networking code. A use-after-free was found in the way the sch_sfb enqueue function used the socket buffer (SKB) cb field after the same SKB had been enqueued (and freed) into a child qdisc. This flaw allows a local, unprivileged user to crash the system, causing a denial of service.
- https://github.com/torvalds/linux/commit/9efd23297cca
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://www.zerodayinitiative.com/advisories/upcoming/
- https://github.com/torvalds/linux/commit/9efd23297cca
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://www.zerodayinitiative.com/advisories/upcoming/
Modified: 2024-11-21
CVE-2022-3625
A vulnerability was found in Linux Kernel. It has been classified as critical. This affects the function devlink_param_set/devlink_param_get of the file net/core/devlink.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211929 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211929
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211929
Modified: 2024-11-21
CVE-2022-3635
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function tst_timer of the file drivers/atm/idt77252.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. VDB-211934 is the identifier assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211934
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211934
Modified: 2024-11-21
CVE-2022-39188
An issue was discovered in include/asm-generic/tlb.h in the Linux kernel before 5.19. Because of a race condition (unmap_mapping_range versus munmap), a device driver can free a page while it still has stale TLB entries. This only occurs in situations with VM_PFNMAP VMAs.
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2329
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/
- https://www.debian.org/security/2022/dsa-5257
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2329
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-05
CVE-2022-39189
An issue was discovered the x86 KVM subsystem in the Linux kernel before 5.18.17. Unprivileged guest users can compromise the guest kernel because TLB flush operations are mishandled in certain KVM_VCPU_PREEMPTED situations.
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2309
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736
- https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230214-0007/
- https://www.debian.org/security/2023/dsa-5480
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2309
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736
- https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230214-0007/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2024-11-21
CVE-2022-39842
An issue was discovered in the Linux kernel before 5.19. In pxa3xx_gcu_write in drivers/video/fbdev/pxa3xx-gcu.c, the count parameter has a type conflict of size_t versus int, causing an integer overflow and bypassing the size check. After that, because it is used as the third argument to copy_from_user(), a heap overflow may occur. NOTE: the original discoverer disputes that the overflow can actually happen.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/
- https://www.debian.org/security/2022/dsa-5257
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-04-15
CVE-2022-47938
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2misc.c has an out-of-bounds read and OOPS for SMB2_TREE_CONNECT.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e
- https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e
- https://www.zerodayinitiative.com/advisories/ZDI-22-1689/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e
- https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e
- https://www.zerodayinitiative.com/advisories/ZDI-22-1689/
Modified: 2025-04-14
CVE-2022-47939
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c has a use-after-free and OOPS for SMB2_TREE_DISCONNECT.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1690/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1690/
Modified: 2025-04-14
CVE-2022-47940
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.18 before 5.18.18. fs/ksmbd/smb2pdu.c lacks length validation in the non-padding case in smb2_write.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6
- https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6
- https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6
Modified: 2025-04-15
CVE-2022-47941
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c omits a kfree call in certain smb2_handle_negotiate error conditions, aka a memory leak.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://www.zerodayinitiative.com/advisories/ZDI-22-1687/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://www.zerodayinitiative.com/advisories/ZDI-22-1687/
Modified: 2025-04-15
CVE-2022-47942
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is a heap-based buffer overflow in set_ntacl_dacl, related to use of SMB2_QUERY_INFO_HE after a malformed SMB2_SET_INFO_HE command.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://www.zerodayinitiative.com/advisories/ZDI-22-1688/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://www.zerodayinitiative.com/advisories/ZDI-22-1688/
Modified: 2025-04-15
CVE-2022-47943
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is an out-of-bounds read and OOPS for SMB2_WRITE, when there is a large length in the zero DataOffset case.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://security.netapp.com/advisory/ntap-20230216-0006/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1691/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://security.netapp.com/advisory/ntap-20230216-0006/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1691/
Modified: 2025-11-14
CVE-2022-50009
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix null-ptr-deref in f2fs_get_dnode_of_data
There is issue as follows when test f2fs atomic write:
F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
F2FS-fs (loop0): invalid crc_offset: 0
F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=1, run fsck to fix.
F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=2, run fsck to fix.
==================================================================
BUG: KASAN: null-ptr-deref in f2fs_get_dnode_of_data+0xac/0x16d0
Read of size 8 at addr 0000000000000028 by task rep/1990
CPU: 4 PID: 1990 Comm: rep Not tainted 5.19.0-rc6-next-20220715 #266
Call Trace:
Modified: 2025-11-14
CVE-2022-50010
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: i740fb: Check the argument of i740_calc_vclk() Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug. If the user provides an improper 'pixclock' value that makes the argumet of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a divide-by-zero bug in: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline] RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline] RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of i740_calc_vclk() first.
- https://git.kernel.org/stable/c/2b7f559152a33c55f51b569b22efbe5e24886798
- https://git.kernel.org/stable/c/40bf722f8064f50200b8c4f8946cd625b441dda9
- https://git.kernel.org/stable/c/4b20c61365140d432dee7da7aa294215e7b900d9
- https://git.kernel.org/stable/c/59cefb583c984c0da8cf21a4c57d26d5a20dff5c
- https://git.kernel.org/stable/c/656689cb03ada4650016c153346939a1c334b1ae
- https://git.kernel.org/stable/c/d2d375eb68b4b8de6ea7460483a26fa9de56b443
- https://git.kernel.org/stable/c/e740e787f06671455b59d1e498c9945f7b4e7b3b
- https://git.kernel.org/stable/c/f350812e2d15278f1d867eeb997407782234fb3c
Modified: 2025-11-14
CVE-2022-50011
In the Linux kernel, the following vulnerability has been resolved: venus: pm_helpers: Fix warning in OPP during probe Fix the following WARN triggered during Venus driver probe on 5.19.0-rc8-next-20220728: WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610 Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+) videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5 phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6 CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_opp_set_config+0x49c/0x610 lr : dev_pm_opp_set_config+0x58/0x610 sp : ffff8000093c3710 x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00 x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810 x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810 x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000 x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858 x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000 x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0 x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640 x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008 x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860 Call trace: dev_pm_opp_set_config+0x49c/0x610 devm_pm_opp_set_config+0x18/0x70 vcodec_domains_get+0xb8/0x1638 [venus_core] core_get_v4+0x1d8/0x218 [venus_core] venus_probe+0xf4/0x468 [venus_core] platform_probe+0x68/0xd8 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0xf0 __driver_attach+0x70/0x120 bus_for_each_dev+0x70/0xc0 driver_attach+0x24/0x30 bus_add_driver+0x150/0x200 driver_register+0x64/0x120 __platform_driver_register+0x28/0x38 qcom_venus_driver_init+0x24/0x1000 [venus_core] do_one_initcall+0x54/0x1c8 do_init_module+0x44/0x1d0 load_module+0x16c8/0x1aa0 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x44/0x108 el0_svc_common.constprop.0+0xcc/0xf0 do_el0_svc+0x2c/0xb8 el0_svc+0x2c/0x88 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x18c/0x190 qcom-venus: probe of aa00000.video-codec failed with error -16 The fix is re-ordering the code related to OPP core. The OPP core expects all configuration options to be provided before the OPP table is added.
Modified: 2025-12-23
CVE-2022-50012
In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Init jump labels before parse_early_param() On 64-bit, calling jump_label_init() in setup_feature_keys() is too late because static keys may be used in subroutines of parse_early_param() which is again subroutine of early_init_devtree(). For example booting with "threadirqs": static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 Call Trace: static_key_enable_cpuslocked+0xf8/0x120 (unreliable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214 So call jump_label_init() just before parse_early_param() in early_init_devtree(). [mpe: Add call trace to change log and minor wording edits.]
Modified: 2025-11-14
CVE-2022-50013
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()
As Dipanjan Das
- https://git.kernel.org/stable/c/141170b759e03958f296033bb7001be62d1d363b
- https://git.kernel.org/stable/c/29e734ec33ae4bd7de4018fb0fb0eec808c36b92
- https://git.kernel.org/stable/c/43ce0a0bda2c54dad91d5a1943554eed9e050f55
- https://git.kernel.org/stable/c/5a01e45b925a0bc9718eccd33e5920f1a4e44caf
- https://git.kernel.org/stable/c/800ba8979111184d5194f4233cc83afe683efc54
- https://git.kernel.org/stable/c/fbfad62b29e9f8f1c1026a806c9e064ec2a7c342
Modified: 2025-11-14
CVE-2022-50015
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot It is not yet clear, but it is possible to create a firmware so broken that it will send a reply message before a FW_READY message (it is not yet clear if FW_READY will arrive later). Since the reply_data is allocated only after the FW_READY message, this will lead to a NULL pointer dereference if not filtered out. The issue was reported with IPC4 firmware but the same condition is present for IPC3.
Modified: 2025-11-14
CVE-2022-50016
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware boot It is not yet clear, but it is possible to create a firmware so broken that it will send a reply message before a FW_READY message (it is not yet clear if FW_READY will arrive later). Since the reply_data is allocated only after the FW_READY message, this will lead to a NULL pointer dereference if not filtered out. The issue was reported with IPC4 firmware but the same condition is present for IPC3.
Modified: 2025-11-13
CVE-2022-50017
In the Linux kernel, the following vulnerability has been resolved: mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_start We should call of_node_put() for the reference 'uctl_node' returned by of_get_parent() which will increase the refcount. Otherwise, there will be a refcount leak bug.
- https://git.kernel.org/stable/c/1b49707df679b5510ed06ace7378ddc2aec5c3fb
- https://git.kernel.org/stable/c/1e39037e44d7fa3728686af146f9285ea197097d
- https://git.kernel.org/stable/c/7822d994eb9579a1df4cdbc315db090a041e50f3
- https://git.kernel.org/stable/c/7a9f743ceead60ed454c46fbc3085ee9a79cbebb
- https://git.kernel.org/stable/c/9d1afa0169a84dcd5b79901d792edeb8403684ab
- https://git.kernel.org/stable/c/a80016c40cc797c7f3e5a705b8e12ae447280335
- https://git.kernel.org/stable/c/af87a469695dc2b2419b2fdff0bf41db5265b325
- https://git.kernel.org/stable/c/c06166a484eece51916dd700a870e53356b7e1bc
Modified: 2025-11-13
CVE-2022-50019
In the Linux kernel, the following vulnerability has been resolved: tty: serial: Fix refcount leak bug in ucc_uart.c In soc_info(), of_find_node_by_type() 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/17c32546166d8a7d2579c4b57c8b16241f94a66b
- https://git.kernel.org/stable/c/59bc4c19d53bdac61ec952c01c6e864f5f0f8367
- https://git.kernel.org/stable/c/81939c4fbc2d5c754d0f1c1f05149d4b70d751ed
- https://git.kernel.org/stable/c/8245e7d1d7f75a9255ad1e8146752e5051d528b8
- https://git.kernel.org/stable/c/ca3fc1c38e4253bc019881301a28ea60b8b0bca3
- https://git.kernel.org/stable/c/d24d7bb2cd947676f9b71fb944d045e09b8b282f
- https://git.kernel.org/stable/c/ec56f886f3bf0f15f7a3844d4c025e165b8e8de7
- https://git.kernel.org/stable/c/f6ed634eedb1a8a6a8cb110a7695c7abb70ffcbf
Modified: 2025-12-23
CVE-2022-50020
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid resizing to a partial cluster size This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUG_ON and leaves the fs with a corrupted in-memory superblock.
- https://git.kernel.org/stable/c/0082e99a9074ff88eff729c70c93454c8588d8e1
- https://git.kernel.org/stable/c/69cb8e9d8cd97cdf5e293b26d70a9dee3e35e6bd
- https://git.kernel.org/stable/c/72b850a2a996f72541172e7cf686d54a2b29bcd8
- https://git.kernel.org/stable/c/7bdfb01fc5f6b3696728aeb527c50386e0ee09a1
- https://git.kernel.org/stable/c/80288883294c5b4ed18bae0d8bd9c4a12f297074
- https://git.kernel.org/stable/c/a6805b3dcf5cd41f2ae3a03dca43411135b99849
Modified: 2025-11-13
CVE-2022-50021
In the Linux kernel, the following vulnerability has been resolved:
ext4: block range must be validated before use in ext4_mb_clear_bb()
Block range to free is validated in ext4_free_blocks() using
ext4_inode_block_valid() and then it's passed to ext4_mb_clear_bb().
However in some situations on bigalloc file system the range might be
adjusted after the validation in ext4_free_blocks() which can lead to
troubles on corrupted file systems such as one found by syzkaller that
resulted in the following BUG
kernel BUG at fs/ext4/ext4.h:3319!
PREEMPT SMP NOPTI
CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
RIP: 0010:ext4_free_blocks+0x95e/0xa90
Call Trace:
Modified: 2025-11-13
CVE-2022-50022
In the Linux kernel, the following vulnerability has been resolved: drivers:md:fix a potential use-after-free bug In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and may cause sh to be released. However, sh is subsequently used in lines 2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an use-after-free bug. It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of the function.
- https://git.kernel.org/stable/c/09cf99bace7789d91caa8d10fbcfc8b2fb35857f
- https://git.kernel.org/stable/c/104212471b1c1817b311771d817fb692af983173
- https://git.kernel.org/stable/c/5d8325fd15892c8ab1146edc1d7ed8463de39636
- https://git.kernel.org/stable/c/7470a4314b239e9a9580f248fdf4c9a92805490e
- https://git.kernel.org/stable/c/d9b94c3ace549433de8a93eeb27b0391fc8ac406
- https://git.kernel.org/stable/c/e5b3dd2d92c4511e81f6e4ec9c5bb7ad25e03d13
- https://git.kernel.org/stable/c/eb3a4f73f43f839df981dda5859e8e075067a360
- https://git.kernel.org/stable/c/f5d46f1b47f65da1faf468277b261eb78c8e25b5
Modified: 2025-11-13
CVE-2022-50023
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-axi-dmac: ignore interrupt if no descriptor If the channel has no descriptor and the interrupt is raised then the kernel will OOPS. Check the result of vchan_next_desc() in the handler axi_chan_block_xfer_complete() to avoid the error happening.
Modified: 2025-11-13
CVE-2022-50024
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-axi-dmac: do not print NULL LLI during error During debugging we have seen an issue where axi_chan_dump_lli() is passed a NULL LLI pointer which ends up causing an OOPS due to trying to get fields from it. Simply print NULL LLI and exit to avoid this.
Modified: 2025-11-13
CVE-2022-50025
In the Linux kernel, the following vulnerability has been resolved: cxl: Fix a memory leak in an error handling path A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the error handling path of afu_allocate_irqs().
- https://git.kernel.org/stable/c/3a15b45b5454da862376b5d69a4967f5c6fa1368
- https://git.kernel.org/stable/c/4be138bcd6d68cec0ce47051b117541061f5141a
- https://git.kernel.org/stable/c/6544ff559315498ad6c0a311359ca44987f9ca07
- https://git.kernel.org/stable/c/695af60af755873399ce01cb97176768828bc1fd
- https://git.kernel.org/stable/c/89d51dc6878c47b6400922fac21b6a33f9d1a588
- https://git.kernel.org/stable/c/addff638c41753639368c252d0c5ba0d8fe9ed97
- https://git.kernel.org/stable/c/c2557780ee7818b701681c226fa4cb7c0b171665
- https://git.kernel.org/stable/c/c2c7a29f99788e9e5dfe41d16868ea33da7cc235
Modified: 2025-11-13
CVE-2022-50026
In the Linux kernel, the following vulnerability has been resolved: habanalabs/gaudi: fix shift out of bounds When validating NIC queues, queue offset calculation must be performed only for NIC queues.
Modified: 2025-11-13
CVE-2022-50027
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe. If ret_val is non-zero, then free the iocbq request structure.
Modified: 2025-11-13
CVE-2022-50028
In the Linux kernel, the following vulnerability has been resolved: gadgetfs: ep_io - wait until IRQ finishes after usb_ep_queue() if wait_for_completion_interruptible() is interrupted we need to wait until IRQ gets finished. Otherwise complete() from epio_complete() can corrupt stack.
- https://git.kernel.org/stable/c/04cb742d4d8f30dc2e83b46ac317eec09191c68e
- https://git.kernel.org/stable/c/118d967ce00a3d128bf731b35e4e2cb0facf5f00
- https://git.kernel.org/stable/c/2b06d5d97c0e067108a122986767731d40742138
- https://git.kernel.org/stable/c/67a4874461422e633236a0286a01b483cd647113
- https://git.kernel.org/stable/c/77040efe59a141286d090c8a0d37c65a355a1832
- https://git.kernel.org/stable/c/94aadba8d000d5de56af4ce8da3f334f21bf7a79
- https://git.kernel.org/stable/c/9ac14f973cb91f0c01776517e6d50981f32b8038
- https://git.kernel.org/stable/c/ca06b4cde54f8ec8be3aa53fd339bd56e62c12b3
Modified: 2025-11-13
CVE-2022-50029
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: ipq8074: dont disable gcc_sleep_clk_src Once the usb sleep clocks are disabled, clock framework is trying to disable the sleep clock source also. However, it seems that it cannot be disabled and trying to do so produces: [ 245.436390] ------------[ cut here ]------------ [ 245.441233] gcc_sleep_clk_src status stuck at 'on' [ 245.441254] WARNING: CPU: 2 PID: 223 at clk_branch_wait+0x130/0x140 [ 245.450435] Modules linked in: xhci_plat_hcd xhci_hcd dwc3 dwc3_qcom leds_gpio [ 245.456601] CPU: 2 PID: 223 Comm: sh Not tainted 5.18.0-rc4 #215 [ 245.463889] Hardware name: Xiaomi AX9000 (DT) [ 245.470050] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 245.474307] pc : clk_branch_wait+0x130/0x140 [ 245.481073] lr : clk_branch_wait+0x130/0x140 [ 245.485588] sp : ffffffc009f2bad0 [ 245.489838] x29: ffffffc009f2bad0 x28: ffffff8003e6c800 x27: 0000000000000000 [ 245.493057] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800226ef20 [ 245.500175] x23: ffffffc0089ff550 x22: 0000000000000000 x21: ffffffc008476ad0 [ 245.507294] x20: 0000000000000000 x19: ffffffc00965ac70 x18: fffffffffffc51a7 [ 245.514413] x17: 68702e3030303837 x16: 3a6d726f6674616c x15: ffffffc089f2b777 [ 245.521531] x14: ffffffc0095c9d18 x13: 0000000000000129 x12: 0000000000000129 [ 245.528649] x11: 00000000ffffffea x10: ffffffc009621d18 x9 : 0000000000000001 [ 245.535767] x8 : 0000000000000001 x7 : 0000000000017fe8 x6 : 0000000000000001 [ 245.542885] x5 : ffffff803fdca6d8 x4 : 0000000000000000 x3 : 0000000000000027 [ 245.550002] x2 : 0000000000000027 x1 : 0000000000000023 x0 : 0000000000000026 [ 245.557122] Call trace: [ 245.564229] clk_branch_wait+0x130/0x140 [ 245.566490] clk_branch2_disable+0x2c/0x40 [ 245.570656] clk_core_disable+0x60/0xb0 [ 245.574561] clk_core_disable+0x68/0xb0 [ 245.578293] clk_disable+0x30/0x50 [ 245.582113] dwc3_qcom_remove+0x60/0xc0 [dwc3_qcom] [ 245.585588] platform_remove+0x28/0x60 [ 245.590361] device_remove+0x4c/0x80 [ 245.594179] device_release_driver_internal+0x1dc/0x230 [ 245.597914] device_driver_detach+0x18/0x30 [ 245.602861] unbind_store+0xec/0x110 [ 245.607027] drv_attr_store+0x24/0x40 [ 245.610847] sysfs_kf_write+0x44/0x60 [ 245.614405] kernfs_fop_write_iter+0x128/0x1c0 [ 245.618052] new_sync_write+0xc0/0x130 [ 245.622391] vfs_write+0x1d4/0x2a0 [ 245.626123] ksys_write+0x58/0xe0 [ 245.629508] __arm64_sys_write+0x1c/0x30 [ 245.632895] invoke_syscall.constprop.0+0x5c/0x110 [ 245.636890] do_el0_svc+0xa0/0x150 [ 245.641488] el0_svc+0x18/0x60 [ 245.644872] el0t_64_sync_handler+0xa4/0x130 [ 245.647914] el0t_64_sync+0x174/0x178 [ 245.652340] ---[ end trace 0000000000000000 ]--- So, add CLK_IS_CRITICAL flag to the clock so that the kernel won't try to disable the sleep clock.
- https://git.kernel.org/stable/c/17d58499dc9c7e059dab7d170e9bae1e7e9c561b
- https://git.kernel.org/stable/c/1bf7305e79aab095196131bdc87a97796e0e3fac
- https://git.kernel.org/stable/c/38cee0d2b65eed42a44052de1bfdc0177b6c3f05
- https://git.kernel.org/stable/c/4203b76abe539f3cac258d4cf1e16e2dd95ea60f
- https://git.kernel.org/stable/c/459411b9f0180e3f382d7abfa3028dd3285984c3
- https://git.kernel.org/stable/c/6b90ab952401bd6c1a321dcfc0e0df080f2bc905
- https://git.kernel.org/stable/c/d401611a93b332914cf91eb9bc0b63fa1bdc17e9
Modified: 2025-11-13
CVE-2022-50030
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input Malformed user input to debugfs results in buffer overflow crashes. Adapt input string lengths to fit within internal buffers, leaving space for NULL terminators.
- https://git.kernel.org/stable/c/2d544e9d19c109dfe34b3dc1253a8b2971abe060
- https://git.kernel.org/stable/c/927907f1cbb3408cadde637fccfc17bb6b10a87d
- https://git.kernel.org/stable/c/b92506dc51f81741eb26609175ac206c20f06e0a
- https://git.kernel.org/stable/c/c29a4baaad38a332c0ae480cf6d6c5bf75ac1828
- https://git.kernel.org/stable/c/f8191d40aa612981ce897e66cda6a88db8df17bb
Modified: 2025-11-13
CVE-2022-50032
In the Linux kernel, the following vulnerability has been resolved: usb: renesas: Fix refcount leak bug In usbhs_rza1_hardware_init(), of_find_node_by_name() 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/36b18b777dece704b7c2e9e7947ca41a9b0fb009
- https://git.kernel.org/stable/c/5c4b699193eba51f1bbf462d758d66f545fddd35
- https://git.kernel.org/stable/c/9790a5a4f07f38a5add85ec58c44797d3a7c3677
- https://git.kernel.org/stable/c/9d6d5303c39b8bc182475b22f45504106a07f086
- https://git.kernel.org/stable/c/cfa8f707a58d68b2341a9dd0b33cf048f0628b4d
- https://git.kernel.org/stable/c/fbdbd61a36d887e00114321c6758e359e9573a8e
Modified: 2025-11-13
CVE-2022-50033
In the Linux kernel, the following vulnerability has been resolved: usb: host: ohci-ppc-of: Fix refcount leak bug In ohci_hcd_ppc_of_probe(), 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/0334d23c56ecf1ee1563bb83e29cc5a51ed7fb4e
- https://git.kernel.org/stable/c/0fc62bbc95319bbd330e3645afc7c286acec9ef8
- https://git.kernel.org/stable/c/403132881e66db7aa98b55c6655daedd80d407fd
- https://git.kernel.org/stable/c/40a959d7042bb7711e404ad2318b30e9f92c6b9b
- https://git.kernel.org/stable/c/c5c5bd5cdcc6dc9f75f53d1c89af463d39a2bb96
- https://git.kernel.org/stable/c/cb5dd65e889163e723df1c2f02288cc527a57785
- https://git.kernel.org/stable/c/ec583e300aee9f152a64911445092d18e1c36729
- https://git.kernel.org/stable/c/fe6fe64403710287f0ae61a516954d8a4f7c9e3f
Modified: 2025-11-13
CVE-2022-50034
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3 fix use-after-free at workaround 2 BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xac cdns3_wa2_remove_old_request() { ... kfree(priv_req->request.buf); cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ^^^ use after free ... } cdns3_gadget_ep_free_request() free the space pointed by priv_req, but priv_req is used in the following list_del_init(). This patch move list_del_init() before cdns3_gadget_ep_free_request().
- https://git.kernel.org/stable/c/6d7ac60098b206d0472475b666cb09d556bec03d
- https://git.kernel.org/stable/c/6fd50446e7c9a98b4bcf96815f5c9602a16ea472
- https://git.kernel.org/stable/c/7d602f30149a117eea260208b1661bc404c21dfd
- https://git.kernel.org/stable/c/c3c1dbad3a2db32ecf371c97f2058491b8ba0f9a
- https://git.kernel.org/stable/c/e65d9b7147d7be3504893ca7dfb85286bda83d40
Modified: 2025-11-13
CVE-2022-50036
In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: dsi: Prevent underflow when computing packet sizes Currently, the packet overhead is subtracted using unsigned arithmetic. With a short sync pulse, this could underflow and wrap around to near the maximal u16 value. Fix this by using signed subtraction. The call to max() will correctly handle any negative numbers that are produced. Apply the same fix to the other timings, even though those subtractions are less likely to underflow.
Modified: 2025-11-13
CVE-2022-50038
In the Linux kernel, the following vulnerability has been resolved: drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors() In this function, there are two refcount leak bugs: (1) when breaking out of for_each_endpoint_of_node(), we need call the of_node_put() for the 'ep'; (2) we should call of_node_put() for the reference returned by of_graph_get_remote_port() when it is not used anymore.
- https://git.kernel.org/stable/c/3aa710e96747c8b4e52ba12ffe09edcb2755897c
- https://git.kernel.org/stable/c/6a758f0ba11699837af9e1a0f7cbac6ef765a23e
- https://git.kernel.org/stable/c/8dec38e19f6928235d4009ce55f7add8af34e5c7
- https://git.kernel.org/stable/c/91b3c8dbe898df158fd2a84675f3a284ff6666f7
- https://git.kernel.org/stable/c/d58ef256781398ad115aef44de0a02ad27ea6c3a
- https://git.kernel.org/stable/c/fc1fc2abfcb9235d0ece9a4d858426fb617cfa66
- https://git.kernel.org/stable/c/fe71d84c1a6c0d54657431e8eeaefc9d24895304
Modified: 2025-11-13
CVE-2022-50039
In the Linux kernel, the following vulnerability has been resolved: stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove() Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove paths") removed this clk_disable_unprepare() This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock handling on remove path") which removed this clk_disable_unprepare() because: " While unloading the dwmac-intel driver, clk_disable_unprepare() is being called twice in stmmac_dvr_remove() and intel_eth_pci_remove(). This causes kernel panic on the second call. " However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver") has updated stmmac_dvr_remove() which do not call clk_disable_unprepare() anymore. So this call should now be called from intel_eth_pci_remove().
Modified: 2025-11-13
CVE-2022-50040
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions() If an error occurs in dsa_devlink_region_create(), then 'priv->regions' array will be accessed by negative index '-1'. Found by Linux Verification Center (linuxtesting.org) with SVACE.
Modified: 2025-11-13
CVE-2022-50041
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix call trace with null VSI during VF reset
During stress test with attaching and detaching VF from KVM and
simultaneously changing VFs spoofcheck and trust there was a
call trace in ice_reset_vf that VF's VSI is null.
[145237.352797] WARNING: CPU: 46 PID: 840629 at drivers/net/ethernet/intel/ice/ice_vf_lib.c:508 ice_reset_vf+0x3d6/0x410 [ice]
[145237.352851] Modules linked in: ice(E) vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio iavf dm_mod xt_CHECKSUM xt_MASQUERADE
xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun
bridge stp llc sunrpc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iTCO_wdt iTC
O_vendor_support irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl ipmi_si intel_cstate ipmi_devintf joydev intel_uncore m
ei_me ipmi_msghandler i2c_i801 pcspkr mei lpc_ich ioatdma i2c_smbus acpi_pad acpi_power_meter ip_tables xfs libcrc32c i2c_algo_bit drm_sh
mem_helper drm_kms_helper sd_mod t10_pi crc64_rocksoft syscopyarea crc64 sysfillrect sg sysimgblt fb_sys_fops drm i40e ixgbe ahci libahci
libata crc32c_intel mdio dca wmi fuse [last unloaded: ice]
[145237.352917] CPU: 46 PID: 840629 Comm: kworker/46:2 Tainted: G S W I E 5.19.0-rc6+ #24
[145237.352921] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[145237.352923] Workqueue: ice ice_service_task [ice]
[145237.352948] RIP: 0010:ice_reset_vf+0x3d6/0x410 [ice]
[145237.352984] Code: 30 ec f3 cc e9 28 fd ff ff 0f b7 4b 50 48 c7 c2 48 19 9c c0 4c 89 ee 48 c7 c7 30 fe 9e c0 e8 d1 21 9d cc 31 c0 e9 a
9 fe ff ff <0f> 0b b8 ea ff ff ff e9 c1 fc ff ff 0f 0b b8 fb ff ff ff e9 91 fe
[145237.352987] RSP: 0018:ffffb453e257fdb8 EFLAGS: 00010246
[145237.352990] RAX: ffff8bd0040181c0 RBX: ffff8be68db8f800 RCX: 0000000000000000
[145237.352991] RDX: 000000000000ffff RSI: 0000000000000000 RDI: ffff8be68db8f800
[145237.352993] RBP: ffff8bd0040181c0 R08: 0000000000001000 R09: ffff8bcfd520e000
[145237.352995] R10: 0000000000000000 R11: 00008417b5ab0bc0 R12: 0000000000000005
[145237.352996] R13: ffff8bcee061c0d0 R14: ffff8bd004019640 R15: 0000000000000000
[145237.352998] FS: 0000000000000000(0000) GS:ffff8be5dfb00000(0000) knlGS:0000000000000000
[145237.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[145237.353002] CR2: 00007fd81f651d68 CR3: 0000001a0fe10001 CR4: 00000000001726e0
[145237.353003] Call Trace:
[145237.353008]
Modified: 2025-11-13
CVE-2022-50042
In the Linux kernel, the following vulnerability has been resolved: net: genl: fix error path memory leak in policy dumping If construction of the array of policies fails when recording non-first policy we need to unwind. netlink_policy_dump_add_policy() itself also needs fixing as it currently gives up on error without recording the allocated pointer in the pstate pointer.
Modified: 2025-11-13
CVE-2022-50043
In the Linux kernel, the following vulnerability has been resolved: net: fix potential refcount leak in ndisc_router_discovery() The issue happens on specific paths in the function. After both the object `rt` and `neigh` are grabbed successfully, when `lifetime` is nonzero but the metric needs change, the function just deletes the route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh` again if above conditions hold. The function simply overwrite `neigh` if succeeds or returns if fails, without decreasing the reference count of previous `neigh`. This may result in memory leaks. Fix it by decrementing the reference count of `neigh` in place.
Modified: 2025-11-13
CVE-2022-50044
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: start MHI channel after endpoit creation MHI channel may generates event/interrupt right after enabling. It may leads to 2 race conditions issues. 1) Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return; Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at this moment. In this situation qrtr-ns will be unable to enumerate services in device. --------------------------------------------------------------- 2) Such event may come at the moment after dev_set_drvdata() and before qrtr_endpoint_register(). In this case kernel will panic with accessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd); Because endpoint is not created yet. -------------------------------------------------------------- So move mhi_prepare_for_transfer_autoqueue after endpoint creation to fix it.
Modified: 2025-11-13
CVE-2022-50046
In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change() The issue happens on some error handling paths. When the function fails to grab the object `xprt`, it simply returns 0, forgetting to decrease the reference count of another object `xps`, which is increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount leaks. Also, the function forgets to check whether `xps` is valid before using it, which may result in NULL-dereferencing issues. Fix it by adding proper error handling code when either `xprt` or `xps` is NULL.
Modified: 2025-11-13
CVE-2022-50047
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6060: prevent crash on an unused port If the port isn't a CPU port nor a user port, 'cpu_dp' is a null pointer and a crash happened on dereferencing it in mv88e6060_setup_port(): [ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014 ... [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84 [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54 [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0 [ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c [ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c [ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0 [ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184 [ 9.986632] __device_attach from bus_probe_device+0x8c/0x94 [ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8 [ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c [ 10.006292] process_one_work from worker_thread+0x30/0x4b8 [ 10.012155] worker_thread from kthread+0xd4/0x10c [ 10.017238] kthread from ret_from_fork+0x14/0x3c
- https://git.kernel.org/stable/c/246bbf2f977ea36aaf41f5d24370fef433250728
- https://git.kernel.org/stable/c/92dc64e8f591425ce4dabf7d479ebf6e67fb8853
- https://git.kernel.org/stable/c/cb1753bc689c7a7f94da6eee7efc1ae6d8abb36c
- https://git.kernel.org/stable/c/dd236b62d25e44ecfa26b0910a12f8d8251aff00
- https://git.kernel.org/stable/c/f3a4b55829617cad2d36fa6524367ef629566ba6
Modified: 2025-11-13
CVE-2022-50048
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: possible module reference underflow in error path dst->ops is set on when nft_expr_clone() fails, but module refcount has not been bumped yet, therefore nft_expr_destroy() leads to module reference underflow.
Modified: 2025-11-13
CVE-2022-50049
In the Linux kernel, the following vulnerability has been resolved: ASoC: DPCM: Don't pick up BE without substream When DPCM tries to add valid BE connections at dpcm_add_paths(), it doesn't check whether the picked BE actually supports for the given stream direction. Due to that, when an asymmetric BE stream is present, it picks up wrongly and this may result in a NULL dereference at a later point where the code assumes the existence of a corresponding BE substream. This patch adds the check for the presence of the substream for the target BE for avoiding the problem above. Note that we have already some fix for non-existing BE substream at commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while applying symmetry"). But the code path we've hit recently is rather happening before the previous fix. So this patch tries to fix at picking up a BE instead of parsing BE lists.
Modified: 2025-11-13
CVE-2022-50050
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf() snprintf() returns the would-be-filled size when the string overflows the given buffer size, hence using this value may result in the buffer overflow (although it's unrealistic). This patch replaces with a safer version, scnprintf() for papering over such a potential issue.
Modified: 2025-11-13
CVE-2022-50051
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: debug: Fix potential buffer overflow by snprintf() snprintf() returns the would-be-filled size when the string overflows the given buffer size, hence using this value may result in the buffer overflow (although it's unrealistic). This patch replaces with a safer version, scnprintf() for papering over such a potential issue.
Modified: 2025-11-13
CVE-2022-50053
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix reset error handling
Do not call iavf_close in iavf_reset_task error handling. Doing so can
lead to double call of napi_disable, which can lead to deadlock there.
Removing VF would lead to iavf_remove task being stuck, because it
requires crit_lock, which is held by iavf_close.
Call iavf_disable_vf if reset fail, so that driver will clean up
remaining invalid resources.
During rapid VF resets, HW can fail to setup VF mailbox. Wrong
error handling can lead to iavf_remove being stuck with:
[ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53
...
[ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds.
[ 5267.189520] Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1
[ 5267.189764] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5267.190062] task:repro.sh state:D stack: 0 pid:11219 ppid: 8162 flags:0x00000000
[ 5267.190347] Call Trace:
[ 5267.190647]
Modified: 2025-11-13
CVE-2022-50054
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix NULL pointer dereference in iavf_get_link_ksettings
Fix possible NULL pointer dereference, due to freeing of adapter->vf_res
in iavf_init_get_resources. Previous commit introduced a regression,
where receiving IAVF_ERR_ADMIN_QUEUE_NO_WORK from iavf_get_vf_config
would free adapter->vf_res. However, netdev is still registered, so
ethtool_ops can be called. Calling iavf_get_link_ksettings with no vf_res,
will result with:
[ 9385.242676] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 9385.242683] #PF: supervisor read access in kernel mode
[ 9385.242686] #PF: error_code(0x0000) - not-present page
[ 9385.242690] PGD 0 P4D 0
[ 9385.242696] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[ 9385.242701] CPU: 6 PID: 3217 Comm: pmdalinux Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1
[ 9385.242708] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019
[ 9385.242710] RIP: 0010:iavf_get_link_ksettings+0x29/0xd0 [iavf]
[ 9385.242745] Code: 00 0f 1f 44 00 00 b8 01 ef ff ff 48 c7 46 30 00 00 00 00 48 c7 46 38 00 00 00 00 c6 46 0b 00 66 89 46 08 48 8b 87 68 0e 00 00
Modified: 2025-11-13
CVE-2022-50055
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix adminq error handling iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent memory for VF mailbox. Free DMA regions for both ASQ and ARQ in case error happens during configuration of ASQ/ARQ registers. Without this change it is possible to see when unloading interface: 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32] One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
- https://git.kernel.org/stable/c/35c63581fdefdcbaeae8cded18908523252353ad
- https://git.kernel.org/stable/c/419831617ed349992c84344dbd9e627f9e68f842
- https://git.kernel.org/stable/c/4fe80492d53971d9a49f39f3c86d2d67c6f3638a
- https://git.kernel.org/stable/c/dab6b551f5ba4c79a0dd4970dd8533c37a7b100f
- https://git.kernel.org/stable/c/ff289f2be5899efd0e897d2b434a78e36df2c69b
Modified: 2025-11-13
CVE-2022-50056
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix missing i_op in ntfs_read_mft There is null pointer dereference because i_op == NULL. The bug happens because we don't initialize i_op for records in $Extend.
Modified: 2025-11-13
CVE-2022-50057
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr
If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL.
Code should check this ptr before dereferencing. Syzbot hit this issue
via passing wrong mount param as can be seen from log below
Fail log:
ntfs3: Unknown parameter 'iochvrset'
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0
...
Call Trace:
Modified: 2025-11-13
CVE-2022-50059
In the Linux kernel, the following vulnerability has been resolved: ceph: don't leak snap_rwsem in handle_cap_grant When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is held and the function is expected to release it before returning. It currently fails to do that in all cases which could lead to a deadlock.
Modified: 2025-11-13
CVE-2022-50060
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix mcam entry resource leak The teardown sequence in FLR handler returns if no NIX LF is attached to PF/VF because it indicates that graceful shutdown of resources already happened. But there is a chance of all allocated MCAM entries not being freed by PF/VF. Hence free mcam entries even in case of detached LF.
Modified: 2025-11-13
CVE-2022-50061
In the Linux kernel, the following vulnerability has been resolved: pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map 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/4b32e054335ea0ce50967f63a7bfd4db058b14b9
- https://git.kernel.org/stable/c/587ac8ac00a1a9f4572785229d9441870fd7b187
- https://git.kernel.org/stable/c/78d05103891d3e96144b846fbc39f2cfb3384eae
- https://git.kernel.org/stable/c/81abaab5a4b815c0ed9f4d2c9745777ac5cc395b
- https://git.kernel.org/stable/c/9272265f2f76629e1a67e6d49b3a4461b3da1a73
- https://git.kernel.org/stable/c/c26012a1e61c7bbd1b393d3bbae8dffdb6df65bb
- https://git.kernel.org/stable/c/c35f89a9021fa947ecede0584ae509368a52ec5a
- https://git.kernel.org/stable/c/f498542bc703bf1e5c6a1610e1ea493a437f0196
Modified: 2025-11-13
CVE-2022-50062
In the Linux kernel, the following vulnerability has been resolved:
net: bgmac: Fix a BUG triggered by wrong bytes_compl
On one of our machines we got:
kernel BUG at lib/dynamic_queue_limits.c:27!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G W O 4.14.275-rt132 #1
Hardware name: BRCM XGS iProc
task: ee3415c0 task.stack: ee32a000
PC is at dql_completed+0x168/0x178
LR is at bgmac_poll+0x18c/0x6d8
pc : [
- https://git.kernel.org/stable/c/1b7680c6c1f6de9904f1d9b05c952f0c64a03350
- https://git.kernel.org/stable/c/ab2b55bb25db289ba0b68e3d58494476bdb1041d
- https://git.kernel.org/stable/c/ac6d4482f29ab992b605c1b4bd1347f1f679f4e4
- https://git.kernel.org/stable/c/c506c9a97120f43257e9b3ce7b1f9a24eafc3787
- https://git.kernel.org/stable/c/da1421a29d3b8681ba6a7f686bd0b40dda5acaf3
Modified: 2025-11-17
CVE-2022-50065
In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix memory leak inside XPD_TX with mergeable When we call xdp_convert_buff_to_frame() to get xdpf, if it returns NULL, we should check if xdp_page was allocated by xdp_linearize_page(). If it is newly allocated, it should be freed here alone. Just like any other "goto err_xdp".
Modified: 2025-11-17
CVE-2022-50066
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: fix aq_vec index out of range error
The final update statement of the for loop exceeds the array range, the
dereference of self->aq_vec[i] is not checked and then leads to the
index out of range error.
Also fixed this kind of coding style in other for loop.
[ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48
[ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]'
[ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2
[ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022
[ 97.937611] Workqueue: events_unbound async_run_entry_fn
[ 97.937616] Call Trace:
[ 97.937617]
Modified: 2025-11-17
CVE-2022-50067
In the Linux kernel, the following vulnerability has been resolved: btrfs: unset reloc control if transaction commit fails in prepare_to_relocate() In btrfs_relocate_block_group(), the rc is allocated. Then btrfs_relocate_block_group() calls relocate_block_group() prepare_to_relocate() set_reloc_control() that assigns rc to the variable fs_info->reloc_ctl. When prepare_to_relocate() returns, it calls btrfs_commit_transaction() btrfs_start_dirty_block_groups() btrfs_alloc_path() kmem_cache_zalloc() which may fail for example (or other errors could happen). When the failure occurs, btrfs_relocate_block_group() detects the error and frees rc and doesn't set fs_info->reloc_ctl to NULL. After that, in btrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl and then used, which may cause a use-after-free bug. This possible bug can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag(). To fix this possible bug, in prepare_to_relocate(), check if btrfs_commit_transaction() fails. If the failure occurs, unset_reloc_control() is called to set fs_info->reloc_ctl to NULL. The error log in our fault-injection testing is shown as follows: [ 58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs] ... [ 58.753577] Call Trace: ... [ 58.755800] kasan_report+0x45/0x60 [ 58.756066] btrfs_init_reloc_root+0x7ca/0x920 [btrfs] [ 58.757304] record_root_in_trans+0x792/0xa10 [btrfs] [ 58.757748] btrfs_record_root_in_trans+0x463/0x4f0 [btrfs] [ 58.758231] start_transaction+0x896/0x2950 [btrfs] [ 58.758661] btrfs_defrag_root+0x250/0xc00 [btrfs] [ 58.759083] btrfs_ioctl_defrag+0x467/0xa00 [btrfs] [ 58.759513] btrfs_ioctl+0x3c95/0x114e0 [btrfs] ... [ 58.768510] Allocated by task 23683: [ 58.768777] ____kasan_kmalloc+0xb5/0xf0 [ 58.769069] __kmalloc+0x227/0x3d0 [ 58.769325] alloc_reloc_control+0x10a/0x3d0 [btrfs] [ 58.769755] btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs] [ 58.770228] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.770655] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.771071] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.771472] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.771902] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ... [ 58.773337] Freed by task 23683: ... [ 58.774815] kfree+0xda/0x2b0 [ 58.775038] free_reloc_control+0x1d6/0x220 [btrfs] [ 58.775465] btrfs_relocate_block_group+0x115c/0x1e20 [btrfs] [ 58.775944] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.776369] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.776784] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.777185] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.777621] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ...
- https://git.kernel.org/stable/c/5d741afed0bac206640cc64d77b97853283cf719
- https://git.kernel.org/stable/c/78f8c2370e3d33e35f23bdc648653d779aeacb6e
- https://git.kernel.org/stable/c/85f02d6c856b9f3a0acf5219de6e32f58b9778eb
- https://git.kernel.org/stable/c/8e546674031fc1576da501e27a8fd165222e5a37
- https://git.kernel.org/stable/c/b60e862e133f646f19023ece1d476d630a660de1
- https://git.kernel.org/stable/c/dcb11fe0a0a9cca2b7425191b9bf30dc29f2ad0f
- https://git.kernel.org/stable/c/ff0e8ed8dfb584575cffc1561f17a1d094e8565b
Modified: 2025-11-17
CVE-2022-50068
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix dummy res NULL ptr deref bug
Check the bo->resource value before accessing the resource
mem_type.
v2: Fix commit description unwrapped warning
Modified: 2025-11-17
CVE-2022-50069
In the Linux kernel, the following vulnerability has been resolved:
BPF: Fix potential bad pointer dereference in bpf_sys_bpf()
The bpf_sys_bpf() helper function allows an eBPF program to load another
eBPF program from within the kernel. In this case the argument union
bpf_attr pointer (as well as the insns and license pointers inside) is a
kernel address instead of a userspace address (which is the case of a
usual bpf() syscall). To make the memory copying process in the syscall
work in both cases, bpfptr_t was introduced to wrap around the pointer
and distinguish its origin. Specifically, when copying memory contents
from a bpfptr_t, a copy_from_user() is performed in case of a userspace
address and a memcpy() is performed for a kernel address.
This can lead to problems because the in-kernel pointer is never checked
for validity. The problem happens when an eBPF syscall program tries to
call bpf_sys_bpf() to load a program but provides a bad insns pointer --
say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()
which would then call bpf_prog_load() to load the program.
bpf_prog_load() is responsible for copying the eBPF instructions to the
newly allocated memory for the program; it creates a kernel bpfptr_t for
insns and invokes copy_from_bpfptr(). Internally, all bpfptr_t
operations are backed by the corresponding sockptr_t operations, which
performs direct memcpy() on kernel pointers for copy_from/strncpy_from
operations. Therefore, the code is always happy to dereference the bad
pointer to trigger a un-handle-able page fault and in turn an oops.
However, this is not supposed to happen because at that point the eBPF
program is already verified and should not cause a memory error.
Sample KASAN trace:
[ 25.685056][ T228] ==================================================================
[ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30
[ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228
[ 25.686732][ T228]
[ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7
[ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014
[ 25.687991][ T228] Call Trace:
[ 25.688223][ T228]
Modified: 2025-11-17
CVE-2022-50070
In the Linux kernel, the following vulnerability has been resolved:
mptcp: do not queue data on closed subflows
Dipanjan reported a syzbot splat at close time:
WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153
inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Modules linked in: uio_ivshmem(OE) uio(E)
CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE
5.19.0-rc6-g2eae0556bb9d #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91
f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b
e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d
RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00
RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002
RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000
R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400
R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258
FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0
Call Trace:
Modified: 2025-11-17
CVE-2022-50071
In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.
Modified: 2025-11-17
CVE-2022-50072
In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: Fix a use-after-free bug in open If someone cancels the open RPC call, then we must not try to free either the open slot or the layoutget operation arguments, since they are likely still in use by the hung RPC call.
- https://git.kernel.org/stable/c/0fffb46ff3d5ed4668aca96441ec7a25b793bd6f
- https://git.kernel.org/stable/c/2135e5d56278ffdb1c2e6d325dc6b87f669b9dac
- https://git.kernel.org/stable/c/76ffd2042438769298f34b76102b40dea89de616
- https://git.kernel.org/stable/c/a4cf3dadd1fa43609f7c6570c9116b0e0a9923d1
- https://git.kernel.org/stable/c/b03d1117e9be7c7da60e466eaf9beed85c5916c8
- https://git.kernel.org/stable/c/f7ee3b772d9de87387a725caa04bc041ac7fe5ec
Modified: 2025-11-17
CVE-2022-50073
In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30
Modified: 2025-11-17
CVE-2022-50074
In the Linux kernel, the following vulnerability has been resolved: apparmor: Fix memleak in aa_simple_write_to_buffer() When copy_from_user failed, the memory is freed by kvfree. however the management struct and data blob are allocated independently, so only kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to fix this issue.
- https://git.kernel.org/stable/c/417ea9fe972d2654a268ad66e89c8fcae67017c3
- https://git.kernel.org/stable/c/6500eb3a48ac221051b1791818a1ac74744ef617
- https://git.kernel.org/stable/c/6583edbf459de2e06b9759f264c0ae27e452b97a
- https://git.kernel.org/stable/c/7db182a2ebeefded86fea542fcc5d6a68bb77f58
- https://git.kernel.org/stable/c/8aab4295582eb397a125d2788b829fa62b88dbf7
- https://git.kernel.org/stable/c/bf7ebebce2c25071c719fd8a2f1307e0c243c2d7
Modified: 2025-11-17
CVE-2022-50075
In the Linux kernel, the following vulnerability has been resolved: tracing/eprobes: Have event probes be consistent with kprobes and uprobes Currently, if a symbol "@" is attempted to be used with an event probe (eprobes), it will cause a NULL pointer dereference crash. Both kprobes and uprobes can reference data other than the main registers. Such as immediate address, symbols and the current task name. Have eprobes do the same thing. For "comm", if "comm" is used and the event being attached to does not have the "comm" field, then make it the "$comm" that kprobes has. This is consistent to the way histograms and filters work.
Modified: 2025-11-17
CVE-2022-50076
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak on the deferred close xfstests on smb21 report kmemleak as below: unreferenced object 0xffff8881767d6200 (size 64): comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s) hex dump (first 32 bytes): 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c.... 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .q.v............ backtrace: [<00000000ad04e6ea>] cifs_close+0x92/0x2c0 [<0000000028b93c82>] __fput+0xff/0x3f0 [<00000000d8116851>] task_work_run+0x85/0xc0 [<0000000027e14f9e>] do_exit+0x5e5/0x1240 [<00000000fb492b95>] do_group_exit+0x58/0xe0 [<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30 [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80 [<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 When cancel the deferred close work, we should also cleanup the struct cifs_deferred_close.
Modified: 2025-11-17
CVE-2022-50077
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix reference count leak in aa_pivotroot() The aa_pivotroot() function has a reference counting bug in a specific path. When aa_replace_current_label() returns on success, the function forgets to decrement the reference count of “target”, which is increased earlier by build_pivotroot(), causing a reference leak. Fix it by decreasing the refcount of “target” in that path.
- https://git.kernel.org/stable/c/11c3627ec6b56c1525013f336f41b79a983b4d46
- https://git.kernel.org/stable/c/2ceeb3296e9dde1d5772348046affcefdea605e2
- https://git.kernel.org/stable/c/3ca40ad7afae144169a43988ef1a3f16182faf0a
- https://git.kernel.org/stable/c/64103ea357734b82384c925cba4758fdb909be0c
- https://git.kernel.org/stable/c/d53194707d2a1851be027cd74266b96ceff799d3
- https://git.kernel.org/stable/c/ef6fb6f0d0d8440595b45a7e53c6162c737177f4
- https://git.kernel.org/stable/c/f4d5c7796571624e3f380b447ada52834270a287
Modified: 2025-11-17
CVE-2022-50078
In the Linux kernel, the following vulnerability has been resolved:
tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
While playing with event probes (eprobes), I tried to see what would
happen if I attempted to retrieve the instruction pointer (%rip) knowing
that event probes do not use pt_regs. The result was:
BUG: kernel NULL pointer dereference, address: 0000000000000024
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
v03.03 07/14/2016
RIP: 0010:get_event_field.isra.0+0x0/0x50
Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8
50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24
8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74
RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086
RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000
RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8
R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8
R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff916c9ea40000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0
Call Trace:
Modified: 2025-11-17
CVE-2022-50079
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check correct bounds for stream encoder instances for DCN303 [Why & How] eng_id for DCN303 cannot be more than 1, since we have only two instances of stream encoders. Check the correct boundary condition for engine ID for DCN303 prevent the potential out of bounds access.
Modified: 2025-11-18
CVE-2022-50080
In the Linux kernel, the following vulnerability has been resolved: tee: add overflow check in register_shm_helper() With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 Fix this by adding an an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early.
- https://git.kernel.org/stable/c/2f8e79a1a6128214cb9b205a9869341af5dfb16b
- https://git.kernel.org/stable/c/573ae4f13f630d6660008f1974c0a8a29c30e18a
- https://git.kernel.org/stable/c/578c349570d2a912401963783b36e0ec7a25c053
- https://git.kernel.org/stable/c/58c008d4d398f792ca67f35650610864725518fd
- https://git.kernel.org/stable/c/965333345fe952cc7eebc8e3a565ffc709441af2
- https://git.kernel.org/stable/c/b37e0f17653c00b586cdbcdf0dbca475358ecffd
- https://git.kernel.org/stable/c/c12f0e6126ad223806a365084e86370511654bf1
Modified: 2025-11-18
CVE-2022-50082
In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_iomap_begin as race between bmap and write We got issue as follows: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0 RIP: 0010:ext4_iomap_begin+0x182/0x5d0 RSP: 0018:ffff88812460fa08 EFLAGS: 00010293 RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001 R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: bmap write bmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on To solved above issue hold inode lock in ext4_bamp.
- https://git.kernel.org/stable/c/30dfb75e1f8645404a536c74d468d498adcd4e74
- https://git.kernel.org/stable/c/51ae846cff568c8c29921b1b28eb2dfbcd4ac12d
- https://git.kernel.org/stable/c/a9fe6d1e3d343d7309f501b1f48020ce7127221f
- https://git.kernel.org/stable/c/e1682c7171a6c0ff576fe8116b8cba5b8f538b94
- https://git.kernel.org/stable/c/fa6482f374fda29a71ad44d76d35b4842d43cda4
Modified: 2025-11-18
CVE-2022-50084
In the Linux kernel, the following vulnerability has been resolved:
dm raid: fix address sanitizer warning in raid_status
There is this warning when using a kernel with the address sanitizer
and running this testsuite:
https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid
==================================================================
BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.
- https://git.kernel.org/stable/c/1ae0ebfb576b72c2ef400917a5484ebe7892d80b
- https://git.kernel.org/stable/c/1fbeea217d8f297fe0e0956a1516d14ba97d0396
- https://git.kernel.org/stable/c/49dba30638e091120256a9e89125340795f034dc
- https://git.kernel.org/stable/c/4c233811a49578634d10a5e70a9dfa569d451e94
- https://git.kernel.org/stable/c/90b006da40dd42285b24dd3c940d2c32aca9a70b
- https://git.kernel.org/stable/c/b4c6c07c92b6cba2bf3cb2dfa722debeaf8a8abe
- https://git.kernel.org/stable/c/b856ce5f4b55f752144baf17e9d5c415072652c5
- https://git.kernel.org/stable/c/cb583ca6125ac64c98e9d65128e95ebb5be7d322
- https://git.kernel.org/stable/c/d8971b595d7adac3421c21f59918241f1574061e
Modified: 2025-11-18
CVE-2022-50085
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix address sanitizer warning in raid_resume There is a KASAN warning in raid_resume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length.
- https://git.kernel.org/stable/c/2a9faa704d83ff0b04387e385efd8ae21cd95af6
- https://git.kernel.org/stable/c/3bfdc95466f5be4d8d95db5a5b470d61641a7c24
- https://git.kernel.org/stable/c/50235d9a1f1f742619ed9963cb9f240e5b821d46
- https://git.kernel.org/stable/c/71f601c779b3cc1baf497796f5b922c3fe5d2a1e
- https://git.kernel.org/stable/c/74af83732a39ab7d3bc9b49219a535853e25679f
- https://git.kernel.org/stable/c/7dad24db59d2d2803576f2e3645728866a056dab
- https://git.kernel.org/stable/c/c2d47bef93fb74aa97d90f9a40ca657b8f376083
- https://git.kernel.org/stable/c/c2f075e729636a44e98d9722e3852c2fa6fa49b6
Modified: 2025-11-18
CVE-2022-50086
In the Linux kernel, the following vulnerability has been resolved: block: don't allow the same type rq_qos add more than once In our test of iocost, we encountered some list add/del corruptions of inner_walk list in ioc_timer_fn. The reason can be described as follows: cpu 0 cpu 1 ioc_qos_write ioc_qos_write ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } When the io.cost.qos file is written by two cpus concurrently, rq_qos may be added to one disk twice. In that case, there will be two iocs enabled and running on one disk. They own different iocgs on their active list. In the ioc_timer_fn function, because of the iocgs from two iocs have the same root iocg, the root iocg's walk_list may be overwritten by each other and this leads to list add/del corruptions in building or destroying the inner_walk list. And so far, the blk-rq-qos framework works in case that one instance for one type rq_qos per queue by default. This patch make this explicit and also fix the crash above.
Modified: 2025-11-18
CVE-2022-50087
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails.
- https://git.kernel.org/stable/c/08272646cd7c310642c39b7f54348fddd7987643
- https://git.kernel.org/stable/c/0c29e149b6bb498778ed8a1c9597b51acfba7856
- https://git.kernel.org/stable/c/18048cba444a7c41dbf42c180d6b46606fc24c51
- https://git.kernel.org/stable/c/4f2d7b46d6b53c07f44a4f8f8f4438888f0e9e87
- https://git.kernel.org/stable/c/5aa558232edc30468d1f35108826dd5b3ffe978f
- https://git.kernel.org/stable/c/689640efc0a2c4e07e6f88affe6d42cd40cc3f85
- https://git.kernel.org/stable/c/87c4896d5dd7fd9927c814cf3c6289f41de3b562
Modified: 2025-11-18
CVE-2022-50088
In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: fix potential memory leak in damon_reclaim_init() damon_reclaim_init() allocates a memory chunk for ctx with damon_new_ctx(). When damon_select_ops() fails, ctx is not released, which will lead to a memory leak. We should release the ctx with damon_destroy_ctx() when damon_select_ops() fails to fix the memory leak.
Modified: 2025-11-18
CVE-2022-50089
In the Linux kernel, the following vulnerability has been resolved:
btrfs: ensure pages are unlocked on cow_file_range() failure
There is a hung_task report on zoned btrfs like below.
https://github.com/naota/linux/issues/59
[726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds.
[726.329839] Not tainted 5.16.0-rc1+ #1
[726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000
[726.331608] Call Trace:
[726.331611]
Modified: 2025-11-18
CVE-2022-50090
In the Linux kernel, the following vulnerability has been resolved:
btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size
On zoned filesystem, data write out is limited by max_zone_append_size,
and a large ordered extent is split according the size of a bio. OTOH,
the number of extents to be written is calculated using
BTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve the
metadata bytes to update and/or create the metadata items.
The metadata reservation is done at e.g, btrfs_buffered_write() and then
released according to the estimation changes. Thus, if the number of extent
increases massively, the reserved metadata can run out.
The increase of the number of extents easily occurs on zoned filesystem
if BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. And, it causes the
following warning on a small RAM environment with disabling metadata
over-commit (in the following patch).
[75721.498492] ------------[ cut here ]------------
[75721.505624] BTRFS: block rsv 1 returned -28
[75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs]
[75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109
[75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021
[75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
[75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs]
[75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286
[75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000
[75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e
[75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7
[75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28
[75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a
[75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000
[75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0
[75721.730499] Call Trace:
[75721.735166]
Modified: 2025-11-18
CVE-2022-50091
In the Linux kernel, the following vulnerability has been resolved: locking/csd_lock: Change csdlock_debug from early_param to __setup The csdlock_debug kernel-boot parameter is parsed by the early_param() function csdlock_debug(). If set, csdlock_debug() invokes static_branch_enable() to enable csd_lock_wait feature, which triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n. With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a NULL dereference because mem_section is initialized only later in sparse_init(). This is also a problem for powerpc because early_param() functions are invoked earlier than jump_label_init(), also resulting in static_key_enable() failures. These failures cause the warning "static key 'xxx' used before call to jump_label_init()". Thus, early_param is too early for csd_lock_wait to run static_branch_enable(), so changes it to __setup to fix these.
Modified: 2025-11-18
CVE-2022-50092
In the Linux kernel, the following vulnerability has been resolved:
dm thin: fix use-after-free crash in dm_sm_register_threshold_callback
Fault inject on pool metadata device reports:
BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80
Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950
CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/05cef0999b3208b5a6ede1bfac855139e4de55ef
- https://git.kernel.org/stable/c/1a199fa9217d28511ff88529238fd9980ea64cf3
- https://git.kernel.org/stable/c/3534e5a5ed2997ca1b00f44a0378a075bd05e8a3
- https://git.kernel.org/stable/c/5e2cf705155a1514be3c96ea664a9cd356998ee7
- https://git.kernel.org/stable/c/e4dbe24f4bfd8377e7ba79fdcdb7c4d6eb1c6790
- https://git.kernel.org/stable/c/f83131a3071a0b61a4d7dca70f95adb3ffad920e
Modified: 2025-11-18
CVE-2022-50093
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)
KASAN reports:
[ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
[ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0
[ 4.683454][ T0]
[ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1
[ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016
[ 4.703196][ T0] Call Trace:
[ 4.706334][ T0]
- https://git.kernel.org/stable/c/0b4c0003aeda32a600f95df53b2848da8a5aa3fa
- https://git.kernel.org/stable/c/5659efdadf04b56707d58c1b758df16d2e0eff2c
- https://git.kernel.org/stable/c/73ce2046e04ad488cecc66757c36cbe1bdf089d4
- https://git.kernel.org/stable/c/b0b0b77ea611e3088e9523e60860f4f41b62b235
- https://git.kernel.org/stable/c/b12304984654d8e58a2b22ff94c4410906d6267f
- https://git.kernel.org/stable/c/c2304c50f4d94f56c2e326f25c9dc8cf2ba6f5fa
Modified: 2025-11-18
CVE-2022-50094
In the Linux kernel, the following vulnerability has been resolved: spmi: trace: fix stack-out-of-bound access in SPMI tracing functions trace_spmi_write_begin() and trace_spmi_read_end() both call memcpy() with a length of "len + 1". This leads to one extra byte being read beyond the end of the specified buffer. Fix this out-of-bound memory access by using a length of "len" instead. Here is a KASAN log showing the issue: BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314 ... Call trace: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ... addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] this frame has 1 object: [32, 33) 'status' Memory state around the buggy address: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00 ==================================================================
- https://git.kernel.org/stable/c/1e0ca3d809c36ad3d1f542917718fc22ec6316e7
- https://git.kernel.org/stable/c/2af28b241eea816e6f7668d1954f15894b45d7e3
- https://git.kernel.org/stable/c/37690cb8662cec672cacda19e6e4fd2ca7b13f0b
- https://git.kernel.org/stable/c/504090815c1ad3fd3fa34618b54d706727f8911c
- https://git.kernel.org/stable/c/80f7c93e573ea9f524924bb529c2af8cb28b1c43
- https://git.kernel.org/stable/c/ac730c72bddc889f5610d51d8a7abf425e08da1a
- https://git.kernel.org/stable/c/bcc1b6b1ed3f42ed25858c1f1eb24a2f741db93f
- https://git.kernel.org/stable/c/dc6033a7761254e5a5ba7df36b64db787a53313c
- https://git.kernel.org/stable/c/dd02510fb43168310abfd0b9ccf49993a722fb91
Modified: 2025-11-18
CVE-2022-50095
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Cleanup CPU timers before freeing them during exec Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") started looking up tasks by PID when deleting a CPU timer. When a non-leader thread calls execve, it will switch PIDs with the leader process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find the task because the timer still points out to the old PID. That means that armed timers won't be disarmed, that is, they won't be removed from the timerqueue_list. exit_itimers will still release their memory, and when that list is later processed, it leads to a use-after-free. Clean up the timers from the de-threaded task before freeing them. This prevents a reported use-after-free.
- https://git.kernel.org/stable/c/541840859ace9c2ccebc32fa9e376c7bd3def490
- https://git.kernel.org/stable/c/9e255ed238fc67058df87b0388ad6d4b2ef3a2bd
- https://git.kernel.org/stable/c/b2fc1723eb65abb83e00d5f011de670296af0b28
- https://git.kernel.org/stable/c/e362359ace6f87c201531872486ff295df306d13
- https://git.kernel.org/stable/c/e8cb6e8fd9890780f1bfcf5592889e1b879e779c
Modified: 2025-11-19
CVE-2022-50096
In the Linux kernel, the following vulnerability has been resolved: x86/kprobes: Update kcb status flag after singlestepping Fix kprobes to update kcb (kprobes control block) status flag to KPROBE_HIT_SSDONE even if the kp->post_handler is not set. This bug may cause a kernel panic if another INT3 user runs right after kprobes because kprobe_int3_handler() misunderstands the INT3 is kprobe's single stepping INT3.
- https://git.kernel.org/stable/c/1cbf3882cb372bbe752efd7c3045ca1c9ab40ac6
- https://git.kernel.org/stable/c/663cdda2716b70751df9c7e60b81bd0850fdfe3c
- https://git.kernel.org/stable/c/b9c3401f7cac6ae291a16784dadcd1bf116218fe
- https://git.kernel.org/stable/c/dec8784c9088b131a1523f582c2194cfc8107dc0
- https://git.kernel.org/stable/c/edc2ac7c7265b33660fa0190898966b49966b855
Modified: 2025-11-19
CVE-2022-50097
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: s3fb: Check the size of screen before memset_io() In the function s3fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000 [ 54.083742] #PF: supervisor write access in kernel mode [ 54.083744] #PF: error_code(0x0002) - not-present page [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Call Trace: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Fix the this by checking the value of 'screen_size' before memset_io().
- https://git.kernel.org/stable/c/3c35a0dc2b4e7acf24c796043b64fa3eee799239
- https://git.kernel.org/stable/c/52461d387cc8c8f8dc40320caa2e9e101f73e7ba
- https://git.kernel.org/stable/c/574912261528589012b61f82d368256247c3a5a8
- https://git.kernel.org/stable/c/5e0da18956d38e7106664dc1d06367b22f06edd3
- https://git.kernel.org/stable/c/6ba592fa014f21f35a8ee8da4ca7b95a018f13e8
- https://git.kernel.org/stable/c/ce50d94afcb8690813c5522f24cd38737657db81
- https://git.kernel.org/stable/c/e2d7cacc6a2a1d77e7e20a492daf458a12cf19e0
- https://git.kernel.org/stable/c/eacb50f1733660911827d7c3720f4c5425d0cdda
Modified: 2025-11-19
CVE-2022-50098
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path. Following crash stack was seen: BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390
Modified: 2025-11-19
CVE-2022-50099
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: arkfb: Check the size of screen before memset_io() In the function arkfb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000 [ 659.399077] #PF: supervisor write access in kernel mode [ 659.399079] #PF: error_code(0x0002) - not-present page [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0 [ 659.399116] Call Trace: [ 659.399122] arkfb_set_par+0x143f/0x24c0 [ 659.399130] fb_set_var+0x604/0xeb0 [ 659.399161] do_fb_ioctl+0x234/0x670 [ 659.399189] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io().
- https://git.kernel.org/stable/c/0701df594bc1d7ae55fed407fb65dd90a93f8a9c
- https://git.kernel.org/stable/c/09e733d6ac948e6fda4b16252e44ea46f98fc8b4
- https://git.kernel.org/stable/c/2ce61c39c2a0b8ec82f48e0f7136f0dac105ae75
- https://git.kernel.org/stable/c/352305ea50d682b8e081d826da53caf9e744d7d0
- https://git.kernel.org/stable/c/4a20c5510aa2c031a096a58deb356e91609781c9
- https://git.kernel.org/stable/c/53198b81930e567ad6b879812d88052a1e8ac79e
- https://git.kernel.org/stable/c/8bcb1a06e3091716b7cbebe0e91d1de9895068cd
- https://git.kernel.org/stable/c/96b550971c65d54d64728d8ba973487878a06454
Modified: 2025-11-19
CVE-2022-50100
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Do not requeue task on CPU excluded from cpus_mask
The following warning was triggered on a large machine early in boot on
a distribution kernel but the same problem should also affect mainline.
WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440
Call Trace:
Modified: 2025-11-19
CVE-2022-50101
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: vt8623fb: Check the size of screen before memset_io() In the function vt8623fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000 [ 583.339049] #PF: supervisor write access in kernel mode [ 583.339052] #PF: error_code(0x0002) - not-present page [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0 [ 583.339110] Call Trace: [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0 [ 583.339146] fb_set_var+0x604/0xeb0 [ 583.339181] do_fb_ioctl+0x234/0x670 [ 583.339209] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io().
- https://git.kernel.org/stable/c/4a3cef1eaced13ba9b55381d46bfad937a3dac2c
- https://git.kernel.org/stable/c/52ad9bfeb8a0e62de30de6d39e8a49a72dd78150
- https://git.kernel.org/stable/c/73280a184aa2e1a625ce54ce761042955cc79cd0
- https://git.kernel.org/stable/c/b17caec5127bba6f90af92bcc85871df54548ac0
- https://git.kernel.org/stable/c/bd8269e57621e5b38cc0b4bd2fa02e85c9f2a441
- https://git.kernel.org/stable/c/c7a3f41e4b133d4dd25bc996b69039b19a34d69d
- https://git.kernel.org/stable/c/d71528ccdc7ae8d7500d414091d27805c51407a2
- https://git.kernel.org/stable/c/ec0754c60217248fa77cc9005d66b2b55200ac06
Modified: 2025-11-19
CVE-2022-50102
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock() Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug in: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul); with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0. and then in: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock); we'll get a division-by-zero. The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline] RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of ark_set_pixclock() first.
- https://git.kernel.org/stable/c/0288fa799e273b08839037499d704dc7bdc13e9a
- https://git.kernel.org/stable/c/15661642511b2b192077684a89f42a8d95d54286
- https://git.kernel.org/stable/c/236c1502520b7b08955467ec2e50b3232e34f1f9
- https://git.kernel.org/stable/c/2f1c4523f7a3aaabe7e53d3ebd378292947e95c8
- https://git.kernel.org/stable/c/76b3f0a0b56e53a960a14624a0f48b3d94b5e7e7
- https://git.kernel.org/stable/c/9ebc5031958c1f3a2795e4533b4091d77c738d14
- https://git.kernel.org/stable/c/a249e1b89ca25e1c34bdf96154e3f6224a91a9af
- https://git.kernel.org/stable/c/b9a66f23612b84617e04412169e155a4b92f632d
Modified: 2025-11-19
CVE-2022-50103
In the Linux kernel, the following vulnerability has been resolved: sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed With cgroup v2, the cpuset's cpus_allowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpuset_can_attach() can call task_can_attach() with an empty mask. This can lead to cpumask_any_and() returns nr_cpu_ids causing the call to dl_bw_of() to crash due to percpu value access of an out of bound CPU value. For example: [80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpuset_can_attach+0xa0/0x140 [80468.209953] cgroup_migrate_execute+0x8c/0x490 [80468.210931] cgroup_update_dfl_csses+0x254/0x270 [80468.211898] cgroup_subtree_control_write+0x322/0x400 [80468.212854] kernfs_fop_write_iter+0x11c/0x1b0 [80468.213777] new_sync_write+0x11f/0x1b0 [80468.214689] vfs_write+0x1eb/0x280 [80468.215592] ksys_write+0x5f/0xe0 [80468.216463] do_syscall_64+0x5c/0x80 [80468.224287] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix that by using effective_cpus instead. For cgroup v1, effective_cpus is the same as cpus_allowed. For v2, effective_cpus is the real cpumask to be used by tasks within the cpuset anyway. Also update task_can_attach()'s 2nd argument name to cs_effective_cpus to reflect the change. In addition, a check is added to task_can_attach() to guard against the possibility that cpumask_any_and() may return a value >= nr_cpu_ids.
- https://git.kernel.org/stable/c/147f66d22f58712dce7ccdd6a1f6cb3ee8042df4
- https://git.kernel.org/stable/c/336626564b58071b8980a4e6a31a8f5d92705d9b
- https://git.kernel.org/stable/c/357f3f0e522a6ce1ce4a571cb780d9861d53bec7
- https://git.kernel.org/stable/c/b6e8d40d43ae4dec00c8fea2593eeea3114b8f44
- https://git.kernel.org/stable/c/f56607b44c9896e51678a7e8cdd3a5479f4b4548
Modified: 2025-11-19
CVE-2022-50104
In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: Fix refcount leak in xive_get_max_prio of_find_node_by_path() 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/255b650cbec6849443ce2e0cdd187fd5e61c218c
- https://git.kernel.org/stable/c/2e18b869a8d574cfe9ee64df9c3d0a7ac7ed07a8
- https://git.kernel.org/stable/c/5ed9709d262bf026b2ff64979fbfe0f496287588
- https://git.kernel.org/stable/c/6d1e53f7f181a11a8a343def1e0d0209905b7c64
- https://git.kernel.org/stable/c/79b8eae24b7ee157bda07695d802be8576983fa8
- https://git.kernel.org/stable/c/d99733ad47a6c990b52e136608455643bfa708f2
- https://git.kernel.org/stable/c/ea494e8a9852abd0ba60f69b254ce0d7c38449e2
- https://git.kernel.org/stable/c/f658d5b528ce97a68efbb64ee54f6fe0909b189a
Modified: 2025-11-19
CVE-2022-50105
In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: Fix refcount leak in spufs_init_isolated_loader of_find_node_by_path() returns remote device nodepointer 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/0aa5de2547b7ccf0a31bc740d12f829fae243112
- https://git.kernel.org/stable/c/14329d29a048dc35aac2374fb3d588d8190095a2
- https://git.kernel.org/stable/c/4288eb035ba4ddb53245e9365c919bb51ac00c2c
- https://git.kernel.org/stable/c/43584490ee6c8a104797444af6bf89d0dafe95c0
- https://git.kernel.org/stable/c/69e9fa07b229badab808980e984a9fe824116f00
- https://git.kernel.org/stable/c/6ac059dacffa8ab2f7798f20e4bd3333890c541c
- https://git.kernel.org/stable/c/85aff6a9b7b7ec4e5c319f7946c9864c8d5e3d4a
- https://git.kernel.org/stable/c/d0cb99948c5f6d8fe56f6e69b8dd0a05ee5f9cec
Modified: 2025-11-19
CVE-2022-50106
In the Linux kernel, the following vulnerability has been resolved: powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() in the error path to avoid refcount leak.
- https://git.kernel.org/stable/c/00dc7cbbb558955ff410fd392cc9b0366eb06df0
- https://git.kernel.org/stable/c/02ed44125d7a7238999750ca126b60f8dd7a88b1
- https://git.kernel.org/stable/c/51cf876b11fb6ca06f69e9d1de58f892d1522e9d
- https://git.kernel.org/stable/c/5eaa93caa63abf382b319dbe2f032232026740c2
- https://git.kernel.org/stable/c/6263ec8032c411b8ef6b7f00198cb18c855ee6cb
- https://git.kernel.org/stable/c/af41cff4ada533b1cf40de6c468ba164fd32c22d
- https://git.kernel.org/stable/c/df5d4b616ee76abc97e5bd348e22659c2b095b1c
- https://git.kernel.org/stable/c/f388643657cd5a04dc47a68d85321876c5b4c208
Modified: 2025-11-17
CVE-2022-50107
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak when using fscache If we hit the 'index == next_cached' case, we leak a refcount on the struct page. Fix this by using readahead_folio() which takes care of the refcount for you.
Modified: 2025-11-19
CVE-2022-50108
In the Linux kernel, the following vulnerability has been resolved: mfd: max77620: Fix refcount leak in max77620_initialise_fps of_get_child_by_name() 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/1520669c8255bd637c6b248b2be910e2688d38dd
- https://git.kernel.org/stable/c/50d5fe8cb94c319cb4316f4d824570c075565354
- https://git.kernel.org/stable/c/a29c40814039535b950149311986a5f348b5db14
- https://git.kernel.org/stable/c/afdbadbf18c19779d7bc5df70d872924f9bbd76b
- https://git.kernel.org/stable/c/b948ff8a9e9ad46d4dff9127777caa14c8c2b53c
- https://git.kernel.org/stable/c/facd31bbc799f4d0cd25d9d688af7ca41e7f38ee
Modified: 2025-11-19
CVE-2022-50109
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: amba-clcd: Fix refcount leak bugs In clcdfb_of_init_display(), we should call of_node_put() for the references returned by of_graph_get_next_endpoint() and of_graph_get_remote_port_parent() which have increased the refcount. Besides, we should call of_node_put() both in fail path or when the references are not used anymore.
- https://git.kernel.org/stable/c/2688df86c02da6bdc9866b62d974e169a2678883
- https://git.kernel.org/stable/c/26c2b7d9fac42eb8317f3ceefa4c1a9a9170ca69
- https://git.kernel.org/stable/c/29f06f1905c312671a09ee85ca92ac04a1d9f305
- https://git.kernel.org/stable/c/49a4c1a87ef884e43cdda58b142a2a30f2f09efc
- https://git.kernel.org/stable/c/a51519ebd0fdad3546463018b8f6bc3b0f4d3032
- https://git.kernel.org/stable/c/a88ab277cca99aeb9a3b2b7db358f1a6dd528b0c
- https://git.kernel.org/stable/c/a97ff8a949dbf41be89f436b2b1a2b3d794493df
- https://git.kernel.org/stable/c/da276dc288bf838ea0fd778b5441ec0f601c69f7
Modified: 2025-11-17
CVE-2022-50110
In the Linux kernel, the following vulnerability has been resolved: watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak.
Modified: 2025-11-19
CVE-2022-50111
In the Linux kernel, the following vulnerability has been resolved: ASoC: mt6359: Fix refcount leak bug In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
Modified: 2025-11-18
CVE-2022-50112
In the Linux kernel, the following vulnerability has been resolved: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge 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/43e42c25a232a6862e7d2f292a069ac828559030
- https://git.kernel.org/stable/c/65382585f067d4256ba087934f30f85c9b6984de
- https://git.kernel.org/stable/c/8ee5d40ae29e63f6fd6cbf9dcfc0a48c474013db
- https://git.kernel.org/stable/c/9715809b9eeb85b3f9b083857a2f29a9e2351125
- https://git.kernel.org/stable/c/ae7fdbab97df6a2115eed6b7e39c278b805c9c7d
- https://git.kernel.org/stable/c/cb50423e46ea585620a6be307d7f7b71587936b7
- https://git.kernel.org/stable/c/ece6cfe62a103cc6032664983be557f1b5a1ff7e
Modified: 2025-11-18
CVE-2022-50113
In the Linux kernel, the following vulnerability has been resolved: ASoc: audio-graph-card2: Fix refcount leak bug in __graph_get_type() We should call of_node_put() for the reference before its replacement as it returned by of_get_parent() which has increased the refcount. Besides, we should also call of_node_put() before return.
Modified: 2025-11-18
CVE-2022-50114
In the Linux kernel, the following vulnerability has been resolved: net: 9p: fix refcount leak in p9_read_work() error handling p9_req_put need to be called when m->rreq->rc.sdata is NULL to avoid temporary refcount leak. [Dominique: commit wording adjustments, p9_req_put argument fixes for rebase]
Modified: 2025-11-18
CVE-2022-50115
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc3-topology: Prevent double freeing of ipc_control_data via load_bytes We have sanity checks for byte controls and if any of the fail the locally allocated scontrol->ipc_control_data is freed up, but not set to NULL. On a rollback path of the error the higher level code will also try to free the scontrol->ipc_control_data which will eventually going to lead to memory corruption as double freeing memory is not a good thing.
Modified: 2025-11-18
CVE-2022-50116
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix deadlock and link starvation in outgoing data path
The current implementation queues up new control and user packets as needed
and processes this queue down to the ldisc in the same code path.
That means that the upper and the lower layer are hard coupled in the code.
Due to this deadlocks can happen as seen below while transmitting data,
especially during ldisc congestion. Furthermore, the data channels starve
the control channel on high transmission load on the ldisc.
Introduce an additional control channel data queue to prevent timeouts and
link hangups during ldisc congestion. This is being processed before the
user channel data queue in gsm_data_kick(), i.e. with the highest priority.
Put the queue to ldisc data path into a workqueue and trigger it whenever
new data has been put into the transmission queue. Change
gsm_dlci_data_sweep() accordingly to fill up the transmission queue until
TX_THRESH_HI. This solves the locking issue, keeps latency low and provides
good performance on high data load.
Note that now all packets from a DLCI are removed from the internal queue
if the associated DLCI was closed. This ensures that no data is sent by the
introduced write task to an already closed DLCI.
BUG: spinlock recursion on CPU#0, test_v24_loop/124
lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0
CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
Modified: 2025-11-18
CVE-2022-50117
In the Linux kernel, the following vulnerability has been resolved: vfio: Split migration ops from main device ops vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps.
Modified: 2025-11-18
CVE-2022-50118
In the Linux kernel, the following vulnerability has been resolved: powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SP ---truncated---
- https://git.kernel.org/stable/c/0a24ea26c3278216642a43291df7976a73a0a7ee
- https://git.kernel.org/stable/c/7e83af3dd4a3afca8f83ffde518cafd52f45b830
- https://git.kernel.org/stable/c/875b2bf469d094754ac2ba9af91dcd529eb12bf6
- https://git.kernel.org/stable/c/87b1a9175f08313f40fcb6d6dc536dbe451090eb
- https://git.kernel.org/stable/c/890005a7d98f7452cfe86dcfb2aeeb7df01132ce
Modified: 2025-11-18
CVE-2022-50120
In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. This function has two paths missing of_node_put().
Modified: 2025-11-18
CVE-2022-50121
In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init 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 child node. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/3f83c4cf1b78331c23876977aa7b9151aff2f9e1
- https://git.kernel.org/stable/c/61cd8cd3b6b33c7eae3b45cf783b114f2ae53528
- https://git.kernel.org/stable/c/75358732af9b26acfe3e609943290bcba13330fc
- https://git.kernel.org/stable/c/cf112a52d758092ca3d5ebdad51dd17bda5ba3e5
- https://git.kernel.org/stable/c/fa220c05d282e7479abe08b54e3bdffd06c25e97
Modified: 2025-11-18
CVE-2022-50122
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix refcount leak in some error paths.
- https://git.kernel.org/stable/c/06ace427953f5036b64aed658f0055f65d76fd27
- https://git.kernel.org/stable/c/403d46971936f9f704b91cecffe66e44aa39e915
- https://git.kernel.org/stable/c/5ec83aa7a9e5bcca80ccd49978916feb4e0ffc07
- https://git.kernel.org/stable/c/79f566907d27abbd7600cebe51def5081d5796b5
- https://git.kernel.org/stable/c/994f2edeeb2114bb22b62741cb8fb030fc7e5441
- https://git.kernel.org/stable/c/e024a24fb264523149658c10c76bb363b3d0004d
- https://git.kernel.org/stable/c/e38e4952ac7a316c9002af30980d6aa850214474
- https://git.kernel.org/stable/c/efe2178d1a32492f99e7f1f2568eea5c88a85729
Modified: 2025-11-18
CVE-2022-50123
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173: Fix refcount leak in mt8173_rt5650_rt5676_dev_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix missing of_node_put() in error paths.
- https://git.kernel.org/stable/c/540c7b7385fb110740703888b4b2bbfa06c7f79c
- https://git.kernel.org/stable/c/58567ed2878f70e0ded242cb529fb4a7618ea9f8
- https://git.kernel.org/stable/c/769399bce8825e1dcc5050dab78e15ab578baf4f
- https://git.kernel.org/stable/c/aa1214ece37944e4dbbb5cfb1d02bf37e4d89b02
- https://git.kernel.org/stable/c/aa668f8e93199cda8fa1612eb49ff70f5ecd8c92
- https://git.kernel.org/stable/c/ae4f11c1ed2d67192fdf3d89db719ee439827c11
- https://git.kernel.org/stable/c/d6d41f04640db0f946e2c3f7963bb2774afc7a0d
- https://git.kernel.org/stable/c/fab5eb31819a2693b0c3d6f3df6a0d193af9a089
Modified: 2025-11-18
CVE-2022-50124
In the Linux kernel, the following vulnerability has been resolved: ASoC: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_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.
- https://git.kernel.org/stable/c/1042353bb67cd1c9109d7481ea182c7794336458
- https://git.kernel.org/stable/c/38dc6faef05f33b4c889be8b7d65878e465c1c4b
- https://git.kernel.org/stable/c/67a28402a9e8c229c7588f214d81d52903ea06ea
- https://git.kernel.org/stable/c/7472eb8d7dd12b6b9b1a4f4527719cc9c7f5965f
- https://git.kernel.org/stable/c/7dee72b1bcecb26bfff8d6360f2169f8656dbaf6
- https://git.kernel.org/stable/c/a0381a9f3e595988e83bac4c4dd1e45ed2b3c744
- https://git.kernel.org/stable/c/b488ceb2336905f071f80627bc8a7d657274e5de
Modified: 2025-11-18
CVE-2022-50125
In the Linux kernel, the following vulnerability has been resolved: ASoC: cros_ec_codec: Fix refcount leak in cros_ec_codec_platform_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.
- https://git.kernel.org/stable/c/0a034d93ee929a9ea89f3fa5f1d8492435b9ee6e
- https://git.kernel.org/stable/c/1065c385325845c88350c765cc6e449f46741984
- https://git.kernel.org/stable/c/b3e64b5562c077218295f2230fb5cf181193cb06
- https://git.kernel.org/stable/c/bae95c5aee1f67da6608ceaebfb744d900e5ffbf
- https://git.kernel.org/stable/c/ca6c9244e6c9827a0b2fe8808c5e7b1ee8ab7104
Modified: 2025-11-18
CVE-2022-50126
In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted
Following process will fail assertion 'jh->b_frozen_data == NULL' in
jbd2_journal_dirty_metadata():
jbd2_journal_commit_transaction
unlink(dir/a)
jh->b_transaction = trans1
jh->b_jlist = BJ_Metadata
journal->j_running_transaction = NULL
trans1->t_state = T_COMMIT
unlink(dir/b)
handle->h_trans = trans2
do_get_write_access
jh->b_modified = 0
jh->b_frozen_data = frozen_buffer
jh->b_next_transaction = trans2
jbd2_journal_dirty_metadata
is_handle_aborted
is_journal_aborted // return false
--> jbd2 abort <--
while (commit_transaction->t_buffers)
if (is_journal_aborted)
jbd2_journal_refile_buffer
__jbd2_journal_refile_buffer
WRITE_ONCE(jh->b_transaction,
jh->b_next_transaction)
WRITE_ONCE(jh->b_next_transaction, NULL)
__jbd2_journal_file_buffer(jh, BJ_Reserved)
J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure !
The reproducer (See detail in [Link]) reports:
------------[ cut here ]------------
kernel BUG at fs/jbd2/transaction.c:1629!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 584 Comm: unlink Tainted: G W
5.19.0-rc6-00115-g4a57a8400075-dirty #697
RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470
RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202
Call Trace:
- https://git.kernel.org/stable/c/0f61c6dc4b714be9d79cf0782ca02ba01c1b7ac3
- https://git.kernel.org/stable/c/4a734f0869f970b8a9b65062ea40b09a5da9dba8
- https://git.kernel.org/stable/c/6073389db83b903678a0920554fa19f5bdc51c48
- https://git.kernel.org/stable/c/731c1662d838fe954c6759e3ee43229b0d928fe4
- https://git.kernel.org/stable/c/ddd896792e1718cb84c96f3e618270589b6886dc
- https://git.kernel.org/stable/c/e62f79827784f56499a50ea2e893c98317b5407b
- https://git.kernel.org/stable/c/f7161d0da975adc234161cd0641d0e484f5ce375
- https://git.kernel.org/stable/c/fa5b65d39332fef7a11ae99cb1f0696012a61527
Modified: 2025-11-18
CVE-2022-50127
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix error unwind in rxe_create_qp() In the function rxe_create_qp(), rxe_qp_from_init() is called to initialize qp, internally things like the spin locks are not setup until rxe_qp_init_req(). If an error occures before this point then the unwind will call rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task() which will oops when trying to access the uninitialized spinlock. Move the spinlock initializations earlier before any failures.
- https://git.kernel.org/stable/c/1a63f24e724f677db1ab21251f4d0011ae0bb5b5
- https://git.kernel.org/stable/c/2ceeb04252e621c0b128ecc8fedbca922d11adba
- https://git.kernel.org/stable/c/3c838ca6fbdb173102780d7bdf18f2f7d9e30979
- https://git.kernel.org/stable/c/3ef491b26c720a87fcfbd78b7dc8eb83d9753fe6
- https://git.kernel.org/stable/c/b348e204a53103f51070513a7494da7c62ecbdaa
- https://git.kernel.org/stable/c/db924bd8484c76558a4ac4c4b5aeb52e857f0341
- https://git.kernel.org/stable/c/f05b7cf02123aaf99db78abfe638efefdbe15555
- https://git.kernel.org/stable/c/fd5382c5805c4bcb50fd25b7246247d3f7114733
Modified: 2025-11-18
CVE-2022-50129
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Fix a use-after-free
Change the LIO port members inside struct srpt_port from regular members
into pointers. Allocate the LIO port data structures from inside
srpt_make_tport() and free these from inside srpt_make_tport(). Keep
struct srpt_device as long as either an RDMA port or a LIO target port is
associated with it. This patch decouples the lifetime of struct srpt_port
(controlled by the RDMA core) and struct srpt_port_id (controlled by LIO).
This patch fixes the following KASAN complaint:
BUG: KASAN: use-after-free in srpt_enable_tpg+0x31/0x70 [ib_srpt]
Read of size 8 at addr ffff888141cc34b8 by task check/5093
Call Trace:
- https://git.kernel.org/stable/c/388326bb1c32fcd09371c1d494af71471ef3a04b
- https://git.kernel.org/stable/c/4ee8c39968a648d58b273582d4b021044a41ee5e
- https://git.kernel.org/stable/c/b5605148e6ce36bb21020d49010b617693933128
- https://git.kernel.org/stable/c/de95b52d9aabc979166aba81ccbe623aaf9c16a1
- https://git.kernel.org/stable/c/e60d7e2462bf57273563c4e00dbfa79ee973b9e2
Modified: 2025-11-18
CVE-2022-50130
In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: core: set smem_len before fb_deferred_io_init call The fbtft_framebuffer_alloc() calls fb_deferred_io_init() before initializing info->fix.smem_len. It is set to zero by the framebuffer_alloc() function. It will trigger a WARN_ON() at the start of fb_deferred_io_init() and the function will not do anything.
Modified: 2025-11-18
CVE-2022-50131
In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: prevent a buffer overflow in mcp_smbus_write() Smatch Warning: drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() '&mcp->txbuf[5]' too small (59 vs 255) drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf' too small (34 vs 255) The 'len' variable can take a value between 0-255 as it can come from data->block[0] and it is user data. So add an bound check to prevent a buffer overflow in memcpy().
- https://git.kernel.org/stable/c/3c0f8a59f2cc8841ee6653399a77f4f3e6e9a270
- https://git.kernel.org/stable/c/62ac2473553a00229e67bdf3cb023b62cf7f5a9a
- https://git.kernel.org/stable/c/6402116a7b5ec80fa40fd145a80c813019cd555f
- https://git.kernel.org/stable/c/66c8e816f2f2ca4a61b406503bd10bad1b35f72f
- https://git.kernel.org/stable/c/91443c669d280937968f0aa4edefa741cfe35314
Modified: 2025-11-18
CVE-2022-50132
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable() If 'ep' is NULL, result of ep_to_cdns3_ep(ep) is invalid pointer and its dereference with priv_ep->cdns3_dev may cause panic. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/7af83bb516d7aa4f96835288e4aeda21d7aa2a17
- https://git.kernel.org/stable/c/bfa0201468587072454dba7933e4a4a7be44467a
- https://git.kernel.org/stable/c/c3ffc9c4ca44bfe9562166793d133e1fb0630ea6
- https://git.kernel.org/stable/c/d342203df9f2d0851b4acd9ed577d73d10eade77
- https://git.kernel.org/stable/c/eb82c0382285ee17a9966aaab27b8becb08eb1ac
Modified: 2025-11-18
CVE-2022-50134
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: fix potential memory leak in setup_base_ctxt() setup_base_ctxt() allocates a memory chunk for uctxt->groups with hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups is not released, which will lead to a memory leak. We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups() when init_user_ctxt() fails.
- https://git.kernel.org/stable/c/1750be1e9f18787cf717c24dbc5fa029fc372a22
- https://git.kernel.org/stable/c/2f90813f1c21c3d780585390af961bd17c8515ae
- https://git.kernel.org/stable/c/90ef48a718f88935d4af53d7dadd1ceafe103ce6
- https://git.kernel.org/stable/c/a85c7dd1edadcdeca24e603a6618153a3bcc81ca
- https://git.kernel.org/stable/c/a9055dfe437efae77e28e57205437c878a03ccb7
- https://git.kernel.org/stable/c/aa2a1df3a2c85f855af7d54466ac10bd48645d63
- https://git.kernel.org/stable/c/e25b828553aecb3185a8d8d0c4f9b4e133fb5db6
- https://git.kernel.org/stable/c/fc4de8009fd6c2ca51986c6757efa964040e7d02
Modified: 2025-11-18
CVE-2022-50136
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event
If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't
been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY
in this case. This may trigger a call trace in iw_cm. A simple way to
trigger this:
server: ib_send_lat
client: ib_send_lat -R
- https://git.kernel.org/stable/c/0066246d2d7e2619f3ecf3cf07333c59e6e7d84d
- https://git.kernel.org/stable/c/11edf0bba15ea9df49478affec7974f351bb2f6e
- https://git.kernel.org/stable/c/1434de50a5d9dab91c8ce031bc23b3e2178379c5
- https://git.kernel.org/stable/c/3056fc6c32e613b760422b94c7617ac9a24a4721
- https://git.kernel.org/stable/c/9ade92ddaf2347fb34298c02080caaa3cdd7c27b
- https://git.kernel.org/stable/c/f6e26e1a5f600b760dc32135d3fac846eabe09e7
Modified: 2025-11-18
CVE-2022-50137
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix a window for use-after-free During a destroy CQ an interrupt may cause processing of a CQE after CQ resources are freed by irdma_cq_free_rsrc(). Fix this by moving the call to irdma_cq_free_rsrc() after the irdma_sc_cleanup_ceqes(), which is called under the cq_lock.
Modified: 2025-11-18
CVE-2022-50138
In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() __qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr" is released while "mr->info.pbl_table" is not released, which will lead to a memory leak. We should release the "mr->info.pbl_table" with qedr_free_pbl() when error occurs to fix the memory leak.
- https://git.kernel.org/stable/c/07ba048df306dc93fc4d2ef670b9e24644a2069f
- https://git.kernel.org/stable/c/79ce50dddaf28b5c57911ecc80a2be17a0b17f83
- https://git.kernel.org/stable/c/7e647a8d5fc0a2c8e0f36f585a6388286a25bb15
- https://git.kernel.org/stable/c/b3236a64ddd125a455ef5b5316c1b9051b732974
- https://git.kernel.org/stable/c/b4c9f7db9f0148423557539af0fdf513338efe08
Modified: 2025-11-18
CVE-2022-50139
In the Linux kernel, the following vulnerability has been resolved: usb: aspeed-vhub: Fix refcount leak bug in ast_vhub_init_desc() We should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
- https://git.kernel.org/stable/c/0e0a40c803643f4edc30f0660f2f3bea4d57a99a
- https://git.kernel.org/stable/c/220fafb4ed04187e9c17be4152da5a7f2ffbdd8c
- https://git.kernel.org/stable/c/3503305225ca24c3229414c769323fb8bf39b4bf
- https://git.kernel.org/stable/c/4070f3c83cd28267f469a59751480ad39435f26a
- https://git.kernel.org/stable/c/e6db5780c2bf6e23be7b315809ef349b4b4f2213
Modified: 2025-11-18
CVE-2022-50140
In the Linux kernel, the following vulnerability has been resolved: memstick/ms_block: Fix a memory leak 'erased_blocks_bitmap' is never freed. As it is allocated at the same time as 'used_blocks_bitmap', it is likely that it should be freed also at the same time. Add the corresponding bitmap_free() in msb_data_clear().
- https://git.kernel.org/stable/c/16e07966638717416abf45393d6a80a5a1034429
- https://git.kernel.org/stable/c/37958980eb4cd71ae594ace093c11b6a91e165e8
- https://git.kernel.org/stable/c/39be95d1ff7b44c1e969af72ba9da7332dfcc1da
- https://git.kernel.org/stable/c/54eb7a55be6779c4d0c25eaf5056498a28595049
- https://git.kernel.org/stable/c/9260a154b3b5e387dbceec7c0ac441470646bc6f
- https://git.kernel.org/stable/c/961d7d12080fe70847f944d656e36cd0dd0214ba
- https://git.kernel.org/stable/c/9d8b911fe3c3ed788c66edba7c90e32a4a7a5f53
- https://git.kernel.org/stable/c/efd675246aec045507b9425c67b548cc2d782d8f
Modified: 2025-11-18
CVE-2022-50141
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch 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/352377cf74710bc3368dddf78f17210dfe456933
- https://git.kernel.org/stable/c/4c472a2c9ed6ea9d272268d7f484d4303c549f1a
- https://git.kernel.org/stable/c/547db1dd98d1815574ebea7358015a17199a93bc
- https://git.kernel.org/stable/c/8b902840f6a3584f702bcb59834691b30f3d7c5a
- https://git.kernel.org/stable/c/a63d5d01e83b984b1b9c7ae8fc9c8c93697a3820
- https://git.kernel.org/stable/c/b074f1e8060836baeb0ee91181f4194b9a0ee16a
- https://git.kernel.org/stable/c/b305475df756256a186623f0991d05a816de881a
- https://git.kernel.org/stable/c/b5899a3e2f783a27b268e38d37f9b24c71bddf45
Modified: 2025-11-19
CVE-2022-50142
In the Linux kernel, the following vulnerability has been resolved:
intel_th: msu: Fix vmalloced buffers
After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's
a chance of DMA buffer getting allocated via vmalloc(), which messes up
the mmapping code:
> RIP: msc_mmap_fault [intel_th_msu]
> Call Trace:
>
- https://git.kernel.org/stable/c/0ed72c6bc632cbf8d979ac60f982ff84b7bb610a
- https://git.kernel.org/stable/c/4914c50670b6a531e2cb17cd984cc565b4681312
- https://git.kernel.org/stable/c/566887bad7ff2297d6b3f9659c702ba075f3d62d
- https://git.kernel.org/stable/c/6ae2881c1d1fa0e33f4763b7c786f8ef05a9c828
- https://git.kernel.org/stable/c/ac12ad3ccf6d386e64a9d6a890595a2509d24edd
- https://git.kernel.org/stable/c/b5d924cb4c7b952eaa61622f14427723a78137a3
Modified: 2025-11-20
CVE-2022-50143
In the Linux kernel, the following vulnerability has been resolved: intel_th: Fix a resource leak in an error handling path If an error occurs after calling 'pci_alloc_irq_vectors()', 'pci_free_irq_vectors()' must be called as already done in the remove function.
- https://git.kernel.org/stable/c/086c28ab7c5699256aced0049aae9c42f1410313
- https://git.kernel.org/stable/c/859342220accd0d332864fafbf4e3d2d0492bc3f
- https://git.kernel.org/stable/c/9b5469573a274729bdb04b60a8d71f8d09940a31
- https://git.kernel.org/stable/c/a8f3b78b1f8e959d06801ae82149f140a75724e8
- https://git.kernel.org/stable/c/ed4d5ecb7d7fd80336afb2f9ac6685651a6aa32f
- https://git.kernel.org/stable/c/fae9da7d4c2ccad3792de03e3cac1fe2bfabb73d
Modified: 2025-11-20
CVE-2022-50144
In the Linux kernel, the following vulnerability has been resolved:
soundwire: revisit driver bind/unbind and callbacks
In the SoundWire probe, we store a pointer from the driver ops into
the 'slave' structure. This can lead to kernel oopses when unbinding
codec drivers, e.g. with the following sequence to remove machine
driver and codec driver.
/sbin/modprobe -r snd_soc_sof_sdw
/sbin/modprobe -r snd_soc_rt711
The full details can be found in the BugLink below, for reference the
two following examples show different cases of driver ops/callbacks
being invoked after the driver .remove().
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150
kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]
kernel: RIP: 0010:mutex_lock+0x19/0x30
kernel: Call Trace:
kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]
kernel: ? newidle_balance+0x26a/0x400
kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]
kernel: BUG: unable to handle page fault for address: ffffffffc07654c8
kernel: Workqueue: pm pm_runtime_work
kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]
kernel: Call Trace:
kernel:
Modified: 2025-11-20
CVE-2022-50145
In the Linux kernel, the following vulnerability has been resolved: dmaengine: sf-pdma: Add multithread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 64 > /sys/module/dmatest/parameters/threads_per_chan % echo 10000 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted 5.17.0-rc5 [ 89.509385] epc : vchan_find_desc+0x32/0x46 [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6 This happens because of data race. Each thread rewrite channels's descriptor as soon as device_prep_dma_memcpy() is called. It leads to the situation when the driver thinks that it uses right descriptor that actually is freed or substituted for other one. With current fixes a descriptor changes its value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. Now it is just possible to queue a descriptor for further processing.
- https://git.kernel.org/stable/c/4c7350b1dd8a192af844de32fc99b9e34c876fda
- https://git.kernel.org/stable/c/5ab2782c944e324008ef5d658f2494a9f0e3c5ac
- https://git.kernel.org/stable/c/a93b3f1e11971a91b6441b6d47488f4492cc113f
- https://git.kernel.org/stable/c/b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc
- https://git.kernel.org/stable/c/b9b4992f897be9b0b9e3a3b956cab6b75ccc3f11
Modified: 2025-11-17
CVE-2022-50146
In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter parts won't be undone thus causing a memory leak. Add a cleanup-on-error path to fix these leaks. [bhelgaas: commit log]
- https://git.kernel.org/stable/c/2d546db5c80c45cac3ccd929550244fd58f4ff58
- https://git.kernel.org/stable/c/3b453f5d06d1f1d6b20a75ea51dc7b53ae78f479
- https://git.kernel.org/stable/c/8161e9626b50892eaedbd8070ecb1586ecedb109
- https://git.kernel.org/stable/c/b03a8f1264ea8c363bec9ef6e37b467f27cb04ea
- https://git.kernel.org/stable/c/e7599a5974d4c64eaae8009c3f2e47b9e3223e07
Modified: 2025-11-17
CVE-2022-50147
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix get_nodes out of bound access When user specified more nodes than supported, get_nodes will access nmask array out of bounds.
Modified: 2025-11-17
CVE-2022-50148
In the Linux kernel, the following vulnerability has been resolved: kernfs: fix potential NULL dereference in __kernfs_remove When lockdep is enabled, lockdep_assert_held_write would cause potential NULL pointer dereference. Fix the following smatch warnings: fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check 'kn' (see line 1346)
Modified: 2025-11-17
CVE-2022-50149
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
In __driver_attach function, The lock holding logic is as follows:
...
__driver_attach
if (driver_allows_async_probing(drv))
device_lock(dev) // get lock dev
async_schedule_dev(__driver_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
__driver_attach_async_helper will get lock dev as
will, 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 above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000
[ 370.788865] Call Trace:
[ 370.789374]
- https://git.kernel.org/stable/c/37f908038402c9b8325763f306a1c65d88757e15
- https://git.kernel.org/stable/c/70fe758352cafdee72a7b13bf9db065f9613ced8
- https://git.kernel.org/stable/c/733ab0c19bf17f6ad7c2b580ede006e369d5ab1b
- https://git.kernel.org/stable/c/779b634714c51d05baaeff4868ce2fd9fc7399bf
- https://git.kernel.org/stable/c/8191b6cd9ada09b675f17446d5872eb1f77685cb
- https://git.kernel.org/stable/c/a93f33aeef4e6a94ae9c9d3f5b2f9085ad0572ec
Modified: 2025-11-20
CVE-2022-50151
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix random warning message when driver load Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748 [ 4.191419] __slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0 pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(*page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... } kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning. GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely.
Modified: 2025-11-20
CVE-2022-50152
In the Linux kernel, the following vulnerability has been resolved: usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_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.
- https://git.kernel.org/stable/c/302970b4cad3ebfda2c05ce06c322ccdc447d17e
- https://git.kernel.org/stable/c/4db00c2fa6f8c9876a7e20511dccf43b50be9006
- https://git.kernel.org/stable/c/50238c4b54c2ac6c2da7a84a4a2b0a570e3da0e2
- https://git.kernel.org/stable/c/59026d5cc615da28e0c9806a71bf07065c906464
- https://git.kernel.org/stable/c/591ab8dbf6c21927f23f83ddb90691f48b86d136
- https://git.kernel.org/stable/c/65d36ec409b635dfc2f95f0d7c5877c9d0cb7630
- https://git.kernel.org/stable/c/a0fbac3bf26a11f084233519ddf3fd5e5bb28939
- https://git.kernel.org/stable/c/d35903e9650f4fa79426ce390db8678dbf5ac432
Modified: 2025-11-25
CVE-2022-50153
In the Linux kernel, the following vulnerability has been resolved: usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe 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/038453b17fe30ea38f0f3c916e2ae2b7f8cef84e
- https://git.kernel.org/stable/c/3a50c917c67dd0bc39c14de4a8b75a1d50fdce66
- https://git.kernel.org/stable/c/585d22a5624ef2b540c337665c72fea8cd33db50
- https://git.kernel.org/stable/c/8cbc3870ff356366842af3228dd8e7bc278e5edd
- https://git.kernel.org/stable/c/8e51a512c1079109bec4c80915e647692d583e79
- https://git.kernel.org/stable/c/b5c5b13cb45e2c88181308186b0001992cb41954
- https://git.kernel.org/stable/c/b9c4a480cb0ada07154debf681454cbb55e30b59
- https://git.kernel.org/stable/c/c0a4b454486b23bb4d94ce49f490830ecc354040
Modified: 2025-11-25
CVE-2022-50154
In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek-gen3: Fix refcount leak in mtk_pcie_init_irq_domains() of_get_child_by_name() returns a node pointer with refcount incremented, so we should use of_node_put() on it when we don't need it anymore. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-21
CVE-2022-50155
In the Linux kernel, the following vulnerability has been resolved: mtd: parsers: ofpart: Fix refcount leak in bcm4908_partitions_fw_offset of_find_node_by_path() 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-11-25
CVE-2022-50156
In the Linux kernel, the following vulnerability has been resolved: HID: cp2112: prevent a buffer overflow in cp2112_xfer() Smatch warnings: drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'data->block[1]' too small (33 vs 255) drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'buf' too small (64 vs 255) The 'read_length' variable is provided by 'data->block[0]' which comes from user and it(read_length) can take a value between 0-255. Add an upper bound to 'read_length' variable to prevent a buffer overflow in memcpy().
- https://git.kernel.org/stable/c/26e427ac85c2b8d0d108cc80b6de34d33e2780c4
- https://git.kernel.org/stable/c/381583845d19cb4bd21c8193449385f3fefa9caf
- https://git.kernel.org/stable/c/3af7d60e9a6c17d6d41c4341f8020511887d372d
- https://git.kernel.org/stable/c/519ff31a6ddd87aa4905bd9bf3b92e8b88801614
- https://git.kernel.org/stable/c/8489a20ac481b08c0391608d81ed3796d373cfdf
- https://git.kernel.org/stable/c/e7028944e61014ae915e7fb74963d3835f2f761a
- https://git.kernel.org/stable/c/ebda3d6b004bb6127a66a616524a2de152302ca7
Modified: 2025-11-25
CVE-2022-50157
In the Linux kernel, the following vulnerability has been resolved: PCI: microchip: Fix refcount leak in mc_pcie_init_irq_domains() of_get_next_child() returns a node pointer with refcount incremented, so we should use of_node_put() on it when we don't need it anymore. mc_pcie_init_irq_domains() only calls of_node_put() in the normal path, missing it in some error paths. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-25
CVE-2022-50158
In the Linux kernel, the following vulnerability has been resolved: mtd: partitions: Fix refcount leak in parse_redboot_of of_get_child_by_name() 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/55d0f7da66dec93c4d53d0886a1555618079a900
- https://git.kernel.org/stable/c/7ec48ac18d8f9e002ce9bfbad32741086739e499
- https://git.kernel.org/stable/c/8ea607579d300b2f7fc997f3dd20949114565fcd
- https://git.kernel.org/stable/c/9f7e62815cf3cbbcb1b8cb21649fb4dfdb3aa016
- https://git.kernel.org/stable/c/e24af43d0cbe9f6aaa413c15ccce50bbbfd61e0e
- https://git.kernel.org/stable/c/f3cc27198c5d78cdda60a55ae749f815cd1fe5eb
Modified: 2025-11-25
CVE-2022-50159
In the Linux kernel, the following vulnerability has been resolved:
of: check previous kernel's ima-kexec-buffer against memory bounds
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:
$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
Modified: 2025-11-18
CVE-2022-50160
In the Linux kernel, the following vulnerability has been resolved: mtd: maps: Fix refcount leak in ap_flash_init 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.
- https://git.kernel.org/stable/c/77087a04c8fd554134bddcb8a9ff87b21f357926
- https://git.kernel.org/stable/c/80b1465b2ae81ebb59bbe62bcb7a7f7d4e9ece6f
- https://git.kernel.org/stable/c/941ef6997f9db704fe4fd62fc01e420fdd5048b2
- https://git.kernel.org/stable/c/995fb2874bb5696357846a91e59181c600e6aac8
- https://git.kernel.org/stable/c/a74322d4b897ddc268b340c4a397f6066c2f945d
- https://git.kernel.org/stable/c/babd7b0124650ab71a6487e38588b8659b3aa2dc
- https://git.kernel.org/stable/c/d10855876a6f47add6ff621cef25cc0171dac162
- https://git.kernel.org/stable/c/d5730780e9ea84e5476752a47c749036c6a74af5
Modified: 2025-11-18
CVE-2022-50161
In the Linux kernel, the following vulnerability has been resolved: mtd: maps: Fix refcount leak in of_flash_probe_versatile 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/33ec82a6d2b119938f26e5c8040ed5d92378eb54
- https://git.kernel.org/stable/c/3c8de6a838b7e0eb392754ac89dd66e698684342
- https://git.kernel.org/stable/c/4d67c8f74d804b20febf716ec96e9a475457ec60
- https://git.kernel.org/stable/c/52ae2b14f76ef2d490337ddc0037bc37125be7b8
- https://git.kernel.org/stable/c/5d5ddd8771fa9cabeb247fba5f6ab60d63f3fbce
- https://git.kernel.org/stable/c/79e57889aa0d92a6d769bad808fb105e7b6ea495
- https://git.kernel.org/stable/c/9124d51e01232a91da4034768a2a8d1688472179
- https://git.kernel.org/stable/c/f516fbb63873ee23cba5b7c3d239677c30f13df8
Modified: 2025-11-18
CVE-2022-50162
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: Fix possible refcount leak in if_usb_probe() usb_get_dev will be called before lbs_get_firmware_async which means that usb_put_dev need to be called when lbs_get_firmware_async fails.
- https://git.kernel.org/stable/c/00d0c4e59c0f8ad1f86874bb64b220394e687028
- https://git.kernel.org/stable/c/4c8e2f9ce1428e44cb103035eeced7aeb6b80980
- https://git.kernel.org/stable/c/5b92f406a5199b6b01dc664b9226d824ae2835f0
- https://git.kernel.org/stable/c/61b2ec97487399c58ae2e34f250f4884e671799b
- https://git.kernel.org/stable/c/6fd57e1d120bf13d4dc6c200a7cf914e6347a316
- https://git.kernel.org/stable/c/878e7f39803a9ab5bb9766956a7a04351d4bf99d
- https://git.kernel.org/stable/c/97e5d3e46a3a2100253a9717a4df98d68aeb10b8
- https://git.kernel.org/stable/c/d7365590d15bbd9008f424ef043d1778ffe29f42
Modified: 2025-11-18
CVE-2022-50163
In the Linux kernel, the following vulnerability has been resolved:
ax25: fix incorrect dev_tracker usage
While investigating a separate rose issue [1], and enabling
CONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2]
An ax25_dev can be used by one (or many) struct ax25_cb.
We thus need different dev_tracker, one per struct ax25_cb.
After this patch is applied, we are able to focus on rose.
[1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/
[2]
[ 205.798723] reference already released.
[ 205.798732] allocated in:
[ 205.798734] ax25_bind+0x1a2/0x230 [ax25]
[ 205.798747] __sys_bind+0xea/0x110
[ 205.798753] __x64_sys_bind+0x18/0x20
[ 205.798758] do_syscall_64+0x5c/0x80
[ 205.798763] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 205.798768] freed in:
[ 205.798770] ax25_release+0x115/0x370 [ax25]
[ 205.798778] __sock_release+0x42/0xb0
[ 205.798782] sock_close+0x15/0x20
[ 205.798785] __fput+0x9f/0x260
[ 205.798789] ____fput+0xe/0x10
[ 205.798792] task_work_run+0x64/0xa0
[ 205.798798] exit_to_user_mode_prepare+0x18b/0x190
[ 205.798804] syscall_exit_to_user_mode+0x26/0x40
[ 205.798808] do_syscall_64+0x69/0x80
[ 205.798812] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 205.798827] ------------[ cut here ]------------
[ 205.798829] WARNING: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81
[ 205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video
[ 205.798948] mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25]
[ 205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3
[ 205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020
[ 205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81
[ 205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 <0f> 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e
[ 205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286
[ 205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000
[ 205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff
[ 205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618
[ 205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0
[ 205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001
[ 205.799024] FS: 0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000
[ 205.799028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0
[ 205.799033] Call Trace:
[ 205.799035]
Modified: 2025-11-18
CVE-2022-50164
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queue
After successfull station association, if station queues are disabled for
some reason, the related lists are not emptied. So if some new element is
added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old
one and produce a BUG like this:
[ 46.535263] list_add corruption. prev->next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388).
[ 46.535283] ------------[ cut here ]------------
[ 46.535284] kernel BUG at lib/list_debug.c:26!
[ 46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1
[ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012
[ 46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f
[ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff <0f> 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1
[ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286
[ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000
[ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff
[ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666
[ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388
[ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0
[ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000
[ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0
[ 46.687422] Call Trace:
[ 46.689906]
- https://git.kernel.org/stable/c/14a3aacf517a9de725dd3219dbbcf741e31763c4
- https://git.kernel.org/stable/c/182d3c1385f44ba7c508bf5b1292a7fe96ad4e9e
- https://git.kernel.org/stable/c/38d71acc15a2e72806b516380af0adb3830d4639
- https://git.kernel.org/stable/c/4a40af2b0b9517fca7ae2a030c9c0a16836303c0
- https://git.kernel.org/stable/c/5cca5f714fe6cedd2df9d8451ad8df21e6464f62
- https://git.kernel.org/stable/c/ff068c25bf90d26f0aee1751553f18076b797e8d
Modified: 2025-11-17
CVE-2022-50165
In the Linux kernel, the following vulnerability has been resolved: wifi: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()` Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user() but it forgets to change the value to be returned that came from simple_write_to_buffer() call. It results in the following warning: warning: variable 'rc' is uninitialized when used here [-Wuninitialized] return rc; ^~ Remove rc variable and just return the passed in length if the memdup_user() succeeds.
- https://git.kernel.org/stable/c/409bd72e544fdf4809ea0dac337bb5a1f11a25a9
- https://git.kernel.org/stable/c/52b11a48cf073e0aab923ae809a765d756cecf13
- https://git.kernel.org/stable/c/689e5caf63e99e15d2f485ec297c1bf9243e0e28
- https://git.kernel.org/stable/c/6c5fee83bdbeffe8d607d1ab125122a75f40bd1a
- https://git.kernel.org/stable/c/b13c84e877d7a3095bacb14665db304b2c00e95f
- https://git.kernel.org/stable/c/c9fde3a44da566d8929070ab6bda4f0dfa9955d0
- https://git.kernel.org/stable/c/d4742c886043b69d2d058bfde3998ef333b66595
- https://git.kernel.org/stable/c/d578e0af3a003736f6c440188b156483d451b329
Modified: 2025-11-17
CVE-2022-50166
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: When HCI work queue is drained, only queue chained work
The HCI command, event, and data packet processing workqueue is drained
to avoid deadlock in commit
76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").
There is another delayed work, which will queue command to this drained
workqueue. Which results in the following error report:
Bluetooth: hci2: command 0x040f tx timeout
WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140
Workqueue: events hci_cmd_timeout
RIP: 0010:__queue_work+0xdad/0x1140
RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000
RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08
RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700
R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60
R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800
FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-17
CVE-2022-50167
In the Linux kernel, the following vulnerability has been resolved: bpf: fix potential 32-bit overflow when accessing ARRAY map element If BPF array map is bigger than 4GB, element pointer calculation can overflow because both index and elem_size are u32. Fix this everywhere by forcing 64-bit multiplication. Extract this formula into separate small helper and use it consistently in various places. Speculative-preventing formula utilizing index_mask trick is left as is, but explicit u64 casts are added in both places.
Modified: 2025-12-03
CVE-2022-50168
In the Linux kernel, the following vulnerability has been resolved: bpf, x86: fix freeing of not-finalized bpf_prog_pack syzbot reported a few issues with bpf_prog_pack [1], [2]. This only happens with multiple subprogs. In jit_subprogs(), we first call bpf_int_jit_compile() on each sub program. And then, we call it on each sub program again. jit_data is not freed in the first call of bpf_int_jit_compile(). Similarly we don't call bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile(). If bpf_int_jit_compile() failed for one sub program, we will call bpf_jit_binary_pack_finalize() for this sub program. However, we don't have a chance to call it for other sub programs. Then we will hit "goto out_free" in jit_subprogs(), and call bpf_jit_free on some subprograms that haven't got bpf_jit_binary_pack_finalize() yet. At this point, bpf_jit_binary_pack_free() is called and the whole 2MB page is freed erroneously. Fix this with a custom bpf_jit_free() for x86_64, which calls bpf_jit_binary_pack_finalize() if necessary. Also, with custom bpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not needed any more, remove it. [1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f [2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445
Modified: 2026-01-23
CVE-2022-50169
In the Linux kernel, the following vulnerability has been resolved: wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi() The simple_write_to_buffer() function will succeed if even a single byte is initialized. However, we need to initialize the whole buffer to prevent information leaks. Just use memdup_user().
- https://git.kernel.org/stable/c/05ceda14ef7c73104e709c414c3680d8a59f51d4
- https://git.kernel.org/stable/c/074e865b37da55aa87baa16d68b96896f85f8adb
- https://git.kernel.org/stable/c/4615458db7793fadc6d546ac3564b36819e77a22
- https://git.kernel.org/stable/c/60c9983425167ec5073c628d83a6875760d18059
- https://git.kernel.org/stable/c/67470920cd3f3cb38699b1ad23234f96bead4d21
- https://git.kernel.org/stable/c/789edc1af9c1a2293956e8534bfef3d18d629de9
- https://git.kernel.org/stable/c/7a4836560a6198d245d5732e26f94898b12eb760
- https://git.kernel.org/stable/c/c1216e699a1ce83ea005510844bd7508d34c6cef
Modified: 2025-11-28
CVE-2022-50170
In the Linux kernel, the following vulnerability has been resolved: kunit: executor: Fix a memory leak on failure in kunit_filter_tests It's possible that memory allocation for 'filtered' will fail, but for the copy of the suite to succeed. In this case, the copy could be leaked. Properly free 'copy' in the error case for the allocation of 'filtered' failing. Note that there may also have been a similar issue in kunit_filter_subsuites, before it was removed in "kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites". This was reported by clang-analyzer via the kernel test robot, here: https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/ And by smatch via Dan Carpenter and the kernel test robot: https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/
Modified: 2025-11-28
CVE-2022-50171
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - don't sleep when in softirq When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error: BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dump_backtrace+0x0/0x1e4 show_stack+0x20/0x2c dump_stack+0xd8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_lock.constprop.0+0x594/0x5dc __mutex_lock_slowpath+0x1c/0x30 mutex_lock+0x50/0x60 sec_request_init+0x8c/0x1a0 [hisi_sec2] sec_process+0x28/0x1ac [hisi_sec2] sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2] sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2] crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp_output_tail+0x348/0x5c0 [esp4] esp_output+0x120/0x19c [esp4] xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0x64/0x130 ip_build_and_send_pkt+0x158/0x20c tcp_v4_send_synack+0xdc/0x1f0 tcp_conn_request+0x7d0/0x994 tcp_v4_conn_request+0x58/0x6c tcp_v6_conn_request+0xf0/0x100 tcp_rcv_state_process+0x1cc/0xd60 tcp_v4_do_rcv+0x10c/0x250 tcp_v4_rcv+0xfc4/0x10a4 ip_protocol_deliver_rcu+0xf4/0x200 ip_local_deliver_finish+0x58/0x70 ip_local_deliver+0x68/0x120 ip_sublist_rcv_finish+0x70/0x94 ip_list_rcv_finish.constprop.0+0x17c/0x1d0 ip_sublist_rcv+0x40/0xb0 ip_list_rcv+0x140/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+0xe4/0x1f0 napi_complete_done+0x70/0x1f0 gro_cell_poll+0x9c/0xb0 napi_poll+0xcc/0x264 net_rx_action+0xd4/0x21c __do_softirq+0x130/0x358 irq_exit+0x11c/0x13c __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x78/0x2c0 el1_irq+0xb8/0x140 arch_cpu_idle+0x18/0x40 default_idle_call+0x5c/0x1c0 cpuidle_idle_call+0x174/0x1b0 do_idle+0xc8/0x160 cpu_startup_entry+0x30/0x11c secondary_start_kernel+0x158/0x1e4 softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with preempt_count 00000100, exited with fffffe00?
- https://git.kernel.org/stable/c/02884a4f12de11f54d4ca67a07dd1f111d96fdbd
- https://git.kernel.org/stable/c/16e18a8ac7c9748cf35a8d2f0ba2c6e8850e7568
- https://git.kernel.org/stable/c/4a461ba5b9753352f438824fdd915cba675b1733
- https://git.kernel.org/stable/c/aa495dfe71229b9034b59d8072ff0b2325ddd5ee
- https://git.kernel.org/stable/c/c9be45e4c69fde36522274f04d1aa0d097ae3958
Modified: 2025-11-28
CVE-2022-50172
In the Linux kernel, the following vulnerability has been resolved: mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.
- https://git.kernel.org/stable/c/2f53ba46d8c97aca681adbe5098e1f84580c446d
- https://git.kernel.org/stable/c/3ad958bc488e3ecb0207d31621c00efb86f17482
- https://git.kernel.org/stable/c/cffd93411575afd987788e2ec3cb8eaff70f0215
- https://git.kernel.org/stable/c/da1ab462b96c5d47a0755aec957bae3d685538c5
- https://git.kernel.org/stable/c/f1609c4f4a21777e081b36596224802b85052ad9
Modified: 2025-11-28
CVE-2022-50173
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Fix global state lock backoff We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0. Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged in CI: WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0 Patchwork: https://patchwork.freedesktop.org/patch/492701/
- https://git.kernel.org/stable/c/0b07f28c23ff50a7fa5dbc3f6b3b6bd53ac9fc70
- https://git.kernel.org/stable/c/247f2934324f9a18d18df24ea4bfcc7d4631d0ef
- https://git.kernel.org/stable/c/2e34d6c8180a398de6448a93df25068bf3062042
- https://git.kernel.org/stable/c/2fdf5a54ef9376ff69149a48c5616f1141008c9f
- https://git.kernel.org/stable/c/92ef86ab513593c6329d04146e61f9a670e72fc5
- https://git.kernel.org/stable/c/bf386c955f35a0a01bef482b6035d40ff2f6cc75
- https://git.kernel.org/stable/c/f4e3a8c7e890049e7ba2b49ad0315dae841dfa55
Modified: 2025-11-28
CVE-2022-50174
In the Linux kernel, the following vulnerability has been resolved: net: hinic: avoid kernel hung in hinic_get_stats64() When using hinic device as a bond slave device, and reading device stats of master bond device, the kernel may hung. The kernel panic calltrace as follows: Kernel panic - not syncing: softlockup: hung tasks Call trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324 When getting device stats from bond, kernel will call bond_get_stats(). It first holds the spinlock bond->stats_lock, and then call hinic_get_stats64() to collect hinic device's stats. However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to protect its critical section, which may schedule current task out. And if system is under high pressure, the task cannot be woken up immediately, which eventually triggers kernel hung panic. Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local variable in hinic_get_stats64(), there is nothing need to be protected by lock, so just removing down()/up() is ok.
- https://git.kernel.org/stable/c/3ba59bbe4f306bb6ee15753db0a40564c0eb7909
- https://git.kernel.org/stable/c/693f31dc91568e61047fd2980a8235e856cd9ce8
- https://git.kernel.org/stable/c/98f9fcdee35add80505b6c73f72de5f750d5c03c
- https://git.kernel.org/stable/c/e74f3097a9c713ce855cda07713393bcc23a005d
- https://git.kernel.org/stable/c/fced5bce712122654ec8a20356342698cce104d2
Modified: 2025-11-28
CVE-2022-50175
In the Linux kernel, the following vulnerability has been resolved: media: tw686x: Fix memory leak in tw686x_video_init video_device_alloc() allocates memory for vdev, when video_register_device() fails, it doesn't release the memory and leads to memory leak, call video_device_release() to fix this.
- https://git.kernel.org/stable/c/0597bcf774896a002edcc7934a9cdbb932b66702
- https://git.kernel.org/stable/c/611f86965df013d6021e6cd0d155b1734ad2cf21
- https://git.kernel.org/stable/c/8b412db51db24dfba22c96948580d4a12f831397
- https://git.kernel.org/stable/c/c142a7531b90c6b0f946c82d3f504b3f36a207df
- https://git.kernel.org/stable/c/e0b212ec9d8177d6f7c404315293f6a085d6ee42
Modified: 2025-11-25
CVE-2022-50176
In the Linux kernel, the following vulnerability has been resolved: drm/mcde: Fix refcount leak in mcde_dsi_bind Every iteration of for_each_available_child_of_node() decrements the reference counter of the previous node. There is no decrement when break out from the loop and results in refcount leak. Add missing of_node_put() to fix this.
- https://git.kernel.org/stable/c/3123ae6fdd4013d24a3a4877084b14e917faae5c
- https://git.kernel.org/stable/c/32c827e30bb44ae809950a9efab59e98e44d30e5
- https://git.kernel.org/stable/c/3a149169e4a2f9127022fec6ef5d71b4e804b3b9
- https://git.kernel.org/stable/c/7214902de5b1fb2b632a7b8b3b9540e41aabab38
- https://git.kernel.org/stable/c/87c35bbefdfa3c5edfb8c80f5c04717aaacc629d
- https://git.kernel.org/stable/c/f57699a9b66ea11f000f56d1f1179059239b8690
Modified: 2025-11-28
CVE-2022-50177
In the Linux kernel, the following vulnerability has been resolved:
rcutorture: Fix ksoftirqd boosting timing and iteration
The RCU priority boosting can fail in two situations:
1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs
is higher than those brought online at boot, then torture_onoff() may
later bring up CPUs that weren't online on boot. Now since rcutorture
initialization only boosts the ksoftirqds of the CPUs that have been
set online on boot, the CPUs later set online by torture_onoff won't
benefit from the boost, making RCU priority boosting fail.
2) The ksoftirqd kthreads are boosted after the creation of
rcu_torture_boost() kthreads, which opens a window large enough for these
rcu_torture_boost() kthreads to wait (despite running at FIFO priority)
for ksoftirqds that are still running at SCHED_NORMAL priority.
The issues can trigger for example with:
./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y"
[ 34.968561] rcu-torture: !!!
[ 34.968627] ------------[ cut here ]------------
[ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610
[ 35.052043] Modules linked in:
[ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1
[ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
[ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610
[ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82
[ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202
[ 37.277320] rcu: De-offloading 8
[ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001
[ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff
[ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff
[ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20
[ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0
[ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000
[ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0
[ 37.290470] Call Trace:
[ 37.295049]
Modified: 2025-11-28
CVE-2022-50178
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: 8852a: rfk: fix div 0 exception
The DPK is a kind of RF calibration whose algorithm is to fine tune
parameters and calibrate, and check the result. If the result isn't good
enough, it could adjust parameters and try again.
This issue is to read and show the result, but it could be a negative
calibration result that causes divisor 0 and core dump. So, fix it by
phy_div() that does division only if divisor isn't zero; otherwise,
zero is adopted.
divide error: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1
Modified: 2025-11-20
CVE-2022-50179
In the Linux kernel, the following vulnerability has been resolved:
ath9k: fix use-after-free in ath9k_hif_usb_rx_cb
Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The
problem was in incorrect htc_handle->drv_priv initialization.
Probable call trace which can trigger use-after-free:
ath9k_htc_probe_device()
/* htc_handle->drv_priv = priv; */
ath9k_htc_wait_for_target() <--- Failed
ieee80211_free_hw() <--- priv pointer is freed
- https://git.kernel.org/stable/c/03ca957c5f7b55660957eda20b5db4110319ac7a
- https://git.kernel.org/stable/c/0ac4827f78c7ffe8eef074bc010e7e34bc22f533
- https://git.kernel.org/stable/c/62bc1ea5c7401d77eaf73d0c6a15f3d2e742856e
- https://git.kernel.org/stable/c/6b14ab47937ba441e75e8dbb9fbfc9c55efa41c6
- https://git.kernel.org/stable/c/ab7a0ddf5f1cdec63cb21840369873806fc36d80
- https://git.kernel.org/stable/c/b66ebac40f64336ae2d053883bee85261060bd27
- https://git.kernel.org/stable/c/e9e21206b8ea62220b486310c61277e7ebfe7cec
- https://git.kernel.org/stable/c/eccd7c3e2596b574241a7670b5b53f5322f470e5
Modified: 2025-11-20
CVE-2022-50181
In the Linux kernel, the following vulnerability has been resolved: virtio-gpu: fix a missing check to avoid NULL dereference 'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. [ kraxel: minor codestyle fixup ]
- https://git.kernel.org/stable/c/259773fc874258606c0121767a4a27466ff337eb
- https://git.kernel.org/stable/c/367882a5a9448b5e1ba756125308092d614cb96c
- https://git.kernel.org/stable/c/39caef09666c1d8274abf9472c72bcac236dc5fb
- https://git.kernel.org/stable/c/adbdd21983fa292e53aec3eab97306b2961ea887
- https://git.kernel.org/stable/c/bd63f11f4c3c46afec07d821f74736161ff6e526
Modified: 2025-11-19
CVE-2022-50182
In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Align upwards buffer size The hardware can support any image size WxH, with arbitrary W (image width) and H (image height) dimensions. Align upwards buffer size for both encoder and decoder. and leave the picture resolution unchanged. For decoder, the risk of memory out of bounds can be avoided. For both encoder and decoder, the driver will lift the limitation of resolution alignment. For example, the decoder can support jpeg whose resolution is 227x149 the encoder can support nv12 1080P, won't change it to 1920x1072.
Modified: 2025-11-19
CVE-2022-50183
In the Linux kernel, the following vulnerability has been resolved: drm/meson: encoder_cvbs: Fix refcount leak in meson_encoder_cvbs_init of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-19
CVE-2022-50184
In the Linux kernel, the following vulnerability has been resolved: drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-19
CVE-2022-50185
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() The last case label can write two buffers 'mc_reg_address[j]' and 'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE since there are no checks for this value in both case labels after the last 'j++'. Instead of changing '>' to '>=' there, add the bounds check at the start of the second 'case' (the first one already has it). Also, remove redundant last checks for 'j' index bigger than array size. The expression is always false. Moreover, before or after the patch 'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it seems it can be a valid value. Detected using the static analysis tool - Svace.
- https://git.kernel.org/stable/c/136f614931a2bb73616b292cf542da3a18daefd5
- https://git.kernel.org/stable/c/1f341053852be76f82610ce47a505d930512f05c
- https://git.kernel.org/stable/c/782e413e38dffd37cc85b08b1ccb982adb4a93ce
- https://git.kernel.org/stable/c/8508d6d23a247c29792ce2fc0df3f3404d6a6a80
- https://git.kernel.org/stable/c/9faff03617afeced1c4e5daa89e79b3906374342
- https://git.kernel.org/stable/c/db1a9add3f90ff1c641974d5bb910c16b87af4ef
- https://git.kernel.org/stable/c/deb603c5928e546609c0d5798e231d0205748943
- https://git.kernel.org/stable/c/ea73869df6ef386fc0feeb28ff66742ca835b18f
Modified: 2025-11-19
CVE-2022-50186
In the Linux kernel, the following vulnerability has been resolved: ath11k: fix missing skb drop on htc_tx_completion error On htc_tx_completion error the skb is not dropped. This is wrong since the completion_handler logic expect the skb to be consumed anyway even when an error is triggered. Not freeing the skb on error is a memory leak since the skb won't be freed anywere else. Correctly free the packet on eid >= ATH11K_HTC_EP_COUNT before returning. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Modified: 2025-11-19
CVE-2022-50187
In the Linux kernel, the following vulnerability has been resolved: ath11k: fix netdev open race Make sure to allocate resources needed before registering the device. This specifically avoids having a racing open() trigger a BUG_ON() in mod_timer() when ath11k_mac_op_start() is called before the mon_reap_timer as been set up. I did not see this issue with next-20220310, but I hit it on every probe with next-20220511. Perhaps some timing changed in between. Here's the backtrace: [ 51.346947] kernel BUG at kernel/time/timer.c:990! [ 51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ... [ 51.578225] Call trace: [ 51.583293] __mod_timer+0x298/0x390 [ 51.589518] mod_timer+0x14/0x20 [ 51.595368] ath11k_mac_op_start+0x41c/0x4a0 [ath11k] [ 51.603165] drv_start+0x38/0x60 [mac80211] [ 51.610110] ieee80211_do_open+0x29c/0x7d0 [mac80211] [ 51.617945] ieee80211_open+0x60/0xb0 [mac80211] [ 51.625311] __dev_open+0x100/0x1c0 [ 51.631420] __dev_change_flags+0x194/0x210 [ 51.638214] dev_change_flags+0x24/0x70 [ 51.644646] do_setlink+0x228/0xdb0 [ 51.650723] __rtnl_newlink+0x460/0x830 [ 51.657162] rtnl_newlink+0x4c/0x80 [ 51.663229] rtnetlink_rcv_msg+0x124/0x390 [ 51.669917] netlink_rcv_skb+0x58/0x130 [ 51.676314] rtnetlink_rcv+0x18/0x30 [ 51.682460] netlink_unicast+0x250/0x310 [ 51.688960] netlink_sendmsg+0x19c/0x3e0 [ 51.695458] ____sys_sendmsg+0x220/0x290 [ 51.701938] ___sys_sendmsg+0x7c/0xc0 [ 51.708148] __sys_sendmsg+0x68/0xd0 [ 51.714254] __arm64_sys_sendmsg+0x28/0x40 [ 51.720900] invoke_syscall+0x48/0x120 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
- https://git.kernel.org/stable/c/307ce58270b3b50ca21cfcc910568429b06803f7
- https://git.kernel.org/stable/c/a2c45f8c3d18269e641f0c7da2dde47ef8414034
- https://git.kernel.org/stable/c/abb7dc8fbb27c15dcc927df56190f3c5ede58bd5
- https://git.kernel.org/stable/c/d4ba1ff87b17e81686ada8f429300876f55f95ad
- https://git.kernel.org/stable/c/eaff3946a86fc63280a30158a4ae1e141449817c
Modified: 2025-11-19
CVE-2022-50188
In the Linux kernel, the following vulnerability has been resolved: drm/meson: Fix refcount leak in meson_encoder_hdmi_init of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() in error path to avoid refcount leak.
Modified: 2025-11-19
CVE-2022-50190
In the Linux kernel, the following vulnerability has been resolved: spi: Fix simplification of devm_spi_register_controller This reverts commit 59ebbe40fb51 ("spi: simplify devm_spi_register_controller"). If devm_add_action() fails in devm_add_action_or_reset(), devm_spi_unregister() will be called, it decreases the refcount of 'ctlr->dev' to 0, then it will cause uaf in the drivers that calling spi_put_controller() in error path.
Modified: 2025-11-19
CVE-2022-50191
In the Linux kernel, the following vulnerability has been resolved: regulator: of: Fix refcount leak bug in of_get_regulation_constraints() We should call the of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
- https://git.kernel.org/stable/c/11ecb4f8735b0230d54a82c18b21ea778b695d61
- https://git.kernel.org/stable/c/332e555dca074c4eb2084898021c3676423814c3
- https://git.kernel.org/stable/c/35f9e861d9b9434903a8ede37a3561f78985826d
- https://git.kernel.org/stable/c/66efb665cd5ad69b27dca8571bf89fc6b9c628a4
- https://git.kernel.org/stable/c/a23098cc32860272dc6c3200ff20c34c65b7b694
- https://git.kernel.org/stable/c/b9ca8585c766616563cf3c062c6878f61f83cf00
- https://git.kernel.org/stable/c/c9df8ff290097aabd5c9200f7f729b0813d37b19
- https://git.kernel.org/stable/c/fc7b19f547bc9e622060a0a9a39da2330aa21c53
Modified: 2025-11-19
CVE-2022-50192
In the Linux kernel, the following vulnerability has been resolved: spi: tegra20-slink: fix UAF in tegra_slink_remove() After calling spi_unregister_master(), the refcount of master will be decrease to 0, and it will be freed in spi_controller_release(), the device data also will be freed, so it will lead a UAF when using 'tspi'. To fix this, get the master before unregister and put it when finish using it.
Modified: 2025-11-19
CVE-2022-50193
In the Linux kernel, the following vulnerability has been resolved:
erofs: wake up all waiters after z_erofs_lzma_head ready
When the user mounts the erofs second times, the decompression thread
may hung. The problem happens due to a sequence of steps like the
following:
1) Task A called z_erofs_load_lzma_config which obtain all of the node
from the z_erofs_lzma_head.
2) At this time, task B called the z_erofs_lzma_decompress and wanted to
get a node. But the z_erofs_lzma_head was empty, the Task B had to
sleep.
3) Task A release nodes and push nodes into the z_erofs_lzma_head. But
task B was still sleeping.
One example report when the hung happens:
task:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000
Workqueue: erofs_unzipd z_erofs_decompressqueue_work
Call Trace:
Modified: 2025-11-19
CVE-2022-50194
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register 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 child node. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/053543ac1d095132fcfd1263805d6e25afbdc6a8
- https://git.kernel.org/stable/c/591f0697ccbac33760d3bb1ad96a5ba2b76ae9f0
- https://git.kernel.org/stable/c/97713ed9b6cc4abaa2dcc8357113c56520dc6d7f
- https://git.kernel.org/stable/c/bc73c72a856c26df7410ddf15f42257cb4960fe9
- https://git.kernel.org/stable/c/ca83c61a6ccf3934cf8d01d5ade30a5034993a86
- https://git.kernel.org/stable/c/e6e0951414a314e7db3e9e24fd924b3e15515288
Modified: 2025-11-19
CVE-2022-50195
In the Linux kernel, the following vulnerability has been resolved: ARM: dts: qcom: replace gcc PXO with pxo_board fixed clock Replace gcc PXO phandle to pxo_board fixed clock declared in the dts. gcc driver doesn't provide PXO_SRC as it's a fixed-clock. This cause a kernel panic if any driver actually try to use it.
Modified: 2025-11-19
CVE-2022-50196
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: ocmem: Fix refcount leak in of_get_ocmem 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/07aea6819d569d1e172227486655e4fb5bd4cdb9
- https://git.kernel.org/stable/c/84a928b44cb303d5756e3bff2734921de8dce4f6
- https://git.kernel.org/stable/c/92a563fcf14b3093226fb36f12e9b5cf630c5a5d
- https://git.kernel.org/stable/c/a1e4243c0dddeafb4ace6d9906d3f5129b81a9fe
- https://git.kernel.org/stable/c/ed40a48d0a9166edb22e2b8efafea822e93dd79a
Modified: 2025-11-19
CVE-2022-50197
In the Linux kernel, the following vulnerability has been resolved: cpufreq: zynq: Fix refcount leak in zynq_get_revision 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/179034fb108e3655142f2af0c309cef171c34d68
- https://git.kernel.org/stable/c/22e6d8bcde8e66b64f46bf9bd2d3d0f88d40c39f
- https://git.kernel.org/stable/c/3b01353f1825151a29d08e0868b2bf01e1116ab5
- https://git.kernel.org/stable/c/a530fa52d4fdffc5f010f90c05ac63019b8ff5f8
- https://git.kernel.org/stable/c/d1ff2559cef0f6f8d97fba6337b28adb10689e16
- https://git.kernel.org/stable/c/dcbb974254d2a27240c2e50185afdde90f923feb
- https://git.kernel.org/stable/c/ecefd22d5db7ccb8bec2646e5d25e058fc33162a
- https://git.kernel.org/stable/c/f52c9be1779d70037ae300762d19b08fe3656237
Modified: 2025-11-19
CVE-2022-50198
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: Fix refcount leak in omap3xxx_prm_late_init 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.
- https://git.kernel.org/stable/c/1bf747824a8ca4008879fd7d2ce6b03d7b428858
- https://git.kernel.org/stable/c/942228fbf5d4901112178b93d41225be7c0dd9de
- https://git.kernel.org/stable/c/c4f92af7fc8cecb8eb426ad187e39c7bcc6679c7
- https://git.kernel.org/stable/c/c652e0f51665f3fa575449909bbd9d7b45dfab1c
- https://git.kernel.org/stable/c/c9ec7993d00250a394d367c8a19fcfe8211c258b
- https://git.kernel.org/stable/c/d294d60dc68550fee0fbbe8a638d798dcd40b2c5
- https://git.kernel.org/stable/c/e5ab8a4967d68a8e9f8f4559d144207d085a8c02
Modified: 2025-11-19
CVE-2022-50199
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: Fix refcount leak in omapdss_init_of omapdss_find_dss_of_node() calls of_find_compatible_node() to get device node. 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() in later error path and normal path.
- https://git.kernel.org/stable/c/14bac0c7035bf920e190a63c7e1b113c72eadbf4
- https://git.kernel.org/stable/c/230ad40a59c9a9ee8f3822b9a7bec09404102ebc
- https://git.kernel.org/stable/c/507159facf002d113c4878fec67f37d62f187887
- https://git.kernel.org/stable/c/935035cf97c8cd6794044b500fb0a44a6d30ffa1
- https://git.kernel.org/stable/c/9705db1eff38d6b9114121f9e253746199b759c9
- https://git.kernel.org/stable/c/a32dc6829e33c54e751346aa3e08ddb6d0e1a6a0
Modified: 2025-11-19
CVE-2022-50200
In the Linux kernel, the following vulnerability has been resolved: selinux: Add boundary check in put_entry() Just like next_entry(), boundary check is necessary to prevent memory out-of-bound access.
- https://git.kernel.org/stable/c/15ec76fb29be31df2bccb30fc09875274cba2776
- https://git.kernel.org/stable/c/2dabe6a872a5744865372eb30ea51e8ccd21305a
- https://git.kernel.org/stable/c/477722f31ad73aa779154d1d7e00825538389f76
- https://git.kernel.org/stable/c/7363a69d8ca8f0086f8e1196c8ddaf0e168614b1
- https://git.kernel.org/stable/c/90bdf50ae70c5571a277b5601e4f5df210831e0a
- https://git.kernel.org/stable/c/9605f50157cae00eb299e1189a6d708c84935ad8
- https://git.kernel.org/stable/c/adbfdaacde18faf6cd4e490764045375266b3fbd
- https://git.kernel.org/stable/c/dedd558d9765b72c66e5a53948e9f5abc3ece1f6
Modified: 2025-11-19
CVE-2022-50201
In the Linux kernel, the following vulnerability has been resolved: selinux: fix memleak in security_read_state_kernel() In this function, it directly returns the result of __security_read_policy without freeing the allocated memory in *data, cause memory leak issue, so free the memory if __security_read_policy failed. [PM: subject line tweak]
Modified: 2025-11-19
CVE-2022-50202
In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: defer device probing when resuming from hibernation syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e. broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface. This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface.
- https://git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570
- https://git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8
- https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50
- https://git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb
- https://git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59
- https://git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91
- https://git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258
- https://git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f
Modified: 2025-11-19
CVE-2022-50203
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: display: Fix refcount leak bug In omapdss_init_fbdev(), of_find_node_by_name() 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/0b4f96b47ff8dc2fa35d03c4116927248796d9af
- https://git.kernel.org/stable/c/2629d171f3d6451724549d8d10d14ac6da37a7be
- https://git.kernel.org/stable/c/3e505298a75f0bbdc96e923e76e5d45d6c8f64a7
- https://git.kernel.org/stable/c/496988a19d5c36fabf97c847db39167e42393c74
- https://git.kernel.org/stable/c/50b87a32a79bca6e275918a711fb8cc55e16d739
- https://git.kernel.org/stable/c/88d556029a78999b098d26a330bb6a7de166f426
- https://git.kernel.org/stable/c/a89a865dc9f0600fd146224e314775b9efc9d845
- https://git.kernel.org/stable/c/bdbdf69d5b78c5712c60c0004fa6aed12da36e26
Modified: 2025-11-19
CVE-2022-50204
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: pdata-quirks: Fix refcount leak bug In pdata_quirks_init_clocks(), the loop contains of_find_node_by_name() but without corresponding of_node_put().
Modified: 2025-11-19
CVE-2022-50205
In the Linux kernel, the following vulnerability has been resolved: ext2: Add more validity checks for inode counts Add checks verifying number of inodes stored in the superblock matches the number computed from number of inodes per group. Also verify we have at least one block worth of inodes per group. This prevents crashes on corrupted filesystems.
- https://git.kernel.org/stable/c/07303a9abe3a997d9864fb4315e34b5acfe8fc25
- https://git.kernel.org/stable/c/0bcdc31094a12b4baf59e241feabc9787cf635fa
- https://git.kernel.org/stable/c/5e63c5fe9123fa76ffaeff26c211308736ec3a07
- https://git.kernel.org/stable/c/7a48fdc88a3c35e046a6a0a38eba00f21c65b16e
- https://git.kernel.org/stable/c/96b18d3a1be0354ccce43f0ef61b5a3d7e432552
- https://git.kernel.org/stable/c/b3f423683818cfe15de14d5d9dff44148ff16bbf
- https://git.kernel.org/stable/c/d08bb199a406424a8ed0009efdf41710e6d849ee
- https://git.kernel.org/stable/c/fa78f336937240d1bc598db817d638086060e7e9
Modified: 2025-11-19
CVE-2022-50206
In the Linux kernel, the following vulnerability has been resolved: arm64: fix oops in concurrently setting insn_emulation sysctls emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing.
- https://git.kernel.org/stable/c/04549063d5701976034d8c2bfda3d3a8cbf0409f
- https://git.kernel.org/stable/c/07022e07017ee5540f5559b0aeb916e8383c1e1a
- https://git.kernel.org/stable/c/353b4673d01c512303c45cf2346f630cda73b5c9
- https://git.kernel.org/stable/c/6a2fd114678d7fc1b5a0f8865ae98f1c17787455
- https://git.kernel.org/stable/c/9d5fec6ba2e4117d196a8259ab54615ffe562460
- https://git.kernel.org/stable/c/af483947d472eccb79e42059276c4deed76f99a6
- https://git.kernel.org/stable/c/b51881b1da57fe9877125dfdd0aac5172958fcfd
- https://git.kernel.org/stable/c/cc69ef95988b9ef2fc730ec452a7441efb90ef5e
Modified: 2025-11-19
CVE-2022-50207
In the Linux kernel, the following vulnerability has been resolved: ARM: bcm: Fix refcount leak in bcm_kona_smc_init 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.
- https://git.kernel.org/stable/c/02b658bfb26452f2c13e4577a13ab802f89a6642
- https://git.kernel.org/stable/c/5afe042c889437de83f38a9d73d145742fb4f65f
- https://git.kernel.org/stable/c/62d719d31ec667276d7375b64542b080cf187797
- https://git.kernel.org/stable/c/75866df2b1d673df5b7781e565ada753a7895f04
- https://git.kernel.org/stable/c/91e7f04f53e680bc72f0a9a5c682ab652100b9c8
- https://git.kernel.org/stable/c/bc7f487395f208fd9af69e9a807815e10435aba7
- https://git.kernel.org/stable/c/c6964cb9ac7a43bf78e7d60126e2722992de2ea1
- https://git.kernel.org/stable/c/cb23389a2458c2e4bfd6c86a513cbbe1c4d35e76
Modified: 2025-11-20
CVE-2022-50208
In the Linux kernel, the following vulnerability has been resolved: soc: amlogic: Fix refcount leak in meson-secure-pwrc.c In meson_secure_pwrc_probe(), there is a refcount leak in one fail path.
- https://git.kernel.org/stable/c/5509d07a9364b75b28055bf2d89289e4e5269929
- https://git.kernel.org/stable/c/80c469e63bfa9a5a8114952bffc6a7d241e7497e
- https://git.kernel.org/stable/c/d18529a4c12f66d83daac78045ea54063bd43257
- https://git.kernel.org/stable/c/d1fbbb5ded714b6610a16ec3d7e271a55291ccc4
- https://git.kernel.org/stable/c/f370fbbd3151c1c87d1e976c8964cb6cc46f2e00
Modified: 2025-11-19
CVE-2022-50209
In the Linux kernel, the following vulnerability has been resolved: meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init 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.
- https://git.kernel.org/stable/c/0c1757480a6a61b8c3164ed371c359edb3928f12
- https://git.kernel.org/stable/c/2691b8780f88e1b8b3578a5bc78a0011741bbd74
- https://git.kernel.org/stable/c/69a64c77aafcf3c772264a36214937514e31ad82
- https://git.kernel.org/stable/c/6b28bf3e044f12db0fc18c42f58ae7fc3fa0144a
- https://git.kernel.org/stable/c/8a4a33b3e898b13c750b1c0c9643516c7bf6473f
- https://git.kernel.org/stable/c/a2106f38077e78afcb4bf98fdda3e162118cfb3d
- https://git.kernel.org/stable/c/e21744c6a0d4116a2d6ebccd947620ca4c952e92
Modified: 2025-11-19
CVE-2022-50210
In the Linux kernel, the following vulnerability has been resolved: MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
- https://git.kernel.org/stable/c/274e44e2123417e0924c90d4b4531913b5f3aa2e
- https://git.kernel.org/stable/c/4cb392956ae392aec4aa06e661a0bb9146b0bace
- https://git.kernel.org/stable/c/7d305823e02217b29d41fca67e3cef87fd7bd688
- https://git.kernel.org/stable/c/807adf6ffa8c3beedcd63b20f5a59c7d061df7d2
- https://git.kernel.org/stable/c/8916ec149c79cb21f5454fa7840ad96f99cf51cf
- https://git.kernel.org/stable/c/98aaa511957667ba26d6dabe28dfa210a8f53a63
- https://git.kernel.org/stable/c/d3ac4e47510ec0753ebe1e418a334ad202784aa8
- https://git.kernel.org/stable/c/e1a534f5d074db45ae5cbac41d8912b98e96a006
- https://git.kernel.org/stable/c/e41db8a9ce696a3382a4f098878fd4d14bccd201
Modified: 2025-11-19
CVE-2022-50211
In the Linux kernel, the following vulnerability has been resolved:
md-raid10: fix KASAN warning
There's a KASAN warning in raid10_remove_disk when running the lvm
test lvconvert-raid-reshape.sh. We fix this warning by verifying that the
value "number" is valid.
BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682
CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/0f4d18cbea4a6e37a05fd8ee2887439f85211110
- https://git.kernel.org/stable/c/5f57843565131bb782388f9d993f9ee8f453dee1
- https://git.kernel.org/stable/c/5fd4ffa2372a41361d2bdd27ea5730e4e673240c
- https://git.kernel.org/stable/c/75fbd370a2cec9e92f48285bd90735ed0c837f52
- https://git.kernel.org/stable/c/7a6ccc8fa192fd357c2d5d4c6ce67c834a179e23
- https://git.kernel.org/stable/c/bcbdc26a44aba488d2f7122f2d66801bccb74733
- https://git.kernel.org/stable/c/bf30b9ba09b0ac2a10f04dce2b0835ec4d178aa6
- https://git.kernel.org/stable/c/ce839b9331c11780470f3d727b6fe3c2794a4620
- https://git.kernel.org/stable/c/d17f744e883b2f8d13cca252d71cfe8ace346f7d
Modified: 2025-11-19
CVE-2022-50212
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not allow CHAIN_ID to refer to another table When doing lookups for chains on the same batch by using its ID, a chain from a different table can be used. If a rule is added to a table but refers to a chain in a different table, it will be linked to the chain in table2, but would have expressions referring to objects in table1. Then, when table1 is removed, the rule will not be removed as its linked to a chain in table2. When expressions in the rule are processed or removed, that will lead to a use-after-free. When looking for chains by ID, use the table that was used for the lookup by name, and only return chains belonging to that same table.
- https://git.kernel.org/stable/c/0f49613a213d918af790c1276f79da741968de11
- https://git.kernel.org/stable/c/58e863f64ee3d0879297e5e53b646e4b91e59620
- https://git.kernel.org/stable/c/91501513016903077f91033fa5d2aa26cac399b2
- https://git.kernel.org/stable/c/95f466d22364a33d183509629d0879885b4f547e
- https://git.kernel.org/stable/c/9e7dcb88ec8e85e4a8ad0ea494ea2f90f32d2583
Modified: 2025-11-19
CVE-2022-50213
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not allow SET_ID to refer to another table When doing lookups for sets on the same batch by using its ID, a set from a different table can be used. Then, when the table is removed, a reference to the set may be kept after the set is freed, leading to a potential use-after-free. When looking for sets by ID, use the table that was used for the lookup by name, and only return sets belonging to that same table. This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.
- https://git.kernel.org/stable/c/0d07039397527361850c554c192e749cfc879ea9
- https://git.kernel.org/stable/c/1a4b18b1ff11ba26f9a852019d674fde9d1d1cff
- https://git.kernel.org/stable/c/470ee20e069a6d05ae549f7d0ef2bdbcee6a81b2
- https://git.kernel.org/stable/c/77d3b5038b7462318f5183e2ad704b01d57215a2
- https://git.kernel.org/stable/c/f4fa03410f7c5f5bd8f90e9c11e9a8c4b526ff6f
- https://git.kernel.org/stable/c/faafd9286f1355c76fe9ac3021c280297213330e
- https://git.kernel.org/stable/c/fab2f61cc3b0e441b1749f017cfee75f9bbaded7
Modified: 2025-11-19
CVE-2022-50214
In the Linux kernel, the following vulnerability has been resolved: coresight: Clear the connection field properly coresight devices track their connections (output connections) and hold a reference to the fwnode. When a device goes away, we walk through the devices on the coresight bus and make sure that the references are dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data() b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match(). However, the coresight_remove_match() doesn't clear the fwnode field, after dropping the reference, this causes use-after-free and additional refcount drops on the fwnode. e.g., if we have two devices, A and B, with a connection, A -> B. If we remove B first, B would clear the reference on B, from A via coresight_remove_match(). But when A is removed, it still has a connection with fwnode still pointing to B. Thus it tries to drops the reference in coresight_release_platform_data(), raising the bells like : [ 91.990153] ------------[ cut here ]------------ [ 91.990163] refcount_t: addition on 0; use-after-free. [ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144 [ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug] [ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53 [ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 [ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 91.990454] pc : refcount_warn_saturate+0xa0/0x144 [ 91.990476] lr : refcount_warn_saturate+0xa0/0x144 [ 91.990496] sp : ffff80000c843640 [ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8 [ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8 [ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2 [ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40 [ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0 [ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375 [ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28 [ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572 [ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027 [ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00 [ 91.991000] Call trace: [ 91.991012] refcount_warn_saturate+0xa0/0x144 [ 91.991034] kobject_get+0xac/0xb0 [ 91.991055] of_node_get+0x2c/0x40 [ 91.991076] of_fwnode_get+0x40/0x60 [ 91.991094] fwnode_handle_get+0x3c/0x60 [ 91.991116] fwnode_get_nth_parent+0xf4/0x110 [ 91.991137] fwnode_full_name_string+0x48/0xc0 [ 91.991158] device_node_string+0x41c/0x530 [ 91.991178] pointer+0x320/0x3ec [ 91.991198] vsnprintf+0x23c/0x750 [ 91.991217] vprintk_store+0x104/0x4b0 [ 91.991238] vprintk_emit+0x8c/0x360 [ 91.991257] vprintk_default+0x44/0x50 [ 91.991276] vprintk+0xcc/0xf0 [ 91.991295] _printk+0x68/0x90 [ 91.991315] of_node_release+0x13c/0x14c [ 91.991334] kobject_put+0x98/0x114 [ 91.991354] of_node_put+0x24/0x34 [ 91.991372] of_fwnode_put+0x40/0x5c [ 91.991390] fwnode_handle_put+0x38/0x50 [ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight] [ 91.991472] coresight_unregister+0x64/0xcc [coresight] [ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x] [ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x] [ 91.991598] amba_remove+0x3c/0x19c ---truncated---
- https://git.kernel.org/stable/c/2af89ebacf299b7fba5f3087d35e8a286ec33706
- https://git.kernel.org/stable/c/847b9273dd61567fb77617eabc5fa002594db062
- https://git.kernel.org/stable/c/b49b29ee113a87997bcca0bb0585bb46582846c1
- https://git.kernel.org/stable/c/bc57850fcb7e4cb91b6321d0ce83357cefd55c54
- https://git.kernel.org/stable/c/d43e967963c4d1b2b49f894d2f1b12865f87b098
- https://git.kernel.org/stable/c/e9205d8dd1cafb7cff689ef9ddf06276a68f54a4
Modified: 2025-11-19
CVE-2022-50215
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Allow waiting for commands to complete on removed device When a SCSI device is removed while in active use, currently sg will immediately return -ENODEV on any attempt to wait for active commands that were sent before the removal. This is problematic for commands that use SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel when userspace frees or reuses it after getting ENODEV, leading to corrupted userspace memory (in the case of READ-type commands) or corrupted data being sent to the device (in the case of WRITE-type commands). This has been seen in practice when logging out of a iscsi_tcp session, where the iSCSI driver may still be processing commands after the device has been marked for removal. Change the policy to allow userspace to wait for active sg commands even when the device is being removed. Return -ENODEV only when there are no more responses to read.
- https://git.kernel.org/stable/c/03d8241112d5e3cccce1a01274a221099f07d2e1
- https://git.kernel.org/stable/c/3455607fd7be10b449f5135c00dc306b85dc0d21
- https://git.kernel.org/stable/c/35e60ec39e862159cb92923eefd5230d4a873cb9
- https://git.kernel.org/stable/c/408bfa1489a3cfe7150b81ab0b0df99b23dd5411
- https://git.kernel.org/stable/c/8c004b7dbb340c1e5889f5fb9e5baa6f6e5303e8
- https://git.kernel.org/stable/c/bbc118acf7baf9e93c5e1314d14f481301af4d0f
- https://git.kernel.org/stable/c/ed9afd967cbfe7da2dc0d5e52c62a778dfe9f16b
- https://git.kernel.org/stable/c/f135c65085eed869d10e4e7923ce1015288618da
- https://git.kernel.org/stable/c/f5e61d9b4a699dd16f32d5f39eb1cf98d84c92ed
Modified: 2025-11-19
CVE-2022-50217
In the Linux kernel, the following vulnerability has been resolved: fuse: write inode in fuse_release() A race between write(2) and close(2) allows pages to be dirtied after fuse_flush -> write_inode_now(). If these pages are not flushed from fuse_release(), then there might not be a writable open file later. So any remaining dirty pages must be written back before the file is released. This is a partial revert of the blamed commit.
Modified: 2025-11-19
CVE-2022-50218
In the Linux kernel, the following vulnerability has been resolved: iio: light: isl29028: Fix the warning in isl29028_remove() The driver use the non-managed form of the register function in isl29028_remove(). To keep the release order as mirroring the ordering in probe, the driver should use non-managed form in probe, too. The following log reveals it: [ 32.374955] isl29028 0-0010: remove [ 32.376861] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI [ 32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0 [ 32.385461] Call Trace: [ 32.385807] sysfs_unmerge_group+0x59/0x110 [ 32.386110] dpm_sysfs_remove+0x58/0xc0 [ 32.386391] device_del+0x296/0xe50 [ 32.386959] cdev_device_del+0x1d/0xd0 [ 32.387231] devm_iio_device_unreg+0x27/0xb0 [ 32.387542] devres_release_group+0x319/0x3d0 [ 32.388162] i2c_device_remove+0x93/0x1f0
- https://git.kernel.org/stable/c/06674fc7c003b9d0aa1d37fef7ab2c24802cc6ad
- https://git.kernel.org/stable/c/359f3b150eab30805fe0e4e9d616887d7257a625
- https://git.kernel.org/stable/c/4f0ebfb4b9bfad2326c0b2c3cc7e37f4b9ee9eba
- https://git.kernel.org/stable/c/a1135205b0affd255510775a27df571aca84ab4b
- https://git.kernel.org/stable/c/ca63d5abf404d2934e2ac03545350de7bb8c8e96
- https://git.kernel.org/stable/c/ed43fb20d3d1fca9d79db0d5faf4321a4dd58c23
- https://git.kernel.org/stable/c/fac589fb764699a4bcd288f6656b8cd0408ea968
- https://git.kernel.org/stable/c/fb1888205c0782f287e5dd4ffff1f665332e868c
Modified: 2025-11-19
CVE-2022-50219
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix KASAN use-after-free Read in compute_effective_progs Syzbot found a Use After Free bug in compute_effective_progs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpf_link_detach on them. Link detach triggers the link to be freed by bpf_link_free(), which calls __cgroup_bpf_detach() and update_effective_progs(). If the memory allocation in this function fails, the function restores the pointer to the bpf_cgroup_link on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to update_effective_progs() causes this already deallocated pointer to be dereferenced in prog_list_length(), and triggers KASAN UAF error. To fix this issue don't preserve the pointer to the prog or link in the list, but remove it and replace it with a dummy prog without shrinking the table. The subsequent call to __cgroup_bpf_detach() or __cgroup_bpf_detach() will correct it.
- https://git.kernel.org/stable/c/1f8ca9c40e6222ce431e9ba5dae3cccce8ef9443
- https://git.kernel.org/stable/c/3527e3cbb84d8868c4d4e91ba55915f96d39ec3d
- https://git.kernel.org/stable/c/4c46091ee985ae84c60c5e95055d779fcd291d87
- https://git.kernel.org/stable/c/6336388715afa419cc97d0255bda3bba1b96b7ca
- https://git.kernel.org/stable/c/be001f9da71eaa3b61e186fb88bde3279728bdca
Modified: 2025-11-19
CVE-2022-50220
In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix linkwatch use-after-free on disconnect usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock": https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). * usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf ("drivers/net: don't use flush_scheduled_work()"). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last.
- https://git.kernel.org/stable/c/135199a2edd459d2b123144efcd7f9bcd95128e4
- https://git.kernel.org/stable/c/635fd8953e4309b54ca6a81bed1d4a87668694f4
- https://git.kernel.org/stable/c/7f77dcbc030c2faa6d8e8a594985eeb34018409e
- https://git.kernel.org/stable/c/8b4588b8b00b299be16a35be67b331d8fdba03f3
- https://git.kernel.org/stable/c/a69e617e533edddf3fa3123149900f36e0a6dc74
- https://git.kernel.org/stable/c/d2d6b530d89b0a912148018027386aa049f0a309
- https://git.kernel.org/stable/c/d49bb8cf9bfaa06aa527eb30f1a52a071da2e32f
- https://git.kernel.org/stable/c/db3b738ae5f726204876f4303c49cfdf4311403f
- https://git.kernel.org/stable/c/e2a521a7dcc463c5017b4426ca0804e151faeff7
Modified: 2025-11-19
CVE-2022-50221
In the Linux kernel, the following vulnerability has been resolved: drm/fb-helper: Fix out-of-bounds access Clip memory range to screen-buffer size to avoid out-of-bounds access in fbdev deferred I/O's damage handling. Fbdev's deferred I/O can only track pages. From the range of pages, the damage handler computes the clipping rectangle for the display update. If the fbdev screen buffer ends near the beginning of a page, that page could contain more scanlines. The damage handler would then track these non-existing scanlines as dirty and provoke an out-of-bounds access during the screen update. Hence, clip the maximum memory range to the size of the screen buffer. While at it, rename the variables min/max to min_off/max_off in drm_fb_helper_deferred_io(). This avoids confusion with the macros of the same name.
Modified: 2025-11-19
CVE-2022-50222
In the Linux kernel, the following vulnerability has been resolved:
tty: vt: initialize unicode screen buffer
syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read
immediately after resize operation. Initialize buffer using kzalloc().
----------
#include
- https://git.kernel.org/stable/c/446f123aa6021e5f75a20789f05ff3f7ae51a42f
- https://git.kernel.org/stable/c/5c6c65681f39bf71bc72ed589dec3b8b20e75cac
- https://git.kernel.org/stable/c/777a462e1ae50a01fc4a871efa8e34d596a1e17d
- https://git.kernel.org/stable/c/af77c56aa35325daa2bc2bed5c2ebf169be61b86
- https://git.kernel.org/stable/c/cc9e874dace0c89ae535230c7da19b764746811e
- https://git.kernel.org/stable/c/e02fa87e572bb7d90dcdbce9c0f519f1eb992e96
- https://git.kernel.org/stable/c/e0ef23e9b0ad18b9fd3741b0f1ad2282e4a18def
Modified: 2025-11-19
CVE-2022-50224
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT
Treat the NX bit as valid when using NPT, as KVM will set the NX bit when
the NX huge page mitigation is enabled (mindblowing) and trigger the WARN
that fires on reserved SPTE bits being set.
KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:
Refuse to load kvm_amd if NX support is not available") for exactly this
reason, but apparently it never occurred to anyone to actually test NPT
with the mitigation enabled.
------------[ cut here ]------------
spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000
WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm]
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022
RIP: 0010:make_spte+0x327/0x340 [kvm]
Call Trace:
Modified: 2025-11-19
CVE-2022-50225
In the Linux kernel, the following vulnerability has been resolved:
riscv:uprobe fix SR_SPIE set/clear handling
In riscv the process of uprobe going to clear spie before exec
the origin insn,and set spie after that.But When access the page
which origin insn has been placed a page fault may happen and
irq was disabled in arch_uprobe_pre_xol function,It cause a WARN
as follows.
There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.
We can just remove it.
[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488
[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work
[ 31.684929] preempt_count: 0, expected: 0
[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G
[ 31.686542] Hardware name: riscv-virtio,qemu (DT)
[ 31.686797] Call Trace:
[ 31.687053] [
Modified: 2025-11-19
CVE-2022-50226
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak For some sev ioctl interfaces, input may be passed that is 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 buffer, the sev ioctl interfaces with the issue may return uninitialized slab memory. Currently, all of the ioctl interfaces in the ccp driver are safe, but to prevent future problems, change all ioctl interfaces that allocate memory with kmalloc to use kzalloc and memset the data buffer to zero in sev_ioctl_do_platform_status.
- https://git.kernel.org/stable/c/13dc15a3f5fd7f884e4bfa8c011a0ae868df12ae
- https://git.kernel.org/stable/c/4c5300f6f5e18b11c02a92f136e69b98fddba15e
- https://git.kernel.org/stable/c/caa395aa16e7c9193fd7fa6cde462dd8229d4953
- https://git.kernel.org/stable/c/e11fb0a3a39bb42da35fa662c46ce7391f277436
- https://git.kernel.org/stable/c/f2a920daa780956b987c14b9f23de7c3c8915bf2
Modified: 2025-11-19
CVE-2022-50228
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0
Don't BUG/WARN on interrupt injection due to GIF being cleared,
since it's trivial for userspace to force the situation via
KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct
for KVM internally generated injections).
kernel BUG at arch/x86/kvm/svm/svm.c:3386!
invalid opcode: 0000 [#1] SMP
CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]
Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53
RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006
RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0
RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000
FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0
Call Trace:
- https://git.kernel.org/stable/c/2c49adeb020995236e63722ef6d0bee14372f471
- https://git.kernel.org/stable/c/2eee1dba70f57148fc7f8252613bfae6bd4b04e3
- https://git.kernel.org/stable/c/3d4e2d884da6312df7c9b85fbf671de49204ead6
- https://git.kernel.org/stable/c/68e1313bb8809e8addcd9431f2bfea0e8ddbca80
- https://git.kernel.org/stable/c/6afe88fbb40eac3291a8728688d61fdc745d8008
- https://git.kernel.org/stable/c/6fcbab82ccbcde915644085f73d3487938bda42d
- https://git.kernel.org/stable/c/8bb683490278005b4caf61e22b0828a04d282e86
- https://git.kernel.org/stable/c/c3396c1c8b87510f2ac2a674948156577559d42d
- https://git.kernel.org/stable/c/f17c31c48e5cde9895a491d91c424eeeada3e134
Modified: 2025-11-19
CVE-2022-50229
In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: Fix a UAF bug on the error path of probing When the driver fails in snd_card_register() at probe time, it will free the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug. The following log can reveal it: [ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] [ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0 [ 50.729530] Call Trace: [ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] Fix this by adding usb_kill_urb() before usb_free_urb().
- https://git.kernel.org/stable/c/05e0bb8c3c4dde3e21b9c1cf9395afb04e8b24db
- https://git.kernel.org/stable/c/1d6a246cf97c380f2da76591f03019dd9c9599c3
- https://git.kernel.org/stable/c/348620464a5c127399ac09b266f494f393661952
- https://git.kernel.org/stable/c/4fc41f7ebb7efca282f1740ea934d16f33c1d109
- https://git.kernel.org/stable/c/5e7338f4dd92b2f8915a82abfa1dd3ad3464bea0
- https://git.kernel.org/stable/c/64ca7f50ad96c2c65ae390b954925a36eabe04aa
- https://git.kernel.org/stable/c/a718eba7e458e2f40531be3c6b6a0028ca7fcace
- https://git.kernel.org/stable/c/b0d4af0a4763ddc02344789ef2a281c494bc330d
- https://git.kernel.org/stable/c/ffb2759df7efbc00187bfd9d1072434a13a54139
Modified: 2025-11-19
CVE-2022-50230
In the Linux kernel, the following vulnerability has been resolved: arm64: set UXN on swapper page tables [ This issue was fixed upstream by accident in c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map") as part of a large refactoring of the arm64 boot flow. This simple fix is therefore preferred for -stable backporting ] On a system that implements FEAT_EPAN, read/write access to the idmap is denied because UXN is not set on the swapper PTEs. As a result, idmap_kpti_install_ng_mappings panics the kernel when accessing __idmap_kpti_flag. Fix it by setting UXN on these PTEs.
Modified: 2025-11-19
CVE-2022-50231
In the Linux kernel, the following vulnerability has been resolved:
crypto: arm64/poly1305 - fix a read out-of-bound
A kasan error was reported during fuzzing:
BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
Call trace:
dump_backtrace+0x0/0x394
show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x158/0x1e4 lib/dump_stack.c:118
print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
__kasan_report+0xe0/0x140 mm/kasan/report.c:547
kasan_report+0x44/0xe0 mm/kasan/report.c:564
check_memory_region_inline mm/kasan/generic.c:187 [inline]
__asan_load4+0x94/0xd0 mm/kasan/generic.c:252
neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
crypto_shash_update crypto/shash.c:131 [inline]
shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
essiv_skcipher_setkey+0x164/0x200 [essiv]
crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
__sys_setsockopt+0x190/0x2e0 net/socket.c:2123
__do_sys_setsockopt net/socket.c:2134 [inline]
__se_sys_setsockopt net/socket.c:2131 [inline]
__arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683
This error can be reproduced by the following code compiled as ko on a
system with kasan enabled:
#include
- https://git.kernel.org/stable/c/3c77292d52b341831cb09c24ca4112a1e4f9e91f
- https://git.kernel.org/stable/c/3d4c28475ee352c440b83484b72b1320ff76364a
- https://git.kernel.org/stable/c/7ae19d422c7da84b5f13bc08b98bd737a08d3a53
- https://git.kernel.org/stable/c/8d25a08599df7ca3093eb7ca731c7cd41cbfbb51
- https://git.kernel.org/stable/c/d069dcffef849b8fd10030fd73007a79612803e6
Modified: 2025-11-24
CVE-2022-50240
In the Linux kernel, the following vulnerability has been resolved: android: binder: stop saving a pointer to the VMA Do not record a pointer to a VMA outside of the mmap_lock for later use. This is unsafe and there are a number of failure paths *after* the recorded VMA pointer may be freed during setup. There is no callback to the driver to clear the saved pointer from generic mm code. Furthermore, the VMA pointer may become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with. Instead, change the binder_alloc struct to record the start address of the VMA and use vma_lookup() to get the vma when needed. Add lockdep mmap_lock checks on updates to the vma pointer to ensure the lock is held and depend on that lock for synchronization of readers and writers - which was already the case anyways, so the smp_wmb()/smp_rmb() was not necessary. [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]
- https://git.kernel.org/stable/c/015ac18be7de25d17d6e5f1643cb3b60bfbe859e
- https://git.kernel.org/stable/c/1ec3f76a436d750fd5023caec5da0494fc2870d2
- https://git.kernel.org/stable/c/27a594bc7a7c8238d239e3cdbcf2edfa3bbe9a1b
- https://git.kernel.org/stable/c/622ef885a89ad04cfb76ee478fb44f051125d1f1
- https://git.kernel.org/stable/c/925e6b6f82c9c80ab3c17acbde8d16f349da7d26
- https://git.kernel.org/stable/c/a43cfc87caaf46710c8027a8c23b8a55f1078f19
Modified: 2025-05-05
CVE-2023-2008
A flaw was found in the Linux kernel's udmabuf device driver. The specific flaw exists within a fault handler. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an array. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel.
- https://bugzilla.redhat.com/show_bug.cgi?id=2186862
- https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4
- https://security.netapp.com/advisory/ntap-20230517-0007/
- https://www.zerodayinitiative.com/advisories/ZDI-23-441/
- https://bugzilla.redhat.com/show_bug.cgi?id=2186862
- https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4
- https://security.netapp.com/advisory/ntap-20230517-0007/
- https://www.zerodayinitiative.com/advisories/ZDI-23-441/
Modified: 2025-03-18
CVE-2023-2177
A null pointer dereference issue was found in the sctp network protocol in net/sctp/stream_sched.c in Linux Kernel. If stream_in allocation is failed, stream_out is freed which would further be accessed. A local user could use this flaw to crash the system or potentially cause a denial of service.
Modified: 2025-03-19
CVE-2023-23004
In the Linux kernel before 5.19, drivers/gpu/drm/arm/malidp_planes.c misinterprets the get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer).
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
Modified: 2025-04-23
CVE-2023-2513
A use-after-free vulnerability was found in the Linux kernel's ext4 filesystem in the way it handled the extra inode size for extended attributes. This flaw could allow a privileged local user to cause a system crash or other undefined behaviors.
- https://bugzilla.redhat.com/show_bug.cgi?id=2193097
- https://github.com/torvalds/linux/commit/67d7d8ad99be
- https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/
- https://bugzilla.redhat.com/show_bug.cgi?id=2193097
- https://github.com/torvalds/linux/commit/67d7d8ad99be
- https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/
Modified: 2025-04-23
CVE-2023-3111
A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag().
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230703-0007/
- https://www.debian.org/security/2023/dsa-5480
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230703-0007/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2024-11-21
CVE-2023-4385
A NULL pointer dereference flaw was found in dbFree in fs/jfs/jfs_dmap.c in the journaling file system (JFS) in the Linux Kernel. This issue may allow a local attacker to crash the system due to a missing sanity check.
- https://access.redhat.com/security/cve/CVE-2023-4385
- https://bugzilla.redhat.com/show_bug.cgi?id=2219272
- https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f
- https://access.redhat.com/security/cve/CVE-2023-4385
- https://bugzilla.redhat.com/show_bug.cgi?id=2219272
- https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f
Modified: 2025-11-03
CVE-2024-46794
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix data leak in mmio_read() The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM. Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM. This variable is only needed as an output value. It did not need to be passed to the VMM in the first place. Do not send the original value of *val to the VMM. [ dhansen: clarify what 'val' is used for. ]
- https://git.kernel.org/stable/c/26c6af49d26ffc377e392e30d4086db19eed0ef7
- https://git.kernel.org/stable/c/b55ce742afcb8e8189d82f2f1e635ba1b5a461fa
- https://git.kernel.org/stable/c/b6fb565a2d15277896583d471b21bc14a0c99661
- https://git.kernel.org/stable/c/ef00818c50cf55a3a56bd9a9fae867c92dfb84e7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
