ALT-PU-2022-7824-8
Package kernel-image-xenomai updated to version 4.19.252-alt1.cip78.23 for branch sisyphus in task 304715.
Closed vulnerabilities
Modified: 2023-11-13
BDU:2022-03283
Уязвимость функции nft_expr_init программного обеспечения фильтрации пакетов Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
Modified: 2025-08-19
BDU:2022-03704
Уязвимость функции dx_insert_block() (fs/ext4/namei.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-04269
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-30
BDU:2022-04270
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-04272
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-30
BDU:2022-04876
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04337
Уязвимость функции nfc_unregister_device() модуля net/nfc/core.c подсистемы NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-04355
Уязвимость функции radeon_fp_native_mode() модуля drivers/gpu/drm/radeon/radeon_connectors.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04416
Уязвимость функции ___slab_alloc() модуля mm/slub.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04420
Уязвимость функции bond_3ad_unbind_slave() модуля drivers/net/bonding/bond_3ad.c - драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04424
Уязвимость функции cx23885_initdev() модуля drivers/media/pci/cx23885/cx23885-core.c - драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04425
Уязвимость функции rt5645_i2c_remove() модуля sound/soc/codecs/rt5645.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-04426
Уязвимость функции sco_sock_connect() модуля net/bluetooth/sco.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04472
Уязвимость функции iio_sysfs_trigger_remove() модуля drivers/iio/trigger/iio-trig-sysfs.c - драйвера поддержки различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-06065
Уязвимость функций nla_alloc_flow_actions() и ovs_nla_free_set_action() модуля net/openvswitch/flow_netlink.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-10269
Уязвимость функции ext4_get_first_dir_block() модуля fs/ext4/namei.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10272
Уязвимость функции ieee80211_vif_use_reserved_context() модуля net/mac80211/chan.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-10578
Уязвимость функции ubi_create_volume() модуля drivers/mtd/ubi/vmt.c - драйвера поддержки памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01394
Уязвимость функции nbd_alloc_config() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01498
Уязвимость функции si_parse_power_table() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02207
Уязвимость функции ext4_resize_begin() модуля fs/ext4/resize.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02211
Уязвимость функции hdlcdev_init() модуля drivers/tty/synclink_gt.c - драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02212
Уязвимость функции extcon_dev_register() модуля drivers/extcon/extcon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02213
Уязвимость функции _nfs4_open_and_get_state() модуля fs/nfs/nfs4proc.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02215
Уязвимость функции rpcrdma_is_bcall() модуля net/sunrpc/xprtrdma/rpc_rdma.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02216
Уязвимость функции trace_event_buffer_lock_reserve() модуля kernel/trace/trace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02217
Уязвимость функции dx_probe() модуля fs/ext4/namei.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02218
Уязвимость функции ext4_convert_inline_data() модуля fs/ext4/inline.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02220
Уязвимость функции icp_opal_init() модуля arch/powerpc/sysdev/xics/icp-opal.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02221
Уязвимость функции nvme_alloc_admin_tags() модуля drivers/nvme/host/pci.c - драйвера поддержки NVME ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02225
Уязвимость функции snd_jack_dev_register() модуля sound/core/jack.c поддержки аудио карт ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02231
Уязвимость функции raid5_add_disk() модуля drivers/md/raid5.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02232
Уязвимость функции ata_host_alloc_pinfo() модуля drivers/ata/libata-core.c - драйвера поддержки SATA/PATA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02253
Уязвимость функции validate_region_size() модуля drivers/md/dm-raid.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02266
Уязвимость функции cx25821_finidev() модуля drivers/media/pci/cx25821/cx25821-core.c драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02269
Уязвимость функции dcscb_init() модуля arch/arm/mach-vexpress/dcscb.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02568
Уязвимость функции hfi1_write_iter() модуля drivers/infiniband/hw/hfi1/file_ops.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02569
Уязвимость функции pci_dev_lock() модуля drivers/pci/pci.c драйвера поддержки утройств PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02570
Уязвимость функции md_bitmap_read_sb() модуля drivers/md/md-bitmap.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02596
Уязвимость функции r871xu_drv_init() модуля drivers/staging/rtl8712/usb_intf.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02598
Уязвимость функции isp116x_remove() модуля drivers/usb/host/isp116x-hcd.c драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02599
Уязвимость функции sa1100_set_termios() модуля drivers/tty/serial/sa1100.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02600
Уязвимость функции ieee80211_beacons_stop() модуля drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02601
Уязвимость функции oxu_bus_suspend() модуля drivers/usb/host/oxu210hp-hcd.c драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02603
Уязвимость функции mips_cpc_default_phys_base() модуля arch/mips/kernel/mips-cpc.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02604
Уязвимость функции rtl8180_tx() модуля drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c - драйвера поддержки адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02607
Уязвимость функции user_dlm_destroy_lock() модуля fs/ocfs2/dlmfs/userdlm.c поддержки файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02615
Уязвимость функции hi3xxx_smp_prepare_cpus() модуля arch/arm/mach-hisi/platsmp.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02616
Уязвимость функции kszphy_config_reset() модуля drivers/net/phy/micrel.c - драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02620
Уязвимость функции virtio_gpu_conn_get_modes() модуля drivers/gpu/drm/virtio/virtgpu_display.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02622
Уязвимость функции libipw_xmit() модуля drivers/net/wireless/intel/ipw2x00/libipw_tx.c - драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02625
Уязвимость функции machine_setup() модуля arch/xtensa/platforms/xtfpga/setup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02626
Уязвимость функции calibrate_ccount() модуля arch/xtensa/kernel/time.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02627
Уязвимость функции l2tp_ip6_sendmsg() модуля net/l2tp/l2tp_ip6.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02629
Уязвимость функции nfcmrvl_play_deferred() модуля drivers/nfc/nfcmrvl/usb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02648
Уязвимость функции icom_probe() модуля drivers/tty/serial/icom.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02650
Уязвимость функции rtllib_beacons_stop() модуля drivers/staging/rtl8192e/rtllib_softmac.c - поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03488
Уязвимость функции clcdfb_of_vram_setup() модуля drivers/video/fbdev/amba-clcd.c драйвера поддержки устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03493
Уязвимость функции tcp_mtup_probe_success() модуля net/ipv4/tcp_input.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03494
Уязвимость функции seg6_hmac_init() модуля net/ipv6/seg6_hmac.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03495
Уязвимость функции xfrm4_protocol_init() модуля net/ipv4/xfrm4_protocol.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03496
Уязвимость функции mdio_bus_init() модуля drivers/net/phy/mdio_bus.c драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03671
Уязвимость функции nbd_cleanup() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03672
Уязвимость функции nbd_start_device_ioctl() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03674
Уязвимость функции bpf_int_jit_compile() модуля arch/arm64/net/bpf_jit_comp.c поддержки сети на платформе ARM 64бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03675
Уязвимость функции tcp_rtx_synack() модуля net/ipv4/tcp_output.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03676
Уязвимость функции goldfish_tty_probe() модуля drivers/tty/goldfish.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03678
Уязвимость функции ath9k_rx_prepare() модуля drivers/net/wireless/ath/ath9k/htc_drv_txrx.c драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03679
Уязвимость функции f2fs_drop_inmem_page() модуля fs/f2fs/segment.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03692
Уязвимость функции rk3399_dmcfreq_remove() модуля drivers/devfreq/rk3399_dmc.c драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03705
Уязвимость функции gs_can_open() модуля drivers/net/can/usb/gs_usb.c драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03707
Уязвимость функции erspan_fb_xmit() модуля net/ipv4/ip_gre.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03708
Уязвимость функции ext4_mb_normalize_request() модуля fs/ext4/mballoc.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03712
Уязвимость функции goldfish_tty_remove() модуля drivers/tty/goldfish.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2026-03713
Уязвимость функции i40e_diag_test() модуля drivers/net/ethernet/intel/i40e/i40e_ethtool.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03810
Уязвимость функции __drm_universal_plane_init() модуля drivers/gpu/drm/drm_plane.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03862
Уязвимость функции dlm_posix_lock() модуля fs/dlm/plock.c поддержки распределенного менеджера блокировок ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03869
Уязвимость функции register_node() модуля drivers/base/node.c драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03891
Уязвимость функции tun_detach_all() модуля drivers/net/tun.c драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03899
Уязвимость функции blkcg_iolatency_throttle() модуля block/blk-iolatency.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03999
Уязвимость функции afs_getattr() модуля fs/afs/inode.c файловой системы Andrew (AFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04025
Уязвимость функции mdp5_crtc_setup_pipeline() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04026
Уязвимость функции mdp5_pipe_assign() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04030
Уязвимость функции sdma_clean() модуля drivers/infiniband/hw/hfi1/sdma.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04038
Уязвимость функции ipgre_xmit() модуля net/ipv4/ip_gre.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04274
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04275
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-14
CVE-2021-47659
In the Linux kernel, the following vulnerability has been resolved: drm/plane: Move range check for format_count earlier While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.
- https://git.kernel.org/stable/c/1e29d829ad51d1472dd035487953a6724b56fc33
- https://git.kernel.org/stable/c/4ab7e453a3ee88c274cf97bee9487ab92a66d313
- https://git.kernel.org/stable/c/4b674dd69701c2e22e8e7770c1706a69f3b17269
- https://git.kernel.org/stable/c/787163d19bc3cdc6ca4b96223f62208534d1cf6b
- https://git.kernel.org/stable/c/978e3d023256bfaf34a0033d40c94e8a8e70cf3c
- https://git.kernel.org/stable/c/ad6dd7a2bac86118985c7b3426e175b9d3c1ec4f
- https://git.kernel.org/stable/c/b5cd108143513e4498027b96ec4710702d186f11
Modified: 2024-11-21
CVE-2022-1184
A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel’s filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service.
- https://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
- https://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-26365
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-11-21
CVE-2022-32250
net/netfilter/nf_tables_api.c in the Linux kernel through 5.18.1 allows a local user (able to create user/net namespaces) to escalate privileges to root because an incorrect NFT_STATEFUL_EXPR check leads to a use-after-free.
- http://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
- http://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
Modified: 2024-11-21
CVE-2022-33740
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-11-21
CVE-2022-33741
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-11-21
CVE-2022-33742
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-12-31
CVE-2022-48710
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix a possible null pointer dereference In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. The failure status of drm_cvt_mode() on the other path is checked too.
- https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
- https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
Modified: 2025-09-23
CVE-2022-49086
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0) Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too.
- https://git.kernel.org/stable/c/1f30fb9166d4f15a1aa19449b9da871fe0ed4796
- https://git.kernel.org/stable/c/3554c214b83ec9a839ed574263a34218f372990c
- https://git.kernel.org/stable/c/53bce9d19b0a9d245b25cd050b81652ed974a509
- https://git.kernel.org/stable/c/5ae05b5eb58773cfec307ff88aff4cfd843c4cff
- https://git.kernel.org/stable/c/7438dc55c0709819b813f4778aec2c48b782990b
- https://git.kernel.org/stable/c/837b96d8103938e35e7d92cd9db96af914ca4fff
- https://git.kernel.org/stable/c/ef6f9ce0a79aa23b10fc5f3b3cab3814a25aac40
Modified: 2025-10-01
CVE-2022-49295
In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-)
- https://git.kernel.org/stable/c/013a79f1b5c89290e2e97f1ebf14b14e0cf5fe5c
- https://git.kernel.org/stable/c/06c4da89c24e7023ea448cadf8e9daf06a0aae6e
- https://git.kernel.org/stable/c/1be608e1ee1f222464b2856bda9b85ab5184a33e
- https://git.kernel.org/stable/c/3d5da1ffba3388c2ae2e6c598855a4d887d3bf79
- https://git.kernel.org/stable/c/6f505bbb8063fd3a238a4239d2d8c165e5279f6f
- https://git.kernel.org/stable/c/8a1435c862ea09b06be7acda325128dc08458e25
- https://git.kernel.org/stable/c/c0868f6e728c3c28bef0e8bee89d2daf86a8bbca
- https://git.kernel.org/stable/c/cbeafa7a79d08ecdb55f8f1d41a11323d0f709db
Modified: 2025-10-21
CVE-2022-49297
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix io hung while disconnecting device
In our tests, "qemu-nbd" triggers a io hung:
INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000
Call Trace:
- https://git.kernel.org/stable/c/09dadb5985023e27d4740ebd17e6fea4640110e5
- https://git.kernel.org/stable/c/141318e62db87105b0103fccc59c9c5940da248d
- https://git.kernel.org/stable/c/54b06dc2a206b4d67349bb56b92d4bd32700b7b1
- https://git.kernel.org/stable/c/62d227f67a8c25d5e16f40e5290607f9306d2188
- https://git.kernel.org/stable/c/67e403136a0e1a55fef6a05f103a3979a39ad3fd
- https://git.kernel.org/stable/c/69893d6d7f5c10d8306c1b5fc64b71efc91aa6cd
- https://git.kernel.org/stable/c/c4ba982bd5084fa659ef518aaf159e4dab02ecda
- https://git.kernel.org/stable/c/f72df77600a43e59b3189e53b47f8685739867d3
Modified: 2025-10-01
CVE-2022-49298
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in r871xu_drv_init() When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
- https://git.kernel.org/stable/c/0458e5428e5e959d201a40ffe71d762a79ecedc4
- https://git.kernel.org/stable/c/0b7371a22489cbb2e8e826ca03fb5ce92afb04fe
- https://git.kernel.org/stable/c/277faa442fe0c59f418ac53f47a78e1266addd65
- https://git.kernel.org/stable/c/52a0d88c328098b4e9fb8f2f3877fec0eff4104b
- https://git.kernel.org/stable/c/70df04433fd351ba72bc635bd0b5fe443d9ac964
- https://git.kernel.org/stable/c/76a964ad0ea8f2b10abd69a7532e174a28258283
- https://git.kernel.org/stable/c/a6535d00a9d54ce1c2a8d86a85001ffb6844f9b2
- https://git.kernel.org/stable/c/f36e754a1f0bafb9feeea63463de78080acb6de0
- https://git.kernel.org/stable/c/ff727ab0b7d7a56b5ef281f12abd00c4b85894e9
Modified: 2025-10-01
CVE-2022-49300
In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between nbd_alloc_config() and module removal When nbd module is being removing, nbd_alloc_config() may be called concurrently by nbd_genl_connect(), although try_module_get() will return false, but nbd_alloc_config() doesn't handle it. The race may lead to the leak of nbd_config and its related resources (e.g, recv_workq) and oops in nbd_read_stat() due to the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Fixing it by checking the return value of try_module_get() in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV), assign nbd->config only when nbd_alloc_config() succeeds to ensure the value of nbd->config is binary (valid or NULL). Also adding a debug message to check the reference counter of nbd_config during module removal.
- https://git.kernel.org/stable/c/122e4adaff2439f1cc18cc7e931980fa7560df5c
- https://git.kernel.org/stable/c/165cf2e0019fa6cedc75b456490c41494c34abb4
- https://git.kernel.org/stable/c/2573f2375b64280be977431701ed5d33b75b9ad0
- https://git.kernel.org/stable/c/2888fa41985f93ed0a6837cfbb06bcbfd7fa2314
- https://git.kernel.org/stable/c/71c142f910da44421213ade601bcbd23ceae19fa
- https://git.kernel.org/stable/c/8a7da4ced236ce6637fe70f14ca18e718d4bf9e9
- https://git.kernel.org/stable/c/c55b2b983b0fa012942c3eb16384b2b722caa810
- https://git.kernel.org/stable/c/d09525720dd5201756f698bee1076de9aefd4602
Modified: 2025-10-01
CVE-2022-49302
In the Linux kernel, the following vulnerability has been resolved: USB: host: isp116x: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e
- https://git.kernel.org/stable/c/3592cfd8b848bf0c4d7740d78a87a7b8f6e1fa9a
- https://git.kernel.org/stable/c/3825db88d8c704e7992b685618a03f82bffcf2ef
- https://git.kernel.org/stable/c/7bffda1560a6f255fdf504e059fbbdb5d46b9e44
- https://git.kernel.org/stable/c/804de302ada3544699c5f48c5314b249af76faa3
- https://git.kernel.org/stable/c/82a101f14943f479fd190b1e5b40d91c77e2ac1b
- https://git.kernel.org/stable/c/aca0cab0e9ed33b6371aafb519a6c38f2850ffc3
- https://git.kernel.org/stable/c/c91a74b1f0f2d2d7e728742ae55e3ffe9ba7853d
- https://git.kernel.org/stable/c/ee105039d3653444de4d3ede642383c92855dc1e
Modified: 2025-10-01
CVE-2022-49304
In the Linux kernel, the following vulnerability has been resolved: drivers: tty: serial: Fix deadlock in sa1100_set_termios() There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever. This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock.
- https://git.kernel.org/stable/c/0976808d0d171ec837d4bd3e9f4ad4a00ab703b8
- https://git.kernel.org/stable/c/09a5958a2452ad22d0cb638711ef34ea1863a829
- https://git.kernel.org/stable/c/2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b
- https://git.kernel.org/stable/c/34d91e555e5582cffdbcbb75517bc9217866823e
- https://git.kernel.org/stable/c/553213432ef0c295becdc08c0207d2094468f673
- https://git.kernel.org/stable/c/62b2caef400c1738b6d22f636c628d9f85cd4c4c
- https://git.kernel.org/stable/c/6e2273eefab54a521d9c59efb6e1114e742bdf41
- https://git.kernel.org/stable/c/85e20f8bd31a46d8c60103d0274a8ebe8f47f2b2
- https://git.kernel.org/stable/c/920f0ae7a129ffee98a106e3bbdfd61a2a59e939
Modified: 2025-10-01
CVE-2022-49305
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/042915c1bfedd684c1d98a841794ee203200571a
- https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25
- https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710
- https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273
- https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2
- https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e
- https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3
Modified: 2025-10-01
CVE-2022-49307
In the Linux kernel, the following vulnerability has been resolved:
tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
When the driver fails at alloc_hdlcdev(), and then we remove the driver
module, we will get the following splat:
[ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
[ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
[ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
[ 25.077709] Call Trace:
[ 25.077924]
- https://git.kernel.org/stable/c/078212ad15dbd88840c82c97f12c93d83703c8fd
- https://git.kernel.org/stable/c/1ceb4ca9543a8a788febf6bc8dad2e605e172d5e
- https://git.kernel.org/stable/c/50c341f9a2adc4c32a8ad5a39eb99d9c4a419e0d
- https://git.kernel.org/stable/c/689ca31c542687709ba21ec2195c1fbce34fd029
- https://git.kernel.org/stable/c/8a95696bdc0e13f8980f05b54a3b9081963d1256
- https://git.kernel.org/stable/c/ba08cbc5b53e151d0acf1930fb526fc65b7f3e65
- https://git.kernel.org/stable/c/d68d5e68b7f64de7170f8e04dd9b995c36b2c71c
- https://git.kernel.org/stable/c/ddd67751ab86c6a65f95c35293c42f85a42ac05d
- https://git.kernel.org/stable/c/f6e07eb7ebec53ffe81fc2489589320fbe4a6b75
Modified: 2025-10-21
CVE-2022-49308
In the Linux kernel, the following vulnerability has been resolved:
extcon: Modify extcon device to be created after driver data is set
Currently, someone can invoke the sysfs such as state_show()
intermittently before dev_set_drvdata() is done.
And it can be a cause of kernel Oops because of edev is Null at that time.
So modified the driver registration to after setting drviver data.
- Oops's backtrace.
Backtrace:
[
- https://git.kernel.org/stable/c/033ec4e7e59ae5e1ef1e8c10bc6552926044ed1c
- https://git.kernel.org/stable/c/35ff1ac55d301efb3f467cf5426faaeb3452994b
- https://git.kernel.org/stable/c/368e68ad6da4317fc4170e8d92b51c13d1bfe7a7
- https://git.kernel.org/stable/c/5dcc2afe716d69f5112ce035cb14f007461ff189
- https://git.kernel.org/stable/c/6e721f3ad0535b24f19a62420f4da95212cf069c
- https://git.kernel.org/stable/c/abf3b222614f49f98e606fccdd269161c0d70204
- https://git.kernel.org/stable/c/cb81ea998c461868d1168411a867d8ffee12f23f
- https://git.kernel.org/stable/c/d472c78cc82999d07bd09193a6718016ce9cd386
Modified: 2025-10-01
CVE-2022-49313
In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/2dcec0bc142be2096af71a5703d63237127db204
- https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868
- https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524
- https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58
- https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124
- https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677
- https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab
- https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221
- https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df
Modified: 2025-10-01
CVE-2022-49314
In the Linux kernel, the following vulnerability has been resolved: tty: Fix a possible resource leak in icom_probe When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated.
- https://git.kernel.org/stable/c/23e155b51d403c0ccedc60c0d6c3c452afed07fe
- https://git.kernel.org/stable/c/5f9b2e4ca88cab1a96b86ecd45544e488ca43faf
- https://git.kernel.org/stable/c/8c014373f178a4f13a08e045ef63bdb23f62e892
- https://git.kernel.org/stable/c/9a8305f357a8d03698fc7bc855ff9c6865d5486b
- https://git.kernel.org/stable/c/a2df0b4d080cc770b4da7bff487048c803dfd07e
- https://git.kernel.org/stable/c/cb7147afd328c07edeeee287710d8d96ac0459f5
- https://git.kernel.org/stable/c/d703d912a985c1c5b50dd38c3181fc3540fa77cb
- https://git.kernel.org/stable/c/ee157a79e7c82b01ae4c25de0ac75899801f322c
- https://git.kernel.org/stable/c/f4c836d90da1ece88905d62ce2ce39a962f25d1a
Modified: 2025-10-01
CVE-2022-49315
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/08bacf871c019163ccd1389d0bc957a43324967a
- https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada
- https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446
- https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12
- https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72
- https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b
- https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303
- https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db
- https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434
Modified: 2025-10-01
CVE-2022-49316
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Don't hold the layoutget locks across multiple RPC calls When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock.
- https://git.kernel.org/stable/c/08d7a26d115cc7892668baa9750f64bd8baca29b
- https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c
- https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee
- https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010
- https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd
- https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e
- https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1
Modified: 2025-10-01
CVE-2022-49321
In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ...
- https://git.kernel.org/stable/c/11270e7ca268e8d61b5d9e5c3a54bd1550642c9c
- https://git.kernel.org/stable/c/8dbae5affbdbf524b48000f9d357925bb001e5f4
- https://git.kernel.org/stable/c/8e3943c50764dc7c5f25911970c3ff062ec1f18c
- https://git.kernel.org/stable/c/90c4f73104016748533a5707ecd15930fbeff402
- https://git.kernel.org/stable/c/91784f3d77b73885e1b2e6b59d3cbf0de0a1126a
- https://git.kernel.org/stable/c/998d35a2aff4b81a1c784f3aa45cd3afff6814c1
- https://git.kernel.org/stable/c/a3fc8051ee061e31db13e2fe011e8e0b71a7f815
- https://git.kernel.org/stable/c/da99331fa62131a38a0947a8204c5208de7b0454
Modified: 2025-10-01
CVE-2022-49322
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
be triggered.
Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
[
- https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd
- https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762
- https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4
- https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b
- https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0
- https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59
- https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec
- https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1
Modified: 2025-10-01
CVE-2022-49324
In the Linux kernel, the following vulnerability has been resolved: mips: cpc: Fix refcount leak in mips_cpc_default_phys_base Add the missing of_node_put() to release the refcount incremented by of_find_compatible_node().
- https://git.kernel.org/stable/c/1699ec1bfb59304a788901474f6bb003f7831b61
- https://git.kernel.org/stable/c/4107fa700f314592850e2c64608f6ede4c077476
- https://git.kernel.org/stable/c/8f843cdfc202caaa5d67db3395d893e56362e43a
- https://git.kernel.org/stable/c/961ee8a6eeef4632a215d995d837b204f8c7c2d4
- https://git.kernel.org/stable/c/aae6b4bb63c694bc91714412718f15468407fe51
- https://git.kernel.org/stable/c/bed702566dcdb6ebe300bc0c62bf3600cf4d5874
- https://git.kernel.org/stable/c/c667b3872a4c435a3f29d4e15971cd8c378b0043
- https://git.kernel.org/stable/c/cc0aed22d33ced9e266c50bdf1cbe668c5acfdf8
Modified: 2025-10-01
CVE-2022-49326
In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized.
- https://git.kernel.org/stable/c/6ad81ad0cf5744738ce94c8e64051ddd80a1734c
- https://git.kernel.org/stable/c/746285cf81dc19502ab238249d75f5990bd2d231
- https://git.kernel.org/stable/c/769ec2a824deae2f1268dfda14999a4d14d0d0c5
- https://git.kernel.org/stable/c/98e55b0b876bde3353f4e074883d66ecb55c65a3
- https://git.kernel.org/stable/c/9ad1981fc4de3afb7db3e8eb5a6a52d4c7d0d577
- https://git.kernel.org/stable/c/9d5e96cc1f1720019ce27b127a31695148d38bb0
- https://git.kernel.org/stable/c/b5dca2cd3f0239512da808598b4e70557eb4c2a1
- https://git.kernel.org/stable/c/b8ce58ab80faaea015c206382041ff3bcf5495ff
- https://git.kernel.org/stable/c/d7e30dfc166d33470bba31a42f9bbc346e5409d5
Modified: 2025-09-22
CVE-2022-49330
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
syzbot got a new report [1] finally pointing to a very old bug,
added in initial support for MTU probing.
tcp_mtu_probe() has checks about starting an MTU probe if
tcp_snd_cwnd(tp) >= 11.
But nothing prevents tcp_snd_cwnd(tp) to be reduced later
and before the MTU probe succeeds.
This bug would lead to potential zero-divides.
Debugging added in commit 40570375356c ("tcp: add accessors
to read/set tp->snd_cwnd") has paid off :)
While we are at it, address potential overflows in this code.
[1]
WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Modules linked in:
CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/11825765291a93d8e7f44230da67b9f607c777bf
- https://git.kernel.org/stable/c/29e13f6b38f0816af2012e0725507754e8f4569c
- https://git.kernel.org/stable/c/38ca71a24cd4845021eed35fd2594d89dba9a5a8
- https://git.kernel.org/stable/c/42726877453afdbe1508a8a96884ea907741d9a7
- https://git.kernel.org/stable/c/602b338e3c3cd7f935f3f5011882961d074e5ac1
- https://git.kernel.org/stable/c/90385f2b65d0cd2b3b1ac8909f0cc6dd31062cfc
- https://git.kernel.org/stable/c/9ba2b4ac35935f05ac98cff722f36ba07d62270e
- https://git.kernel.org/stable/c/aa7f333efd1138a68517a6a6a69ae540dd59d800
- https://git.kernel.org/stable/c/f2845e1504a3bc4f3381394f057e8b63cb5f3f7a
Modified: 2025-10-01
CVE-2022-49331
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.
- https://git.kernel.org/stable/c/3eca2c42daa4659965db6817479027cbc6df7899
- https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f
- https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd
- https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74
- https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded
- https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe
- https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383
- https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7
- https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e
Modified: 2025-10-01
CVE-2022-49335
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
- https://git.kernel.org/stable/c/15c3bcc9b5349d40207e5f8d4d799b8b4b7d13b8
- https://git.kernel.org/stable/c/20b947e5a3c74c5084d661c097517a554989d462
- https://git.kernel.org/stable/c/31ab27b14daaa75541a415c6794d6f3567fea44a
- https://git.kernel.org/stable/c/70276460e914d560e96bfc208695a872fe9469c9
- https://git.kernel.org/stable/c/7086a23890d255bb5761604e39174b20d06231a4
- https://git.kernel.org/stable/c/8189f44270db1be78169e11eec51a3eeb980bc63
- https://git.kernel.org/stable/c/aa25acbe96692e4bf8482311c293f72d8c6034c0
- https://git.kernel.org/stable/c/be585921f29df5422a39c952d188b418ad48ffab
- https://git.kernel.org/stable/c/c12984cdb077b9042d2dc20ca18cb16a87bcc774
Modified: 2025-09-22
CVE-2022-49337
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_lock failed, it didn't clean up the flags it set
before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of
lock is still in used, next time when unlink invokes this function, it
will return succeed, and then unlink will remove inode and dentry if lock
is not in used(file closed), but the dlm lock is still linked in dlm lock
resource, then when bast come in, it will trigger a panic due to
user-after-free. See the following panic call trace. To fix this,
USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should
be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink
fail.
For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,
USER_LOCK_BUSY is also required to be cleared. Even though spin lock is
released in between, but USER_LOCK_IN_TEARDOWN is still set, for
USER_LOCK_BUSY, if before every place that waits on this flag,
USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow
waits on the busy flag set by user_dlm_destroy_lock(), then we can
simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix
user_dlm_cluster_lock() which is the only function not following this.
[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink
004fb0000060000b5a90b8c847b72e1, error -16 from destroy
[ 989.757536] ------------[ cut here ]------------
[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!
[ 989.757876] invalid opcode: 0000 [#1] SMP
[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)
ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc
xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5
auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs
ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc
fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc
rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad
rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)
mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad
ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support
pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si
ipmi_msghandler
[ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp
pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel
be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio
libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi
dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
ksplice_2zhuk2jr_ib_ipoib_old]
[ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE
4.1.12-124.57.1.el6uek.x86_64 #2
[ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021
[ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:
ffff88017f7c8000
[ 989.762848] RIP: e030:[
- https://git.kernel.org/stable/c/02480e2e82ae0e5588374bbbcf4fa6e4959fa174
- https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207c
- https://git.kernel.org/stable/c/2c5e26a626fe46675bceba853e12aaf13c712e10
- https://git.kernel.org/stable/c/337e36550788dbe03254f0593a231c1c4873b20d
- https://git.kernel.org/stable/c/733a35c00ef363a1c774d7ea486e0735b7c13a15
- https://git.kernel.org/stable/c/82bf8e7271fade40184177cb406203addc34c4a0
- https://git.kernel.org/stable/c/863e0d81b6683c4cbc588ad831f560c90e494bef
- https://git.kernel.org/stable/c/9c96238fac045b289993d7bc5aae7b2d72b25c76
- https://git.kernel.org/stable/c/efb54ec548829e1d3605f0434526f86e345b1b28
Modified: 2025-09-22
CVE-2022-49339
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the caller (net/ipv6/seg6.c) and the callee (net/ipv6/seg6_hmac.c) belong to the same module. It seems an internal function call in ipv6.ko.
- https://git.kernel.org/stable/c/1084716f76c8045eadf92a9d9a62641f3c8d8c90
- https://git.kernel.org/stable/c/317260b3eb6384a05a8af212308fa50f3b2e8290
- https://git.kernel.org/stable/c/3e6de5037148c5a93a436b1e8d2edad3dac11755
- https://git.kernel.org/stable/c/5801f064e35181c71857a80ff18af4dbec3c5f5c
- https://git.kernel.org/stable/c/5d9c1b081ad28c852a97e10dd75412546497694a
- https://git.kernel.org/stable/c/64aef8efe96c1616142c4476a05731306fc4494e
- https://git.kernel.org/stable/c/9ba4416b831eeb4d185e88e73488d1d21288e63a
- https://git.kernel.org/stable/c/ab8b2c2de273ec1d698a18e399896a6febb5cda0
Modified: 2025-10-21
CVE-2022-49340
In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local checksum offload on CHECKSUM_PARTIAL packets. ipgre_xmit must validate csum_start after an optional skb_pull, else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; This had false positives when skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement was straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; But was eventually revised more thoroughly: - restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull. - test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath. Turns out skbs can arrive in this branch without the transport header set, e.g., through BPF redirection. Revise the check back to check csum_start directly, and only if CHECKSUM_PARTIAL. Do leave the check in the updated location. Check field regardless of whether TUNNEL_CSUM is configured.
- https://git.kernel.org/stable/c/0c92d813c7c9ca2212ecd879232e7d87362fce98
- https://git.kernel.org/stable/c/0ffa268724656633af5f37a38c212326d98ebe8c
- https://git.kernel.org/stable/c/3d08bc3a5d9b2106f5c8bcf1adb73147824aa006
- https://git.kernel.org/stable/c/7596bd7920985f7fc8579a92e48bc53ce4475b21
- https://git.kernel.org/stable/c/8d21e9963bec1aad2280cdd034c8993033ef2948
- https://git.kernel.org/stable/c/e6b6f98fc7605c06c0a3baa70f62c534d7b4ce58
- https://git.kernel.org/stable/c/fbeb8dfa8b87ef259eef0c89e39b53962a3cf604
Modified: 2025-10-21
CVE-2022-49341
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)
- https://git.kernel.org/stable/c/0cf7aaff290cdc4d7cee683d4a18138b0dacac48
- https://git.kernel.org/stable/c/10f3b29c65bb2fe0d47c2945cd0b4087be1c5218
- https://git.kernel.org/stable/c/3f4d5e727aeaa610688d46c9f101f78b7f712583
- https://git.kernel.org/stable/c/41f7c4f85d402043687e863627a1a84fa867c62d
- https://git.kernel.org/stable/c/5c25a3040bc0486c41a7b63a1fb0de7cdb846ad7
- https://git.kernel.org/stable/c/aaf61a312af63e1cfe2264c4c5b8cd4ea3626025
- https://git.kernel.org/stable/c/e412b3d178ea4bf746f6b8ee086761613704c6be
Modified: 2025-10-21
CVE-2022-49343
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique.
- https://git.kernel.org/stable/c/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3
- https://git.kernel.org/stable/c/3a3ce941645407cd0b0b7f01ad9e2ea3770f46cc
- https://git.kernel.org/stable/c/3ba733f879c2a88910744647e41edeefbc0d92b2
- https://git.kernel.org/stable/c/6084240bfc44bf265ab6ae7d96980469b05be0f1
- https://git.kernel.org/stable/c/b3ad9ff6f06c1dc6abf7437691c88ca3d6da3ac0
- https://git.kernel.org/stable/c/d5a16a6df2c16eaf4de04948553ef0089dee463f
- https://git.kernel.org/stable/c/e157c8f87e8fac112d6c955e69a60cdb9bc80a60
- https://git.kernel.org/stable/c/ff4cafa51762da3824881a9000ca421d4b78b138
Modified: 2025-10-01
CVE-2022-49344
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race.
- https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf
- https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432
- https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2
- https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6
- https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca
- https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f
- https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913
Modified: 2025-09-22
CVE-2022-49345
In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean)
- https://git.kernel.org/stable/c/2b253fbc9f7b5db18d716436bdcf8ecef09fd63d
- https://git.kernel.org/stable/c/31f3c6a4dcd3260a386e62cef2d5b36e902600a1
- https://git.kernel.org/stable/c/4a388f08d8784af48f352193d2b72aaf167a57a1
- https://git.kernel.org/stable/c/85a055c03691e51499123194a14a0c249cf33227
- https://git.kernel.org/stable/c/be3884d5cd04ccd58294b83a02d70b7c5fca19d3
- https://git.kernel.org/stable/c/c58d82a1264813e69119c13e9804e2e60b664ad5
- https://git.kernel.org/stable/c/e04d59cfe0c0129df7aba7ef7bb17b96be2a64f2
- https://git.kernel.org/stable/c/e53cd3814504b2cadaba4d5a8a07eeea9ddacd03
- https://git.kernel.org/stable/c/ef6d2354de238b065d8799c80da4be9a6af18e39
Modified: 2025-09-22
CVE-2022-49347
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on in ext4_writepages
we got issue as follows:
EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls
------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2708!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155
RIP: 0010:ext4_writepages+0x1977/0x1c10
RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000
RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002
RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000
R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001
R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028
FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/013f12bdedb96816aaa27ee04349f4433d361f52
- https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4
- https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce
- https://git.kernel.org/stable/c/1b061af037646c9cdb0afd8a8d2f1e1c06285866
- https://git.kernel.org/stable/c/1cde35417edc0370fb0179a4e38b78a15350a8d0
- https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9
- https://git.kernel.org/stable/c/b2b78f5bf2d453dda3903955efee059260787a42
- https://git.kernel.org/stable/c/de1732b5c1693ad489c5d254f124f67cb775f37d
- https://git.kernel.org/stable/c/ef09ed5d37b84d18562b30cf7253e57062d0db05
Modified: 2025-03-25
CVE-2022-49349
In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ]
- https://git.kernel.org/stable/c/0be698ecbe4471fcad80e81ec6a05001421041b3
- https://git.kernel.org/stable/c/0ff38b99fa075ddd246487a28cb9af049f4ceef1
- https://git.kernel.org/stable/c/10801095224de0d0ab06ae60698680c1f883a3ae
- https://git.kernel.org/stable/c/1a3a15bf6f9963d755270cbdb282863b84839195
- https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f
- https://git.kernel.org/stable/c/4a2bea60cf7ff957b3eda0b17750d483876a02fa
- https://git.kernel.org/stable/c/97f802a652a749422dede32071d29a53cf4bd034
- https://git.kernel.org/stable/c/dd887f83ea54aea5b780a84527e23ab95f777fed
- https://git.kernel.org/stable/c/eaecf7ebfd5dd09038a80b14be46b844f54cfc5c
Modified: 2025-09-22
CVE-2022-49350
In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phy_device.c is never compiled as modular. (CONFIG_PHYLIB is boolean)
- https://git.kernel.org/stable/c/35b42dce619701f1300fb8498dae82c9bb1f0263
- https://git.kernel.org/stable/c/5534bcd7c40299862237c4a8fd9c5031b3db1538
- https://git.kernel.org/stable/c/59fa94cddf9eef8d8dae587373eed8b8f4eb11d7
- https://git.kernel.org/stable/c/6a90a44d53428a3bf01bd80df9ba78b19959270c
- https://git.kernel.org/stable/c/7759c3222815b945a94b212bc0c6cdec475cfec2
- https://git.kernel.org/stable/c/ab64ec2c75683f30ccde9eaaf0761002f901aa12
- https://git.kernel.org/stable/c/f2f0f8c18b60ca64ff50892ed899cf1c77864755
- https://git.kernel.org/stable/c/f5c68137f1191ba3fcf6260ec71b30be2e2bf4c3
Modified: 2025-10-01
CVE-2022-49351
In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d31950dcba0b3dd7283c
- https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584
- https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de
- https://git.kernel.org/stable/c/5cd0e22fa11f4a21a8c09cc258f20b1474c95801
- https://git.kernel.org/stable/c/803b217f1fb49a2dbb2123acdb45111b9c48b8be
- https://git.kernel.org/stable/c/8174acbef87b8dd8bf3731eba2a5af1ac857e239
- https://git.kernel.org/stable/c/96bf5ed057df2d157274d4e2079002f9a9404bb8
- https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833
- https://git.kernel.org/stable/c/e31d9ba169860687dba19bdc8fccbfd34077f655
Modified: 2025-10-01
CVE-2022-49354
In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak.
- https://git.kernel.org/stable/c/10d6bdf532902be1d8aa5900b3c03c5671612aa2
- https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1
- https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf
- https://git.kernel.org/stable/c/888312dc297a8a103f6371ef668c7e04f57a7679
- https://git.kernel.org/stable/c/8d8ad067b90f231b8fdb14acee673ca4012f6045
- https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b
- https://git.kernel.org/stable/c/c9782e1b21bee4b783a64b2a91e7e71406c21a21
- https://git.kernel.org/stable/c/d5a1e7f33c88780b279835d63665d7e38ccb671f
- https://git.kernel.org/stable/c/fb2cb409b504bb3a69e65a17f3120328c8e50219
Modified: 2025-10-01
CVE-2022-49367
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/02ded5a173619b11728b8bf75a3fd995a2c1ff28
- https://git.kernel.org/stable/c/42658e47f1abbbe592007d3ba303de466114d0bb
- https://git.kernel.org/stable/c/86c3c5f8e4bd1325e24f6fba9017cade29933377
- https://git.kernel.org/stable/c/8a1a1255152da4fb934290e7ababc66f24985520
- https://git.kernel.org/stable/c/a101793994c0a14c70bb4e44c7fda597eeebba0a
- https://git.kernel.org/stable/c/c1df9cb756e5a9ba1841648c44ee5d92306b9c65
- https://git.kernel.org/stable/c/dc1cf8c6f9793546696fded437a5b4c84944c48b
- https://git.kernel.org/stable/c/e0d763d0c7665c7897e4f5a0847ab0c82543345f
Modified: 2025-10-01
CVE-2022-49368
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read.
- https://git.kernel.org/stable/c/0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8
- https://git.kernel.org/stable/c/2bd1faedb74dc2a2be3972abcd4239b75a3e7b00
- https://git.kernel.org/stable/c/4cde554c70d7397cfa2e4116bacb4accdfb6fd48
- https://git.kernel.org/stable/c/5ba81f82607ead85fe36f50869fc4f5661359ab8
- https://git.kernel.org/stable/c/657e7174603f0aab2cdedc64ac81edffd2a87afe
- https://git.kernel.org/stable/c/71ae30662ec610b92644d13f79c78f76f17873b3
- https://git.kernel.org/stable/c/b24ca1cf846273361d5bd73a35de95a486a54b6d
- https://git.kernel.org/stable/c/b4f0e57ea0d867aacffad7999527e48bd4ea9293
- https://git.kernel.org/stable/c/e7e7104e2d5ddf3806a28695670f21bef471f1e1
Modified: 2025-10-01
CVE-2022-49370
In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put().
- https://git.kernel.org/stable/c/3ba359ebe914ac3f8c6c832b28007c14c39d3766
- https://git.kernel.org/stable/c/660ba678f9998aca6db74f2dd912fa5124f0fa31
- https://git.kernel.org/stable/c/985706bd3bbeffc8737bc05965ca8d24837bc7db
- https://git.kernel.org/stable/c/a724634b2a49f6ff0177a9e19a5a92fc1545e1b7
- https://git.kernel.org/stable/c/a9bfb37d6ba7c376b0d53337a4c5f5ff324bd725
- https://git.kernel.org/stable/c/c66cc3c62870a27ea8f060a7e4c1ad8d26dd3f0d
- https://git.kernel.org/stable/c/ec752973aa721ee281d5441e497364637c626c7b
- https://git.kernel.org/stable/c/ed38d04342dfbe9e5aca745c8b5eb4188a74f0ef
- https://git.kernel.org/stable/c/fdffa4ad8f6bf1ece877edfb807f2b2c729d8578
Modified: 2025-10-21
CVE-2022-49372
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_rtx_synack() can be called from process context
Laurent reported the enclosed report [1]
This bug triggers with following coditions:
0) Kernel built with CONFIG_DEBUG_PREEMPT=y
1) A new passive FastOpen TCP socket is created.
This FO socket waits for an ACK coming from client to be a complete
ESTABLISHED one.
2) A socket operation on this socket goes through lock_sock()
release_sock() dance.
3) While the socket is owned by the user in step 2),
a retransmit of the SYN is received and stored in socket backlog.
4) At release_sock() time, the socket backlog is processed while
in process context.
5) A SYNACK packet is cooked in response of the SYN retransmit.
6) -> tcp_rtx_synack() is called in process context.
Before blamed commit, tcp_rtx_synack() was always called from BH handler,
from a timer handler.
Fix this by using TCP_INC_STATS() & NET_INC_STATS()
which do not assume caller is in non preemptible context.
[1]
BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
caller is tcp_rtx_synack.part.0+0x36/0xc0
CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1
Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
Call Trace:
- https://git.kernel.org/stable/c/0a0f7f84148445c9f02f226928803a870139d820
- https://git.kernel.org/stable/c/0a375c822497ed6ad6b5da0792a12a6f1af10c0b
- https://git.kernel.org/stable/c/3db889f883e65bbd3b1401279bfc1e9ed255c481
- https://git.kernel.org/stable/c/58bd38cbc961fd799842b7be8c5222310f04b908
- https://git.kernel.org/stable/c/88cd232146207ff1d41dededed5e77c0d4438113
- https://git.kernel.org/stable/c/bdc28a8fb43cc476e33b11519235adb816ce00e8
- https://git.kernel.org/stable/c/c348b0f8d035fc4bdc040796889beec7218bd1b8
- https://git.kernel.org/stable/c/d05c2fdf8e10528bb6751bd95243e862d5402a9b
- https://git.kernel.org/stable/c/d8e1bc6029acac796293310aacef7b7336f35b6a
Modified: 2025-10-01
CVE-2022-49374
In the Linux kernel, the following vulnerability has been resolved: tipc: check attribute length for bearer name syzbot reported uninit-value: ===================================================== BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME. - Do not use 'illegal name' in printing message.
- https://git.kernel.org/stable/c/292be63c382ce20673ee61dff1ee9ed4a3dcaae7
- https://git.kernel.org/stable/c/3af15272cde28fe5c8489174b8624e232c1775ec
- https://git.kernel.org/stable/c/7f36f798f89bf32c0164049cb0e3fd1af613d0bb
- https://git.kernel.org/stable/c/8b91d0dfc839e67708c905648cd0e7507a2263e5
- https://git.kernel.org/stable/c/92a930fcf4250fe961f6238b99af0bc405799f39
- https://git.kernel.org/stable/c/b8fac8e321044a9ac50f7185b4e9d91a7745e4b0
- https://git.kernel.org/stable/c/f07670871f4d19e613740eebe210e7e9ea535973
Modified: 2025-10-01
CVE-2022-49375
In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/3867f0bbb94773d41e789257abec0d14f37da217
- https://git.kernel.org/stable/c/58a729c55ce3a432eb827fdaa24c7909cd3b0a6b
- https://git.kernel.org/stable/c/6ecd4d5c28408df36a1a6f0b1973f633c949ac1f
- https://git.kernel.org/stable/c/79fa3f5758d8712df0678df98161f948fc4370e5
- https://git.kernel.org/stable/c/82bfea344e8f7e9a0e0b1bf9af27552baa756620
- https://git.kernel.org/stable/c/865051de2d9eaa50630e055b73921ceaf3c4a7fc
- https://git.kernel.org/stable/c/d3b43eb505bffb8e4cdf6800c15660c001553fe6
- https://git.kernel.org/stable/c/d77f28c1bc9d3043a52069fe42e4a26fbf961ebd
- https://git.kernel.org/stable/c/da38e86d6cf6dd3bc65c602d998f357145aa1a0b
Modified: 2025-10-01
CVE-2022-49381
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_fill_super
If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
an error, we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff888105a65340 (size 64):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/28048a4cf3813b7cf5cc8cce629dfdc7951cb1c2
- https://git.kernel.org/stable/c/3252d327f977b14663a10967f3b0930d6c325687
- https://git.kernel.org/stable/c/4ba7bbeab8009faf3a726e565d98816593ddd5b0
- https://git.kernel.org/stable/c/4da8763a3d2b684c773b72ed80fad40bc264bc40
- https://git.kernel.org/stable/c/69295267c481545f636b69ff341b8db75aa136b9
- https://git.kernel.org/stable/c/c14adb1cf70a984ed081c67e9d27bc3caad9537c
- https://git.kernel.org/stable/c/cf9db013e167bc8fc2ecd7a13ed97a37df0c9dab
- https://git.kernel.org/stable/c/d3a4fff1e7e408c32649030daa7c2c42a7e19a95
- https://git.kernel.org/stable/c/ecc53e58596542791e82eff00702f8af7a313f70
Modified: 2025-10-01
CVE-2022-49382
In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/042571fe1d171773655ad706715ecc865913d9a4
- https://git.kernel.org/stable/c/28133325526b92921f3269fdf97a20d90b92b217
- https://git.kernel.org/stable/c/5b3e990f85eb034faa461e691e719e8ce9e2a3c8
- https://git.kernel.org/stable/c/69a30b2ed620c2206cbbd1e9c112e4fc584e02bd
- https://git.kernel.org/stable/c/8f64e84924604bb969ee1fbc4b8d7d09b9214889
- https://git.kernel.org/stable/c/9b59588d8be91c96bfb0371e912ceb4f16315dbf
- https://git.kernel.org/stable/c/aab25b669cb9fd3698c2631be4435f4fe92d9e59
- https://git.kernel.org/stable/c/d5422f323858cad3ac3581075f9a3a5e0d41c0d8
Modified: 2025-03-25
CVE-2022-49388
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link].
- https://git.kernel.org/stable/c/1174ab8ba36a48025b68b5ff1085000b1e510217
- https://git.kernel.org/stable/c/25ff1e3a1351c0d936dd1ac2f9e58231ea1510c9
- https://git.kernel.org/stable/c/5ff2514e4fb55dcf3d88294686040ca73ea0c1a2
- https://git.kernel.org/stable/c/6d8d3f68cbecfd31925796f0fb668eb21ab06734
- https://git.kernel.org/stable/c/8302620aeb940f386817321d272b12411ae7d39f
- https://git.kernel.org/stable/c/8c03a1c21d72210f81cb369cc528e3fde4b45411
- https://git.kernel.org/stable/c/abb67043060f2bf4c03d7c3debb9ae980e2b6db3
- https://git.kernel.org/stable/c/e27ecf325e51abd06aaefba57a6322a46fa4178b
Modified: 2025-10-01
CVE-2022-49389
In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review.
- https://git.kernel.org/stable/c/11c65408bd0ba1d9cd1307caa38169292de9cdfb
- https://git.kernel.org/stable/c/247d3809e45a34d9e1a3a2bb7012e31ed8b46031
- https://git.kernel.org/stable/c/2f0ae93ec33c8456cdfbf7876b80403a6318ebce
- https://git.kernel.org/stable/c/51422046be504515eb5a591adf0f424b62f46804
- https://git.kernel.org/stable/c/6bafee2f18af5e5ac125e42960bc65496d0e56a0
- https://git.kernel.org/stable/c/8afb048800919d0ab10c57983940eba956339f21
- https://git.kernel.org/stable/c/9ec4cbf1cc55d126759051acfe328d489c5d6e60
- https://git.kernel.org/stable/c/bcbb795a9e78180d74c6ab21518da87e803dfdce
- https://git.kernel.org/stable/c/f20d2d3b3364ce6525c050a8b6b4c54c8c19674d
Modified: 2025-10-21
CVE-2022-49394
In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix inflight count imbalances and IO hangs on offline iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.
- https://git.kernel.org/stable/c/515d077ee3085ae343b6bea7fd031f9906645f38
- https://git.kernel.org/stable/c/5b0ff3ebbef791341695b718f8d2870869cf1d01
- https://git.kernel.org/stable/c/77692c02e1517c54f2fd0535f41aa4286ac9f140
- https://git.kernel.org/stable/c/8a177a36da6c54c98b8685d4f914cb3637d53c0d
- https://git.kernel.org/stable/c/968f7a239c590454ffba79c126fbe0e963a0ba78
- https://git.kernel.org/stable/c/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547
- https://git.kernel.org/stable/c/d19fa8f252000d141f9199ca32959c50314e1f05
Modified: 2025-10-01
CVE-2022-49395
In the Linux kernel, the following vulnerability has been resolved: um: Fix out-of-bounds read in LDT setup syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================
- https://git.kernel.org/stable/c/10995a382271254bd276627ec74136da4a23c4a6
- https://git.kernel.org/stable/c/24ca648bf5f72ed8878cf09b5d4431935779681e
- https://git.kernel.org/stable/c/2a4a62a14be1947fa945c5c11ebf67326381a568
- https://git.kernel.org/stable/c/3549ab4b962cf619e8c55484a0d870a34b3f845f
- https://git.kernel.org/stable/c/668ca34a428d6ffc0f99a1a6a9b661a288d4183b
- https://git.kernel.org/stable/c/91e5ba2af2d729d5126aefd5aa3eadc69b8426e5
- https://git.kernel.org/stable/c/9caad70819aef3431abaf73ba5163b55b161aba0
- https://git.kernel.org/stable/c/cf0dabc37446c5ee538ae7b4c467ab0e53fa5463
- https://git.kernel.org/stable/c/ef1dc929a1e5fa1b2d842256db9fb8710d3be910
Modified: 2025-09-22
CVE-2022-49396
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix reset-controller leak on probe errors Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly.
- https://git.kernel.org/stable/c/2156dc390402043ba5982489c6625adcb0b0975c
- https://git.kernel.org/stable/c/4d2900f20edfe541f75756a00deeb2ffe7c66bc1
- https://git.kernel.org/stable/c/7ac21b24af859c097eb4034e93430056068f8f31
- https://git.kernel.org/stable/c/8c03eb0c8982677b4e17174073a011788891304d
- https://git.kernel.org/stable/c/a39d9eccb333b8c07c43ebea1c6dfda122378a0f
- https://git.kernel.org/stable/c/b7b5fbcaac5355e2e695dc0c08a0fcf248250388
- https://git.kernel.org/stable/c/ba173a6f8d8dffed64bb13ab23081bdddfb464f0
- https://git.kernel.org/stable/c/feb05b10b3ed3ae21b851520a0d0b71685439517
Modified: 2025-09-22
CVE-2022-49397
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix struct clk leak on probe errors Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral).
- https://git.kernel.org/stable/c/1668ad103679306ba2ef37f758d704e58a3ef1a0
- https://git.kernel.org/stable/c/621a4bcfb7aa031e7760d7b156bad7a45df58387
- https://git.kernel.org/stable/c/6f3673c8d8eff0c4ab5a5ee0d3ca9717d85419b4
- https://git.kernel.org/stable/c/ad9b0fad02f9b3a06ad5ac7df11f244e316a6254
- https://git.kernel.org/stable/c/b246695636a861a09f0e2cde92bb2dd8f114f024
- https://git.kernel.org/stable/c/b999d48b0869b8599de532ff6081575a7ab5358a
- https://git.kernel.org/stable/c/f0a4bc38a12f5a0cc5ad68670d9480e91e6a94df
- https://git.kernel.org/stable/c/f8d23895a41243c6a8dbf392e531fff9497bb023
Modified: 2025-10-21
CVE-2022-49399
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Use tty_port_destroy() to destroy port In goldfish_tty_probe(), the port initialized through tty_port_init() should be destroyed in error paths.In goldfish_tty_remove(), qtty->port also should be destroyed or else might leak resources. Fix the above by calling tty_port_destroy().
- https://git.kernel.org/stable/c/241fcb79dd1df276d80b19f5f6acc9eaaaa63309
- https://git.kernel.org/stable/c/326192b99c903a2193d820c30ed936cc2402382c
- https://git.kernel.org/stable/c/45f6ce70abfb7ccf9d787781cbc4c03294a775a1
- https://git.kernel.org/stable/c/4639d1b992de8f37d66f698056875c274efcd45f
- https://git.kernel.org/stable/c/507b05063d1b7a1fcb9f7d7c47586fc4f3508f98
- https://git.kernel.org/stable/c/9ae3d073f7db5578ae1907544f0c15947e9678e6
- https://git.kernel.org/stable/c/da64f419d7f78272bfe40dde1262602d4ff6b32c
- https://git.kernel.org/stable/c/ee6c33b29e624f515202a31bf6ef0437f26a1867
Modified: 2025-10-01
CVE-2022-49404
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow.
- https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188407eba2996d
- https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a
- https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6
- https://git.kernel.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b
- https://git.kernel.org/stable/c/79c164e61f818054cd6012e9035701840d895c51
- https://git.kernel.org/stable/c/8858284dd74906fa00f04f0252c75df4893a7959
- https://git.kernel.org/stable/c/a89cb7ddf6a89bab6012e19da38b7cdb26175c19
- https://git.kernel.org/stable/c/ef5ab2e48a5f9960e2352332b7cdb7064bb49032
- https://git.kernel.org/stable/c/f93e91a0372c922c20d5bee260b0f43b4b8a1bee
Modified: 2025-09-22
CVE-2022-49407
In the Linux kernel, the following vulnerability has been resolved: dlm: fix plock invalid read This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated---
- https://git.kernel.org/stable/c/2c55155cc365861044d9e6e80e342693e8805e33
- https://git.kernel.org/stable/c/42252d0d2aa9b94d168241710a761588b3959019
- https://git.kernel.org/stable/c/49cd9eb7b9a7b88124b31e31f8e539acaf1b3a6d
- https://git.kernel.org/stable/c/56aa8d1fbd02357f3bf81bdfba1cde87ce8402fc
- https://git.kernel.org/stable/c/5a1765adf9855cf0f6d3f7e0eb4b78ca66f70dee
- https://git.kernel.org/stable/c/72f2f68970f9bdc252d59e119b385a6441b0b155
- https://git.kernel.org/stable/c/899bc4429174861122f0c236588700a4710c1fec
- https://git.kernel.org/stable/c/acdad5bc9827922ec2f2e84fd198718aa8e8ab92
- https://git.kernel.org/stable/c/e421872fa17542cf33747071fb141b0130ce9ef7
Modified: 2025-10-01
CVE-2022-49410
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref().
- https://git.kernel.org/stable/c/058cb6d86b9789377216c936506b346aaa1eb581
- https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50
- https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e
- https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f
- https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae
- https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2
- https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a
Modified: 2025-03-24
CVE-2022-49416
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx.
- https://git.kernel.org/stable/c/265bec4779a38b65e86a25120370f200822dfa76
- https://git.kernel.org/stable/c/2965c4cdf7ad9ce0796fac5e57debb9519ea721e
- https://git.kernel.org/stable/c/4ba81e794f0fad6234f644c2da1ae14d5b95e1c4
- https://git.kernel.org/stable/c/4f05a9e15edcdf5b97e0d86ab6ecd5f187289f6c
- https://git.kernel.org/stable/c/6118bbdf69f4718b02d26bbcf2e497eb66004331
- https://git.kernel.org/stable/c/82c8e7bbdd06c7ed58e22450cc5b37f33a25bb2c
- https://git.kernel.org/stable/c/88cc8f963febe192d6ded9df7217f92f380b449a
- https://git.kernel.org/stable/c/9f1e5cc85ad77e52f54049a94db0407445ae2a34
- https://git.kernel.org/stable/c/b79110f2bf6022e60e590d2e094728a8eec3e79e
Modified: 2025-09-22
CVE-2022-49421
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/2e2e2c71b2642289438392edbf5d08cdbc0b138b
- https://git.kernel.org/stable/c/38d245cebf545338a6bc1c7762023de3fbecd7b7
- https://git.kernel.org/stable/c/51eb1bb6baeb478538dd4ec6459fd68c44a855b1
- https://git.kernel.org/stable/c/6c92711db7c90f78e0b67ac2a8944d0fe7e12d83
- https://git.kernel.org/stable/c/8db59df7f5826e104db82cfddbf22a33a151193e
- https://git.kernel.org/stable/c/b23789a59fa6f00e98a319291819f91fbba0deb8
- https://git.kernel.org/stable/c/bbb2a24e863b6a10129546a0a4ceea2f07deec39
- https://git.kernel.org/stable/c/c1c4405222b6fc98c16e8c2aa679c14e41d81465
- https://git.kernel.org/stable/c/f2dfb4ab887d67be7d0892ba041d3c8d738d3356
Modified: 2025-10-22
CVE-2022-49425
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dereference of stale list iterator after loop body The list iterator variable will be a bogus pointer if no break was hit. Dereferencing it (cur->page in this case) could load an out-of-bounds/undefined value making it unsafe to use that in the comparision to determine if the specific element was found. Since 'cur->page' *can* be out-ouf-bounds it cannot be guaranteed that by chance (or intention of an attacker) it matches the value of 'page' even though the correct element was not found. This is fixed by using a separate list iterator variable for the loop and only setting the original variable if a suitable element was found. Then determing if the element was found is simply checking if the variable is set.
- https://git.kernel.org/stable/c/2aaf51dd39afb6d01d13f1e6fe20b684733b37d5
- https://git.kernel.org/stable/c/385edd3ce5b4b1e9d31f474a5e35a39779ec1110
- https://git.kernel.org/stable/c/45b2b7d7108ae1e25a5036cab04ab9273e792332
- https://git.kernel.org/stable/c/51d584704d18e60fa473823654f35611c777b291
- https://git.kernel.org/stable/c/5e47a7add3dda7f236548c5ec3017776dc2a729f
- https://git.kernel.org/stable/c/b26e1c777890e4b938136deb8ec07a29f33862e4
- https://git.kernel.org/stable/c/ed7efc472c00986dcd6903ab6ed165c7fa167674
Modified: 2025-10-22
CVE-2022-49429
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent panic when SDMA is disabled If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.
- https://git.kernel.org/stable/c/0e4dda8b3f4c07ee9ea670a10ea3171a5e63a86f
- https://git.kernel.org/stable/c/22e7e400fd1a890db2ea13686324aff50e972f4f
- https://git.kernel.org/stable/c/29952ab85d6c3fe0b7909d9a737f10c58bf6824d
- https://git.kernel.org/stable/c/32e6aea33944f364d51cd263e4cd236393a188b6
- https://git.kernel.org/stable/c/33794e8e9bcb4affc0ebff9cdec85acc8b8a1762
- https://git.kernel.org/stable/c/629e052d0c98e46dde9f0824f0aa437f678d9b8f
- https://git.kernel.org/stable/c/cc80d3c37cec9d6ddb140483647901bc7cc6c31d
- https://git.kernel.org/stable/c/e60ad83f645ee6fadd5a8057ba267aeec54f08fe
Modified: 2025-10-22
CVE-2022-49432
In the Linux kernel, the following vulnerability has been resolved: powerpc/xics: fix refcount leak in icp_opal_init() The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done.
- https://git.kernel.org/stable/c/1d5c8cea85fb1680eae8d645b96b92146cb4633c
- https://git.kernel.org/stable/c/2357bd7499a81c70b460e2191852bbfc7b63c354
- https://git.kernel.org/stable/c/537a317e5ff45d1f5a0ecaf6a0d7c8043c878cb1
- https://git.kernel.org/stable/c/53f3f7f73e609b934083f896cb7ca2c2cb009b9f
- https://git.kernel.org/stable/c/5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9
- https://git.kernel.org/stable/c/6a61a97106279c2aa16fbbb2a171fd5dde127d23
- https://git.kernel.org/stable/c/977dbc81d0f866ef63b93c127b7404f07734b3cc
- https://git.kernel.org/stable/c/9a42bc2494fadb453de00ce61042e588563ddc6d
- https://git.kernel.org/stable/c/df802880a7f9cd96b921b00639b00871f18a9a57
Modified: 2025-10-22
CVE-2022-49433
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent use of lock before it is initialized If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized.
- https://git.kernel.org/stable/c/05c03dfd09c069c4ffd783b47b2da5dcc9421f2c
- https://git.kernel.org/stable/c/288d198f50434f29b4a26a9de4394ae2305ad8af
- https://git.kernel.org/stable/c/30eb275e7ed588270ae159cc590a96658e0cfd8f
- https://git.kernel.org/stable/c/66090815a24ce14cf51ef5453fc0218fe8a39bc2
- https://git.kernel.org/stable/c/addb192000d8819c0b1553453994df9bb54c28db
- https://git.kernel.org/stable/c/ca55150bff5817af4f857a746ecab9862c23e12a
- https://git.kernel.org/stable/c/fc0750e659db7b315bf6348902cc8ca3cdd4b8d8
Modified: 2025-12-23
CVE-2022-49434
In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
- https://git.kernel.org/stable/c/2cdd5284035322795b0964f899eefba254cfe483
- https://git.kernel.org/stable/c/59ea6b3ae51df7cd6bfd84c9c0030609b9315622
- https://git.kernel.org/stable/c/a91ee0e9fca9d7501286cfbced9b30a33e52740a
- https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c
- https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831
- https://git.kernel.org/stable/c/c9a81f9ed6ae3554621d6a50220b1bc74b67d81e
- https://git.kernel.org/stable/c/ea047f51172aa68841adef7f52d375002438b8f0
- https://git.kernel.org/stable/c/eff3587b9c01439b738298475e555c028ac9f55e
Modified: 2025-10-01
CVE-2022-49438
In the Linux kernel, the following vulnerability has been resolved: Input: sparcspkr - fix refcount leak in bbc_beep_probe of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1124e39fea0e2fdb4202f95b716cb97cc7de7cc7
- https://git.kernel.org/stable/c/2f51db16cb740ff90086189a1ef2581eab665591
- https://git.kernel.org/stable/c/353bc58ac6c782d4dcde9136a91d1f90867938fe
- https://git.kernel.org/stable/c/418b6a3e12f75638abc5673eb76cb32127d0ab13
- https://git.kernel.org/stable/c/6e07ccc7d56130f760d23f67a70c45366c07debc
- https://git.kernel.org/stable/c/73d6f42d8d86648bec2e73d34fe1648cb6d23e08
- https://git.kernel.org/stable/c/bbc2b0ce6042dd3117827f10ea8cb67e0ab786da
- https://git.kernel.org/stable/c/c8994b30d71d64d5dcc9bc0edbfdf367171aa96f
- https://git.kernel.org/stable/c/f13064b0f2c651a3fbb0749932795c6fd21556a8
Modified: 2025-10-01
CVE-2022-49439
In the Linux kernel, the following vulnerability has been resolved: powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/46fd994763cf6884b88a2da712af918f3ed54d7b
- https://git.kernel.org/stable/c/51e25fbf20c9152d84a34b7afac15a41fe5c9116
- https://git.kernel.org/stable/c/5607a77a365df8c0fd5ff43ac424812b95775527
- https://git.kernel.org/stable/c/5b8aa2ba38c010f47c965dd9bb5a8561813ed649
- https://git.kernel.org/stable/c/7b668a59ddfb32727e39b06fdf52b28e58c684e0
- https://git.kernel.org/stable/c/bcb6c4c5eb4836a21411dfe8247bf9951eb6e7c3
- https://git.kernel.org/stable/c/c70dd353d37158e06bf8d450d4b31a7091609924
- https://git.kernel.org/stable/c/fcee96924ba1596ca80a6770b2567ca546f9a482
Modified: 2025-10-01
CVE-2022-49441
In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
- https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314
- https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50
- https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded
- https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28
- https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246
- https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9
- https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3
- https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede
- https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6
Modified: 2025-10-22
CVE-2022-49442
In the Linux kernel, the following vulnerability has been resolved: drivers/base/node.c: fix compaction sysfs file leak Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix this issue.
- https://git.kernel.org/stable/c/386e69e068177ee91cac27f2f0e6ebda1515f5ca
- https://git.kernel.org/stable/c/39642b0feddb9c39faa6de469a94bfeb4dc0d3a9
- https://git.kernel.org/stable/c/466134df7561aeb801baddf6666b512e0e1a1707
- https://git.kernel.org/stable/c/606732650a2c88e66c59c22dd5464ea0d820250e
- https://git.kernel.org/stable/c/6905be93d1ab54f73718047536fec0ca488d5315
- https://git.kernel.org/stable/c/b3fcf1f583b1a0946d9d9bfb7362c9c186801775
- https://git.kernel.org/stable/c/d8a5bdc767f17281da648555cdbd286f98fd98ee
- https://git.kernel.org/stable/c/da63dc84befaa9e6079a0bc363ff0eaa975f9073
- https://git.kernel.org/stable/c/f76ddc8fcf6d81fe89bfa4d3efcbc4fe69a91d48
Modified: 2025-10-01
CVE-2022-49447
In the Linux kernel, the following vulnerability has been resolved: ARM: hisi: Add missing of_node_put after of_find_compatible_node of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak
- https://git.kernel.org/stable/c/21a3effe446dd6dc5eed7fe897c2f9b88c9a5d6d
- https://git.kernel.org/stable/c/45d211668d33c49d73f5213e8c2b58468108647c
- https://git.kernel.org/stable/c/46cb7868811d025c3d29c10d18b3422db1cf20d5
- https://git.kernel.org/stable/c/9bc72e47d4630d58a840a66a869c56b29554cfe4
- https://git.kernel.org/stable/c/a3265a9440030068547a20dfee646666f3ca5278
- https://git.kernel.org/stable/c/cafaaae4bb9ce84a2791fa29bf6907a9466c3883
- https://git.kernel.org/stable/c/dd4be8ecfb41a29e7c4e551b4e866157ce4a3429
- https://git.kernel.org/stable/c/e109058165137ef42841abd989f080adfefa14fa
- https://git.kernel.org/stable/c/f8da78b2bae1f54746647a2bb44f8bd6025c57af
Modified: 2025-10-01
CVE-2022-49450
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump
up the sysctl), but whilst the preallocation circular buffers have 32 slots
in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket
is closed because rxrpc_service_prealloc_one() allocated one too many calls
and rxrpc_discard_prealloc() won't then be able to get rid of them because
it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries
to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match
the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086
...
RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]
Call Trace:
- https://git.kernel.org/stable/c/369de57492c4f1a42563c5a3bd365822ca3bfc79
- https://git.kernel.org/stable/c/4a3a78b7918bdd723d8c7c9786522ca969bffcc4
- https://git.kernel.org/stable/c/5b4826657d36c218e9f08e8d3223b0edce3de88f
- https://git.kernel.org/stable/c/616f76498d5ddf26b997caf64a95cda3c8a55533
- https://git.kernel.org/stable/c/61fb38cfbb1d54d3dafd0c25752f684b3cd00b32
- https://git.kernel.org/stable/c/88e22159750b0d55793302eeed8ee603f5c1a95c
- https://git.kernel.org/stable/c/91b34bf0409f43bb60453bab23c5beadd726d022
- https://git.kernel.org/stable/c/b3a9b227d5e7467b8518160ff034ea22bb9de573
- https://git.kernel.org/stable/c/e198f1930050e3115c80b67d9249f80f98a27c67
Modified: 2025-10-01
CVE-2022-49451
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix list protocols enumeration in the base protocol While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition.
- https://git.kernel.org/stable/c/1052f22e127d0c34c3387bb389424ba1c61491ff
- https://git.kernel.org/stable/c/2ccfcd7a09c826516edcfe464b05071961aada3f
- https://git.kernel.org/stable/c/444a2d27fe9867d0da4b28fc45b793f32e099ab8
- https://git.kernel.org/stable/c/6e7978695f4a6cbd83616b5a702b77fa2087b247
- https://git.kernel.org/stable/c/8009120e0354a67068e920eb10dce532391361d0
- https://git.kernel.org/stable/c/98342148a8cd242855d7e257f298c966c96dba9f
- https://git.kernel.org/stable/c/b0e4bafac8963c2d85ee18d3d01f393735acceec
Modified: 2025-10-01
CVE-2022-49457
In the Linux kernel, the following vulnerability has been resolved: ARM: versatile: Add missing of_node_put in dcscb_init The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/23b44f9c649bbef10b45fa33080cd8b4166800ae
- https://git.kernel.org/stable/c/2d7b23db35254b7d46e852967090c64cdccf24da
- https://git.kernel.org/stable/c/3c6006faed9aba5144b33176d061031a9be66954
- https://git.kernel.org/stable/c/83c329b980bddbc8c6a3d287d91f2103a4d4a860
- https://git.kernel.org/stable/c/a0fc05cd17617e63fc13ad0c01f3f0afd890d8ec
- https://git.kernel.org/stable/c/bbdfb7d4f036118d36415a2575efa6f5246505ae
- https://git.kernel.org/stable/c/d146e2a9864ade19914494de3fb520390b415d58
- https://git.kernel.org/stable/c/d6de7b181c29cd4578ec139aafb5eac062abbe1b
- https://git.kernel.org/stable/c/fcd1999ba97445a12cc394f5f42ffd9116bf0185
Modified: 2025-10-22
CVE-2022-49460
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: rk3399_dmc: Disable edev on remove() Otherwise we hit an unablanced enable-count when unbinding the DFI device: [ 1279.659119] ------------[ cut here ]------------ [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c ... [ 1279.659352] Hardware name: Google Kevin (DT) [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28 ... [ 1279.659571] Call trace: [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c [ 1279.659590] devm_devfreq_event_release+0x1c/0x28 [ 1279.659602] release_nodes+0x1cc/0x244 [ 1279.659611] devres_release_all+0x44/0x60 [ 1279.659621] device_release_driver_internal+0x11c/0x1ac [ 1279.659629] device_driver_detach+0x20/0x2c [ 1279.659641] unbind_store+0x7c/0xb0 [ 1279.659650] drv_attr_store+0x2c/0x40 [ 1279.659663] sysfs_kf_write+0x44/0x58 [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190 [ 1279.659684] vfs_write+0x2b0/0x2e4 [ 1279.659693] ksys_write+0x80/0xec [ 1279.659701] __arm64_sys_write+0x24/0x30 [ 1279.659714] el0_svc_common+0xf0/0x1d8 [ 1279.659724] do_el0_svc_compat+0x28/0x3c [ 1279.659738] el0_svc_compat+0x10/0x1c [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc [ 1279.659758] el0_sync_compat+0x188/0x1c0 [ 1279.659768] ---[ end trace cec200e5094155b4 ]---
- https://git.kernel.org/stable/c/2fccf9e6050e0e3b8b4cd275d41daf7f7fa22804
- https://git.kernel.org/stable/c/664736e2cc09e504ce58ec61164d029d1f2651bb
- https://git.kernel.org/stable/c/86b091b6894c449d2734de7aa7d79ccb33ffd97d
- https://git.kernel.org/stable/c/a0180e324a9a63de8f770da300477b48cb4a53f1
- https://git.kernel.org/stable/c/a9c2b23a7ac6ab19214cad8cac8af8608a4d9cef
- https://git.kernel.org/stable/c/cb1be1d4be18fe286ba5a67d928598378fd7fbe5
- https://git.kernel.org/stable/c/fb089b6f21de03a685dd31df3789bbb01c59f8e3
Modified: 2025-10-01
CVE-2022-49467
In the Linux kernel, the following vulnerability has been resolved: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails.
- https://git.kernel.org/stable/c/33546183c16c7b9650682dc610bedd732d9c6919
- https://git.kernel.org/stable/c/449374565f349d4233beec811d4286fdfe5de44b
- https://git.kernel.org/stable/c/656aa3c51fc662064f17179b38ec3ce43af53bca
- https://git.kernel.org/stable/c/947a844bb3ebff0f4736d244d792ce129f6700d7
- https://git.kernel.org/stable/c/d544880482a5558ec06393b1b3d5dc9275b7a32b
- https://git.kernel.org/stable/c/d63ffe3fb3f8327ca21cf91b6a14a2961bc629b4
- https://git.kernel.org/stable/c/f8cd192752a1f613b14eee77783c6f0aebb49691
Modified: 2025-10-01
CVE-2022-49472
In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type.
- https://git.kernel.org/stable/c/143878e18001c5a61fcc7ae5c5240323753bb641
- https://git.kernel.org/stable/c/1e5fbfc2a6f384e3195446c14bbd3bc298eb88c2
- https://git.kernel.org/stable/c/660dfa033ccc9afb032015b6dc76e846bba42cfb
- https://git.kernel.org/stable/c/7dcb404662839a4ed1a9703658fee979eb894ca4
- https://git.kernel.org/stable/c/91e720b32cba25fa58eaa4c88fe957009cffe9f3
- https://git.kernel.org/stable/c/abb5594ae2ba7b82cce85917cc6337ec5d774837
- https://git.kernel.org/stable/c/bd219273b4e004a3f853da72e111fc8f81357501
- https://git.kernel.org/stable/c/f2ef6f7539c68c6bd6c32323d8845ee102b7c450
Modified: 2025-03-24
CVE-2022-49474
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30
- https://git.kernel.org/stable/c/36c644c63bfcaee2d3a426f45e89a9cd09799318
- https://git.kernel.org/stable/c/390d82733a953c1fabf3de9c9618091a7a9c90a6
- https://git.kernel.org/stable/c/537f619dea4e3fa8ed1f8f938abffe3615794bcc
- https://git.kernel.org/stable/c/65d347cb39e2e6bd0c2a745ad7c928998ebb0162
- https://git.kernel.org/stable/c/6f55fac0af3531cf60d11369454c41f5fc81ab3f
- https://git.kernel.org/stable/c/7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2
- https://git.kernel.org/stable/c/7d61dbd7311ab978d8ddac1749a758de4de00374
- https://git.kernel.org/stable/c/99df16007f4bbf9abfc3478cb17d10f0d7f8906e
- https://git.kernel.org/stable/c/9de3dc09e56f8deacd2bdbf4cecb71e11a312405
Modified: 2025-10-01
CVE-2022-49478
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work.
- https://git.kernel.org/stable/c/1310fc3538dcc375a2f46ef0a438512c2ca32827
- https://git.kernel.org/stable/c/24e807541e4a9263ed928e6ae3498de3ad43bd1e
- https://git.kernel.org/stable/c/2e004fe914b243db41fa96f9e583385f360ea58e
- https://git.kernel.org/stable/c/3309c2c574e13b21b44729f5bdbf21f60189b79a
- https://git.kernel.org/stable/c/4351bfe36aba9fa7dc9d68d498d25d41a0f45e67
- https://git.kernel.org/stable/c/471bec68457aaf981add77b4f590d65dd7da1059
- https://git.kernel.org/stable/c/a3304766d9384886e6d3092c776273526947a2e9
- https://git.kernel.org/stable/c/a3660e06675bccec4bf149c7229ea1d491ba10d7
- https://git.kernel.org/stable/c/f99a8b1ec0eddc2931aeaa4f490277a15b39f511
Modified: 2025-10-01
CVE-2022-49481
In the Linux kernel, the following vulnerability has been resolved: regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore.
- https://git.kernel.org/stable/c/0be5d9da5743b9825a95baec85a67500b2c1d362
- https://git.kernel.org/stable/c/49d785baeb91568332197be356d138e5e59c7ddb
- https://git.kernel.org/stable/c/56ab0c01027492cd161c64148e1dc892c56887ad
- https://git.kernel.org/stable/c/671be14fc31374b1a10a3abd93db6a8480838fc9
- https://git.kernel.org/stable/c/6ca675f4abbc74bc991d154a1ecc8b384dc2aae4
- https://git.kernel.org/stable/c/984cfef0675ed7398814e14af2c5323911723e1c
- https://git.kernel.org/stable/c/9f564e29a51210a49df3d925117777c157a17d6d
- https://git.kernel.org/stable/c/afaa7b933ef00a2d3262f4d1252087613fb5c06d
- https://git.kernel.org/stable/c/b74c0dd9179d21b7260260e075d597b23970100c
Modified: 2025-10-01
CVE-2022-49482
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done.
- https://git.kernel.org/stable/c/18b907ff0ae4bf20120aae1538f7156b9d08e3a7
- https://git.kernel.org/stable/c/24491124406666bf0dcb9ee10c5575c6ce6a1730
- https://git.kernel.org/stable/c/2a0da7641e1f17a744ac7b3f76471388c97b63dc
- https://git.kernel.org/stable/c/2be84f73785fa9ed6443e3c5b158730266f1c2ee
- https://git.kernel.org/stable/c/30d110ca703ce60162ec337aa564a3e4da30715f
- https://git.kernel.org/stable/c/4e2a1bcc51bdebed48176f6e88c150f175983f9c
- https://git.kernel.org/stable/c/c933829cbf3338b684869e6c4c8931abf5d68fbd
- https://git.kernel.org/stable/c/d42601e93fce7802bb8d70dd59b60cfeefa20469
- https://git.kernel.org/stable/c/d855505851ee8ba666eb204149b49f906130dc17
Modified: 2025-10-22
CVE-2022-49488
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Patchwork: https://patchwork.freedesktop.org/patch/485181/
- https://git.kernel.org/stable/c/09bdeedc1fc53e64b8282e1de67752c69e43bdba
- https://git.kernel.org/stable/c/1a5d1474026ea4f1a6f931075ca2adb884af39cf
- https://git.kernel.org/stable/c/22d8424913b1348c6324916745fadaeea5273f0e
- https://git.kernel.org/stable/c/46e5ce63924a96af452c4fc5ee0bb3b241e1b9f4
- https://git.kernel.org/stable/c/47e393061049aff6818d1b9fdca7351411a23fc2
- https://git.kernel.org/stable/c/883f1d52a57bf51e1d7a80c432345e2c6222477e
- https://git.kernel.org/stable/c/ca75f6f7c6f89365e40f10f641b15981b1f07c31
Modified: 2025-03-24
CVE-2022-49489
In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag]
- https://git.kernel.org/stable/c/134760263f6441741db0b2970e7face6b34b6d1c
- https://git.kernel.org/stable/c/5b0adf5cbf3b74721e4e4c4e0cadc91b8df8bcc2
- https://git.kernel.org/stable/c/97ac682b6f7d36be5d934f86c9911066540a68f1
- https://git.kernel.org/stable/c/aa4cb188988dc6f1b3f4917d4dbc452150a5d871
- https://git.kernel.org/stable/c/ef10d0c68e8608848cd58fca2589685718426607
- https://git.kernel.org/stable/c/ef4bdaac7cb5416f236613ed9337ff0ea8ee329b
- https://git.kernel.org/stable/c/fa5186b279ecf44b14fb435540d2065be91cb1ed
Modified: 2025-10-22
CVE-2022-49490
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Patchwork: https://patchwork.freedesktop.org/patch/485179/
- https://git.kernel.org/stable/c/04bef5f1ba8ea6d7c1c8f5f65e0395c62db59cb8
- https://git.kernel.org/stable/c/19964dfb39bda4d7716a71009488f0668ecbcf52
- https://git.kernel.org/stable/c/33dc5aac46e0fad8f5eb193e5906ed0eb6b66ceb
- https://git.kernel.org/stable/c/49dc28b4b2e28ef7564e355c91487996c1cbebd7
- https://git.kernel.org/stable/c/776f5c58bfe16cf322d71eeed3c5dda1eeac7e6b
- https://git.kernel.org/stable/c/b2aa2c4efe93e2580d6a8774b04fe2b99756a322
- https://git.kernel.org/stable/c/d59be579fa932c46b908f37509f319cbd4ca9a68
Modified: 2025-10-01
CVE-2022-49491
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref.
- https://git.kernel.org/stable/c/3451852312303d54a003c73bd0ae39cebb960bd5
- https://git.kernel.org/stable/c/452922955df215a417c80d09dab72bbc667a1861
- https://git.kernel.org/stable/c/6ff986e057bf28e2f7690dad410768b2270f9453
- https://git.kernel.org/stable/c/769c53bb6116d0eaec0f1fe4ec4b27a74465cad1
- https://git.kernel.org/stable/c/a9b4599665e437de8a1152799c34841b799a2e1c
- https://git.kernel.org/stable/c/b54926bd558d97c888c3d2d87886f3c159d3254a
- https://git.kernel.org/stable/c/ecfa52654d0c9c333c1fe1611f47105f6bce9591
- https://git.kernel.org/stable/c/f8c242908ad15bbd604d3bcb54961b7d454c43f8
- https://git.kernel.org/stable/c/fcd6a886443730c39170b8383411e52118aec0a3
Modified: 2025-10-01
CVE-2022-49492
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference.
- https://git.kernel.org/stable/c/54a4c1e47d1b2585e74920399455bd9abbfb2bd7
- https://git.kernel.org/stable/c/7a28556082d1fbcbc599baf1c24252dfc73efefc
- https://git.kernel.org/stable/c/8321b17789f614414206af07e17ce4751c95dc76
- https://git.kernel.org/stable/c/8da2b7bdb47e94bbc4062a3978c708926bcb022c
- https://git.kernel.org/stable/c/906c81dba8ee8057523859b5e1a2479e9fd34860
- https://git.kernel.org/stable/c/9e649471b396fa0139d53919354ce1eace9b9a24
- https://git.kernel.org/stable/c/af98940dd33c9f9e1beb4f71c0a39260100e2a65
- https://git.kernel.org/stable/c/da42761181627e9bdc37d18368b827948a583929
- https://git.kernel.org/stable/c/f76729662650cd7bc8f8194e057af381370349a7
Modified: 2025-09-03
CVE-2022-49493
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix errorenous cleanup order There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync.
- https://git.kernel.org/stable/c/061a6159cea583f1155f67d1915917a6b9282662
- https://git.kernel.org/stable/c/0941150100173d4eaf3fe08ff4b16740e7c3026f
- https://git.kernel.org/stable/c/1a5a3dfd9f172dcb115072f0aea5e27d3083c20e
- https://git.kernel.org/stable/c/236d29c5857f02e0a53fdf15d3dce1536c4322ce
- https://git.kernel.org/stable/c/2def44d3aec59e38d2701c568d65540783f90f2f
- https://git.kernel.org/stable/c/453f0920ffc1a28e28ddb9c3cd5562472b2895b0
- https://git.kernel.org/stable/c/88c09e4812d72c3153afc8e5a45ecac2d0eae3ff
- https://git.kernel.org/stable/c/abe7554da62cb489712a54de69ef5665c250e564
Modified: 2025-10-01
CVE-2022-49495
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/
- https://git.kernel.org/stable/c/0978fcce91b90b561b8c82e7c492ba9fc8440eef
- https://git.kernel.org/stable/c/2b3ed7547b1a052209da6c4ab886ffe0eed88c42
- https://git.kernel.org/stable/c/4cd66a8016b872a153bf892fe4258cbc0dacf5b1
- https://git.kernel.org/stable/c/6369dda4a2209142ab819f01d3d2076d81e3ebdd
- https://git.kernel.org/stable/c/9cb1ee33efccb8b107ee04b7b3441820de3fd2da
- https://git.kernel.org/stable/c/9f5495a5c51c1d11c6ffc13aa2befffec0c2651a
- https://git.kernel.org/stable/c/a36e506711548df923ceb7ec9f6001375be799a5
- https://git.kernel.org/stable/c/c1bfacf0daf25a5fc7d667399d6ff2dffda84cd8
- https://git.kernel.org/stable/c/d9cb951d11a4ace4de5c50b1178ad211de17079e
Modified: 2025-10-21
CVE-2022-49503
In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()'
- https://git.kernel.org/stable/c/0bcb528402cd5e1a6e1833e956fd58a12d509e8e
- https://git.kernel.org/stable/c/2326d398ccd41ba6d93b8346532dfa432ab00fee
- https://git.kernel.org/stable/c/2dc509305cf956381532792cb8dceef2b1504765
- https://git.kernel.org/stable/c/3dad3fed5672828c7fb0465cb66a3d9a70952fa6
- https://git.kernel.org/stable/c/461e4c1f199076275f16bf6f3d3e42c6b6c79f33
- https://git.kernel.org/stable/c/4bdcf32c965c27f55ccc4ee71c1927131115b0bb
- https://git.kernel.org/stable/c/7f6defe0fabc79f29603c6fa3c80e4fe0456a3e9
- https://git.kernel.org/stable/c/a048e0c3caa852397b7b50d4c82a0415c05f7ac3
- https://git.kernel.org/stable/c/eda518db7db16c360bc84379d90675650daa3048
Modified: 2025-03-24
CVE-2022-49505
In the Linux kernel, the following vulnerability has been resolved:
NFC: NULL out the dev->rfkill to prevent UAF
Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
assumes the device_is_registered() in function nfc_dev_up() will help
to check when the rfkill is unregistered. However, this check only
take effect when device_del(&dev->dev) is done in nfc_unregister_device().
Hence, the rfkill object is still possible be dereferenced.
The crash trace in latest kernel (5.18-rc2):
[ 68.760105] ==================================================================
[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750
[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313
[ 68.760756]
[ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4
[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 68.760756] Call Trace:
[ 68.760756]
- https://git.kernel.org/stable/c/1632be63862f183cd5cf1cc094e698e6ec005dfd
- https://git.kernel.org/stable/c/1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9
- https://git.kernel.org/stable/c/2a1b5110c95e4d49c8c3906270dfcde680a5a7be
- https://git.kernel.org/stable/c/4a68938f43b7c2663e4c90bb9bbe29ac8b9a42a0
- https://git.kernel.org/stable/c/4f5d71930f41be78557f9714393179025baacd65
- https://git.kernel.org/stable/c/6abfaca8711803d0d7cc8c0fac1070a88509d463
- https://git.kernel.org/stable/c/a8e03bcad52dc9afabf650fdbad84f739cec9efa
- https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf
- https://git.kernel.org/stable/c/fbf9c4c714d3cdeb98b6a18e4d057f931cad1d81
Modified: 2025-10-01
CVE-2022-49508
In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails).
- https://git.kernel.org/stable/c/1af20714fedad238362571620be0bd690ded05b6
- https://git.kernel.org/stable/c/24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47
- https://git.kernel.org/stable/c/5291451851feeb66fd4bf0826710f482f3b1ab38
- https://git.kernel.org/stable/c/6d0726725c7c560495f5ff364862a2cefea542e3
- https://git.kernel.org/stable/c/8bb1716507ebf12d50bbf181764481de3b6bc7fd
- https://git.kernel.org/stable/c/c92ec22a991778a096342cf1a917ae36c5c86a90
- https://git.kernel.org/stable/c/f1d4f19a796551edc6679a681ea1756b8c578c08
Modified: 2025-10-01
CVE-2022-49514
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe Call of_node_put(platform_node) to avoid refcount leak in the error path.
- https://git.kernel.org/stable/c/0a1901f34f775b83ea4b8dbb5ed992147b9b8531
- https://git.kernel.org/stable/c/1e932aba3c7628c9f880ee9c2cfcc2ae3ba0c01e
- https://git.kernel.org/stable/c/23f340ed906c758cec6527376768e3bc1474ac30
- https://git.kernel.org/stable/c/48889eb3cce91d7f58e02bc07277b7f724b7a54a
- https://git.kernel.org/stable/c/4f4e0454e226de3bf4efd7e7924d1edc571c52d5
- https://git.kernel.org/stable/c/98d5afe868df998b0244f4c229ab758b4083684a
- https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6
- https://git.kernel.org/stable/c/ebd5cb4f1f3f10b839e7575219e0f17b60c23113
- https://git.kernel.org/stable/c/fb66e0512e5ccc093070e21cf88cce8d98c181b5
Modified: 2025-10-01
CVE-2022-49517
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/05654431a18fe24e5e46a375d98904134628a102
- https://git.kernel.org/stable/c/318afb1442eeef089fe7f8a8297d97c0302ff6f6
- https://git.kernel.org/stable/c/61a85a20e8df5e0a92cfe169c92425c7bae0753b
- https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912
- https://git.kernel.org/stable/c/94587aa17abf8b26f543d2b29c44abc21bc36836
- https://git.kernel.org/stable/c/bc2afecaabd2a2c9f17e43b4793a30e3461bfb29
- https://git.kernel.org/stable/c/c71494f5f2b444adfd992a7359a0d2a791642b39
- https://git.kernel.org/stable/c/f279c49f17ce10866087ea6c0c57382158974b63
Modified: 2025-03-24
CVE-2022-49524
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: Fix the error handling in cx23885_initdev() When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask().
- https://git.kernel.org/stable/c/453514a874c78df1e7804e6e3aaa60c8d8deb6a8
- https://git.kernel.org/stable/c/6041d1a0365baa729b6adfb6ed5386d9388018db
- https://git.kernel.org/stable/c/7b9978e1c94e569d65a0e7e719abb9340f5db4a0
- https://git.kernel.org/stable/c/86bd6a579c6c60547706cabf299cd2c9feab3332
- https://git.kernel.org/stable/c/98106f100f50c487469903b9cf6d966785fc9cc3
- https://git.kernel.org/stable/c/ca17e7a532d1a55466cc007b3f4d319541a27493
- https://git.kernel.org/stable/c/e8123311cf06d7dae71e8c5fe78e0510d20cd30b
- https://git.kernel.org/stable/c/fa636e9ee4442215cd9a2e079cd5a8e1fe0cb8ba
Modified: 2025-10-21
CVE-2022-49525
In the Linux kernel, the following vulnerability has been resolved:
media: cx25821: Fix the warning when removing the module
When removing the module, we will get the following warning:
[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'
[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0
[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0
[ 14.759589] Call Trace:
[ 14.759792]
- https://git.kernel.org/stable/c/005fd553f5f10fe8618d92f94ad10f9051eac331
- https://git.kernel.org/stable/c/1f0fc1dfb5fdd456657519a97fab83691b96c6a0
- https://git.kernel.org/stable/c/2203436a4d24302871617373a7eb21bc17e38762
- https://git.kernel.org/stable/c/222292930c8ecc3516e03ec1f9fa8448be7ff496
- https://git.kernel.org/stable/c/258639bc55a586ee6df92d89786ccf1c71546d70
- https://git.kernel.org/stable/c/3f94169affa33c9db4a439d88f09cb2ed3a33332
- https://git.kernel.org/stable/c/4d6295b6d986476232332fffd08575b185f90d81
- https://git.kernel.org/stable/c/5beb85ff7d005ddb7bf604a4f2dc76f01b84b318
- https://git.kernel.org/stable/c/9d92291698e5cc35a2b8a1106a01ddd7d60ade2d
Modified: 2025-10-21
CVE-2022-49526
In the Linux kernel, the following vulnerability has been resolved: md/bitmap: don't set sb values if can't pass sanity check If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed. How to trigger: (faulty injection) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
- https://git.kernel.org/stable/c/0959aa00f9765bd8c654b1365012e41b51c733cc
- https://git.kernel.org/stable/c/27f672af28a8e9b783ff7f0eaf7ef2fbd5a2f4ba
- https://git.kernel.org/stable/c/422e8f7ba1e08c8e0e88d375bcb550bc2bbfe96d
- https://git.kernel.org/stable/c/cf9392282a2cf5a8d83dd1c5aa1a097e12f172bc
- https://git.kernel.org/stable/c/d8f1558e1daf54f53a90b4c5700ae3e3a4b13412
- https://git.kernel.org/stable/c/e68cb83a57a458b01c9739e2ad9cb70b04d1e6d2
- https://git.kernel.org/stable/c/e69e93120f6219b9cc4fba3b515b6ababd8548aa
Modified: 2025-10-01
CVE-2022-49527
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: avoid null dereference in deinit If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary.
- https://git.kernel.org/stable/c/0ac84ab50712879eac3c1dd2598440652a85d3d0
- https://git.kernel.org/stable/c/0ed5a643b1a4a46b9b7bfba5d468c10cc30e1359
- https://git.kernel.org/stable/c/2533acb652359c9e097dfa33587896af782e8a91
- https://git.kernel.org/stable/c/27ad46da44177a78a4a0cae6fe03906888c61aa1
- https://git.kernel.org/stable/c/86594f6af867b5165d2ba7b5a71fae3a5961e56c
- https://git.kernel.org/stable/c/9c385b961d4c378228e80f6abea8509cb67feab6
- https://git.kernel.org/stable/c/a21d15dde21d7e8ae047eb8368677407db45d840
- https://git.kernel.org/stable/c/b73ed0510bb8d9647cd8e8a4c4c8772bbe545c3a
Modified: 2025-10-01
CVE-2022-49530
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix double free in si_parse_power_table() In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated.
- https://git.kernel.org/stable/c/2615464854505188f909d0c07c37a6623693b5c7
- https://git.kernel.org/stable/c/43eb9b667b95f2a31c63e8949b0d2161b9be59c3
- https://git.kernel.org/stable/c/6c5bdaa1325be7f04b79ea992ab216739192d342
- https://git.kernel.org/stable/c/a5ce7051db044290b1a95045ff03c249005a3aa4
- https://git.kernel.org/stable/c/af832028af6f44c6c45645757079c4ed6884ade5
- https://git.kernel.org/stable/c/c0e811c4ccf3b42705976285e3a94cc82dea7300
- https://git.kernel.org/stable/c/ca1ce206894dd976275c78ee38dbc19873f22de9
- https://git.kernel.org/stable/c/f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd
- https://git.kernel.org/stable/c/fd2eff8b9dcbe469c3b7bbbc7083ab5ed94de07b
Modified: 2025-10-01
CVE-2022-49532
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218
- https://git.kernel.org/stable/c/0f8bc147a963686b7351aa35d1701124ffacac08
- https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e9846957402
- https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c
- https://git.kernel.org/stable/c/848dd072744ea662ab3097e3c8282bee552df218
- https://git.kernel.org/stable/c/c51d00472fa54b9b05c17789ed665c17adf3a25d
- https://git.kernel.org/stable/c/e0828456578cc8ba0a69147f7ae3428392eec287
- https://git.kernel.org/stable/c/edafcad84c4134ebec4bc24b29ca4497a1184eea
- https://git.kernel.org/stable/c/f85cb059fad03a3b33a50023be91e944bb065ae8
- https://git.kernel.org/stable/c/fadc626cae99aaa1325094edc6a9e2b883f3e562
Modified: 2025-10-01
CVE-2022-49538
In the Linux kernel, the following vulnerability has been resolved: ALSA: jack: Access input_dev under mutex It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock.
- https://git.kernel.org/stable/c/1b6a6fc5280e97559287b61eade2d4b363e836f2
- https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348
- https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5
- https://git.kernel.org/stable/c/74bab3bcf422593c582e47130aa8eb41ebb2dc09
- https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879
- https://git.kernel.org/stable/c/9e6a73b0c0f2014eb89249fb1640c5a3d58221c4
- https://git.kernel.org/stable/c/c093b62c40027c21d649c5534ad7aa3605a99b00
- https://git.kernel.org/stable/c/e2b8681769f6e205382f026b907d28aa5ec9d59a
- https://git.kernel.org/stable/c/f68bed124c7699e23ffb4ce4fcc84671e9193cde
Modified: 2025-10-01
CVE-2022-49544
In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference
- https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21
- https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd
- https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882
- https://git.kernel.org/stable/c/528d2023ccf4748fd542582955236c1634a7d293
- https://git.kernel.org/stable/c/5f7ea274e88c0eeffe6bd6dbf6cf5c479d356af6
- https://git.kernel.org/stable/c/8fb1b9beb085bb767ae43e441db5ac6fcd66a04d
- https://git.kernel.org/stable/c/98d1dc32f890642476dbb78ed3437a456bf421b0
- https://git.kernel.org/stable/c/b4628e0d3754ab2fc98ee6e3d21851ba45798077
- https://git.kernel.org/stable/c/e8366bbabe1d207cf7c5b11ae50e223ae6fc278b
Modified: 2025-10-01
CVE-2022-49652
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in to fix this.
- https://git.kernel.org/stable/c/37147e22cd8dfc0412495cb361708836157a4486
- https://git.kernel.org/stable/c/3bd66010398871807c1cebacee07d60ded1b1402
- https://git.kernel.org/stable/c/452b9dfd7aca96befce22634fadb111737f22bbe
- https://git.kernel.org/stable/c/61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc
- https://git.kernel.org/stable/c/b31ab132561c7f1b6459039152b8d09e44eb3565
- https://git.kernel.org/stable/c/b5a817f8d62e9e13280928f3756e54854ae4962e
- https://git.kernel.org/stable/c/c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a
- https://git.kernel.org/stable/c/cb9813d7eae917acd34436160a278b8b5d48ca53
Modified: 2025-10-01
CVE-2022-49656
In the Linux kernel, the following vulnerability has been resolved: ARM: meson: Fix refcount leak in meson_smp_prepare_cpus 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/2e1bcd33478ef44e63a45457055060b5fe4118ad
- https://git.kernel.org/stable/c/34d2cd3fccced12b958b8848e3eff0ee4296764c
- https://git.kernel.org/stable/c/3cf8ece9113242c10f83c7675ea4f4f67959ee43
- https://git.kernel.org/stable/c/3d90607e7e6afa89768b0aaa915b58bd2b849276
- https://git.kernel.org/stable/c/7208101ded1e9dcc52c8f0f8b16474211c871c1a
- https://git.kernel.org/stable/c/c5fbf4f74c94fd60d5e9bf9f7f8268c3601562ca
Modified: 2025-10-01
CVE-2022-49657
In the Linux kernel, the following vulnerability has been resolved: usbnet: fix memory leak in error case usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf pointer
- https://git.kernel.org/stable/c/0085da9df3dced730027923a6b48f58e9016af91
- https://git.kernel.org/stable/c/04894ab34faf40ab72a8a5ab5b404bb0606bbbff
- https://git.kernel.org/stable/c/3eed421ca5c809da93456f69203d164d5220be3d
- https://git.kernel.org/stable/c/5269209f54dd8dfd15f9383f3a3a1fe8370764f8
- https://git.kernel.org/stable/c/b55a21b764c1e182014630fa5486d717484ac58f
- https://git.kernel.org/stable/c/d5165e657987ff4ba0ace896d4376a3718a9fbc3
- https://git.kernel.org/stable/c/db89582ff330556188da856e01382ccbf3a5e706
- https://git.kernel.org/stable/c/e7b4f69946a38209b4a4f660bf0e4cbed94f9b4b
Modified: 2025-10-23
CVE-2022-49661
In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_open/close(): fix memory leak The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver. This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2. For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak").
- https://git.kernel.org/stable/c/0e60230bc64355c80abe993d1719fdb318094e20
- https://git.kernel.org/stable/c/2bda24ef95c0311ab93bda00db40486acf30bd0a
- https://git.kernel.org/stable/c/339fa9f80d3b94177a7a459c6d115d3b56007d5a
- https://git.kernel.org/stable/c/6f655b5e13fa4b27e915b6c209ac0da74fd75963
- https://git.kernel.org/stable/c/c1d806bc29ff7ffe0e2a023583c8720ed96cb0b0
- https://git.kernel.org/stable/c/d0b8e223998866b3e7b2895927d4e9689b0a80d8
- https://git.kernel.org/stable/c/d91492638b054f4a359621ef216242be5973ed6b
- https://git.kernel.org/stable/c/ffb6cc6601ec7c8fa963dcf76025df4a02f2cf5c
Modified: 2025-03-24
CVE-2022-49667
In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [ 767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148] __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470
- https://git.kernel.org/stable/c/050133e1aa2cb49bb17be847d48a4431598ef562
- https://git.kernel.org/stable/c/2765749def4765c5052a4c66445cf4c96fcccdbc
- https://git.kernel.org/stable/c/63b2fe509f69b90168a75e04e14573dccf7984e6
- https://git.kernel.org/stable/c/893825289ba840afd86bfffcb6f7f363c73efff8
- https://git.kernel.org/stable/c/a853b7a3a9fd1d74a4ccdd9cd73512b7dace2f1e
- https://git.kernel.org/stable/c/b90ac60303063a43e17dd4aec159067599d255e6
- https://git.kernel.org/stable/c/ef0af7d08d26c5333ff4944a559279464edf6f15
- https://git.kernel.org/stable/c/f162f7c348fa2a5555bafdb5cc890b89b221e69c
Modified: 2025-10-24
CVE-2022-49672
In the Linux kernel, the following vulnerability has been resolved: net: tun: unlink NAPI from device on destruction Syzbot found a race between tun file and device destruction. NAPIs live in struct tun_file which can get destroyed before the netdev so we have to del them explicitly. The current code is missing deleting the NAPI if the queue was detached first.
- https://git.kernel.org/stable/c/3b9bc84d311104906d2b4995a9a02d7b7ddab2db
- https://git.kernel.org/stable/c/8145f77d38de4f88b8a69e1463f5c09ba189d77c
- https://git.kernel.org/stable/c/82e729aee59acefe135fceffadcbc5b86dd4f1b9
- https://git.kernel.org/stable/c/8661d4b8faa2f7ee7a559969c0a7c57f077b1728
- https://git.kernel.org/stable/c/a8cf919022373c97a84fe596bbea544f909c485d
- https://git.kernel.org/stable/c/bec1be0a745ab420718217e3e0d9542a75108989
Modified: 2025-10-24
CVE-2022-49673
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix KASAN warning in raid5_add_disks There's a KASAN warning in raid5_add_disk when running the LVM testsuite. The warning happens in the test lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning by verifying that rdev->saved_raid_disk is within limits.
- https://git.kernel.org/stable/c/02cffb1921edadd9b6e4eee7ada4a5213e8ba12e
- https://git.kernel.org/stable/c/2d4e7c9898c20fb3d3f55381cab601761aab7d64
- https://git.kernel.org/stable/c/2fb2928728038280bd925ce2aafb4997e9d47ee9
- https://git.kernel.org/stable/c/3553a69bb52be2deba61d0ca064c41aee842bb35
- https://git.kernel.org/stable/c/617b365872a247480e9dcd50a32c8d1806b21861
- https://git.kernel.org/stable/c/d5b06039b195d4b6f94f5d345b1e4ac1975a9832
- https://git.kernel.org/stable/c/d8bca518d5272fe349e0a722fdb9e3acb661f3f0
- https://git.kernel.org/stable/c/f157bd9cf377a947fdb7035e69466b6ecdc17c17
Modified: 2025-10-24
CVE-2022-49674
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled).
- https://git.kernel.org/stable/c/332bd0778775d0cf105c4b9e03e460b590749916
- https://git.kernel.org/stable/c/5e161a8826b63c0b8b43e4a7fad1f956780f42ab
- https://git.kernel.org/stable/c/6352b2f4d8e95ec0ae576d7705435d64cfa29503
- https://git.kernel.org/stable/c/90de15357504c8097ab29769dc6852e16281e9e8
- https://git.kernel.org/stable/c/9bf2b0757b04c78dc5d6e3a198acca98457b32a1
- https://git.kernel.org/stable/c/bcff98500ea3b4e7615ec31d2bdd326bc1ef5134
- https://git.kernel.org/stable/c/df1a5ab0dd0775f2ea101c71f2addbc4c0ea0f85
Modified: 2025-10-01
CVE-2022-49677
In the Linux kernel, the following vulnerability has been resolved: ARM: cns3xxx: Fix refcount leak in cns3xxx_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1ba904b6b16e08de5aed7c1349838d9cd0d178c5
- https://git.kernel.org/stable/c/45bebbc8cea7d586a6216dc62814bdb380b9b29b
- https://git.kernel.org/stable/c/68d4303bf59662b64bd555e2aa0518282d20aa4f
- https://git.kernel.org/stable/c/b8b84e01ca94e2e1f5492353e9c24dab520b2e5b
- https://git.kernel.org/stable/c/c980392af1473d6d5662f70d8089c8e6d85144a4
- https://git.kernel.org/stable/c/d1359e4129ad43e43972a28838b87291c51de23d
- https://git.kernel.org/stable/c/da3ee7cd2f15922ad88a7ca6deee2eafdc7cd214
- https://git.kernel.org/stable/c/dc5170aae24e04068fd5ea125d06c0ab51f48a27
Modified: 2025-10-01
CVE-2022-49678
In the Linux kernel, the following vulnerability has been resolved: soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In brcmstb_init_sram, it pass dn to of_address_to_resource(), of_address_to_resource() will call of_find_device_by_node() to take reference, so we should release the reference returned by of_find_matching_node().
- https://git.kernel.org/stable/c/10ba9d499a9fd82ed40897e734ba19870a879407
- https://git.kernel.org/stable/c/30bbfeb480ae8b5ee43199d72417b232590440c2
- https://git.kernel.org/stable/c/37d838de369b07b596c19ff3662bf0293fdb09ee
- https://git.kernel.org/stable/c/4f5877bdf7b593e988f1924f4c3df6523f80b39c
- https://git.kernel.org/stable/c/734a4d15142bb4c8ecad2d8ec70d7564e78ae34d
- https://git.kernel.org/stable/c/dcafd5463d8f20c4f90ddc138a5738adb99f74c8
Modified: 2025-10-01
CVE-2022-49679
In the Linux kernel, the following vulnerability has been resolved: ARM: Fix refcount leak in axxia_boot_secondary of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/29ca9c4efacccdc15104a8d4bf10b5183fc92840
- https://git.kernel.org/stable/c/3c19fe3f04f4f4e7a2b722c2fd3c98356fc1d72b
- https://git.kernel.org/stable/c/44a5b3a073e5aaa5720929dba95b2725eb32bb65
- https://git.kernel.org/stable/c/4d9c60e868f7cf8e09956e7d5bb44d807d712699
- https://git.kernel.org/stable/c/71e12e5b02674459a24f16e965255d63b31fe049
- https://git.kernel.org/stable/c/7c7ff68daa93d8c4cdea482da4f2429c0398fcde
- https://git.kernel.org/stable/c/a9b76c232a1ce4cbf27862097f7eb634dcc779eb
- https://git.kernel.org/stable/c/b385cb59aac8d61c29bc72ebf3d19a536914af96
Modified: 2025-10-01
CVE-2022-49680
In the Linux kernel, the following vulnerability has been resolved: ARM: exynos: Fix refcount leak in exynos_map_pmu of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer.
- https://git.kernel.org/stable/c/31d09571bb071c20f6bdc0bb7ac1ef8dd2987c04
- https://git.kernel.org/stable/c/545ae5cbae839ce39bfe09828e413f1c916082de
- https://git.kernel.org/stable/c/68f28d52e6cbab8dcfa249cac4356d1d0573e868
- https://git.kernel.org/stable/c/7571bcecf01b69f0d3ec60ca41ce5d4c75411a4a
- https://git.kernel.org/stable/c/c4c79525042a4a7df96b73477feaf232fe44ae81
- https://git.kernel.org/stable/c/d23f76018e17618559da9eea179d137362023f95
- https://git.kernel.org/stable/c/f9b77a52937582a5b99a5a07e4ef1e2f48f87347
- https://git.kernel.org/stable/c/fc354856e9fad9cd36e2ad28f9da70716025055a
Modified: 2025-10-01
CVE-2022-49681
In the Linux kernel, the following vulnerability has been resolved: xtensa: xtfpga: Fix refcount leak bug in setup In machine_setup(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0162451723178602c37f0555d235dfa17e486112
- https://git.kernel.org/stable/c/0715d0e60052662c3f225342062f174dd721d1c7
- https://git.kernel.org/stable/c/173940b3ae40114d4179c251a98ee039dc9cd5b3
- https://git.kernel.org/stable/c/35d7e961be68732eb3acaeba81fb81ca16eafd05
- https://git.kernel.org/stable/c/6c0839cf1b9e1b3c88da6af76794583cbfae8da3
- https://git.kernel.org/stable/c/9b30c5c8884eda3f541229899671cebbad15979b
- https://git.kernel.org/stable/c/a52972ee706b438302eb0350e61f378eb191e3d1
- https://git.kernel.org/stable/c/b12d5c52f073a0420622aaf2f21b615cce8b36cc
Modified: 2025-10-01
CVE-2022-49682
In the Linux kernel, the following vulnerability has been resolved: xtensa: Fix refcount leak bug in time.c In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0dcc1dd8a5dd9240639f1051dfaa2dffc9fbbde5
- https://git.kernel.org/stable/c/0e403a383c14b63c86bd9df085b7e573e9caee64
- https://git.kernel.org/stable/c/3e5eb904d9ba657308fc75a5de434b0e58dcb8d7
- https://git.kernel.org/stable/c/7de4502af68f4f3932f450157f5483eb7b33cb74
- https://git.kernel.org/stable/c/a0117dc956429f2ede17b323046e1968d1849150
- https://git.kernel.org/stable/c/af0ff2da01521144bc11194f4c26485d7c9cee73
- https://git.kernel.org/stable/c/e5234a9d64a976abd134a14710dcd5188158a7c5
- https://git.kernel.org/stable/c/f1eaf4ba5372ad111f687a80c67e270708e14c23
Modified: 2025-03-24
CVE-2022-49685
In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix use-after-free on remove Ensure that the irq_work has completed before the trigger is freed. ================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25 Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write ==================================================================
- https://git.kernel.org/stable/c/31ff3309b47d98313c61b8301bf595820cc3cc33
- https://git.kernel.org/stable/c/4687c3f955240ca2a576bdc3f742d4d915b6272d
- https://git.kernel.org/stable/c/4ef1e521be610b720daeb7cf899fedc7db0274c4
- https://git.kernel.org/stable/c/5e39397d60dacc7f5d81d442c1c958eaaaf31128
- https://git.kernel.org/stable/c/78601726d4a59a291acc5a52da1d3a0a6831e4e8
- https://git.kernel.org/stable/c/b07a30a774b3c3e584a68dc91779c68ea2da4813
- https://git.kernel.org/stable/c/d6111e7bdb8ec27eb43d01c4cd4ff1620a75f7f2
- https://git.kernel.org/stable/c/fd5d8fb298a2866c337da635c79d63c3afabcaf7
Modified: 2026-01-22
CVE-2022-49687
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix xdp_rxq_info bug after suspend/resume
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
- https://git.kernel.org/stable/c/340fbdc8011f2dc678f622c5ce1cbb5ab8305de7
- https://git.kernel.org/stable/c/57ee40f1b198b59d43c216fbc4672f9300d3c8b0
- https://git.kernel.org/stable/c/8af52fe9fd3bf5e7478da99193c0632276e1dfce
- https://git.kernel.org/stable/c/8c7a32b7c15555beddc5810c3334d9cefff061bf
- https://git.kernel.org/stable/c/8d7fe9ad6fddc2af8bde4b921b4f8fab231ed38c
- https://git.kernel.org/stable/c/9222672fa6370f0ec3d899662cb8680e9282fc4c
Modified: 2025-10-24
CVE-2022-49688
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix dynamic root getattr
The recent patch to make afs_getattr consult the server didn't account
for the pseudo-inodes employed by the dynamic root-type afs superblock
not having a volume or a server to access, and thus an oops occurs if
such a directory is stat'd.
Fix this by checking to see if the vnode->volume pointer actually points
anywhere before following it in afs_getattr().
This can be tested by stat'ing a directory in /afs. It may be
sufficient just to do "ls /afs" and the oops looks something like:
BUG: kernel NULL pointer dereference, address: 0000000000000020
...
RIP: 0010:afs_getattr+0x8b/0x14b
...
Call Trace:
- https://git.kernel.org/stable/c/2b2bba96526f25f2eba74ecadb031de2e05a83ce
- https://git.kernel.org/stable/c/65c24caf1b9f5b08397c6e805ec24ebc390c6e4d
- https://git.kernel.org/stable/c/7844ceada44eca740d31beb3d97b8511b1ca0a9b
- https://git.kernel.org/stable/c/7b564e3254b7db5fbfbf11a824627a6c31b932b4
- https://git.kernel.org/stable/c/cb78d1b5efffe4cf97e16766329dd7358aed3deb
- https://git.kernel.org/stable/c/e3a232e5767051483ffad4cef7d0a89d292a192b
Modified: 2025-10-24
CVE-2022-49691
In the Linux kernel, the following vulnerability has been resolved:
erspan: do not assume transport header is always set
Rewrite tests in ip6erspan_tunnel_xmit() and
erspan_fb_xmit() to not assume transport header is set.
syzbot reported:
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Modules linked in:
CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00
RSP: 0018:ffffc90005daf910 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003
RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40
R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000
FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0
Call Trace:
- https://git.kernel.org/stable/c/02da602bc2f353dccd9e489a604490034ded941e
- https://git.kernel.org/stable/c/2c8aeffc7c586d53e1d380f010bdca4f710f2480
- https://git.kernel.org/stable/c/301bd140ed0b24f0da660874c7e8a47dad8c8222
- https://git.kernel.org/stable/c/a3b2470399f679587c45abe56e551caf10becca2
- https://git.kernel.org/stable/c/cec9867ee55478ef5dcb2adf030fe0c442a4c4ee
- https://git.kernel.org/stable/c/fb401f37f6eadf24956d93687e5758c163c0d12b
Modified: 2025-03-25
CVE-2022-49700
In the Linux kernel, the following vulnerability has been resolved: mm/slub: add missing TID updates on slab deactivation The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab. If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects. (I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...) The race leading to state inconsistency is (all operations on the same CPU and kmem_cache): - task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu_ptr() (enables preemption) - [PREEMPT B->A] - task A: finish do_slab_free(): - this_cpu_cmpxchg_double() succeeds() - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL] From there, the object on c->freelist will get lost if task B is allowed to continue from here: It will proceed to the retry_load_slab label, set c->slab, then jump to load_freelist, which clobbers c->freelist. But if we instead continue as follows, we get worse corruption: - task A: run __slab_free() on object from other struct slab: - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial) - task A: run slab_alloc_node() with NUMA node constraint: - fastpath fails (c->slab is NULL) - call __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - c->slab is NULL: goto new_slab - slub_percpu_partial() is non-NULL - set c->slab to slub_percpu_partial(c) - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects from slab-2] - goto redo - node_match() fails - goto deactivate_slab - existing c->freelist is passed into deactivate_slab() - inuse count of slab-1 is decremented to account for object from slab-2 At this point, the inuse count of slab-1 is 1 lower than it should be. This means that if we free all allocated objects in slab-1 except for one, SLUB will think that slab-1 is completely unused, and may free its page, leading to use-after-free.
- https://git.kernel.org/stable/c/0515cc9b6b24877f59b222ade704bfaa42caa2a6
- https://git.kernel.org/stable/c/197e257da473c725dfe47759c3ee02f2398d8ea5
- https://git.kernel.org/stable/c/308c6d0e1f200fd26c71270c6e6bfcf0fc6ff082
- https://git.kernel.org/stable/c/6c32496964da0dc230cea763a0e934b2e02dabd5
- https://git.kernel.org/stable/c/d6a597450e686d4c6388bd3cdcb17224b4dae7f0
- https://git.kernel.org/stable/c/e2b2f0e2e34d71ae6c2a1114fd3c525930e84bc7
- https://git.kernel.org/stable/c/e7e3e90d671078455a3a08189f89d85b3da2de9e
- https://git.kernel.org/stable/c/eeaa345e128515135ccb864c04482180c08e3259
Modified: 2025-10-01
CVE-2022-49707
In the Linux kernel, the following vulnerability has been resolved:
ext4: add reserved GDT blocks check
We capture a NULL pointer issue when resizing a corrupt ext4 image which
is freshly clear resize_inode feature (not run e2fsck). It could be
simply reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
not reduced to zero, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.
mkfs.ext4 /dev/sda 3G
tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
mount /dev/sda /mnt
resize2fs /dev/sda 8G
========
BUG: kernel NULL pointer dereference, address: 0000000000000028
CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
...
RIP: 0010:ext4_flex_group_add+0xe08/0x2570
...
Call Trace:
- https://git.kernel.org/stable/c/0dc2fca8e4f9ac4a40e8424a10163369cca0cc06
- https://git.kernel.org/stable/c/33b1bba31f4c784d33d2c2517964bdccdc9204cd
- https://git.kernel.org/stable/c/7c921328ac760bba780bdace41f4cd045f7f1405
- https://git.kernel.org/stable/c/af75c481a2e45e70f62f5942c93695e95bf7bd21
- https://git.kernel.org/stable/c/b55c3cd102a6f48b90e61c44f7f3dda8c290c694
- https://git.kernel.org/stable/c/b9747263b13e5290ac4d63bec47e38f701303cad
- https://git.kernel.org/stable/c/bfd004a1d3a062aac300523d406ac1f3e5f1a82c
- https://git.kernel.org/stable/c/fba54289176702a7caac0b64738406775817f451
Modified: 2025-10-24
CVE-2022-49708
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on ext4_mb_use_inode_pa Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f [...] Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0 [...] ================================================================== Above issue may happen as follows: ------------------------------------- do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0); we can easily reproduce this problem with the following commands: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1` The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP. Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur when the size is truncated. So start should be the start position of the group where ac_o_ex.fe_logical is located after alignment. In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP is very large, the value calculated by start_off is more accurate.
- https://git.kernel.org/stable/c/5707d721d1819db57dba57b1d4623034fcb32047
- https://git.kernel.org/stable/c/6880fb2e64331b9fdc85d3f32b1d7e81ad8703f1
- https://git.kernel.org/stable/c/6fdaf31ad5f3d3afab744dfd9a8b0d9142aa881f
- https://git.kernel.org/stable/c/887a3e9ad4b8309a2266bce7ae749b2bf1f7a687
- https://git.kernel.org/stable/c/90f0f9d45dff0128c0fca0d2358c4153b024afa6
- https://git.kernel.org/stable/c/a08f789d2ab5242c07e716baf9a835725046be89
- https://git.kernel.org/stable/c/a37c1359714da42517dd19d36fc3c4d17edba832
- https://git.kernel.org/stable/c/a6b31616e5afe1d3972cb0682a373e50597faf5c
Modified: 2025-10-01
CVE-2022-49712
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer.
- https://git.kernel.org/stable/c/0ef6917c0524da5b88496b9706628ffef108b9bb
- https://git.kernel.org/stable/c/2a598da14856ead80c726b38ba426c68637d9211
- https://git.kernel.org/stable/c/46da1e4a8b6329479433b2a4056941dfdd7f3efd
- https://git.kernel.org/stable/c/4757c9ade34178b351580133771f510b5ffcf9c8
- https://git.kernel.org/stable/c/57901c658f77d9ea2e772f35cb38e47efb54c558
- https://git.kernel.org/stable/c/727c82d003e0ec64411fd1257a9a57de4ad7a99a
- https://git.kernel.org/stable/c/b75bddfcc18170ce8e3fb695a76ec2dec4ce0ea5
- https://git.kernel.org/stable/c/d85e4e6284a91aa2d1ab004e9d84b9c09b4aa203
Modified: 2025-10-01
CVE-2022-49713
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix memory leak in dwc2_hcd_init usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 to fix this.
- https://git.kernel.org/stable/c/3755278f078460b021cd0384562977bf2039a57a
- https://git.kernel.org/stable/c/52bfcedbfd5bf962dbdcb6e761f4d0dd3ba26dfd
- https://git.kernel.org/stable/c/6506aff2dc2f7059aa3d45ee2e8639b25e87090f
- https://git.kernel.org/stable/c/701d8ec01e0f229d4db6f43d3d64ee479120cbeb
- https://git.kernel.org/stable/c/84e6d0af87e27bbc0db94f2e7323b34abe17b6e5
- https://git.kernel.org/stable/c/981ee40649e5fd9550f82db1fbb3bfab037da346
- https://git.kernel.org/stable/c/a44a8a762f7fe9ad3c065813d058e835a6180cb2
Modified: 2025-10-01
CVE-2022-49715
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/506a88a5bf261d76a5214c0338a320f2214c67ac
- https://git.kernel.org/stable/c/8d884c08eeb83142a7173cb46bcff0434ec42cf1
- https://git.kernel.org/stable/c/c136c2924a59a399aa789858cfb320d481964fb7
- https://git.kernel.org/stable/c/cc5984cf270b69d03f9f4b27063e535036c659e9
- https://git.kernel.org/stable/c/e824482e2c5edacc961b7dd30a92fd47606c3036
- https://git.kernel.org/stable/c/fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b
Modified: 2025-10-01
CVE-2022-49719
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic/realview: Fix refcount leak in realview_gic_of_init of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/16b603cb8d34c2d917983918db1f88c8b831baaa
- https://git.kernel.org/stable/c/486f68f85085d9b16ae097679b1486dcb1b6eb69
- https://git.kernel.org/stable/c/56526c3883fc7a1f5898b1d40a02c8b8685a5d92
- https://git.kernel.org/stable/c/5d38720661a4b9c87705c206a6081177ffb8ec1d
- https://git.kernel.org/stable/c/87da903ce632d5689bef66d56ee5dae700d82104
- https://git.kernel.org/stable/c/b634af84bc1edece4e63317b0ad95618dd3a8693
- https://git.kernel.org/stable/c/e52a58b79f11755ea7e877015c4a1704303fa55f
- https://git.kernel.org/stable/c/f4b98e314888cc51486421bcf6d52852452ea48b
Modified: 2025-10-24
CVE-2022-49724
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Fix free_irq() on remove Pass the correct dev_id to free_irq() to fix this splat when the driver is unbound: WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq Trying to free already-free IRQ 65 Call Trace: warn_slowpath_fmt free_irq goldfish_tty_remove platform_remove device_remove device_release_driver_internal device_driver_detach unbind_store drv_attr_store ...
- https://git.kernel.org/stable/c/499e13aac6c762e1e828172b0f0f5275651d6512
- https://git.kernel.org/stable/c/65ca4db68b6819244df9024aea4be55edf8af1ef
- https://git.kernel.org/stable/c/a6fcd7ffd76a9c1d998a2d02d518c78a55c5bed8
- https://git.kernel.org/stable/c/c4b0b8edccb0cfb15a8cecf4161e0571d3daac64
- https://git.kernel.org/stable/c/c83a1d40dc624070a203eb383ef9fb60eb634136
- https://git.kernel.org/stable/c/f7183c76d500324b8b5bd0af5e663cfa57b7b836
- https://git.kernel.org/stable/c/fb15e79cacddfbc62264e6e807bde50ad688e988
Modified: 2025-10-24
CVE-2022-49725
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix call trace in setup_tx_descriptors After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors. Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash. Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test()
- https://git.kernel.org/stable/c/0a4e5a3dc5e41212870e6043895ae02455c93f63
- https://git.kernel.org/stable/c/15950157e2c24865b696db1c9ccc72743ae0e967
- https://git.kernel.org/stable/c/322271351b0e41565171e4cce70ea41854fac115
- https://git.kernel.org/stable/c/5ba9956ca57e361fb13ea369bb753eb33177acc7
- https://git.kernel.org/stable/c/814092927a215f5ca6c08249ec72a205e0b473cd
- https://git.kernel.org/stable/c/fd5855e6b1358e816710afee68a1d2bc685176ca
- https://git.kernel.org/stable/c/ff6e03fe84bc917bb0c907d02de668c2fe101712
Modified: 2025-10-01
CVE-2022-49727
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max.
- https://git.kernel.org/stable/c/034246122f5c5e2e2a0b9fe04e24517920e9beb1
- https://git.kernel.org/stable/c/0e818d433fc2718fe4da044ffca7431812a7e04e
- https://git.kernel.org/stable/c/27a37755ceb401111ded76810359d3adc4b268a1
- https://git.kernel.org/stable/c/2cf73c7cb6125083408d77f43d0e84d86aed0000
- https://git.kernel.org/stable/c/2f42389d270f2304c8855b0b63498a5a4d0c053d
- https://git.kernel.org/stable/c/6c4e3486d21173d60925ef52e512cae727b43d30
- https://git.kernel.org/stable/c/b8879ca1fd7348b4d5db7db86dcb97f60c73d751
- https://git.kernel.org/stable/c/f638a84afef3dfe10554c51820c16e39a278c915
Modified: 2025-10-01
CVE-2022-49729
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well. Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak. Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.
- https://git.kernel.org/stable/c/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed
- https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee
- https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f
- https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4
- https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d
- https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537
- https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e
- https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c
Modified: 2025-10-01
CVE-2022-49731
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/07cbdb4807d369fbda73062a91b570c4dc5ec429
- https://git.kernel.org/stable/c/1ac5efee33f29e704226506d429b84575a5d66f8
- https://git.kernel.org/stable/c/253334f84c81bc6a43af489f108c0bddad989eef
- https://git.kernel.org/stable/c/36cd19e7d4e5571d77a2ed20c5b6ef50cf57734a
- https://git.kernel.org/stable/c/a810bd5af06977a847d1f202b22d7defd5c62497
- https://git.kernel.org/stable/c/bf476fe22aa1851bab4728e0c49025a6a0bea307
- https://git.kernel.org/stable/c/ca4693e6e06e4fd2b240c0fec47aa2498c94848e
- https://git.kernel.org/stable/c/ff128fbea720bf763fa345680dda5f050bc24a47
Modified: 2023-07-08
GHSA-j4rf-7357-f4cg
Unpatched extfs vulnerabilities are exploitable through suid-mode Apptainer
- https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
- https://nvd.nist.gov/vuln/detail/CVE-2022-1184
- https://nvd.nist.gov/vuln/detail/CVE-2023-30549
- https://github.com/apptainer/apptainer/commit/5a4964f5ba9c8d89a0e353b97f51fd607670a9f7
- https://github.com/torvalds/linux/commit/2220eaf90992c11d888fe771055d4de3303
- https://github.com/torvalds/linux/commit/4f04351888a83e595571de672e0a4a8b74f
- https://github.com/torvalds/linux/commit/61a1d87a324ad5e3ed27c6699dfc93218fcf3201
- https://github.com/torvalds/linux/commit/65f8ea4cd57dbd46ea13b41dc8bac03176b04233
- https://www.suse.com/security/cve/CVE-2022-1184.html
- https://ubuntu.com/security/CVE-2022-1184
- https://sylabs.io/2023/04/response-to-cve-2023-30549
- https://security.gentoo.org/glsa/202311-13
- https://security-tracker.debian.org/tracker/CVE-2022-1184
- https://lwn.net/Articles/932137
- https://lwn.net/Articles/932136
- https://github.com/apptainer/apptainer/releases/tag/v1.1.8
- https://github.com/apptainer/apptainer
- https://access.redhat.com/security/cve/cve-2022-1184
